Здравствуйте, hardcase, Вы писали:
H>Здравствуйте, hardcase, Вы писали:
H>Парсер C#4.0, генерирующий AST, вроде как принял законченную форму к r9078. Кому интересно, может посмотреть и ужаснуться.
Практически завершил работу над транслятором C# AST -> Nemerle AST.
В r9114 он умеет транслировать все мыслимые члены классов, предложения и выражения C#.
Осталось: трансляция LINQ, вменяемая работа с атрибутами (сейчас цель атрибутов игнорируется), ну и поиск багов, связанных с локациями.
НЕ поддерживаются следующие фичи C#:
dynamic;
extern alias; (работает для global:)
все, что связано с unsafe: указатели, stackalloc, sizeof, fixed, буферы фиксированных размеров;
конструкция goto (а также goto case и goto default);
в конструкторах массивов c инициализатором игнорируется их размер, например тут: new int[4] { 1, 2, 3, 4 }.
Поддерживаются следующие фичи Nemerle:
полноценный вывод типов для var и возможность опускать параметры типов;
вывод типов для делегатов и лямбд;
открытие классов конструкцией using;
макросы-функции с аргументами-выражениями в стиле C#, например printf;
макроатрибуты с аргументами-выражениями в стиле C#, например Accessor.
Собственно говоря получился тот же Nemerle, с синтаксисом C#.
Здравствуйте, hardcase, Вы писали:
H>Здравствуйте, hardcase, Вы писали:
H>Парсер C#4.0, генерирующий AST, вроде как принял законченную форму к r9078. Кому интересно, может посмотреть и ужаснуться.
Здравствуйте, hardcase, Вы писали:
WH>>Хорошо бы разбирать весь синтаксис C# включая goto и unsafe. WH>>Но при трансформации AST сообщать что эти конструкции не поддерживаются. WH>>Тем более что со временем их можно будет и реализовать в основном компиляторе. WH>>А пока хоть сообщение об ошибке будет предельно ясным. H>Так оно и происходит.
Что-то не заметно.
Вот это например не парсит
public override void PutBytes (byte [] dest, int destIdx, long value)
{
Check (dest, destIdx, 8);
fixed (byte *target = &dest [destIdx]){
long *source = (long *) &value;
*((long*)target) = *source;
}
}
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, Воронков Василий, Вы писали:
ВВ>Здравствуйте, hardcase, Вы писали:
VD>>>goto case и goto default можно было бы и реализовать. Какие с ними проблемы? H>>Я не знаю как их обработать.
ВВ>Вообще полезные вещи, goto эти. Может, компилировать свитч не просто в матч, а в матч+tail call, соответственно, goto будет просто вызовом ф-ции, который будет компилятором Немерле "обратно" превращаться в тот же goto?
Goto в Nemerle есть, это TExpr.Goto и использовать его в Match в принципе можно, но проблема в том, прежде придется типизировать вхождения матча, на которые осуществляются переходы.
Здравствуйте, para, Вы писали:
P>Здравствуйте, hardcase:
P>Супер!!
P>ОТЛАДКА по cs-файлу работает!!! P>МАГИЯ!!!
Дык, должна. Я локации в файлах постарался сохранить.
P>Вопрос (понимаю, что не очень в тему):
P>что можно сделать с поддержкой intelliSence в *.cs? P>похоже студия открывает эти файлы вне проекта, как будто бы открыт только один этот cs-файл. P>в связи с чем intelliSence, навигация и т.п. работают не очень...
Я думаю вопрос не ко мне а к владу — студия сама разбирает эти файлы (SD поступает точно также).
Я в ближайшее время займусь интеграцией C# парсера в компилятор.
Здравствуйте, IT, Вы писали:
H>>Парсер C#4.0, генерирующий AST, вроде как принял законченную форму к r9078. Кому интересно, может посмотреть и ужаснуться.
IT>Надо Хейльсбергу и Ко послать. Пусть поучаться как делать нормальный вывод типов
Он же дизайнер! Ему такие мелочи не интересны .
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Аноним, Вы писали:
А>Здравствуйте, hardcase, Вы писали:
H>>Здравствуйте, Аноним, Вы писали:
А>>>2) перегенерированный код по моему опыту обычно бывает корявым. Упадет существенно скорость компиляции.
H>>В каком смысле перегенерированый? Если вы решили что *.cs транслируется в *.n то вы заблуждаетесь: парсер встраивается в компилятор и AST C# преобразовывается в AST Nemerle с ограничениями, которые я перечислил в начале топика. На выходе имеем исполняемый код аналогичный тому, что получается при компиляции *.n.
А>Извините, тогда вопрос снят. Я вас не правильно понял.
Наиполезнейшие инструкции goto case и goto default теперь также поддерживаются.
Пока несколько ограниченно: каков был "case XXX", таким и должен быть "goto case XXX", иначе транслятор AST расскажет об ошибке.
Константные выражения также не поддерживаются, это не техническое ограничение (можно вполне вырутиться на макросе), это мое нежелание делать ненужную работу.
Здравствуйте, hardcase, Вы писали:
H>Парсер C#4.0, генерирующий AST, вроде как принял законченную форму к r9078. Кому интересно, может посмотреть и ужаснуться.
Ужасаться там не чем. Наоборот — отличная работа! Надеюсь не за горами полноценный конвертер из C# в Nemerle и компиляция C#-исходников (без динамиков и ансэйфа) в рамках Nemerle-проектов.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, hardcase, Вы писали:
H>НЕ поддерживаются следующие фичи C#: H>модификаторы вариантности ref/out;
А чё так? Немерл же их поддерживает.
H>конструкция goto (а также goto case и goto default);
goto case и goto default можно было бы и реализовать. Какие с ними проблемы?
H>в конструкторах массивов c инициализатором игнорируется их размер, например тут: new int[4] { 1, 2, 3, 4 }.
Можно переписывать в код отдельно создающие массив, и отдельно копирующий в него элементы из другого.
H>Собственно говоря получился тот же Nemerle, с синтаксисом C#.
Без синтаксических расширений.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, hardcase, Вы писали:
H>>НЕ поддерживаются следующие фичи C#: H>>модификаторы вариантности ref/out;
VD>А чё так? Немерл же их поддерживает.
А как их обрабатывать?
H>>конструкция goto (а также goto case и goto default);
VD>goto case и goto default можно было бы и реализовать. Какие с ними проблемы?
Я не знаю как их обработать.
H>>в конструкторах массивов c инициализатором игнорируется их размер, например тут: new int[4] { 1, 2, 3, 4 }.
VD>Можно переписывать в код отдельно создающие массив, и отдельно копирующий в него элементы из другого.
Это не спортивно. Нужно все же статически анализировать размеры. Сейчас выдается предупреждение.
Здравствуйте, hardcase, Вы писали:
H>>>НЕ поддерживаются следующие фичи C#: H>>>модификаторы вариантности ref/out; VD>>А чё так? Немерл же их поддерживает.
H>А как их обрабатывать?
VD>>goto case и goto default можно было бы и реализовать. Какие с ними проблемы? H>Я не знаю как их обработать.
ОК. Подумаем.
H>>>в конструкторах массивов c инициализатором игнорируется их размер, например тут: new int[4] { 1, 2, 3, 4 }.
VD>>Можно переписывать в код отдельно создающие массив, и отдельно копирующий в него элементы из другого.
H>Это не спортивно. Нужно все же статически анализировать размеры. Сейчас выдается предупреждение.
Что-то не понял. Что там анализировать то?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
H>>>>в конструкторах массивов c инициализатором игнорируется их размер, например тут: new int[4] { 1, 2, 3, 4 }.
VD>>>Можно переписывать в код отдельно создающие массив, и отдельно копирующий в него элементы из другого.
H>>Это не спортивно. Нужно все же статически анализировать размеры. Сейчас выдается предупреждение.
VD>Что-то не понял. Что там анализировать то?
Сравнивать фактическое количество элементов (1, 2, 3, 4) с заявляенным в конструкторе — 4.
что можно сделать с поддержкой intelliSence в *.cs?
похоже студия открывает эти файлы вне проекта, как будто бы открыт только один этот cs-файл.
в связи с чем intelliSence, навигация и т.п. работают не очень...
Здравствуйте, para, Вы писали:
P>что можно сделать с поддержкой intelliSence в *.cs?
Ничего. По крайней мере без хаков.
P>похоже студия открывает эти файлы вне проекта, как будто бы открыт только один этот cs-файл. P>в связи с чем intelliSence, навигация и т.п. работают не очень...
Расширение cs зарезервировано за языковым сервисом MS. Еще решапер его перехватывает (если он установлен).
Конечно можно пытатьс поступать как решарпер, то это не просто и может привести к ужасным наложенным багам (особенно в присутсвтии решарпера).
Более разумный способ — завести для встроенного в немерловые проекты C#-а отдельное расширение (например, cs-n) и создать (и зарегистрировать) для него собственный языковый сервис. Но это не малый объем работы.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Более разумный способ — завести для встроенного в немерловые проекты C#-а отдельное расширение (например, cs-n) и создать (и зарегистрировать) для него собственный языковый сервис. Но это не малый объем работы.
я тоже об этом думал, ведь от c# только синтаксис, а с метоатрибутами это уже "диалект" nemerle, т.е. компилятором CS его в общем случае не обработаешь.
По этому логично ввести новое расширение например "ncs" и обрабатывать его, как файл немерла. и ни какого дополнительного сервиса получается не надо или я не совсем прав?
Здравствуйте, para, Вы писали:
P>По этому логично ввести новое расширение например "ncs" и обрабатывать его, как файл немерла. и ни какого дополнительного сервиса получается не надо или я не совсем прав?
Нет не прав. Парсер и лексер важные части интеграции. Для корректной работы нужно создавать свой языковый сервис.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, hardcase, Вы писали:
H>Парсер C#4.0, генерирующий AST, вроде как принял законченную форму к r9078. Кому интересно, может посмотреть и ужаснуться.
Надо Хейльсбергу и Ко послать. Пусть поучаться как делать нормальный вывод типов
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, hardcase, Вы писали:
VD>>goto case и goto default можно было бы и реализовать. Какие с ними проблемы? H>Я не знаю как их обработать.
Вообще полезные вещи, goto эти. Может, компилировать свитч не просто в матч, а в матч+tail call, соответственно, goto будет просто вызовом ф-ции, который будет компилятором Немерле "обратно" превращаться в тот же goto?
Вернее, сделать так — если внутри матча есть goto компилировать так, если нет, то обычный матч.
Здравствуйте, Аноним, Вы писали:
А>пока не понял зачем это все надо
1) генератор парсеров с помощью которого был реализован парсер C# станет ключевым звеном в новой системе макросов, этот проект — полигон для его обкатки
2) теперь можно будет использовать стандартные дизайнеры и кодогенераторы VisualStudio и других инструментов, порождающих код на C#, и не тратить время на разработку и поддержку своих.
/* иЗвиНите зА неРовнЫй поЧерК */
Re[3]: [PEG] Парсер C# 4.0
От:
Аноним
Дата:
04.10.10 08:27
Оценка:
Здравствуйте, hardcase, Вы писали:
H>Здравствуйте, Аноним, Вы писали:
А>>пока не понял зачем это все надо
H>1) генератор парсеров с помощью которого был реализован парсер C# станет ключевым звеном в новой системе макросов, этот проект — полигон для его обкатки H>2) теперь можно будет использовать стандартные дизайнеры и кодогенераторы VisualStudio и других инструментов, порождающих код на C#, и не тратить время на разработку и поддержку своих.
1) ясно
2) перегенерированный код по моему опыту обычно бывает корявым. Упадет существенно скорость компиляции.
Здравствуйте, Аноним, Вы писали:
А>2) перегенерированный код по моему опыту обычно бывает корявым. Упадет существенно скорость компиляции.
В каком смысле перегенерированый? Если вы решили что *.cs транслируется в *.n то вы заблуждаетесь: парсер встраивается в компилятор и AST C# преобразовывается в AST Nemerle с ограничениями, которые я перечислил в начале топика. На выходе имеем исполняемый код аналогичный тому, что получается при компиляции *.n.
/* иЗвиНите зА неРовнЫй поЧерК */
Re[5]: [PEG] Парсер C# 4.0
От:
Аноним
Дата:
04.10.10 08:35
Оценка:
Здравствуйте, hardcase, Вы писали:
H>Здравствуйте, Аноним, Вы писали:
А>>2) перегенерированный код по моему опыту обычно бывает корявым. Упадет существенно скорость компиляции.
H>В каком смысле перегенерированый? Если вы решили что *.cs транслируется в *.n то вы заблуждаетесь: парсер встраивается в компилятор и AST C# преобразовывается в AST Nemerle с ограничениями, которые я перечислил в начале топика. На выходе имеем исполняемый код аналогичный тому, что получается при компиляции *.n.
Извините, тогда вопрос снят. Я вас не правильно понял.
Здравствуйте, hardcase, Вы писали:
H>В каком смысле перегенерированый? Если вы решили что *.cs транслируется в *.n то вы заблуждаетесь: парсер встраивается в компилятор и AST C# преобразовывается в AST Nemerle с ограничениями, которые я перечислил в начале топика. На выходе имеем исполняемый код аналогичный тому, что получается при компиляции *.n.
Кстати о птичках.
Хорошо бы разбирать весь синтаксис C# включая goto и unsafe.
Но при трансформации AST сообщать что эти конструкции не поддерживаются.
Тем более что со временем их можно будет и реализовать в основном компиляторе.
А пока хоть сообщение об ошибке будет предельно ясным.
Что касается препроцессора то тут нужна поддержка со стороны генератора парсеров. Я думаю над тем как ее сделать.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, hardcase, Вы писали:
H>>В каком смысле перегенерированый? Если вы решили что *.cs транслируется в *.n то вы заблуждаетесь: парсер встраивается в компилятор и AST C# преобразовывается в AST Nemerle с ограничениями, которые я перечислил в начале топика. На выходе имеем исполняемый код аналогичный тому, что получается при компиляции *.n. WH>Кстати о птичках. WH>Хорошо бы разбирать весь синтаксис C# включая goto и unsafe. WH>Но при трансформации AST сообщать что эти конструкции не поддерживаются. WH>Тем более что со временем их можно будет и реализовать в основном компиляторе. WH>А пока хоть сообщение об ошибке будет предельно ясным.
Так оно и происходит.
WH>Что касается препроцессора то тут нужна поддержка со стороны генератора парсеров. Я думаю над тем как ее сделать.
Здравствуйте, hardcase, Вы писали:
H>1) генератор парсеров с помощью которого был реализован парсер C# станет ключевым звеном в новой системе макросов, этот проект — полигон для его обкатки H>2) теперь можно будет использовать стандартные дизайнеры и кодогенераторы VisualStudio и других инструментов, порождающих код на C#, и не тратить время на разработку и поддержку своих.
3) можно будет плавно преобразовывать C#-проекты в немерловые.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, hardcase, Вы писали:
WH>>>Хорошо бы разбирать весь синтаксис C# включая goto и unsafe. WH>>>Но при трансформации AST сообщать что эти конструкции не поддерживаются. WH>>>Тем более что со временем их можно будет и реализовать в основном компиляторе. WH>>>А пока хоть сообщение об ошибке будет предельно ясным. H>>Так оно и происходит. WH>Что-то не заметно. WH>Вот это например не парсит WH>
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, hardcase, Вы писали:
WH>>>Хорошо бы разбирать весь синтаксис C# включая goto и unsafe. WH>>>Но при трансформации AST сообщать что эти конструкции не поддерживаются. WH>>>Тем более что со временем их можно будет и реализовать в основном компиляторе. WH>>>А пока хоть сообщение об ошибке будет предельно ясным. H>>Так оно и происходит. WH>Что-то не заметно. WH>Вот это например не парсит WH>
Здравствуйте, WolfHound, Вы писали:
WH>Хорошо бы разбирать весь синтаксис C# включая goto и unsafe.
Дык он и разбирает. Только в немерл перевести, по понятным причинам, не может.
WH>Но при трансформации AST сообщать что эти конструкции не поддерживаются.
Так и происходит.
WH>Тем более что со временем их можно будет и реализовать в основном компиляторе.
Ну, goto и так можно реализовать. На уровне типизированного дерева он поддерживается.
С unsafe сложнее. Да и не нужно оно на практике. Долболомов что пишут unsafe-код очень мало. Тех кто использует unsafe по делу вообще почти нет (разве что ли создатели Сингулярити).
WH>Что касается препроцессора то тут нужна поддержка со стороны генератора парсеров. Я думаю над тем как ее сделать.
Да не особо оно и нужно. Прпероцессор можно сделать отдельным парсером или даже вручную. Там все очень просто и примитивно.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, hardcase, Вы писали:
H>Проверил. Парсит. AST корректное. Может ты не обновил парсер? Я не так давно там несколько ошибок исправил.
Я каждый день обновляюсь и компилятор пересобираю.
Сейчас еще раз обновился. Что-то смержилось и теперь дейстительно парсит.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, hardcase, Вы писали:
H>В каком смысле перегенерированый? Если вы решили что *.cs транслируется в *.n то вы заблуждаетесь: парсер встраивается в компилятор и AST C# преобразовывается в AST Nemerle с ограничениями, которые я перечислил в начале топика. На выходе имеем исполняемый код аналогичный тому, что получается при компиляции *.n.
А overload resolution и вывод типов в лямбдах/generic методах по правилам C# или Nemerle происходит?
Здравствуйте, nikov, Вы писали:
N>А overload resolution и вывод типов в лямбдах/generic методах по правилам C# или Nemerle происходит?
Это просто танслятор из АСТ-а шарпа в АСТ немерла. Так что вся семантика немерловая, ну, за исключением тех случаев когда ее специально напильником доводили (например, для оператора ++).
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, nikov, Вы писали:
N>А overload resolution и вывод типов в лямбдах/generic методах по правилам C# или Nemerle происходит?
Да... Только одна поправка! Сам парсер тупо генерирует АСТ. Никаких выводов типов или разрешения перегрузки он не делает (это же парсер!). Так что когда мы говорим о семантике, то речь идет уже об созданном на базе этого парсера конверторе. Но парсер можно использовать и отдельно.
Судя по вот этому замечанию, наша реализация оказалась примерно в 10 раз быстрее АНТЛР-овской. И это не смотря на то, что у нас тупой PEG, а в АНТЛР-е конечные автоматы!
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, hardcase, Вы писали:
H>Парсер C#4.0, генерирующий AST, вроде как принял законченную форму
А существует конвертер С#->Nemerle? Натыкался на упоминание об утилитке cs2n, но бинарника в дистре не нашёл. Вот на этом парсере кто-то делает что-нибудь подобное?
Здравствуйте, matumba, Вы писали:
M>А существует конвертер С#->Nemerle? Натыкался на упоминание об утилитке cs2n, но бинарника в дистре не нашёл. Вот на этом парсере кто-то делает что-нибудь подобное?
Было такое дело в старых версиях (9.3). Но оно давно устарело. Шарп там чуть ли не 1.0 поддерживался. Так что на сегодня оно интереса не предсавляет.
В принципе, на базе современного парсера сделать такую утилиту будет не сложно. Вот только рук не хватает.
Вот можешь помочь проекту, смастерить такую утилиту. Что делать подскажем.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
M>>А существует конвертер С#->Nemerle? VD>В принципе, на базе современного парсера сделать такую утилиту будет не сложно. Вот только рук не хватает. VD>Вот можешь помочь проекту, смастерить такую утилиту. Что делать подскажем.
Написать скорее всего могу, но я же цэшарповод, Немерле знаю на уровне "Хелл о, ворлд!" Писать лучше на Немерле, я правильно понимаю?
Последний билд у меня поставлен, но стоит только студия 2010. Если я ПОСЛЕ Немерли поставлю студию 2008 (isolated shell), она его подхватит?
(и кстати про шелл — он встанет без оригинальной студии 2008?)
Времени особо много нет, но вечерами могу ваять.
Здравствуйте, matumba, Вы писали:
M>Здравствуйте, VladD2, Вы писали:
M>>>А существует конвертер С#->Nemerle? VD>>В принципе, на базе современного парсера сделать такую утилиту будет не сложно. Вот только рук не хватает. VD>>Вот можешь помочь проекту, смастерить такую утилиту. Что делать подскажем.
M>Писать лучше на Немерле, я правильно понимаю?
Правильно.
M>Если я ПОСЛЕ Немерли поставлю студию 2008 (isolated shell), она его подхватит?
Насколько мне известно нет.
M>(и кстати про шелл — он встанет без оригинальной студии 2008?)
На то он и шелл — установится без проблем.
M>Времени особо много нет, но вечерами могу ваять.
Там дел не слишком много — вручную придется юзинги и пространства имен писать, остальное (декларации и выражения) Немерл сам умеет писать.
Здравствуйте, matumba, Вы писали:
M>Здравствуйте, VladD2, Вы писали:
M>>>А существует конвертер С#->Nemerle? VD>>В принципе, на базе современного парсера сделать такую утилиту будет не сложно. Вот только рук не хватает. VD>>Вот можешь помочь проекту, смастерить такую утилиту. Что делать подскажем.
M>Написать скорее всего могу, но я же цэшарповод, Немерле знаю на уровне "Хелл о, ворлд!"
Ну, вот за одно и подучишь. Тем более, что задача не сложная совсем, если не брать в расчет необходимость причесывания PrettyPrint-а для немерлового АСТ (сейчас он не очень качественно работает).
M> Писать лучше на Немерле, я правильно понимаю?
Естественно.
M>Последний билд у меня поставлен, но стоит только студия 2010. Если я ПОСЛЕ Немерли поставлю студию 2008 (isolated shell), она его подхватит?
Подхватит. Хотя, конечно, лучше было бы иметь полноценную VS 2008 SP1 + VS SDK 1.1 и немрел собранный с исходников.
M>(и кстати про шелл — он встанет без оригинальной студии 2008?)
Да.
M>Времени особо много нет, но вечерами могу ваять.
Там не так много работы.
Все что нужно находится в солюшене: http://code.google.com/p/nemerle/source/browse/nemerle/trunk/snippets/peg-parser/CSharp/CSharpParser.sln
По сути все что нужно сделать:
1. Получить шарповский код. Тут есть варианты. По уму входом может быть фалы или клипборд. Клипбордную версию можно вставить прямо в Интеграцию.
2. С помощью парсера шарпа распарсить шарповский код.
3. С помощью конвертера преобразуем АСТ шарпа в АСТ немерла.
4. Вызываем PrettyPrint (или даже просто ToString()) для генерации кода по немерловому АСТ.
5. Записываем результат в файл или клипборд.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Там не так много работы.
Еще добавлю, что для работы AstConverter'а (штуки которая преобразует C#-овый AST в Немерловый) необходим ManagerClass — это собственно сам компилятор.
Вот его придется в новом cs2n хостить.
Здравствуйте, matumba, Вы писали:
M>Последний билд у меня поставлен, но стоит только студия 2010. Если я ПОСЛЕ Немерли поставлю студию 2008 (isolated shell), она его подхватит?
Тут я гоню. Если поставить "isolated shell", то немерл надо будет переставить.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
ВВ>матч+tail call, соответственно, goto будет просто вызовом ф-ции, который будет компилятором Немерле "обратно" превращаться в тот же goto? ВВ>Вернее, сделать так — если внутри матча есть goto компилировать так, если нет, то обычный матч.
А реверс инжиниринг? Т.е. компилятор немерла генерит код, который не сможет при реверсе стать немерлом?
VD>С unsafe сложнее. Да и не нужно оно на практике. Долболомов что пишут unsafe-код очень мало. Тех кто использует unsafe по делу вообще почти нет (разве что ли создатели Сингулярити).
На практике встречал в работе с железом. Там сплошь и рядом этажерки указателей на помойки со структурами и указателями в которых указатели на массивы. Новейшее китайское железо с ихним же апи (железо в смысле промышленное которое на шине RS485). Хорошо когда массив с получаемыми данными можно сразу fixed и GC просто понервирничает, а бывает где все совсем плохо, что умножается на в принципе сложную тему invoke/interop... ну вы поняли. Кто умнее пишут в неуправляемых плюсах либу-прокладку, но большинство не парится — unsafe.
Так вот сама тема указателей и unsafe выливается в сложные fixed, MarshallAs, invoke/interop. Надо ли оно по настоящему высокому языку? Я думаю не стоит заморачиваться. Кому надо тот все-таки в плюсах прокладку сделает. А кто не умеет, тому лучше сначала плюсы учить, и рано ему высоким языком пользоваться, "тут вам не web".
Здравствуйте, enCobalt, Вы писали:
VD>>С unsafe сложнее. Да и не нужно оно на практике. Долболомов что пишут unsafe-код очень мало. Тех кто использует unsafe по делу вообще почти нет (разве что ли создатели Сингулярити).
C>На практике встречал в работе с железом. Там сплошь и рядом этажерки указателей на помойки со структурами и указателями в которых указатели на массивы. Новейшее китайское железо с ихним же апи (железо в смысле промышленное которое на шине RS485). Хорошо когда массив с получаемыми данными можно сразу fixed и GC просто понервирничает, а бывает где все совсем плохо, что умножается на в принципе сложную тему invoke/interop... ну вы поняли. Кто умнее пишут в неуправляемых плюсах либу-прокладку, но большинство не парится — unsafe.
А что людей работающих с никоуровневыми АПИ на дотнете много?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Судя по вот этому замечанию, наша реализация оказалась примерно в 10 раз быстрее АНТЛР-овской. И это не смотря на то, что у нас тупой PEG, а в АНТЛР-е конечные автоматы!
АНТЛР вообще как-то не быстр. Пытался я его использовать, но в итоге отказался. Если хочется бенчей, то имеет смысл с Кокором сравнить.
Здравствуйте, VladD2, Вы писали:
ВВ>>Если хочется бенчей, то имеет смысл с Кокором сравнить. VD>Хочу. Коку я сам использовал и у меня сложилось хорошее впечатление о его производительности. Так что сравнение с ним было бы очень интересно.
Тест сделать в принципе несложно. В качестве основы со стороны Кокора можно взять грамматику C# 3.0 — от 4-й версии отличий очень мало. Она у них тут: http://www.ssw.uni-linz.ac.at/Research/Projects/Coco/CS/CSharp3.atg. У ПЕГа в свою очередь надо будет отключить семантические действия, чтобы сравнивать чисто парсинг.
Я могу собрать небольшой проектик для Кокора, переслать тебе, а ты уже запустишь тесты. Могу сделать консольку, которая в качестве первого параметра принимает путь к файле, а по завершении парсинга выводит потраченное время в мс.
Здравствуйте, enCobalt, Вы писали:
H>>Там дел не слишком много — вручную придется юзинги и пространства имен писать, остальное (декларации и выражения) Немерл сам умеет писать.
C>Это по хорощему счету разбирать сорец по честному, например есди вдруг там уже есть юзинги?
Здравствуйте, Воронков Василий, Вы писали:
ВВ>Я могу собрать небольшой проектик для Кокора, переслать тебе, а ты уже запустишь тесты. Могу сделать консольку, которая в качестве первого параметра принимает путь к файле, а по завершении парсинга выводит потраченное время в мс.
Давай. Можешь и нашу реализацию подключить.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, matumba, Вы писали:
VD>>Все что нужно находится в солюшене
M>Т.е. мне его создавать не надо, просто дописать код в солюшен, так? Уже качаю сорсы.
Солюшен — это не проект. Тебе нужно создать новый проект. Этот проект действительно можно добавить в указанный солюшен. Ему там будет самое место.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[9]: [PEG] Парсер C# 4.0
От:
Аноним
Дата:
11.11.10 23:16
Оценка:
C>>На практике встречал в работе с железом. Там сплошь и рядом этажерки указателей на помойки со структурами и указателями в которых указатели на массивы. Новейшее китайское железо с ихним же апи (железо в смысле промышленное которое на шине RS485). Хорошо когда массив с получаемыми данными можно сразу fixed и GC просто понервирничает, а бывает где все совсем плохо, что умножается на в принципе сложную тему invoke/interop... ну вы поняли. Кто умнее пишут в неуправляемых плюсах либу-прокладку, но большинство не парится — unsafe.
VD>А что людей работающих с никоуровневыми АПИ на дотнете много?
Весьма. Причем есть забавная тенденция — asm помню, микроконтроллеры программлю, .net помню пишу софт... а вот ++ хреново помню, пишу и читаю уже медленно.
Скажу больше, в самой теме низкоуровневого программинга касающегося железа, в особенности железа промышленного все меньше низкоуровневого и все чаще встречаются уже готовые производителем API под .Net. Прогресс виден невооруженным глазом, но это пока только очевидная тенденция, о прорыве такими темпами года два-три еще, потом будет дурным тоном не дать готовый API .Net. Причем есть положительная обратная связь, те кто делают .Net API у них и API к ++ вдруг проще и понятнее оказываются. Ну а процы под .Net Micro Framework вообще сказка, там прошивку сразу на чистом .Net пишешь.
Китайцы ODM-щики (делают платформу-прототип на выставки, потом зафигачивают бренды покупателей, типа Rover) тоже коммерсанты, .net платформа это еще +1 способ завоевания рынка.
Re[7]: [PEG] Парсер C# 4.0
От:
Аноним
Дата:
11.11.10 23:25
Оценка:
H>>>Там дел не слишком много — вручную придется юзинги и пространства имен писать, остальное (декларации и выражения) Немерл сам умеет писать. C>>Это по хорощему счету разбирать сорец по честному, например есди вдруг там уже есть юзинги? H>Вы топик пробовали от начала читать?
Виноват. Я и немерлом заинтересовался с точки зрения парсинга, вот и подумал "в лоб".
Здравствуйте, Аноним, Вы писали:
А>Весьма. Причем есть забавная тенденция — asm помню, микроконтроллеры программлю, .net помню пишу софт... а вот ++ хреново помню, пишу и читаю уже медленно.
Что-то мне кажется, что их не так уж и много. А учитывая слова про наличие готовых дотнетных АПИ актуальность так же понижается.
Мне кажется лучшим выходом тут будет использование C++/CLI для создания безопасных оберток.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, hardcase, Вы писали:
H>>goto великий и могучий теперь поддерживается! H>>Исходники с ним теперь компилируются
VD>Замечательно! Не загорами время когда большая часть С"-проектов сможет быть скомпилирована немерлом!
Да уж
Я тренерую конвертер на SharpDevelop-овских исходниках (версии 3.2). Именно goto какраз мешает компилироваться.
Хотя вот интеграция F#-а и еще пары небольших библиотек вполне собирается и работает.
H>>goto case пока под вопросом.
VD>А в чем вопрос? Мне кажется, что твой текущий опыт должен позволить решить и эту проблему. Нет?
Есть идея по эмуляции, но нужно собственный макрос изготавливать (идея основана на работе с ConstantFolder-ом).
Здравствуйте, hardcase, Вы писали:
VD>>А в чем вопрос? Мне кажется, что твой текущий опыт должен позволить решить и эту проблему. Нет?
H>Есть идея по эмуляции, но нужно собственный макрос изготавливать (идея основана на работе с ConstantFolder-ом).
Идею не понял. Но раз есть — пробуй!
Я бы, возможно, подумал над банальным запихиванием меток во вхождения match-а. Но там могут возникнуть сложности с тем, что при разворачивании кода match-ей компилятор может заниматься "копи-пэстом", т.е. дублировать участки кода во вложенных if-ах. А двух одинаковых меток ведь быть не должно.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.