Re[5]: Вопрос по синтаксису макросов для v2
От: Ziaw Россия  
Дата: 22.06.10 17:22
Оценка:
Здравствуйте, Аноним, Вы писали:

Z>>Надо что-то думать насчет независимости правил от порядка либо явного задания и просмотра порядка. Чем дольше я об этом думаю, тем меньше мне нравится идея при которой отлаженная грамматика может взбеситься от невинного выражения. Вспомнилась диагностика проблемной ситуации, когда в куче ошибок я просто не заметил макровскую NRE.


А>Это скорее решается продуманной обработкой ошибок в макросе.


Надо просто писать программы без багов и все будет хорошо? нюню
Re[6]: Вопрос по синтаксису макросов для v2
От: Аноним  
Дата: 22.06.10 18:04
Оценка:
Здравствуйте, Ziaw, Вы писали:

А>>Это скорее решается продуманной обработкой ошибок в макросе.


Z>Надо просто писать программы без багов и все будет хорошо? нюню


Я имел в виду обработку ошибок макроса компилятором.
Re[7]: Вопрос по синтаксису макросов для v2
От: VladD2 Российская Империя www.nemerle.org
Дата: 22.06.10 18:13
Оценка:
Здравствуйте, Аноним, Вы писали:

Z>>Надо просто писать программы без багов и все будет хорошо? нюню


А>Я имел в виду обработку ошибок макроса компилятором.


На сегодня компилятор перехватывает исключения возникшие в макросах и сообщает о них как об ошибках. Так что не заметить их очень не просто.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[4]: Вопрос по синтаксису макросов для v2
От: VladD2 Российская Империя www.nemerle.org
Дата: 22.06.10 18:22
Оценка:
Здравствуйте, Ziaw, Вы писали:

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


В принципе вот такой вариант:
  macro tagOpen : XmlAst.TagOpen
  syntax: lt:'<' s id:identifier attrs:attr* gt:'>' s

читается относительно не плохо. Только вот несколько противоречит концепциям языка. Хотя меньше чем твой вариант, в котором имя переменной находилось в месте где обычно находится тип.

Z>Кстати насчет типов, хотелось бы без явного объявления синтаксиса делать макры вида:

Z>
Z>macro attrList(attrs : params array[XmlAst.Attr]) // эквивалентно syntax attrList "(" attrs : attr* ")"
Z>{}
Z>


Z>Это реально?


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

Z>Надо что-то думать насчет независимости правил от порядка либо явного задания и просмотра порядка.


Опять же не уверен на счет правильного понимания вопроса. Единственная проблема которая мне известна на сегодня — это последовательность выполнения макро-атрибутов. Из-за этого, например, макро-атрибут фабрики классов может не видеть конструкторов сгенерированных макро-атрибутом Record. Тут — да, надо вводить зависимости. Например, дать возможность указывать создателям макросов, что их макрос должен выполняться до или после некоторого другого известного на момент компиляции макро-атрибута.

Z>Чем дольше я об этом думаю, тем меньше мне нравится идея при которой отлаженная грамматика может взбеситься от невинного выражения.


Можно пример?

Z> Вспомнилась диагностика проблемной ситуации, когда в куче ошибок я просто не заметил макровскую NRE.


Дык кучу ошибок просто нельзя допускать. От исключений никто не застрахован. И компилятор честно о них сообщает.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re: Вопрос по синтаксису макросов для v2
От: Тролль зеленый и толстый  
Дата: 22.06.10 20:42
Оценка: 95 (2)
Ну первый вариант однозначно плох: сложное выражение редактировать и воспринимать будет сверхнеудобно, и будет крайне легко допустить ошибку. Плюс нехороший мусор для непоименованных элементов (подчеркивания). Второй — тоже не фонтан, так как ухудшается читаемость собственно грамматики, легко запутаться в этом чередовании 'as', все сливается.

Указание имен в каком-то смысле эквивалентно введению подправил грамматики. Названия правил в описании грамматики могут говорить сами за себя (например, attrs), так что и без расшифровки понятно, что это. Если какой-то макрос упоминается только один раз (а таких случаев будет 99%), его можно явно не именовать.

macro class Xml
{
  macro tagOpen : XmlAst.TagOpen
  syntax: '<' identifier attrs '>'
  where 
    attrs: attr*
  {
    TagOpen(identifier.Value, attrs.Map(x => x.Value :> Attr))
  }

  macro attr : XmlAst
  syntax: identifier '=' attrValue
  {
    Attr(identifier, attrValue)
  }
}


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

Здесь, кстати, есть какая-то аналогия с регэксповыми "матчами". То есть мы как бы создаем поименованное подвыражение.

Вариант синтаксиса со скобками, скобки вроде как визуально выделяют поименованный фрагмент:

  macro tagOpen : XmlAst.TagOpen
  syntax: '<' identifier {attrs attr*} '>'
  {
    TagOpen(identifier.Value, attrs.Map(x => x.Value :> Attr))
  }


Можно смешать варианты:

  macro tagOpen : XmlAst.TagOpen
  syntax: {lt '<'} identifier attrs {gt '>'}
  where 
    attrs: attr*
  {
    TagOpen(lt.StartPos, gt.EndPos, identifier.Value, attributes.Map(x => x.Value :> Attr))
  }


По поводу пробелов (а точнее, разделителей, в которые входят также комментарии). Выписывать явно разделители, тем более с таким именем как "s" — явно некрасиво. Потому что в 99% случаев он будет нужен и только в 1% — не нужен. Скорее, было бы лучше, если бы макрос s вставлялся по умолчанию, если не вставлен кейворд nospace, например:

 '<' nospace identifier nospace '>'.


Еще с разделителями интересная вещь. Если я захочу добавить новый вид комментариев, значит мне как-то надо расширить макрос s? Значит, макросы можно будет определять более одного раза, расширяя их, так что ли?
Re[8]: Вопрос по синтаксису макросов для v2
От: Ziaw Россия  
Дата: 23.06.10 03:27
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>На сегодня компилятор перехватывает исключения возникшие в макросах и сообщает о них как об ошибках. Так что не заметить их очень не просто.


Не заметить их очень просто, если данная ошибка влечет за собой десятки ошибок компиляции.

Дело в том, что интеграция как-то хитро сортирует ошибки. NRE просто потонула в десятках ошибок overload resolution. Почему она оказалась у них в середине — непонятно.
Re[5]: Вопрос по синтаксису макросов для v2
От: Ziaw Россия  
Дата: 23.06.10 04:16
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>читается относительно не плохо. Только вот несколько противоречит концепциям языка. Хотя меньше чем твой вариант, в котором имя переменной находилось в месте где обычно находится тип.


Да я сразу признал, что наоборот лучше
Автор: Ziaw
Дата: 21.06.10
, еще до появления аналогичного варианта от WolfHound. Первый вариант родился из опыта других описаний, ganjustas вон тоже его предложил.

Z>>Кстати насчет типов, хотелось бы без явного объявления синтаксиса делать макры вида:

Z>>
Z>>macro attrList(attrs : params array[XmlAst.Attr]) // эквивалентно syntax attrList "(" attrs : attr* ")"
Z>>{}
Z>>


Z>>Это реально?


VD>Не вполне уверен, что понял вопрос верно. Но если речь идет о макросах без синтаксиса (с синтаксисом аналогичным вызову функций), то для них конечно же никаких расширений не требуется. Речь идет только о макрах расширяющих синтаксис.


Да, речь идет о макрах без синтаксиса принимающих Аst отличный от PExpr.

Z>>Надо что-то думать насчет независимости правил от порядка либо явного задания и просмотра порядка.


VD>Опять же не уверен на счет правильного понимания вопроса. Единственная проблема которая мне известна на сегодня — это последовательность выполнения макро-атрибутов. Из-за этого, например, макро-атрибут фабрики классов может не видеть конструкторов сгенерированных макро-атрибутом Record. Тут — да, надо вводить зависимости. Например, дать возможность указывать создателям макросов, что их макрос должен выполняться до или после некоторого другого известного на момент компиляции макро-атрибута.


Это да, будет очень полезно. Что нибудь типа depends on SomeMacro.

Z>>Чем дольше я об этом думаю, тем меньше мне нравится идея при которой отлаженная грамматика может взбеситься от невинного выражения.


VD>Можно пример?


Это пока на уровне интуиции Видится что-то типа http://rsdn.ru/forum/dotnet/3851708.1.aspx
Автор: nikov
Дата: 22.06.10
.

VD>Дык кучу ошибок просто нельзя допускать. От исключений никто не застрахован. И компилятор честно о них сообщает.


Проблема в том, что неверно работающий макрос может породить сотни, а то и тысячи ошибок. У меня было 50+ на трех простых методах, ломался overload resolution на цепочках вызовов linq.
Re[8]: Вопрос по синтаксису макросов для v2
От: Ziaw Россия  
Дата: 23.06.10 04:34
Оценка:
Здравствуйте, gandjustas, Вы писали:

G>Я не спец в макрах, но встеаки:

G>0)Задавать игнорируемые парсером паттерны, так будут и коменты работать, и можно будет whitespace не указывать

+1, а для отключения этого режима можно использовать предложенный rawsyntax

G>1)Строки (лиералы) обязательно в двойных кавычках все, даже односимвольные.


Имхо, это просто опечатка, я не обращаю внимания.

G>2)Мозолят глаза ключевые слова macro ... syntax, выглядят как два разных объявления, хотя это две части одного.


Тут все нормально, это ты с непривычки, тебе же не кажутся class и when двумя разными объявлениями.

G>3)Я бы предпочел писать имя для токена после указания его паттерна, так однородность записи не нарушается


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

G>4)API для работы внутри макроса


?

G>5)Coding style для определений синтаксиса, вплоть до варнингов при компиляции. Например все паттерны — с большой буквы, все алиасы — маленькими.

G>Что-то вроде
G>
G>macro TagOpen:XmlAst.TagOpen = '<' Identifier:id Attr*:attrs '>' => {TagOpen(Macro.StartPos, Macro.EndPos, identifier.Value, attrs.Map(x => x.Value :> Attr))}
G>


syntax лучше

G>6)вместо macro class написать language, и чтобы в исходниках было using language <Name>, а внутри другого language — import language <Name>


далеко не все макры определяют свой синтаксис. но идея using language мне нравится.

G>7)Писать макры без вывода + атрибуты на макрах = красивая подсветка.


G>
G>[Keyword]
G>macro Keyword = "keyword"
G>macro Z = Keyword Identifier => { Console.WriteLine(Macro.Tokens[1].Value) }
G>



G>Если очень не нравится двоеточие, то можно использовать собаку


G>
G>macro TagOpen:XmlAst.TagOpen = '<' Identifier@id Attr*@attrs '>' => {TagOpen(Macro.StartPos, Macro.EndPos, identifier.Value, attrs.Map(x => x.Value :> Attr))}
G>


Собака нравится гораздо меньше
Re[9]: Вопрос по синтаксису макросов для v2
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 23.06.10 05:10
Оценка:
Здравствуйте, Ziaw, Вы писали:

G>>2)Мозолят глаза ключевые слова macro ... syntax, выглядят как два разных объявления, хотя это две части одного.

Z>Тут все нормально, это ты с непривычки, тебе же не кажутся class и when двумя разными объявлениями.
Кажутся. Форматтер студии отбивает на один таб when по-умолчанию, хотя по возможности я в одну строчку пишу.

G>>3)Я бы предпочел писать имя для токена после указания его паттерна, так однородность записи не нарушается

Z>Это только на первый взгляд, в немерле интуитивнее будет указание биндящейся переменной перед двоеточием.
Возможно, при наличии строгих coding style для макросов не так заметно отличие будет.

G>>4)API для работы внутри макроса

Z>?
Чтобы можно было работать с частями макроса без присвоения им имен.
Re[2]: Вопрос по синтаксису макросов для v2
От: Ziaw Россия  
Дата: 23.06.10 06:02
Оценка:
Здравствуйте, Тролль зеленый и толстый, Вы писали:

ТЗИ>Указание имен в каком-то смысле эквивалентно введению подправил грамматики. Названия правил в описании грамматики могут говорить сами за себя (например, attrs), так что и без расшифровки понятно, что это. Если какой-то макрос упоминается только один раз (а таких случаев будет 99%), его можно явно не именовать.


Более того, можно не именовать явно даже макросы упоминающиеся несколько раз, они просто превратятся в одноименный массив. attr attr* тоже.

ТЗИ>По поводу пробелов (а точнее, разделителей, в которые входят также комментарии). Выписывать явно разделители, тем более с таким именем как "s" — явно некрасиво. Потому что в 99% случаев он будет нужен и только в 1% — не нужен. Скорее, было бы лучше, если бы макрос s вставлялся по умолчанию, если не вставлен кейворд nospace, например:


ТЗИ>
ТЗИ> '<' nospace identifier nospace '>'.
ТЗИ>


Отличная мысль, даже лучше чем rawsyntax.

ТЗИ>Еще с разделителями интересная вещь. Если я захочу добавить новый вид комментариев, значит мне как-то надо расширить макрос s? Значит, макросы можно будет определять более одного раза, расширяя их, так что ли?


Имхо, определения разделителей просто должны помечаться, например атрибутом. Расширение макросов как то уж слишком сложно выглядит.
Re[2]: Вопрос по синтаксису макросов для v2
От: VladD2 Российская Империя www.nemerle.org
Дата: 23.06.10 18:39
Оценка:
Здравствуйте, Тролль зеленый и толстый, Вы писали:

ТЗИ>...


Интересные предложения. Беру небольшой таймаут на их осмысление.

ТЗИ>Еще с разделителями интересная вещь. Если я захочу добавить новый вид комментариев, значит мне как-то надо расширить макрос s? Значит, макросы можно будет определять более одного раза, расширяя их, так что ли?


Откровенно говоря расширение списка пробельных символов не стоит на повестке дня. Получится сделать это естественным образом и без потери производительности — хорошо. Не получится, ну и ладно.

Важна другая возможность — возможность учета тех самых пробельных символов (и вообще чего угодно) внутр некоторых макросов. Например, при парсинге ХМЛ-я очень важно учитывать все детали. Ведь даже какзлось бы не значащие пробелы могут быть очень важны.

Кроме того те же комментарии являются весьма важной вещью для компилятора и IDE. В них может содержаться метаинформация и (возможно) управляющие конструкции. Посему полезно иметь возможность разбора их макросом.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[9]: Вопрос по синтаксису макросов для v2
От: VladD2 Российская Империя www.nemerle.org
Дата: 23.06.10 18:45
Оценка: +1
Здравствуйте, Ziaw, Вы писали:

Z>Не заметить их очень просто, если данная ошибка влечет за собой десятки ошибок компиляции.


Ну, дык разбираться нужно в причине ошибки. Если ошибок много — это уже само по себе основание чтобы насторожиться.

Z>Дело в том, что интеграция как-то хитро сортирует ошибки. NRE просто потонула в десятках ошибок overload resolution. Почему она оказалась у них в середине — непонятно.


Она их просто не сортирует. Можно подумать над расширенной поддержкой для исключений. Скажем если при обработке метода есть исключения в макросах, то все остальные ошибки выбрасывать и оставлять только информацию об исключениях.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[6]: Вопрос по синтаксису макросов для v2
От: VladD2 Российская Империя www.nemerle.org
Дата: 23.06.10 18:57
Оценка:
Здравствуйте, Ziaw, Вы писали:

Z>Да я сразу признал, что наоборот лучше
Автор: Ziaw
Дата: 21.06.10
, еще до появления аналогичного варианта от WolfHound. Первый вариант родился из опыта других описаний, ganjustas вон тоже его предложил.


Пока что из всего предложенного я склоняюсь к смеси вариантов Троля и Вольфхаунда, т.е. вести некий раздел where для именования подправил и кроме того позволить именовать через двоеточние, но принудительно требовать чтобы двоеточие шло без пробелов, т.е.:
lt:'<'


Z>Да, речь идет о макрах без синтаксиса принимающих Аst отличный от PExpr.


Хм. А нужно ли это? На сегодня макросы без синтаксиса могут принимать только PExpr (т.е. выражения) и это не приводит к каким-то трудностям.

В прочем, думаю что это не будет проблемой.

Z>Это да, будет очень полезно. Что нибудь типа depends on SomeMacro.


Я думал о возвожности задать приоритет таким образом:
macro MyMacro...
priority: SomeMacro > this > OtherMacro // т.е. текущий макрос мене приоритетный нежели SomeMacro но более приоритетный нежели OtherMacro


Z>Это пока на уровне интуиции Видится что-то типа http://rsdn.ru/forum/dotnet/3851708.1.aspx
Автор: nikov
Дата: 22.06.10
.


Не понял связи обсуждения с этим примером.

Z>Проблема в том, что неверно работающий макрос может породить сотни, а то и тысячи ошибок. У меня было 50+ на трех простых методах, ломался overload resolution на цепочках вызовов linq.


Ясно. Тут пока ничего не придумано. Отладка макросов дело по прежнему не простое. Но с опытом проблемы исчезают.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[2]: Вопрос по синтаксису макросов для v2
От: VladD2 Российская Империя www.nemerle.org
Дата: 23.06.10 20:33
Оценка:
Здравствуйте, Тролль зеленый и толстый, Вы писали:

ТЗИ>Ну первый вариант однозначно плох: сложное выражение редактировать и воспринимать будет сверхнеудобно, и будет крайне легко допустить ошибку.


На мой взгляд — нормально. Но если будет найден более удобный вариант, я буду не против.

ТЗИ>Плюс нехороший мусор для непоименованных элементов (подчеркивания).


Это стандартное соглашение в языке означающие игнорирование имени.

ТЗИ>Второй — тоже не фонтан, так как ухудшается читаемость собственно грамматики, легко запутаться в этом чередовании 'as', все сливается.


+1

ТЗИ>Указание имен в каком-то смысле эквивалентно введению подправил грамматики.


Если только вырожденных. В грамматиках частенько правила используются по много раз в рамках тела другого правила. Собственно задание имени и нужно чтобы отличить разные вхождения.

Однако если это позволяет ввести имена для правил которые можно будет использовать в теле макросов, то в этом появляется смысл. Идея ввести "where" — мне нравится. В принципе с ее помощью можно решить проблемы именования полностью, но при этом грамматике не допустимо будет использовать литералы. Наше пример при этом выродится в:
  macro tagOpen : XmlAst.TagOpen
  syntax: lt identifier attrs gt;
  where 
    attrs = attr*;
    lt    = '<';
    gt    = '>';
  {
    ...
  }

Что мне не нравится. Так что все же именование по месту все равно нужно.

ТЗИ> Названия правил в описании грамматики могут говорить сами за себя (например, attrs), так что и без расшифровки понятно, что это. Если какой-то макрос упоминается только один раз (а таких случаев будет 99%), его можно явно не именовать.


Есть еще одна проблема. Это имена макросов! А они сами могут потребоваться (в коде макроса). Ведь макрос сам может использовать макросы. Так в стандартной библиотеке макросов немерла сейчас во всю используются эти же макросы (из прошлой версии библиотеки). Может возникнуть конфликт имен. В прочем его можно решать или в том же "where" или путем добавления префикса '@'.

ТЗИ>Я убрал из примера сохранение позиции в тексте, так как мне кажется, что этот нудный процесс обязательно должен быть как-то автоматизирован.


"Как-то" это несерьезно! Лично я не вижу как это сделать, по сему пока не появится внятного решения придется делать это вручную.

Тут нужно понимать, что копировать местположение руками нужно довольно редко. Все стандартные правила уже будут содержать корректное местоположение.

ТЗИ>Здесь, кстати, есть какая-то аналогия с регэксповыми "матчами". То есть мы как бы создаем поименованное подвыражение.


Скорее с грамматиками. Твое where — это ни что иное как явное задание имен подправилам которые раньше просто их не имели. В принципе можно на каждый чих создавать мелкий макрос. Но это очень неудобно!

ТЗИ>Вариант синтаксиса со скобками, скобки вроде как визуально выделяют поименованный фрагмент:


ТЗИ>
ТЗИ>  macro tagOpen : XmlAst.TagOpen
ТЗИ>  syntax: '<' identifier {attrs attr*} '>'
ТЗИ>  {
ТЗИ>    TagOpen(identifier.Value, attrs.Map(x => x.Value :> Attr))
ТЗИ>  }
ТЗИ>


Это мне совсем не нравится. Уж лучше двоеточния, но в синтаксисе жетско оговорить, что между двоеточием и подправилом которое оно именует не должно быть пробелов. Тогда можно будет легко отличать то подправило для которого задается имя.

ТЗИ>Можно смешать варианты:


ТЗИ>
ТЗИ>  macro tagOpen : XmlAst.TagOpen
ТЗИ>  syntax: {lt '<'} identifier attrs {gt '>'}
ТЗИ>  where 
ТЗИ>    attrs: attr*
ТЗИ>  {
ТЗИ>    TagOpen(lt.StartPos, gt.EndPos, identifier.Value, attributes.Map(x => x.Value :> Attr))
ТЗИ>  }
ТЗИ>


Пожалуй смешанный вариант твоего where и вольфхаудовского именования через двоеточие будет выглядеть лучше:
  macro tagOpen : XmlAst.TagOpen
  syntax: lt:'<' identifier attrs gt:'>';
  where 
    attrs = attr* // "Равно" здесь более уместно. Как вариант, можно использовать "<-" раз уж мы используем PEG
  {
    ...
  }


ТЗИ>По поводу пробелов (а точнее, разделителей, в которые входят также комментарии). Выписывать явно разделители, тем более с таким именем как "s" — явно некрасиво. Потому что в 99% случаев он будет нужен и только в 1% — не нужен. Скорее, было бы лучше, если бы макрос s вставлялся по умолчанию, если не вставлен кейворд nospace, например:


ТЗИ>
ТЗИ> '<' nospace identifier nospace '>'.
ТЗИ>


Хорошая идея! Еще как вариант, можно ввести соглашение по которому "nospace" подразумевается если несколько литералов и правил записаны без отступов. Таким образом приведенный ниже пример будет эквивалентным твоему:
 '<'identifier'>'.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[10]: Вопрос по синтаксису макросов для v2
От: VladD2 Российская Империя www.nemerle.org
Дата: 23.06.10 20:50
Оценка:
Здравствуйте, gandjustas, Вы писали:

G>>>4)API для работы внутри макроса

Z>>?
G>Чтобы можно было работать с частями макроса без присвоения им имен.

Лучше уж вводить имена. Я видел несколько вариантов позиционного доступа. Во всех случаях получалась не читаемая муть.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[3]: Вопрос по синтаксису макросов для v2
От: Ziaw Россия  
Дата: 24.06.10 05:24
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Хорошая идея! Еще как вариант, можно ввести соглашение по которому "nospace" подразумевается если несколько литералов и правил записаны без отступов. Таким образом приведенный ниже пример будет эквивалентным твоему:

VD>
VD> '<'identifier'>'.
VD>


Согласен со всем написаным кроме этого. Не так уж часто будет использоваться nospace, чтобы вводить такие правила. Тем более учитывая то, что документация не в лучшем состоянии.

Кстати, ты не ничего не сказал про идею помечать макросы атрибутом который добавляет его грамматику к списку пробельных. Комментарии действительно должны считаться пробельными символами по умолчанию.
Re[4]: Вопрос по синтаксису макросов для v2
От: VladD2 Российская Империя www.nemerle.org
Дата: 24.06.10 17:46
Оценка:
Здравствуйте, Ziaw, Вы писали:

Z>Кстати, ты не ничего не сказал про идею помечать макросы атрибутом который добавляет его грамматику к списку пробельных. Комментарии действительно должны считаться пробельными символами по умолчанию.


А что тут скжешь? Пока что детали не ясны.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re: Вопрос по синтаксису макросов для v2
От: catbert  
Дата: 24.06.10 19:08
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Собственно вопрос заключается в том какой вариант выбрать?

VD>Если есть свои варианты, то их тоже можно озвучивать.

Можно на макросах же реализовать полноценный DSL для описания всех свойств макроса. Вроде как:

macro FooMacro
{
    dependencies // отдельно описать зависимости
    {
        BarMacro, 
        BazMacro
    }

    parameters // отдельно — параметры и их типы
    {
        First  : BarMacro
        Second : BazMacro
        Third  : PExpr
        Fourth : int
    }

    syntax // отдельно — синтаксис (почему бы его не описывать PEG-грамматикой, если он все равно к ней сводится)
    {
        FooMacro = ShortMode | LongMode
        ShortMode = First * 
        LongMode = Third *
    }
 
    beforeTypedMembers // отдельно — реализацию для каждой фазы компиляции
    {
         // blah blah
    }

}


Упрощенные формы синтаксиса можно так же реализовать другими макросами.
Re: еще один вариант построения DSL
От: Ziaw Россия  
Дата: 25.06.10 05:36
Оценка:
у нас есть грамматика, есть некий ast который она создает. не зря ли мы смешиваем грамматики и ast? может быть грамматика отдельно, AST отдельно?

language Xml
{
    macro XmlAttr: Xml.Attr
    syntax name '=' value
    where name : PExpr.Ref, value : PExpr.Expr
    {
       Xml.Attr(name.Name, value);
    }

    macro XmlNodeStart: Xml.NodeStart
    syntax '<' name attrs:attr* '>' 
    where name : PExpr.Ref, attr : Xml.Attr
    {
       Xml.NodeStart(name.Name, attrs)
    }

    macro XmlNodeEnd: Xml.NodeEnd
    syntax '</' name  '>'
    where name : PExpr.Ref
    {
       Xml.NodeEnd(name)
    }

    macro XmlNode: Xml.Node
    syntax start nodes:node* end
    where start : Xml.NodeStart, 
          node  : Xml.Node, 
          end   : Xml.NodeEnd
    {
      assert(start.Name == end.Name);
      Xml.Node(start.Name, start.Attrs, nodes)
    }
}
// program
using language Xml
{
  def x = <foo x="1">; // def x = Xml.NodeStart("foo", [Xml.Attr("x", "1")])

  def str = "1";
  def x = <foo x="1">; // def x = Xml.NodeStart("foo", [Xml.Attr("x", str)])

  def attr = Xml.Attr("x", "1");
  def x = <foo <( [attr : Xml.Attr] )> ></foo>; // def x = Xml.Node(foo, [attr], [])
}


Где <()> антицитата, уточнение типа потребуется парсеру. Идея в том, чтобы PExpr'ы генерили код, а остальной Ast генерил обычные конструкторы, что то типа expression tree в C#.

Либо вариант, с возможностью выбора подходящего возвращаемого значения:
language Xml
{
    macro XmlAttr: (Xml.Attr | PExpr)
    syntax name '=' value
    where name : PExpr.Ref, value : PExpr.Expr
    {
       | Xml.Attr => Xml.Attr(name.Name, value);
       | PExpr    => <[ Xml.Attr( $(name.Name : string), $value); ]>
    }
}



Получается, что парсер работает не только с текстом, но и с астом. Алгоритм тот же, рекурсивный спуск. Если ожидается аст мы проверяем все синтаксические макры способные вернуть нужный нам тип.
Re[2]: еще один вариант построения DSL
От: VladD2 Российская Империя www.nemerle.org
Дата: 25.06.10 19:39
Оценка:
Здравствуйте, Ziaw, Вы писали:

Z>у нас есть грамматика, есть некий ast который она создает. не зря ли мы смешиваем грамматики и ast? может быть грамматика отдельно, AST отдельно?


Задача макроса — вернуть некоторый АСТ. Так что я вообще не понимаю о чем идет речь.

Z>
Z>    macro XmlAttr: Xml.Attr
Z>    syntax name '=' value
Z>    where name : PExpr.Ref, value : PExpr.Expr
Z>    {
Z>       Xml.Attr(name.Name, value);
Z>    }
Z>


Я вижу тут банальное задание типов для элементов грамматики. В этом нет смысла, так как типы и так известны. Ведь каждое имя — это имя макроса у которого и так известен возвращаемый им тип.

Z>Где <()> антицитата, уточнение типа потребуется парсеру. Идея в том, чтобы PExpr'ы генерили код, а остальной Ast генерил обычные конструкторы, что то типа expression tree в C#.


PExpr — это тоже "обычные конструкторы".

Z>Либо вариант, с возможностью выбора подходящего возвращаемого значения:


Зачем это все?

Z>Получается, что парсер работает не только с текстом, но и с астом. Алгоритм тот же, рекурсивный спуск. Если ожидается аст мы проверяем все синтаксические макры способные вернуть нужный нам тип.


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