Здравствуйте, VladD2, Вы писали:
VD>Так вот при раскрытии шаблонов отступы должны складываться и в итоге должен получаться правильно отформатированный код.
VD>Это была первая проблема. Суть ее в том, что в лексемах теряется информациях о "ведущих" пробелах (т.е. о символах идущих в начале строки. Как в рпочем и о других пробелах (под словом "пробем" так же могут проходить и табуляции).
С этим понятно. А для чего нужно сохранять эти данные ? Чтобы нормально можно было генерировать код для немерле в python-like режиме, я правильно понимаю ?
VD>Оптимальным решением было бы расширить компилятор введя в него новый тип макроса — лексерные, то есть макросы котрым предоставляется поток входных символов файла и который может сам распознать часть этого потока и заменить на набор токенов, такой как он считает нужным.
VD>В нашем случае такой макрос встречая конструкцию: VD>
VD>StringTemplate <[ ... ]>
VD>
VD>выделял бы содержимео <[ ... ]> в виде строки и возвращал бы набор токенов: VD>
VD>{ StringTemplateParser(...) }
VD>
VD>где StringTemplateParser — это макрос который на одной из следующих стадий будет разбирать тело шаблона. А ... — это преобразованное в текстовую строку содержимое шаблона.
А что мешает сделать следующим образом
Пишем макрос StringTemplate(string). Этому макросу может передаваться любая строка, на основании которой можно сгенерировать любой код который ты пожелаешь.
То есть что я имею ввиду
Ты хотел, чтобы темплейт тебе отдавался компилятором в виде строки ?
Тогда можно написать так. VD>
VD> StringTemplate
VD> ("
VD>....CREATE $(Unique(index.IsUnique)) $(Clustered(index.IsClustered)) INDEX $(Quot(index.Name)) ON $(Quot(table))
VD>....(
VD>.... ..$(index.EntryColumns; "
\n"; entry => $(entry.Column) $(Direction(entry.IsAscending)))
VD>....)
VD>....")
VD>
И обрабатывать строку как ты сам захочешь с сохранением табуляции им прочих прелестей.
Равно как и отпадет проблема с балансированием скобок.
А на выходе этого макроса будет Немерловый код, который будет проверяться компилятором.
"Если Вы отличаетесь от меня, то это ничуть мне не вредит — Вы делаете меня богаче". Экзюпери
VD>Нужно ли расширять компилятор вводя новый тип макросов (авторы языка весьма не радостно приняли эту идею)?
можно это сделать опцией?
ключём в командной строке либо pragma.
либо автоматически: если не подключен ни один лексерный "макрос" (просится слово "плагин"), то лексер работает по-старому.
при чём, это же известно на этапе начала компиляции! поэтому по ходу дела переключать режим не придётся.
вообще, как мне кажется, это — довольно полезная функциональность.
с ней, например, легко реализовать что-то типа Nemerle Server Pages хоть смысла в этом мало.
Re[7]: [Движок текстовых шаблонов]: Проблемы компилятора
Если в языке появятся лексерные макросы, то во время разработки в IDE, не получится использовать ни Intellisense, ни подсветку. Потому что макрос работает только на во время компиляции, а подсветки и интелисенс получают данные от компилятора, насколько я помню.
Вижу 2 выхода.
1) Runtime макросы. Они позволят получать в рантайме информацию о различных DSL-ях по типу String Templates, что в свою очередь означает, что можно будет реализовать интелисенс и подсветку для любого дсля. Только макрос для него должен будет реализовывать какой-то интерфейс, чтобы отдавать нужную информацию о раскараске и интелисенсе.
+ должно выглядеть красиво
+ проверка во время написания кода
— необходимо добавлять в компилятор рантайм макросы
— необходимо добавляь в компилятор лексерные макросы
2) Представлять DSLи ввиде строки.
Это то, что я описывал в предыдущем посте. Просто представляем код нашего ДСЛя в виде строки и работаем
+ не нужно ничего делать с компилятором
— отсутсвие приятных фишек при разработке
— неудобство в оформлении многострочного кода. ("\t\t somecode,\n" не очень красиво выглядит )
Вот такие вот мои мысли.
... << RSDN@Home 1.2.0 alpha rev. 676>>
Re[8]: [Движок текстовых шаблонов]: Проблемы компилятора
M>- неудобство в оформлении многострочного кода. ("\t\t somecode,\n" не очень красиво выглядит )
тут можно поступить так же, как в жаваскрипте и перле — разрешить переносы строк внутри символьных констант:
s1 = "123\n\t456";
s2 = "123
456";
s1 = s2
для этого, конечно, придётся "что-то сделать с компилятором" но фича, как мне кажется, полезная.
Re[9]: [Движок текстовых шаблонов]: Проблемы компилятора
Здравствуйте, _pk_sly, Вы писали:
__>тут можно поступить так же, как в жаваскрипте и перле — разрешить переносы строк внутри символьных констант:
хъ __>для этого, конечно, придётся "что-то сделать с компилятором" но фича, как мне кажется, полезная.
+1
Хотя именно в такой реализации будет неудобно задавать строковые литералы внутри кода.
ИМХО нужно что-то типа xml'ной CDATA
<![CDATA[
function matchwo(a,b)
{
if (a < b && a < 0) then
{
return 1
}
else
{
return 0
}
}
]]>
Но из-за
A CDATA section cannot contain the string "]]>", therefore, nested CDATA sections are not allowed.
опять могут быть проблемы
Таким образом приходим к чемуто типа HTTP'шных boundary
<![some boundary[
function matchwo(a,b)
{
if (a < b && a < 0) then
{
return 1
}
else
{
return 0
}
}
]some boundary]!>
И как вырожденый случай
<![[
function matchwo(a,b)
{
if (a < b && a < 0) then
{
return 1
}
else
{
return 0
}
}
]]!>
... << RSDN@Home 1.2.0 alpha rev. 673>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[10]: [Движок текстовых шаблонов]: Проблемы компилятора
Здравствуйте, _pk_sly, Вы писали:
__>да, такое есть в перле. __>но на эту тему будут ещё долго и нудно спорить, а разрешить переносы внутри строк — элементарно
Вот только толку не будет. Ибо двойные кавычки используются много где. И их придется эскейпить, а это очень не удобно.
... << RSDN@Home 1.2.0 alpha rev. 673>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[12]: [Движок текстовых шаблонов]: Проблемы компилятора
Здравствуйте, _pk_sly, Вы писали:
WH>>Вот только толку не будет. Ибо двойные кавычки используются много где. И их придется эскейпить, а это очень не удобно.
__>толк — как минимум, не надо будет эскейпить переносы строк. __>мелочь, а приятно!
Хм, verbatim string literals? Единственное что можно эскейпить — кавычки, чтобы ввести кавычку вводим 2 кавычки.
Re[14]: [Движок текстовых шаблонов]: Проблемы компилятора
Здравствуйте, WolfHound, Вы писали:
WH>Хотя именно в такой реализации будет неудобно задавать строковые литералы внутри кода. WH>ИМХО нужно что-то типа xml'ной CDATA
WH>Таким образом приходим к чемуто типа HTTP'шных boundary
Что по большому счету те же лексерные макросы о которых говорил Влад..
Похоже действительно стандартными средствами Немерле красиво сделать не получится.
Дублировать кавычки очень неудобно, имхо
А если кто-то потом напишет свой вариант Стринг Темпелйтс, где эскейпить кавычку нужно будет через \" или еще как.. Мрачно получится.
... << RSDN@Home 1.2.0 alpha rev. 676>>
Re[15]: [Движок текстовых шаблонов]: Проблемы компилятора
Здравствуйте, _pk_sly, Вы писали:
ИД>>Хм, verbatim string literals? Единственное что можно эскейпить — кавычки, чтобы ввести кавычку вводим 2 кавычки. __>да, это я проглядел __>в $-строках это работает?
Работает, но для текствых шаблонов нужда дублировать ковычки — это никудышное решение.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[7]: [Движок текстовых шаблонов]: Проблемы компилятора
Здравствуйте, _pk_sly, Вы писали:
__>можно это сделать опцией? __>ключём в командной строке либо pragma.
__>либо автоматически: если не подключен ни один лексерный "макрос" (просится слово "плагин"), то лексер работает по-старому. __>при чём, это же известно на этапе начала компиляции! поэтому по ходу дела переключать режим не придётся.
Это все лишний геморрой. Уж если делать расширение компилятора, то хоть так чтобы оно не утомляло опциями.
__>вообще, как мне кажется, это — довольно полезная функциональность. __>с ней, например, легко реализовать что-то типа Nemerle Server Pages хоть смысла в этом мало.
Это да. Незнаю насколько нужны Server Pages, а от код или SQL генерировать милое дело. Любые JSP/AST.NET отдыхают по полной.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Mirrorer, Вы писали:
VD>>Это была первая проблема. Суть ее в том, что в лексемах теряется информациях о "ведущих" пробелах (т.е. о символах идущих в начале строки. Как в рпочем и о других пробелах (под словом "пробем" так же могут проходить и табуляции). M>С этим понятно. А для чего нужно сохранять эти данные ? Чтобы нормально можно было генерировать код для немерле в python-like режиме, я правильно понимаю ?
Нет. Это нужно чтобы генерировать вложенный текс. Например, при генерации SQL-я нужно чтобы все вложенные конструкции отбивались правильно. Так при герерации описания котлонок, они должны быть отбиты внутрь относительно тела конструкций в которых они генерируются (create table или create index, например).
Ведущие отсутпы же нужно учитывать еще и для того, чтобы отбросить незначащие. Ведь шаблон может начинаться не у левой кромки текста, а там где находится отбивка фукнции. Еще раз погляди на пример с отбивкой:
точками указаны пробелы которые нужно отбросить. А проблами те что должны остаться в шаблоне.
В общем, если есть Скайп, то проще соедениться и обговорить проблему голосом.
M>А что мешает сделать следующим образом M>Пишем макрос StringTemplate(string). Этому макросу может передаваться любая строка, на основании которой можно сгенерировать любой код который ты пожелаешь.
M>То есть что я имею ввиду M>Ты хотел, чтобы темплейт тебе отдавался компилятором в виде строки ? M>Тогда можно написать так. VD>>
VD>> StringTemplate
VD>> ("
VD>>....CREATE $(Unique(index.IsUnique)) $(Clustered(index.IsClustered)) INDEX $(Quot(index.Name)) ON $(Quot(table))
VD>>....(
VD>>.... ..$(index.EntryColumns; "
\n"; entry => $(entry.Column) $(Direction(entry.IsAscending)))
VD>>....)
VD>>....")
VD>> M>И обрабатывать строку как ты сам захочешь с сохранением табуляции им прочих прелестей. M>Равно как и отпадет проблема с балансированием скобок.
Мешает, то что работать с такими шаблонами будет неудобно. Ведь прийдется использовать verbatim-строки (те что с @ начинаются), а строковые литералы в них выделять удвоением. Приведенный мной пример сразу превращается в:
Здравствуйте, VladD2, Вы писали:
_FR>>Может, вынести в отдельный проект с форумом?
VD>Мы подняли на сервере второй сайт и будем общаться на нем. Только вот решим технические вопросы и пропишим всем туда логины.
Здравствуйте, VladD2, Вы писали:
VD>Ведущие отсутпы же нужно учитывать еще и для того, чтобы отбросить незначащие. Ведь шаблон может начинаться не у левой кромки текста, а там где находится отбивка фукнции.
... VD>точками указаны пробелы которые нужно отбросить. А проблами те что должны остаться в шаблоне.
Да, в таком случае только лексерные макросы, потому что тебе нужно будет откидывать отбивку функции, а кому-то нет. Получится как с С++ — сным string в начале своего развития.
VD>В общем, если есть Скайп, то проще соедениться и обговорить проблему голосом.
Да скайп уже скачал, письмо сегодня наваяю для регистрациии, только гарнитуры нет. Так что голосом не получится. Пока
VD> Ну, а двойная вложенность вообще будет полным писцом.
+1
Плюс при наличии ошибок в реализации таких макросов компилятор будет ругаться на непонятные ошибки в Немерле-коде. Это конкретно усложнит получение фидбека от пользователей, даже если они программисты.
Также нужно помнить о версионности ДСЛей. Дополнительный источник возникновения проблем на ровном месте.
Существует вероятность того, что различные ДСЛИ сгенерируют сущности с одинаковыми именами. И если для переменных это можно как-то разрулить на уровне неймспейсов, то в том случае, если два ДСЛя сгенерят два одинаковых extension method-а, опять получим проблемы.
хоть смысла в этом мало.
)
Если нам не помогут, то мы тоже никого не пощадим.
