Изменение синтаксиса это, например, если вместо слова PARSE&TYPE после каких-то переопределений можно будет писать PARSE AND TYPE, при этом это остается одним словом, а не тремя.
Я же говорю, вы смешиваете синтаксис и семантику. Синтаксис по-прежнему простенький и разбирается КА или регулярными выражениями, а вот терминалы могут изменяться динамически по ходу трансляции. В макропроцессоре ровно все то же самое: можно переопределять символы до морковкина заговения. Если посмотреть на тонкие манипуляции с Си-шным препроцессором или с древним, но супермощным M4, то там подобной эзотерики очень много.
Альтернативный вариант — использование макропроцессора поверх более универсального языка, как правило, интерпретирующего. Собственно, по классу грамматики (регулярная) Форт и макропроцессор эквивалентны. Пример для SQL
Несмотря на простоту, в таком подходе есть свои недостатки, поэтому если ресурсы позволяют, то я предпочту написать транслятор КС-грамматики и стековую виртуальную машину исполнения (а ля Форт, кстати).
Ооо, ну, понятно, решили заменить тему «проектирование ЯП» на «да кто их проектирует-то». Это несерьёзно. В свою очередь рекомендую посмотреть на «реально используемые ЯП» вроде SQL, Явы, Сишарпа, не говоря уже о большом Паскаль-семействе. Современный компилятор GNU С использует формальные описания и yacc для построения синтаксического анализатора.
КС-язык вовсе не зависит от «следующего токена», как это присуще регулярной грамматике. В КС общий случай — LR(k)-разбор, когда для принятия решения о свертке нужен предпросмотр k символов. Но скорее соглашусь: языки, созданные «на коленке» чаще всего влезают в LR(1), потому что голова не резиновая, а проектировать не умеем.
Раз уж перешли на личности, да, я разрабатывал трансляторы и не раз видел поделки, сделанные «по наитию». С усложнением языка без формальных моделей не обойтись (в т.ч. для упрощения разбора), каждый раз изучать код и комментарии, восстанавливая картину — это не очень продуктивно, мягко говоря.
Я не совсем понимаю, а проектирование языка у вас где-то присутствует или надо сразу кодировать транслятор? А что у нас на входе автоматических построителей трансляторов, созданных в 1960-е годы (lex/yacc и прочая) и с тех пор мало изменившихся? А как убедиться, что язык получился контекстно-свободным? Фортран же, как вы, надеюсь, знаете, не помещается и потому разбор должен писаться руками. А зачем класс регулярных грамматик, для которых вообще не нужен рекурсивный спуск? Вы и для Форта или макропроцессора собираетесь писать спуск?
Вы извините, но какое-то «зачем нужна география, если есть таксисты» получается.
Не вдаваясь в написанную несуразицу, она как-то опровергает факты, что теория и практика языко- и компиляторостроения процветала на Западе, тогда как в СССР уже в 1960-е в основном передирали готовые грамматики, которые вы так походя зачислили в категорию академических забав?
Не совсем ясно, насколько увеличились расходы при переходе от ежемесячных релизов к ежечасным (при сохранении того же уровня качества, обеспечиваемого тестами разных уровней).
— Hello, excuse… Effel tor.
— Comment?
— Effel To-or
— Je ne comprends pas
— Co… co… (бормотание)
— Ah, la Tour Eiffel! C'est par là!
...
«Le Parisien», il vaut mieux l'avoir en journal
Если знаете 3-4 неродных языка в совершенстве — конечно, приятное исключение :)
Почему именно 3 впридачу к родному? Потому что с 1 и 2 — билингвы и трилингвы, соответственно.
Про мотивацию — совершенно верно. Кроме того, если учить язык в зрелом возрасте, то возникает дискомфорт от деградации: вместо размышлений над смыслами слов приходится их зубрить :)
С образованием был эпизод. Коллега из Египта, когда узнал, что у нас все образование на русском, сначала переваривал этот факт, потом сказал, что круто, нам бы так.
В идеале же хочется один «галактический» язык + локальный для сохранения культур. Голова не бездонная, я пока не встречал полиглотов, владеющих другими сложными знаниями (науки, инженерия, медицина) на профессиональном уровне, обычно они работают в маркетинге, PR, поддержке, где коммуникации составляют основу.
Успешно решал подобную проблему у клиента еще на версии 2005. Они вовремя спохватились, не имея в штате специалистов по СУБД и сделав нагрузочные тесты на ранней стадии. Усеченный пример есть в книжке (в профиле).
именно, что «как бы выполнены». Проблема иерархической модели (к коим относится документ-ориентированная) в необходимости дублирования данных в иерархиях. Или хранить логические ссылки (по коду, ID и т.п.) на другие иерархии с неизбежными соединениями в запросах.
Простейший пример, две иерархии (коллекции в терминах монги) заказов и отгрузок хранят данные о клиентах. Либо дублирование, либо третья иерархия клиентов со ссылками. «Нормализация» в рамках иерархической модели. Привет из 1960-х и от IBM IMS персонально :)
JSON как был легким форматом для сериализации обьектов, так по сути им и остался. Понадобится обеспечение целостности, валидация — пиши код в приложении, языки запросов специфичны для СУБД, стандарты фактически отсутствуют, RFC — предел мечтаний.
XML изначально проектировался для хранения документов, обеспечения целостности и извлечения информации по запросам, стандарт устоялся и щироко используется в корпоративном софтостроении.
Сходство в том, что обе модели основаны на теоретико-графовой иеррхической модели. Но ограничения иерархий тоже известны с 1960-х годов, когда переходили к сетевым и множественным моделям данных.
Более подробно есть в статье "Classification of data models in DBMS" на researchgate и в книжке "СУБД для программиста" (пардон за продакт-плейсмент)
Пример для SQL
Несмотря на простоту, в таком подходе есть свои недостатки, поэтому если ресурсы позволяют, то я предпочту написать транслятор КС-грамматики и стековую виртуальную машину исполнения (а ля Форт, кстати).
pmk.arbinada.com
КС-язык вовсе не зависит от «следующего токена», как это присуще регулярной грамматике. В КС общий случай — LR(k)-разбор, когда для принятия решения о свертке нужен предпросмотр k символов. Но скорее соглашусь: языки, созданные «на коленке» чаще всего влезают в LR(1), потому что голова не резиновая, а проектировать не умеем.
Раз уж перешли на личности, да, я разрабатывал трансляторы и не раз видел поделки, сделанные «по наитию». С усложнением языка без формальных моделей не обойтись (в т.ч. для упрощения разбора), каждый раз изучать код и комментарии, восстанавливая картину — это не очень продуктивно, мягко говоря.
Вы извините, но какое-то «зачем нужна география, если есть таксисты» получается.
— Comment?
— Effel To-or
— Je ne comprends pas
— Co… co… (бормотание)
— Ah, la Tour Eiffel! C'est par là!
...
«Le Parisien», il vaut mieux l'avoir en journal
Почему именно 3 впридачу к родному? Потому что с 1 и 2 — билингвы и трилингвы, соответственно.
С образованием был эпизод. Коллега из Египта, когда узнал, что у нас все образование на русском, сначала переваривал этот факт, потом сказал, что круто, нам бы так.
В идеале же хочется один «галактический» язык + локальный для сохранения культур. Голова не бездонная, я пока не встречал полиглотов, владеющих другими сложными знаниями (науки, инженерия, медицина) на профессиональном уровне, обычно они работают в маркетинге, PR, поддержке, где коммуникации составляют основу.
именно, что «как бы выполнены». Проблема иерархической модели (к коим относится документ-ориентированная) в необходимости дублирования данных в иерархиях. Или хранить логические ссылки (по коду, ID и т.п.) на другие иерархии с неизбежными соединениями в запросах.
Простейший пример, две иерархии (коллекции в терминах монги) заказов и отгрузок хранят данные о клиентах. Либо дублирование, либо третья иерархия клиентов со ссылками. «Нормализация» в рамках иерархической модели. Привет из 1960-х и от IBM IMS персонально :)
XML изначально проектировался для хранения документов, обеспечения целостности и извлечения информации по запросам, стандарт устоялся и щироко используется в корпоративном софтостроении.
Сходство в том, что обе модели основаны на теоретико-графовой иеррхической модели. Но ограничения иерархий тоже известны с 1960-х годов, когда переходили к сетевым и множественным моделям данных.
Более подробно есть в статье "Classification of data models in DBMS" на researchgate и в книжке "СУБД для программиста" (пардон за продакт-плейсмент)