Nemerle 2.0
От: VladD2 Российская Империя www.nemerle.org
Дата: 17.06.10 15:03
Оценка:
#Имя: FAQ.nemerle.Nemerle_2_0
В этой теме будут публиковаться мысли связанные со второй версий компилятора.

Приблизительная тематика:
1. Список фич отложенных до 2.0 (которые не будут реализованы в 1.0 или будут реализованы не полностью).
2. Изменения планируемые на вторую версию.
3. Стратегические и идеологические мысли по поводу 2.0.
4. Технические аспекты.

ЗЫ

Просьбы не засорять тему обсуждениями (открывайте другие темы). Эта тема — копилка того что нужно не забыть реализовать в 2.0 и для серьезных вопросов.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Поддержку сопоставления с образцом для nullable-типов
От: VladD2 Российская Империя www.nemerle.org
Дата: 17.06.10 15:05
Оценка:
Полноценную поддержку сопоставления с образцом для nullable-типов переносим на 2.0.

Пока что будет выдаваться предупреждение о том, что нужно использовать приведение к option[T] или вызов метода GetValueOrDefault().
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Пересесть на System.Tuple
От: hardcase Пират http://nemerle.org
Дата: 17.06.10 15:07
Оценка: 1 (1) +2
Пересесть на System.Tuple, доступный в .NET 4.0 (для .NET 2.0/3.5 написать аналог).

Просьба указывать в названии сообщения предлагаемую идею (вопрос)
/* иЗвиНите зА неРовнЫй поЧерК */
Синтаксические макросв в Nemerle 2.0
От: VladD2 Российская Империя www.nemerle.org
Дата: 17.06.10 17:01
Оценка: 31 (3)
В 2.0 планируется реализовать новую систему синтаксических макросов (макросов расширяющих синтаксис языка).

Это потребует переработки всей системы парсинга.

Общая идея такова...
1. Из компилятора удаляются модули лексического и синтаксического разбора.
2. Вводится новый вид макросов описывающий синтаксис в виде PEG-нотации. Такой макрос при описании синтаксиса может пользоваться другими синтаксическими макросами доступными на момент компиляции (из других сборок) или находящихся в той же сборки что и данный. Этот вид макросов будет возвращать в результате своей работы АСТ. По всей видимости тип возвращаемого АСТ должен будет указываться при описании макроса.
3. Парсер собирается из доступных макросов. Каждый макрос рассматривается как правило грамматики языка. Результирующий парсер частично прекомпилируется (для конструкций верхнего уровня), а частично строится динамически (на основании открытых пространств имен, как это происходит с современными макросами).
4. В макросы вводятся функции самодокументирования. При описании макроса будет можно (или даже нужно) задать описание конструкции.

Плюсы данной схемы:
1. Парсер будет хорошо структурирован, что упростит его развитие.
2. Парсер будет полностью расширяемым (причем макросами, т.е. без изменения компилятора).
3. Будет возможно разбирать синтаксические конструкции любой сложности. Это позволит вводить практически не ограниченные синтаксические изменения. Например, конструкции вроде XML-я (не говоря уже о linq) можно будет описывать прямо правилами, а не загонять в строки и заниматься ручным парсингом внутри строк. В общем, почти полное снятие ограничений на разбираемые грамматики и возможность встраивать расширения прямо в язык.
4. Грамматика всего компилятора станет описываться декларативно.
5. Документацию к макросам, а значит и к самому языку можно будет генерировать автоматически.

Минусы:
1. В макросах нельзя будет производить побочных эффектов, так как правила описываемые макросами могут вызываться при парсинге ветвей грамматики которые в последствии будут отброшены как не верные.
2. Пока не ясно (и это следует обсудить) как в такой схеме воспроизвести синтаксис базируемый на отступах. Как вариант, можно просто от него отказаться. Возможно, что данную проблему получится решить самими же макросами (введя альтернативные макросы для парсинга последовательностей и элементов верхнего уровня. Хорошо бы, чтобы кто-то продумал это.
3. Парсер построенный в лоб на базе PEG неминуемо будет более медленным и прожорливым по сравнению с ручным. Это потребует потратить не мало времени на оптимизацию. Нужно реализовать генерацию ДКА для терминальных правил (разбирающих символы строки).
4. Весь код файла придется грузить в память перед парсингом (это требование алгоритма связанного с парсингом PEG-а). На сегодня это вряд ли будет проблемой. Если только на мобильных девайсах, где немерл и так не работает.
5. Придется парсить весь файл целиком, без предварительной токенизации и шага препарс (где на сегодня производится свертка токенов в группы). Это так же накладывает дополнительные требования на скорость парсинга (т.е. на оптимизацию PEG-а). Это же не позволит парсить части фалов (как это сейчас делает интеграция), но оно и правильно, так как это неминуемо ведет к проблемам в работе интеграции.
6. Грамматика используемая в макросах не должна быть лево-рекурсивной (так как это не поддерживается реализацией PEG-а) и должна будет подчиняться некоторым правилам разработанным для нашего PEG-парсера. Например, в операторах приоритетного выбора (... / ...) обязаны использоваться только имена правил (макросов) причем типы возвращаемых значений этих правил обязаны совпадать (или иметь общий базовый тип совпадающий с типом правила содержащего оператор приоритетного выбора).
7. Невозможно будет предсказать, что два подправила в операторе приоритетного выбора не конфликтуют. Правило стоящее первым будет всегда оказываться "победителем". Если правило разобралось, то для других даже не будет производиться попытка разбора. Возможно, имеет смысл кроме оператора приоритетного выбора PEG-а "/" ввести стандартный оператор перечисления равноценных правил "|" из BNF с тем, чтобы программисты могли явно выражать, что отдельные правила (макросы) не должны пересекаться и тем самым заставлять компилятор проверять это условие. Однако прочерка может оказаться трудной в реализации, так как для выявления эквивалентности правил придется строить для них конечный автомат (что приближает нас к ANTLR 3, и является весьма сложным занятием... особенно для динамически расширяемого парсера).
8. В макросах придется явно указывать пробельные символы. PEG позволяет обходиться без лексера, что координатно повышает гибкость и модульность парсера, но за это надо платить.

Наиболее вероятные для реализации идеи (и синтаксис) описаны в следующих сообщениях:
http://www.rsdn.ru/forum/nemerle/3853002.1.aspx
Автор: Тролль зеленый и толстый
Дата: 23.06.10

http://www.rsdn.ru/forum/nemerle/3854325.1.aspx
Автор: VladD2
Дата: 24.06.10


"macro class" — это класс позволяющий объединить несколько логически связанных макросов и методов реализации связанных с ними. Планируется, что "macro class" так же будет обеспечивать обработку событий связанных со стадиями компиляции и хранение состояния (в прочем тут нужно много думать, так как парсер PEG-а не любит глобального состояния).
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[2]: Nemerle 2.0
От: VladD2 Российская Империя www.nemerle.org
Дата: 17.06.10 17:03
Оценка:
Здравствуйте, hardcase, Вы писали:

H>Пересесть на System.Tuple, доступный в .NET 4.0 (для .NET 2.0/3.5 написать аналог).


Не уверен, что это хорошая идея с точки зрения производительности. Совместимость, конечно, сделать надо. Но можно ограничиться просто неявным приведением типов.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re: Синтаксические макросв в Nemerle 2.0
От: Ziaw Россия  
Дата: 17.06.10 18:45
Оценка:
Здравствуйте, VladD2, Вы писали:

В таком случае, макросы должны задавать метаинформацию для IDE

Re[2]: Синтаксические макросв в Nemerle 2.0
От: VladD2 Российская Империя www.nemerle.org
Дата: 17.06.10 19:02
Оценка:
Здравствуйте, Ziaw, Вы писали:

Z>* Хинты

Z>* Уметь менять подсветку
Z>* По хорошему еще комплишенменеджер как-то указывать, но тут у меня думалка отказывает.

Подсказки и автодополнение при вводе работают на следующем уровне — на уровне AST. Для того чтобы все это дело работало корректно макросам нужно всего лишь правильно указать местоположения в возвращаемом AST. А эта задача резко упрощается за счет того, что сам парсер будет генерироваться (т.е. в нем не будет ошибок класса "забыли про что-то".

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

А вот с подсветкой проблема действительно может возникнуть.
Для PEG-а совершенно не нужны ключевые слова.
Плюс в его случае как класс отсутствует лексер. Так что не совсем ясно как организовать подсветку.

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

ЗЫ

Вообще, поддержку IDE для двушки придется координатно пересмотреть.
В прочем, сама двушка во многом нацелена на то, чтобы избавиться от тех проблем которые сейчас присутствуют в IDE.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re: Пересесть на System.Tuple
От: catbert  
Дата: 17.06.10 20:14
Оценка:
Здравствуйте, hardcase, Вы писали:

H>Пересесть на System.Tuple, доступный в .NET 4.0 (для .NET 2.0/3.5 написать аналог).


Более общий вопрос: какие фреймворки поддерживать? Вариант 2.0 и выше мне нравится больше всего, но дублирование функционального API из linq и того же System.Tuple — это не очень хорошо.
Re[2]: Пересесть на System.Tuple
От: VladD2 Российская Империя www.nemerle.org
Дата: 18.06.10 11:46
Оценка:
Здравствуйте, catbert, Вы писали:

C>Здравствуйте, hardcase, Вы писали:


H>>Пересесть на System.Tuple, доступный в .NET 4.0 (для .NET 2.0/3.5 написать аналог).


C>Более общий вопрос: какие фреймворки поддерживать? Вариант 2.0 и выше мне нравится больше всего, но дублирование функционального API из linq и того же System.Tuple — это не очень хорошо.


Думаю .NET 4.0 или даже 5.0 . К тому времени все что меньше 4.0 будет не актуально.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re: Синтаксические макросв в Nemerle 2.0
От: Aleх  
Дата: 19.06.10 14:52
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>В 2.0 планируется реализовать новую систему синтаксических макросов (макросов расширяющих синтаксис языка).


VD>Это потребует переработки всей системы парсинга.


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


VD>Минусы:

VD>1. В макросах нельзя будет производить побочных эффектов, так как правила описываемые макросами могут вызываться при парсинге ветвей грамматики которые в последствии будут отброшены как не верные.
VD>2. Пока не ясно (и это следует обсудить) как в такой схеме воспроизвести синтаксис базируемый на отступах. Как вариант, можно просто от него отказаться. Возможно, что данную проблему получится решить самими же макросами (введя альтернативные макросы для парсинга последовательностей и элементов верхнего уровня. Хорошо бы, чтобы кто-то продумал это.
Если парсер поддерживате наследуемые атрибуты, можно просто передавать желаемую ширину отступа в дочернее правило, а там будет предикат, определяющий равенство количества отступов заданному. Вроде ничего сложного. Но лично мне не нравится такой синтаксис, и хотелось бы иметь возможность конвертировать из одного в другой.
VD>3. Парсер построенный в лоб на базе PEG неминуемо будет более медленным и прожорливым по сравнению с ручным. Это потребует потратить не мало времени на оптимизацию. Нужно реализовать генерацию ДКА для терминальных правил (разбирающих символы строки).
VD>4. Весь код файла придется грузить в память перед парсингом (это требование алгоритма связанного с парсингом PEG-а). На сегодня это вряд ли будет проблемой. Если только на мобильных девайсах, где немерл и так не работает.
VD>5. Придется парсить весь файл целиком, без предварительной токенизации и шага препарс (где на сегодня производится свертка токенов в группы). Это так же накладывает дополнительные требования на скорость парсинга (т.е. на оптимизацию PEG-а). Это же не позволит парсить части фалов (как это сейчас делает интеграция), но оно и правильно, так как это неминуемо ведет к проблемам в работе интеграции.
Что в таком случае будет с диагностикой ошибок? Ведь макросы дадут возможность менять не только синтаксис, используя ограниченный набор типов лексем, но и вводить лексические конструкции (к примеры новый вид комментариев).
Почему бы все таки не оставить лексер, который будет выделять пробелы, слова (ключевые слова, идентификаторы и тд), операторы, строки и комментарии?
Такие неограниченный возможности изменения синтаксиса могут привести к тому, что
— парсер будет дико медленно работать
— язык будет превращаться в брейнфак
— реализация диагностики ошибок и предложенных оптимизаций(генераций ДКА) будет чрезвычайно сложна в реализации, что в итоге сделает такой автоматический парсер гораздо сложнее написанного вручную
В итоге, я думаю в любом случае необходимо наложить некоторые ограничения на изменение синтаксиса.

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

VD>7. Невозможно будет предсказать, что два подправила в операторе приоритетного выбора не конфликтуют. Правило стоящее первым будет всегда оказываться "победителем". Если правило разобралось, то для других даже не будет производиться попытка разбора. Возможно, имеет смысл кроме оператора приоритетного выбора PEG-а "/" ввести стандартный оператор перечисления равноценных правил "|" из BNF с тем, чтобы программисты могли явно выражать, что отдельные правила (макросы) не должны пересекаться и тем самым заставлять компилятор проверять это условие. Однако прочерка может оказаться трудной в реализации, так как для выявления эквивалентности правил придется строить для них конечный автомат (что приближает нас к ANTLR 3, и является весьма сложным занятием... особенно для динамически расширяемого парсера).
Считается, что это невозможно. И несмотря на то, что в некоторых случаях возмножно определить неоднозначность правил, это приведет к усложнению парсера, и как следствие, к тормозам
VD>8. В макросах придется явно указывать пробельные символы. PEG позволяет обходиться без лексера, что координатно повышает гибкость и модульность парсера, но за это надо платить.
Это очень неудобно. Должно быть соглашение о том, где добавлять пробелы в дочернем правиле или родительском, иначе неосторожное написание макросов приведет к тому, что от количества пробелов будет зависеть применится ли макрос или нет.
Re: Уйти от с SRE
От: hardcase Пират http://nemerle.org
Дата: 20.06.10 15:38
Оценка:
Уйти от IL-эмиттера на SRE.
Кандидат уже выбран?
/* иЗвиНите зА неРовнЫй поЧерК */
Re[2]: Уйти от с SRE
От: VladD2 Российская Империя www.nemerle.org
Дата: 20.06.10 20:06
Оценка:
Здравствуйте, hardcase, Вы писали:

H>Уйти от IL-эмиттера на SRE.

H>Кандидат уже выбран?

CCI
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[3]: Уйти от с SRE
От: catbert  
Дата: 20.06.10 20:12
Оценка:
VD>CCI

Над ним еще и Москаль работает: http://ccimetadata.codeplex.com/team/view
Re[4]: Уйти от с SRE
От: VladD2 Российская Империя www.nemerle.org
Дата: 21.06.10 13:19
Оценка:
Здравствуйте, catbert, Вы писали:

VD>>CCI


C>Над ним еще и Москаль работает: http://ccimetadata.codeplex.com/team/view


Не над ним, а используя его.
Это было дополнительным аргументом в пользу CCI.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[2]: Синтаксические макросв в Nemerle 2.0
От: VladD2 Российская Империя www.nemerle.org
Дата: 21.06.10 15:11
Оценка:
Здравствуйте, Aleх, Вы писали:

A>Будет ли это значить, что макросы можно объявлять и использовать в одной и той же единице компиляции?


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

То есть, можно будет сделать вот так (см. выделенное):

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

  macro attr(id, _, _, value) : XmlAst
  syntax: identifier '=' s attrValue;
  {
    Attr(id.Value.StartPos, value.Value.EndPos, id.Value, value.Value)
  }
}


А так, нельзя:
macro class Xml
{
  macro tagOpen(lt, _, id, attrs, gt, _) : XmlAst.TagOpen
  syntax: '<' s identifier attr* '>' s
  {
    <[ ... $attr ... ]>
  }

  macro attr(id, _, _, value) : XmlAst
  syntax: identifier '=' s attrValue;
  {
    Attr(id.Value.StartPos, value.Value.EndPos, id.Value, value.Value)
  }
}


A>Как я понимаю, авторы немерле планировали реализовать эту фичу.


Не особо. Была расплывчатая фраза вроде "Это остается предметом будущих исследований.". И то эта фраза была в какой-то институтской работе.

VD>>2. Пока не ясно (и это следует обсудить) как в такой схеме воспроизвести синтаксис базируемый на отступах. Как вариант, можно просто от него отказаться. Возможно, что данную проблему получится решить самими же макросами (введя альтернативные макросы для парсинга последовательностей и элементов верхнего уровня. Хорошо бы, чтобы кто-то продумал это.

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

Парсера как такового, как я уже говорил, не будет. Макросы могут передавать что угодно, но как-то не хочется нагружать не относящиеся к отступам макросы дополнительной работой.

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

VD>>5. Придется парсить весь файл целиком, без предварительной токенизации и шага препарс (где на сегодня производится свертка токенов в группы). Это так же накладывает дополнительные требования на скорость парсинга (т.е. на оптимизацию PEG-а). Это же не позволит парсить части фалов (как это сейчас делает интеграция), но оно и правильно, так как это неминуемо ведет к проблемам в работе интеграции.


A>Что в таком случае будет с диагностикой ошибок?


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

Выявить место ошибки при этом так же будет можно если вести в процессе парсинга выявлять макросы/правила которые не разобралось при самом большой позиции. Однако кроме того еще нужно будет обеспечить стратегию восстановления после ошибки. Для этого нужно будет или вводить специализированный механизм отсечения (о котором я как-то говорил в Философии), или создавать специализированные макросы отлавливающие ошибочную ситуацию, выдающие сообщение о ошибке и пропускающие входной поток до момента с которого можно продолжить парсинг в штатном режиме. Скажу честно, что тут еще нужно произвести некоторые исследования, но в целом задача выглядит вполне понятной и реализуемой.

A>Ведь макросы дадут возможность менять не только синтаксис, используя ограниченный набор типов лексем, но и вводить лексические конструкции (к примеры новый вид комментариев).


Да, это так. Но чем это может помешать обработке ошибок?

A>Почему бы все таки не оставить лексер, который будет выделять пробелы, слова (ключевые слова, идентификаторы и тд), операторы, строки и комментарии?


Потому что это ограничит возможность встраивания нового синтаксиса в язык. В озвученном варианте синтаксис может меняться практически без ограничений. В плоть до того, что с помощью некоторой прагмы можно будет разбирать синтаксис Паскаля или C#-а.

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

A>Такие неограниченный возможности изменения синтаксиса могут привести к тому, что


Не понял. Что и где ограничено?

A>- парсер будет дико медленно работать


Практика показывает, что даже в текущем (не сильно оптимизированном виде) парсер на базе PEG работает с приемлемой скоростью. Если учесть, что нами планируется ввести ряд оптимизаций (построение ДКА для терминальных правил, точки отсечения и мемоизация результатов некоторых правил), то можно смело предположить, что скорость будет приемлемой. Причем приемлемой не только для компилятора, но и для работы в рамках интеграции.

A>- язык будет превращаться в брейнфак


Вот это точно не соответствует действительности. Наличие мощной системы макросов позволяющей менять синтаксис почти как угодно не означает, что язык (точнее его стандартная библиотека макросов) будет превращена в помойку.

Конечно кто-то нерадивый может превратить в помойку свой код, но это его проблемы. За чистотой стандартной библиотеки будет следить все сообщество.

A>- реализация диагностики ошибок и предложенных оптимизаций(генераций ДКА) будет чрезвычайно сложна в реализации, что в итоге сделает такой автоматический парсер гораздо сложнее написанного вручную


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

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


Зачем?

В прочем, некоторые ограничения конечно же будут. Так расширять синтаксис можно будет только в точках расширения специально предусмотренных теми кто будет писать стандартные макросы компилятора (т.е. грамматику языка).

Пока что планируется введение точек расширений на следующих уровнях:
1. На уровне файлов (скорее всего с помощью прагм). Это позволит вводить собственные языки. Возможно, что синтаксис базируемый на отступах будет сделать именно макросом такого типа.
2. На уровне пространств имен (для введения собственных конструкций верхнего уровня). Например, собственных типов).
3. На уровне префиксов и суффиксов типов. Например, чтобы можно было организовать синтаксис вида:
class A
  invariant x == 10
{
  ...

4. На уровне содержимого типов. Для введения своих членов типов.
5. На уровне префиксов и суффиксов стандартных членов типов.
6. На уровне выражений (в телах членов).
7. На уровне макро-атрибутов.
8. Будет так же предусмотрен специальный синтаксис для введения унарных и бинарных операторов.

Точки расширений можно будет так же вставлять и в самодельные макросы. Это будет стандартный механизм расширения. Общая идея точек расширения заключается в том, что в некоторые списки приоритетного выбора можно будет добавить специальное правило подразумевающее, что на его место в рантайме могут подставляться те или иные макросы. Точка расширения должно будет описывать тип который обязан возвращать макрос который желает быть примененным в данной точке расширения. Таким образом если мы хотим позволить расширять синтаксис членов типов, то в макрос описывающий список доступных типов мы должны будем добавить точку расширения:
member(member) : ClassMember
syntax: method / property / field / type;
expansible: instead, besides // позволяет вставить новые правила вперед списка или в его конец
{
  member
}


VD>>7. Невозможно будет предсказать, что два подправила в операторе приоритетного выбора не конфликтуют. Правило стоящее первым будет всегда оказываться "победителем". Если правило разобралось, то для других даже не будет производиться попытка разбора. Возможно, имеет смысл кроме оператора приоритетного выбора PEG-а "/" ввести стандартный оператор перечисления равноценных правил "|" из BNF с тем, чтобы программисты могли явно выражать, что отдельные правила (макросы) не должны пересекаться и тем самым заставлять компилятор проверять это условие. Однако прочерка может оказаться трудной в реализации, так как для выявления эквивалентности правил придется строить для них конечный автомат (что приближает нас к ANTLR 3, и является весьма сложным занятием... особенно для динамически расширяемого парсера).

A>Считается, что это невозможно.

Можно разрешить выбор по ИЛИ в том случае когда компилятор в силах построить ДКА для всех вариантов перечисления и доказать тем самым, что правила не конфликтуют. Скажем совершенно не ясно зачем по очереди пытаться спарсить декларацию всех видов типов когда с помощью построения ДКА можно сразу перейти к разбору конеретного вида.

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

A>И несмотря на то, что в некоторых случаях возмножно определить неоднозначность правил, это приведет к усложнению парсера, и как следствие, к тормозам


Ну, к тормозам это точно привести не может, так как данные вычисления должны будут производиться не на стадии работы макросов, а на стадии их компиляции. Правда любые предвычисления связаны кроме всего с отказом от расширяемости. Так оператор ИЛИ не будет позволять встроить точку расширения. Но можно будет ведь создать правила таким образом:
standardMember(member) : ClassMember
syntax: method | property | field | type;
{
  member
}

member(member) : ClassMember
syntax: standardMember;
expansible: instead, besides // позволяет вставить новые правила вперед списка или в его конец
{
  member
}

Тогда компилятор сможет проверить непротиворечивость правил в standardMember и построить для него эффективный код, а member будет обеспечивать расширяемость.

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

VD>>8. В макросах придется явно указывать пробельные символы. PEG позволяет обходиться без лексера, что координатно повышает гибкость и модульность парсера, но за это надо платить.

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

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

Возможно имеет смысл ввести два типа макросов. В одном можно будет манипулировать пробельными символами явно, а в другом компилятор будет не явно подставлять правило "s" после каждой грамматической конструкции. Например, вот как это может выглядеть.
Вариант без учета пробельных символов:
  macro tagOpen(lt, id, attrs, gt) : XmlAst.TagOpen
  syntax: '<' identifier attr* '>'
  {
    TagOpen(lt.StartPos, gt.EndPos, id.Value, attrs.Map(x => x.Value :> Attr))
  }

Вариант с их учетом (исходный):
  macro tagOpen(lt, _, id, attrs, gt, _) : XmlAst.TagOpen
  autospace: false
  syntax: '<' s identifier attr* '>' s
  {
    TagOpen(lt.StartPos, gt.EndPos, id.Value, attrs.Map(x => x.Value :> Attr))
  }

В первом варианте подразумевается, что "autospace: true", что означает, что после каждого элемента грамматики не явно вставляется правило "s".

Кстати, вставка правила "s" более одного раза подряд не приведет к проблемам, так как правило не обязательное. Ну, и компилятор сможет устранять лишние "s", так что можно смело лепить их "на всякий пожарный".
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re: Синтаксические макросв в Nemerle 2.0 ++
От: VladD2 Российская Империя www.nemerle.org
Дата: 23.06.10 20:01
Оценка:
Кроме того планируется ввести декларативное описание зависимостей между макросами. Пример (гипотетический) синтаксиса:
[MacroUsage(MacroPhase.BeforeTypedMembers, MacroTargets.Class)]
macro AbstractFactory(tb : TypeBuilder, params classes : list [PExpr])
  depends on: Record
{

Это объявление означает, что макрос AbstractFactory зависит от результатов работы макроса Record, и что сначала должны будут раскрыться макросы Record, а затем уже AbstractFactory.

Конечно это касается только макросов работающих на одной и той же стадии компиляции.

Рекурсивные зависимости не допустимы. Зависимости от макросов не работающих на данной стадии так же недопустимы.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re: Nemerle 2.0
От: _nn_ www.nemerleweb.com
Дата: 24.06.10 11:56
Оценка: 15 (1)
Здравствуйте, VladD2, Вы писали:

Исправить систему типов для уменьшения NRE:
Разделить типы на два вида: которые могут принимать null и которые не могут принимать null значение.

http://groups.google.com/group/nemerle-en/browse_thread/thread/54394c3dd1a8fa83
http://rsdn.nemerleweb.com
http://nemerleweb.com
Re: Nemerle 2.0
От: _nn_ www.nemerleweb.com
Дата: 01.07.10 07:46
Оценка:
Здравствуйте, VladD2, Вы писали:

Хотелось бы возможности создания операций пересекающимися с именами макросов.

В частности операциии && и ||.
http://rsdn.nemerleweb.com
http://nemerleweb.com
Re: Вынести процесс генерации MSIL-а в отдельную стадию
От: VladD2 Российская Империя www.nemerle.org
Дата: 06.07.10 16:48
Оценка:
Во второй версии так же нужно вынести процесс генерации MSIL-а в отдельную стадию.

Сейчас генерация кода методов производится сразу после окончания типизации их тел. Эмит структур данных должен происходить до того как они используются при генерации кода методов. Это создает серьезные проблемы. Так это препятствует генерации полей класса или модуля из макросов уровня выражений. Это происходит потому, что SRE-структуры генерируются после вызова метода TypwBuilder.Compile(), но после его вызова в класс уже невозможно добавить новые элементы.

Вынесение генерации MSIL-а в отдельную стадию позволит избежать проблем подобных описанным выше, а так же сделает код более чистым и менее связанным.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[2]: Вынести процесс генерации MSIL-а в отдельную стадию
От: SergASh  
Дата: 07.07.10 06:44
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Сейчас генерация кода методов производится сразу после окончания типизации их тел. Эмит структур данных должен происходить до того как они используются при генерации кода методов. Это создает серьезные проблемы. Так это препятствует генерации полей класса или модуля из макросов уровня выражений. Это происходит потому, что SRE-структуры генерируются после вызова метода TypwBuilder.Compile(), но после его вызова в класс уже невозможно добавить новые элементы.


В CCI это решено?
Re[3]: Вынести процесс генерации MSIL-а в отдельную стадию
От: VladD2 Российская Империя www.nemerle.org
Дата: 07.07.10 07:04
Оценка:
Здравствуйте, SergASh, Вы писали:

VD>>Сейчас генерация кода методов производится сразу после окончания типизации их тел. Эмит структур данных должен происходить до того как они используются при генерации кода методов. Это создает серьезные проблемы. Так это препятствует генерации полей класса или модуля из макросов уровня выражений. Это происходит потому, что SRE-структуры генерируются после вызова метода TypwBuilder.Compile(), но после его вызова в класс уже невозможно добавить новые элементы.


SAS>В CCI это решено?


Мне кажется это можно решить даже на SRE. Тут нужно менять логику генерации кода компилятора. Сейчас код генерируется сразу после окончания компиляции кода. А надо чтобы сначала проходила типизация всех тел методов, а потом уже отдельным шагом генерировать МСИЛ.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re: Nemerle 2.0
От: _nn_ www.nemerleweb.com
Дата: 12.07.10 04:48
Оценка:
Здравствуйте, VladD2, Вы писали:

Еще желаемые фичи.

Частичное применение вида:
  • _.Property = Value.
  • _.Property1 = _.Property2 = Value

    Операции == == , < < , < > , > > .
  • a == b == c
  • a < b < c
  • a < b > c
  • a > b > c

    А так же с <= , >= .
    Как в Python.
  • http://rsdn.nemerleweb.com
    http://nemerleweb.com
    Re[2]: Nemerle 2.0
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 12.07.10 13:14
    Оценка:
    Здравствуйте, _nn_, Вы писали:

    __>Еще желаемые фичи.


    __>Частичное применение вида:

    __>
  • _.Property = Value.
    __>
  • _.Property1 = _.Property2 = Value

    Это уже не частичное применение. Да и на таком объеме "x => " уже ни на что не влияет.

    __>Операции == == , < < , < > , > > .

    __>
  • a == b == c
    __>
  • a < b < c
    __>
  • a < b > c
    __>
  • a > b > c

    __>А так же с <= , >= .

    __>Как в Python.

    Ну, не знаю. На мой взгляд такое применение часто только в примерах нужно. Макросом это дело и сейчас можно сделать, а вот введение в синтаксис языка этого дела может быть не простым занятием.
  • Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re: Многопоточность
    От: hardcase Пират http://nemerle.org
    Дата: 13.07.10 06:43
    Оценка:
    Исходя из того, что планируется (где писалось не нашел) сделать дерево типов версионным, было бы неплохо добавить поддержку многопоточности в типизатор. Например параллельно типизировать несколько тел методов, это позволило бы некисло ускорить работу компилятора.
    /* иЗвиНите зА неРовнЫй поЧерК */
    Re[2]: Многопоточность
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 13.07.10 15:42
    Оценка:
    Здравствуйте, hardcase, Вы писали:

    H>Исходя из того, что планируется (где писалось не нашел) сделать дерево типов версионным, было бы неплохо добавить поддержку многопоточности в типизатор. Например параллельно типизировать несколько тел методов, это позволило бы некисло ускорить работу компилятора.


    Для того все это и планируется.

    Думаю первым шагом будет просто рефакторинг того движка типизации что есть сейчас. Кое-какую многопоточность можно будет ввести уже на этом этапе. Но для полного кайфа нужно полность переписывать все это дело вводя версионность в структуры данных.
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re: Макросы высших порядков
    От: hardcase Пират http://nemerle.org
    Дата: 10.08.10 06:44
    Оценка:
    Сейчас компилятор на попытку объявить квазицитату с макросом:
    <[ decl: macro X(x) { x } ]>

    Сообщает следующее:
    [quote]
    quoting macro is not supported — macros should not create macros, it is Bad(TM)
    [/quote]

    Мне такое ограничение видится искусственным.
    /* иЗвиНите зА неРовнЫй поЧерК */
    Re[2]: Макросы высших порядков
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 17.08.10 17:29
    Оценка:
    Здравствуйте, hardcase, Вы писали:

    H>Сейчас компилятор на попытку объявить квазицитату с макросом:

    H>
    H><[ decl: macro X(x) { x } ]>
    H>

    H>Сообщает следующее:
    H>[quote]
    H>quoting macro is not supported — macros should not create macros, it is Bad(TM)
    H>[/quote]

    H>Мне такое ограничение видится искусственным.


    А мне видится свершенно нормальным, учитывая компилируемую природу языка.
    "macro" это всег лишь точка входа. Ее генерировать бессмыселнно. Если же нужно генерировать мкро-код (т.е. код который в свою очередь будет порождать код), то это вполне возможно.
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re[3]: Синтаксические макросв в Nemerle 2.0
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 01.11.10 17:42
    Оценка:
    Здравствуйте, VladD2, Вы писали:

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


    Похоже, что проблема ручного задания местоположений решена. Уже современный PegGrammar умеет указывать их автоматически. В новых синтаксических макросах мы будем автоматом сохранять все местоположения (значимые в самом AST, а не значимые (вроде местоположений литералов) в массивах прикрепляемых к АСТ).
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re[2]: Вынести процесс генерации MSIL-а в отдельную стадию
    От: Воронков Василий Россия  
    Дата: 02.11.10 08:43
    Оценка:
    Здравствуйте, VladD2, Вы писали:

    VD>Вынесение генерации MSIL-а в отдельную стадию позволит избежать проблем подобных описанным выше, а так же сделает код более чистым и менее связанным.


    В идеале мне кажется сделать свой бэкенд — как минимум свой байт-код — и компилировать в него. Потом уже осуществлять поддержку конкретных бэкендов создавая трансляторы, например, свой байт код -> MSIL. Это если действительно хочется в перспективе поддерживать тот же LLVM и расширить, так сказать, клиентскую базу за пределы дотнетчиков. Плюс для своего бэкенда можно будет сварганить виртуальную машину и получить полноценный РЕПЛ.
    Re[3]: Вынести процесс генерации MSIL-а в отдельную стадию
    От: hardcase Пират http://nemerle.org
    Дата: 02.11.10 08:53
    Оценка:
    Здравствуйте, Воронков Василий, Вы писали:


    ВВ>Плюс для своего бэкенда можно будет сварганить виртуальную машину и получить полноценный РЕПЛ.


    РЕПЛ не нужен
    /* иЗвиНите зА неРовнЫй поЧерК */
    Re[4]: Вынести процесс генерации MSIL-а в отдельную стадию
    От: Воронков Василий Россия  
    Дата: 02.11.10 08:54
    Оценка: :))
    Здравствуйте, hardcase, Вы писали:

    ВВ>>Плюс для своего бэкенда можно будет сварганить виртуальную машину и получить полноценный РЕПЛ.

    H>РЕПЛ не нужен

    Не, не прокатит. Я сегодня не в настроении.
    Re: Nemerle 2.0
    От: _nn_ www.nemerleweb.com
    Дата: 20.01.11 08:57
    Оценка: 9 (2) +2
    Здравствуйте, VladD2, Вы писали:

    VD>В этой теме будут публиковаться мысли связанные со второй версий компилятора.


    VD>Приблизительная тематика:

    VD>1. Список фич отложенных до 2.0 (которые не будут реализованы в 1.0 или будут реализованы не полностью).
    VD>2. Изменения планируемые на вторую версию.
    VD>3. Стратегические и идеологические мысли по поводу 2.0.
    VD>4. Технические аспекты.

    VD>ЗЫ


    VD>Просьбы не засорять тему обсуждениями (открывайте другие темы). Эта тема — копилка того что нужно не забыть реализовать в 2.0 и для серьезных вопросов.


    Добавить в match поддержку массивов и IEnumerable.
    http://rsdn.nemerleweb.com
    http://nemerleweb.com
    Re[3]: Вынести процесс генерации MSIL-а в отдельную стадию
    От: Visor2004  
    Дата: 20.01.11 12:47
    Оценка:
    Здравствуйте, Воронков Василий, Вы писали:

    что такое "РЕПЛ"?
    Помните!!! ваш говнокод кому-то предстоит разгребать.
    Re[4]: Вынести процесс генерации MSIL-а в отдельную стадию
    От: hardcase Пират http://nemerle.org
    Дата: 20.01.11 13:37
    Оценка:
    Здравствуйте, Visor2004, Вы писали:

    V>Здравствуйте, Воронков Василий, Вы писали:


    V>что такое "РЕПЛ"?


    REPL = Read-eval-print loop
    /* иЗвиНите зА неРовнЫй поЧерК */
    Re: Nemerle 2.0
    От: hardcase Пират http://nemerle.org
    Дата: 21.01.11 08:21
    Оценка:
    Здравствуйте, VladD2, Вы писали:

    Интересная ссылка.
    /* иЗвиНите зА неРовнЫй поЧерК */
    Re[2]: Nemerle 2.0
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 21.01.11 12:59
    Оценка:
    Здравствуйте, hardcase, Вы писали:

    H>Интересная ссылка.


    Что это?
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re[3]: Nemerle 2.0
    От: Visor2004  
    Дата: 21.01.11 13:06
    Оценка:
    Здравствуйте, VladD2, Вы писали:

    VD>Здравствуйте, hardcase, Вы писали:


    H>>Интересная ссылка.


    VD>Что это?


    Lisp
    Помните!!! ваш говнокод кому-то предстоит разгребать.
    Re[4]: Nemerle 2.0
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 21.01.11 13:41
    Оценка:
    Здравствуйте, Visor2004, Вы писали:

    H>>>Интересная ссылка.

    VD>>Что это?
    V>Lisp

    Какое-то странное имя у этого диалекта — "A Meta Language Kit for the Web".
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re[3]: [Snippets] Обновленный макрос with
    От: catbert  
    Дата: 21.01.11 14:00
    Оценка:
    Здравствуйте, VladD2, Вы писали:

    VD>Здравствуйте, hardcase, Вы писали:


    H>>Интересная ссылка.


    VD>Что это?


    Это диалект Scheme, который работает на виртуальной машине флеша и с помощью PEG (фактически там есть PEG-препроцессор, который превращает код в Scheme) парсит другой язык — Forall — похожий на Джаваскрипт, и скармливает его ВМ. Как-то так.

    Практически это наверное не особо полезно, потому что нативный для флеша ActionScript тоже похож на Джаваскрипт. Но поскольку в статье есть макросы, PEG, лисп и веб — она автоматически становится интересной
    Re[4]: [Snippets] Обновленный макрос with
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 21.01.11 14:29
    Оценка:
    Здравствуйте, catbert, Вы писали:

    C>Это диалект Scheme, который работает на виртуальной машине флеша и с помощью PEG (фактически там есть PEG-препроцессор, который превращает код в Scheme) парсит другой язык — Forall — похожий на Джаваскрипт, и скармливает его ВМ. Как-то так.


    Да предисловие я прочел. Но к чему это все?

    C>Практически это наверное не особо полезно, потому что нативный для флеша ActionScript тоже похож на Джаваскрипт. Но поскольку в статье есть макросы, PEG, лисп и веб — она автоматически становится интересной


    Ну, так не плохо было бы указать на то что там интересного. А то подобных работ не мало. И читать про каждую из них как-то не хочется.
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re[2]: Nemerle 2.0
    От: WolfHound  
    Дата: 21.01.11 15:02
    Оценка:
    Здравствуйте, hardcase, Вы писали:

    H>Интересная ссылка.

    Полезной информации ноль целых хрен десятых.
    ... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
    Пусть это будет просто:
    просто, как только можно,
    но не проще.
    (C) А. Эйнштейн
    Re[3]: Nemerle 2.0
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 21.01.11 15:40
    Оценка:
    Здравствуйте, WolfHound, Вы писали:

    H>>Интересная ссылка.

    WH>Полезной информации ноль целых хрен десятых.

    Я беглым взглядом пробежался и мне тоже так показалось, но не хочет быть столь же категоричным. Может Хардкейс что-то конкретное имел в виду.
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re[4]: Nemerle 2.0
    От: hardcase Пират http://nemerle.org
    Дата: 21.01.11 15:50
    Оценка:
    Здравствуйте, VladD2, Вы писали:

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


    Просто, документик заинтересовал, но ничего конкретного Раз такие дела, ветку можно прикрыть за ненадобностью.
    /* иЗвиНите зА неРовнЫй поЧерК */
    Re: Nemerle 2.0
    От: _nn_ www.nemerleweb.com
    Дата: 26.06.11 10:44
    Оценка:
    Здравствуйте, VladD2, Вы писали:

    VD>Просьбы не засорять тему обсуждениями (открывайте другие темы). Эта тема — копилка того что нужно не забыть реализовать в 2.0 и для серьезных вопросов.


    Убрать хардкод с '$'.

    (Невозможно создать макрос начинающийся с '$' )
    http://rsdn.nemerleweb.com
    http://nemerleweb.com
    Re[3]: Вынести процесс генерации MSIL-а в отдельную стадию
    От: BogdanMart Украина  
    Дата: 26.06.11 12:48
    Оценка:
    Здравствуйте, Воронков Василий, Вы писали:

    ВВ>В идеале мне кажется сделать свой бэкенд — как минимум свой байт-код — и компилировать в него.


    Зачем свой байткод, если есть AST ?


    зы. (офтопик) не понятно зачем вообще байткоди почему макфрософт не хранить в бинарниках щасериализорованое АСТ.
    Re[4]: Вынести процесс генерации MSIL-а в отдельную стадию
    От: Мишень-сан  
    Дата: 27.06.11 05:55
    Оценка:
    Здравствуйте, BogdanMart, Вы писали:

    BM>зы. (офтопик) не понятно зачем вообще байткоди почему макфрософт не хранить в бинарниках щасериализорованое АСТ.


    Наверное потому, что AST разных языков может отличаться. Байткод более низкоуровневый, а потому более универсальный.
    Re[4]: Вынести процесс генерации MSIL-а в отдельную стадию
    От: WolfHound  
    Дата: 27.06.11 09:07
    Оценка: +2
    Здравствуйте, BogdanMart, Вы писали:

    BM>зы. (офтопик) не понятно зачем вообще байткоди почему макфрософт не хранить в бинарниках щасериализорованое АСТ.

    Байткод это сериализованный АСТ языка MSIL.
    ... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
    Пусть это будет просто:
    просто, как только можно,
    но не проще.
    (C) А. Эйнштейн
    Re[4]: Вынести процесс генерации MSIL-а в отдельную стадию
    От: Воронков Василий Россия  
    Дата: 27.06.11 09:48
    Оценка: +1
    Здравствуйте, BogdanMart, Вы писали:

    BM>Зачем свой байткод, если есть AST ?


    В данном случае — необязательно именно байт-код, можно и АСТ. Вот только все равно придется делать "свое" абстрактное АСТ.

    BM>зы. (офтопик) не понятно зачем вообще байткоди почему макфрософт не хранить в бинарниках щасериализорованое АСТ.


    АСТ какого языка хранить в бинарнике?
    Даже если бы язык был один, байт-код есть уже результат первичной компиляции, к которому был применен ряд оптимизаций. Его компиляция произойдет быстрее (или интерпретация).
    Наконец байт-код тупо компактнее.
    Re[5]: Вынести процесс генерации MSIL-а в отдельную стадию
    От: BogdanMart Украина  
    Дата: 27.06.11 21:29
    Оценка: :)
    Здравствуйте, Воронков Василий, Вы писали:

    ВВ>АСТ какого языка хранить в бинарнике?

    ВВ>Даже если бы язык был один, байт-код есть уже результат первичной компиляции, к которому был применен ряд оптимизаций. Его компиляция произойдет быстрее (или интерпретация).
    ВВ>Наконец байт-код тупо компактнее.

    Какой то очень абстрактный и низкоуровневый.

    Просто не понятно чем стековая машинатакая крутая?

    Помоему компиляция из такого байткода в реальные инструкции -- ад

    Приходиться разбирать байткод, потом оптимизировать. А байткод зачастую далеко не оптимальный (Самый чисты байткод у Managed C++)

    Но JIT'c довольно однозначно, но в тупую транслирует байткод и результат получаеться довольно далек от оптимума(ох я и поржал над его результатами)

    например такой код

    call MethodName
    stloc.3
    ldloc.3
    .....

    после вызова делает
    mov [ebp+6], eax //stloc.3
    mov eax, [ebp+6] //ldloc.3

    Что, согласитесь, совсем не оптимально потому что байткод уже оптимизироавть почтине реально и CLR втупую странслирует его на асм.


    еслибы сгенерить хотябы
    dup
    stloc.3

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

    А я про сам байткод (MSIL точнее), оперировали бы они перемеными а не стеком, было бы проще генерировать машинный код на его основе.
    Re[6]: Вынести процесс генерации MSIL-а в отдельную стадию
    От: WolfHound  
    Дата: 27.06.11 22:01
    Оценка: +1
    Здравствуйте, BogdanMart, Вы писали:

    BM>Просто не понятно чем стековая машинатакая крутая?

    Это самое компактное представление кода.

    BM>Помоему компиляция из такого байткода в реальные инструкции -- ад

    Не сложнее чем из исходника на C#.

    BM>Что, согласитесь, совсем не оптимально потому что байткод уже оптимизироавть почтине реально и CLR втупую странслирует его на асм.

    То что JIT хреново оптимизирует с этим не поспоришь.
    То что это вина байткода ты не прав.

    BM>А я про сам байткод (MSIL точнее), оперировали бы они перемеными а не стеком, было бы проще генерировать машинный код на его основе.

    Стековую машину можно превратить в регистровую за один проход тупейшим алгоритмом.
    ... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
    Пусть это будет просто:
    просто, как только можно,
    но не проще.
    (C) А. Эйнштейн
    Re[6]: Вынести процесс генерации MSIL-а в отдельную стадию
    От: Воронков Василий Россия  
    Дата: 28.06.11 04:50
    Оценка:
    Здравствуйте, BogdanMart, Вы писали:

    ВВ>>АСТ какого языка хранить в бинарнике?

    ВВ>>Даже если бы язык был один, байт-код есть уже результат первичной компиляции, к которому был применен ряд оптимизаций. Его компиляция произойдет быстрее (или интерпретация).
    ВВ>>Наконец байт-код тупо компактнее.
    BM>Какой то очень абстрактный и низкоуровневый.
    BM>Просто не понятно чем стековая машинатакая крутая?

    В смысле "чем крутая"? Для кого крутая? Технически, основной плюс — компактность инструкций по сравению с регистровой.

    BM>Помоему компиляция из такого байткода в реальные инструкции -- ад


    Обычная трансляция из стекового байткода в регистровый. И ее можно произвести *гораздо* быстрее, чем многопроходную первоначальную компиляцию в MSIL. Липперт как-то писал о том, сколько стадий у компилятора C#.

    BM>Приходиться разбирать байткод, потом оптимизировать. А байткод зачастую далеко не оптимальный (Самый чисты байткод у Managed C++)


    И что?

    BM>Но JIT'c довольно однозначно, но в тупую транслирует байткод и результат получаеться довольно далек от оптимума(ох я и поржал над его результатами)


    Как проверяли? Очень похоже на запуск дебуг версии.

    BM>еслибы сгенерить хотябы

    BM>dup
    BM>stloc.3
    BM>Тогда можно изббежать лишнего чтения из локальной переменной, но это уже про корявость компиляторов управляемых.

    Нет, вы пожалуйста продолжайте. Приведите, пожалуйста, x86 код, в который скомпилируется dup stloc.3

    BM>А я про сам байткод (MSIL точнее), оперировали бы они перемеными а не стеком, было бы проще генерировать машинный код на его основе.


    Эту мысль я не понял.
    Re[6]: Вынести процесс генерации MSIL-а в отдельную стадию
    От: hardcase Пират http://nemerle.org
    Дата: 28.06.11 06:52
    Оценка: +1
    Здравствуйте, BogdanMart, Вы писали:

    BM>например такой код


    BM>call MethodName

    BM>stloc.3
    BM>ldloc.3
    BM>.....

    BM>после вызова делает

    BM>mov [ebp+6], eax //stloc.3
    BM>mov eax, [ebp+6] //ldloc.3

    BM>Что, согласитесь, совсем не оптимально потому что байткод уже оптимизироавть почтине реально и CLR втупую странслирует его на асм.


    Байткод оптимизировать вполне реально, и по сути это лишь проблема конкретных кодогенераторов. Если тебе не нравится, какой код генерирует Nemerle можешь вполне закопаться в ILEmitter (который на самом деле стоит просто выбросить) — нам не точно не помешает объектная модель IL и CFG-оптимизатор.
    /* иЗвиНите зА неРовнЫй поЧерК */
    Re[7]: Вынести процесс генерации MSIL-а в отдельную стадию
    От: catbert  
    Дата: 28.06.11 09:33
    Оценка:
    Здравствуйте, hardcase, Вы писали:

    H>Байткод оптимизировать вполне реально, и по сути это лишь проблема конкретных кодогенераторов. Если тебе не нравится, какой код генерирует Nemerle можешь вполне закопаться в ILEmitter (который на самом деле стоит просто выбросить) — нам не точно не помешает объектная модель IL и CFG-оптимизатор.


    У нас ведь CFG есть вроде?
    Re[8]: Вынести процесс генерации MSIL-а в отдельную стадию
    От: WolfHound  
    Дата: 28.06.11 09:57
    Оценка: +1
    Здравствуйте, catbert, Вы писали:

    C>У нас ведь CFG есть вроде?

    Лучшеб его небыло. Глючит страшно.
    ... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
    Пусть это будет просто:
    просто, как только можно,
    но не проще.
    (C) А. Эйнштейн
    Re[8]: Вынести процесс генерации MSIL-а в отдельную стадию
    От: hardcase Пират http://nemerle.org
    Дата: 28.06.11 10:22
    Оценка:
    Здравствуйте, catbert, Вы писали:

    C>У нас ведь CFG есть вроде?


    Он глючный и почти бесполезный для генерирования IL, так как работает на уровне TExpr.
    /* иЗвиНите зА неРовнЫй поЧерК */
    Re[5]: Вынести процесс генерации MSIL-а в отдельную стадию
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 28.06.11 14:39
    Оценка:
    Здравствуйте, Мишень-сан, Вы писали:

    МС>Наверное потому, что AST разных языков может отличаться. Байткод более низкоуровневый, а потому более универсальный.


    Все прозаичнее. Байткод банально компактнее. А так, он тоже описывает некую модель. Так что никакой разницы нет.
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re[7]: Вынести процесс генерации MSIL-а в отдельную стадию
    От: BogdanMart Украина  
    Дата: 28.06.11 15:06
    Оценка:
    Здравствуйте, Воронков Василий, Вы писали:
    ВВ>Нет, вы пожалуйста продолжайте. Приведите, пожалуйста, x86 код, в который скомпилируется dup stloc.3

    Чертовски странно, раньше я видел другой результат, но сегодня немного по дебльному сгенерировало А в не отладочном проверить не получилось, так как в нем отладчик вообще нивкакую не подключаеться

        stloc.0
    00000035  mov         eax,dword ptr [ebp-30h] 
    00000038  mov         dword ptr [ebp-2Ch],eax 
        ldloc.0             // Load local variable 0 onto stack
    0000003b  mov         eax,dword ptr [ebp-2Ch] 
    0000003e  mov         dword ptr [ebp-34h],eax 
        ldc.i4.0            // Load constant 0 to the stack 
    00000041  xor         edx,edx 
    00000043  mov         dword ptr [ebp-0Ch],edx 
        ldc.i4.s   10        // Load constant 10 to the stack (s form is used for n > 8)
    00000046  mov         dword ptr [ebp-10h],0Ah

    30h и 34h это походу стек ИЛа)))
        dup
    00000035  nop              
        stloc.0
    00000036  mov         eax,dword ptr [ebp-30h] 
    00000039  mov         dword ptr [ebp-2Ch],eax 
    0000003c  mov         eax,dword ptr [ebp-2Ch] 
    0000003f  mov         dword ptr [ebp-34h],eax 
        ldc.i4.0            // Load constant 0 to the stack 
    00000042  xor         edx,edx 
    00000044  mov         dword ptr [ebp-0Ch],edx 
        ldc.i4.s   10        // Load constant 10 to the stack (s form is used for n > 8)
    00000047  mov         dword ptr [ebp-10h],0Ah



    в режиме х64
        stloc.0
    00000042  mov         qword ptr [rsp+20h],rax 
        ldloc.0             // Load local variable 0 onto stack
    00000047  nop              
        ldc.i4.0            // Load constant 0 to the stack 
    00000048  nop              
        ldc.i4.s   10        // Load constant 10 to the stack (s form is used for n > 8)
    00000049  nop
    оно дофига шарит, хотя раньше в этом режиме выдавало такие перлы...))

    00000042  mov         qword ptr [rsp+30h],rax 
             dup
    00000047  mov         rax,qword ptr [rsp+30h] 
        stloc.0
    0000004c  mov         qword ptr [rsp+20h],rax 
        ldc.i4.0            // Load constant 0 to the stack 
    00000051  nop              
        ldc.i4.s   10        // Load constant 10 to the stack (s form is used for n > 8)
    00000052  nop
    немного странно

    Но как видно ведет он себя непредсказуемо
    Re[8]: Вынести процесс генерации MSIL-а в отдельную стадию
    От: Воронков Василий Россия  
    Дата: 29.06.11 08:20
    Оценка:
    Здравствуйте, BogdanMart, Вы писали:

    BM>Чертовски странно, раньше я видел другой результат, но сегодня немного по дебльному сгенерировало А в не отладочном проверить не получилось, так как в нем отладчик вообще нивкакую не подключаеться


    Билдите релиз, запускаете его *без отладчика*, потом — аттач отладчиком. Если не получается -можно тупо вставить в код Debugger.Break.

    А по поводу dup — это я к тому, что dup на самом деле ни фига не оптимизация. Я с ним игрался, так код еще медленнее получается.

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

    Скажем, в таком высокоуровневом языке как Немерле на уровне АСТ будут такие конструкции как ПМ. Компилятор на уровне байт-код просто превратит их в цепочку условных переходов — при этом сделает кучу проверок, типизирует выражение, проверит достижимость отдельных веток матча и пр. И компилировать уже сам байт-код в машинный код будет тупо быстрее.

    Ну а про компактность тут уже много раз сказали.
    Re[9]: Вынести процесс генерации MSIL-а в отдельную стадию
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 29.06.11 20:10
    Оценка:
    Здравствуйте, WolfHound, Вы писали:

    C>>У нас ведь CFG есть вроде?

    WH>Лучшеб его небыло. Глючит страшно.

    Это еще ладно. Главное что он написан так, что кроме автора его мало кто может понять. И при этом он еще практически ничего не делает. Точнее то что он делает делает и джит.
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re[2]: Nemerle 2.0
    От: catbert  
    Дата: 29.06.11 20:42
    Оценка:
    Здравствуйте, _nn_, Вы писали:

    __>Убрать хардкод с '$'.


    __>(Невозможно создать макрос начинающийся с '$' )


    А это не будет конфликтовать с квазицитированием?
    Re[3]: Nemerle 2.0
    От: Ziaw Россия  
    Дата: 30.06.11 04:06
    Оценка:
    Здравствуйте, catbert, Вы писали:

    __>>(Невозможно создать макрос начинающийся с '$' )


    C>А это не будет конфликтовать с квазицитированием?


    Не будет. Это вообще странное пожелание, в Н2 не будет хардкода грамматик вообще. Весь парсер будет описан в виде синтаксических макросов.
    Re[4]: Nemerle 2.0
    От: catbert  
    Дата: 30.06.11 13:39
    Оценка:
    Здравствуйте, Ziaw, Вы писали:

    Z>Не будет. Это вообще странное пожелание, в Н2 не будет хардкода грамматик вообще. Весь парсер будет описан в виде синтаксических макросов.


    Да, но макросы-то тоже код. В смысле, фундаментально они не решают проблему: какая разница, где захардкожен оператор, в макросе или в парсере?
    Re[5]: Nemerle 2.0
    От: Ziaw Россия  
    Дата: 01.07.11 03:19
    Оценка:
    Здравствуйте, catbert, Вы писали:

    Z>>Не будет. Это вообще странное пожелание, в Н2 не будет хардкода грамматик вообще. Весь парсер будет описан в виде синтаксических макросов.


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


    Это не оператор, это грамматика. Грамматика будет расширяема.
    Re: Nemerle 2.0
    От: _nn_ www.nemerleweb.com
    Дата: 10.08.11 16:24
    Оценка:
    Хотелось бы возможность указывать , что переменная может быть инициализированна только в каком-то методе и один или более раза.

    Часто имеем код:
    class MyClass
    {
      MyType t;
    
      public MyClass() {}
      
      public void Start() { t = new MyType(); }
      public void Stop() { t = null; }
    }


    t не может быть readonly, т.к. инициализация в Start.
    А это означает , что если где-то меняем переменную, компилятор ничего не скажет.

    Предложение:

    class MyClass
    {
       // Установить значение можно только в MyMethod
       private readonly(MyMethod) var : MyType;
    
       public void MyMethod()
       {
          var = new MyType(); // OK
          var = null; // OK
       }
    
       public void MyMethod2()
       {
          var = null; // Error, только в MyMethod
       }
    }


    Может быть возможно будет обойтись одним макросом ?
    http://rsdn.nemerleweb.com
    http://nemerleweb.com
    Re[2]: Nemerle 2.0
    От: Ziaw Россия  
    Дата: 10.08.11 17:15
    Оценка:
    Здравствуйте, _nn_, Вы писали:

    __>Может быть возможно будет обойтись одним макросом ?


    Предполагаю, что можно уже сейчас сделать нормальную стейт-машину используя Nemerle.Statechart.
    Re[2]: Nemerle 2.0
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 10.08.11 19:30
    Оценка:
    Здравствуйте, _nn_, Вы писали:

    __>Хотелось бы возможность указывать , что переменная может быть инициализированна только в каком-то методе и один или более раза.

    __> // Установить значение можно только в MyMethod
    __> private readonly(MyMethod) var : MyType;
    __>Может быть возможно будет обойтись одним макросом ?

    Можно. Но не уверен что нужно.
    В прочем, если у тебя есть на это время, то можешь заняться.

    Схема действий проста. Делаешь макро-атрибут для поля. Вешаешь другой макро-атрибут на весь класс с фазой WithTypedMembers. Во втором макросе обходишь все методы и с помощью Macros.TraverseExpr() обходишь все содержимое тел методов. Там фильтруешь присвоения и обращения по ссылке к нужной тебе переменной и выдаешь сообщение об ошибке.

    Перед тем как делать обход имеет смысл типизировать тела методов, следующим образом:
            def oldEmitDebug = typer.Manager.Options.EmitDebug;
            typer.Manager.Options.EmitDebug = false;
            def methodTyper = Typer(tb, null, meth, meth.Env);
            methodTyper.RunFullTyping();
            typer.Manager.Options.EmitDebug = oldEmitDebug;

    После этого в meth.Body будет PExpr в свойстве TypedObject которых будет нужная тебе информация о типах. Ее можно использовать чтобы упростить идентификацию переменной.

    Расплатой за это будет двойная типизация тел всех членов этого класса.

    ЗЫ

    По уму нужно был сделать макрос которые запускаются уже на типизированном АСТ. Об этом много раз уже говорили.
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
     
    Подождите ...
    Wait...
    Пока на собственное сообщение не было ответов, его можно удалить.