язык программирования - структура файла

[Palex]

Общепринято, что файл для компиляции содержит код и вставки в виде комментариев.
Комментарии обрабатываются анализаторами и выбрасываются.

Предлагается другой подход к содержимому файла,так как он в большинстве случаев является текстовым файлом:
Файл является текстовым файлом, и содержит вставки, начинающиеся и заканчивающиеся ключевыми словами, и содержащими компилируемый код

При этом вставки могут быть именованными, с содержать вид компилируемого кода

Например:
meta source="text" name="text_for_out"
текст
на
нескольких
строчках
/meta

исполнение
meta source="pascal"
writeln (source.get_text("text_for_out"));
/meta

Какие преимущества существующий подход имеет перед предлагаемым?

[Xaositect]

Все уже придумано до нас, причем не кем-нибудь, а Кнутом. Почитайте про literate programming.

[Palex]

Мне очень приятно, что я не глупее Кнута, но вопрос был про преимущества.
Почему альтернативный метод не используется?

Из-за сложности проектирования компиляторов?

[Pavia]

Palex в сообщении #896488 писал(а):

Мне очень приятно, что я не глупее Кнута, но вопрос был про преимущества.
Почему альтернативный метод не используется?

Из-за сложности проектирования компиляторов?

Используется HTML + JavaScipt
Но смысла делать так не вижу потому, что противоречит основам стратегии. А именно "разделяй и властвуй".

[Palex]

Вы думаете рамками Древнего Мира. Ни одному из древних данная стратегия счастья не принесла.
Предпочитаю стратегию "демократического централизма"

Кроме того, речь шла о текстовом файле с его вкраплениями, а не о вложении SQL в PHP

[Xaositect]

Palex в сообщении #896488 писал(а):

Почему альтернативный метод не используется?

Из-за отсутствия необходимости? Комментариев к каждой функции вполне достаточно, а подробная документация обычно идет отдельным документом.

Он иногда используется там, где он уместен - в блог-постах о разных категорных штуках с кодом на Haskell, например.

[Palex]

Xaositect в сообщении #896491 писал(а):

Комментариев к каждой функции вполне достаточно, а подробная документация обычно идет отдельным документом.

Вот тут и фикус: поддержка кода и документации одновременно обойдется дешевле. А комментарий к функции не хуже его внешнего предварительного описания (вместо анализа цепочек ///)
Кроме того, внешняя документация должна описывать функциональность, а внутренняя - ссылки на алгоритмы, расшифровки переменных и т.п.

[Xaositect]

Palex в сообщении #896492 писал(а):

Вот тут и фикус: поддержка кода и документации одновременно обойдется дешевле

На практике это приводит к постепенному "протуханию" документации. Поэтому та документация, которая находится в коде, должна быть достаточно стабильна, например "что делает эта функция".

Palex в сообщении #896492 писал(а):

Кроме того, внешняя документация должна описывать функциональность, а внутренняя - ссылки на алгоритмы, расшифровки переменных и т.п.

Ссылка на алгоритмы должны быть привязана к функции, которая этот алгоритм реализует. Расшифровка переменной должна быть привязана к переменной. Какой-то дополнительный синтаксис для различения "этот кусок - код, а этот - комментарий", здесь только отвлекает от дела.

[Palex]

Xaositect в сообщении #896494 писал(а):

Расшифровка переменной должна быть привязана к переменной.

Тему о комментариях методов и переменных вынес в отдельную тему http://dxdy.ru/topic86905.html

[Pavia]

Palex
Это научный форум, а счастья науке не поддаётся.

В научной среде принято все раскладывать по полочкам, классифицировать. А классификация есть не что иное, как разделение. Конечно по мимо разделения есть и вторая стратегия это "объединение слабых".
Что касается вашего вопроса, то документация и код считаю надо разделять. Но при этом код должен быть само документированным.

Просто документация будет загромождать код. А за деревьями и леса не видно. Особенность человека в том что он сосредотачивается на чём-то одном и другое не будет видеть. А разбирать документация в поисках того места откуда идет код будет затруднительна.

Palex в сообщении #896490 писал(а):

Кроме того, речь шла о текстовом файле с его вкраплениями, а не о вложении SQL в PHP

Вы бы не позорились, а прочитали бы что значит буква T в сокращении HTML.
Что касается PHP и SQL они тоже текстовые по определению.
Видимо Вы не доконца сами поняли, что Вы хотите поэтому точно и не смогли выразить свою мысль.
Если не сформулировать четких правил, то и результат будет не четкий. Если вы не сформулируете грамматику вашего языка, то и компилятор будет на выходе выдавать нечёткие результаты. А на практике интересно получить предсказуемое поведение программы.

[Palex]

Pavia в сообщении #896512 писал(а):

Видимо Вы не до конца сами поняли, что Вы хотите поэтому точно и не смогли выразить свою мысль.
Если не сформулировать четких правил, то и результат будет не четкий.

Если про то, что хочу - это иметь коллекцию LR парсеров, которые в состоянии выполнять анализ любых цепочек, вплоть до лексического анализа. На нижнем уровне парсеры позволяют осуществлять лексический анализ, но структура всех парсеров одинакова.

За основу описания грамматик принято стандартное модульное программирование. Т.е. размеры грамматики для каждого парсера не превышают размеров одного модуля (20-50 строк).

Конструирование грамматик производится путем ссылок на элементы грамматики из других модулей.

Исходя из успеха структурного программирования, такое структурное метапрограммирование тоже может иметь успех.

[mustitz]

Вопрос надо ставить в другой плоскости: какие преимущества несет данный подход перед существующим? В большинстве случаев цель можно достигнуть и при существующем подходе, а значит это просто лишняя и никому не нужная фигня.

Если брать парсеры, то увеличивается порог вхождения.

[Palex]

Xaositect в сообщении #896487 писал(а):

Все уже придумано до нас, причем не кем-нибудь, а Кнутом. Почитайте про literate programming.

Прочитал статью “Грамотное программирование” http://itc.ua/articles/_gramotnoe_progr ... anie_9950/

Выделю три цитаты:

Цитата:

Как и всякая методология, ЛП обладает массой специфических недостатков. Их можно характеризовать "часто высказываемыми возмущениями" (ЧВВ) в тематических сетевых конференциях: реализации слишком сложны, реализации недостаточно функциональны, с имеющимися реализациями трудно отлаживать программы и организовать коллективную разработку, реализации не поддерживают используемый нами язык программирования

Цитата:

Поразительно и то, что во всем изобилии материалов, посвященных ЛП (а их действительно много), до сих пор не была усмотрена напрашивающаяся аналогия между сочетанием "фрагмент псевдоязыка — фрагмент-"реализация" и… структурами, используемыми для описания знаний, в первую очередь, с фреймами. Уже упоминавшийся ранее в весьма странном контексте термин "адрес" в данном случае получает ясное толкование: объекты ЛП-программы — фрагменты псевдоязыка — могут адресовать другие объекты и при этом включать дополнительные описания фрагментов реальных программ.

Идеально соответствующая фреймовому представлению знаний картина, позволяющая говорить об ЛП-программе как о высокоуровневой базе знаний. Качество содержимого этой базы, естественно, определяется качеством работы создателей программы, и в этом плане ЛП как методология не способна привести ни к каким принципиальным улучшениям (опять же, как и любая методология вообще). А вот сама фреймовая модель открывает весьма неожиданные и привлекательные перспективы, связанные, в первую очередь, с коллективной разработкой программ и повторным использованием кода.

Существующие отработанные реализации распределенных фреймовых баз знаний (например, система FramerD), по идее, позволяют создавать громадные репозитории ЛП-программ, находить подходящие для повторного использования фрагменты ЛП-кода, организовывать управление и совместную
работу тысяч программистов над одним проектом.

Цитата:

Развития функциональности ЛП, скорее всего, не было вообще — после Д. Кнута то ли никто не осмелился что-либо улучшить в идеях мастера, то ли эти идеи не столь сильно овладели умами… Хотя целый ряд усовершенствований напрашивается сам собой — сочетание ЛП-систем и систем статической проверки программ, генерация высокоуровневых спецификаций на основе ЛП-кода, построение гибридных систем класса "ЛП — формальный язык описания, пригодный к верификации".

Хотя, до сих пор не понимаю, почему не посмотрел книгу про TeX. Но, рядом стояла другая большая - по SADT

[Palex]

mustitz в сообщении #896896 писал(а):

В большинстве случаев цель можно достигнуть и при существующем подходе, а значит это просто лишняя и никому не нужная фигня.

На мой взгляд, Вы говорите не о цели, а о точке зрения заказчика на видение цели.

Вот засунуть справочник Кнута в библиотеку настраиваемых элементов - цель
И туда-же справочник Корнов...

[mustitz]

Palex в сообщении #896917 писал(а):

Вот засунуть справочник Кнута в библиотеку настраиваемых элементов - цель
И туда-же справочник Корнов...

А зачем для этого приведенный выше формат файла?