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

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

H>>Скорее всего там распарсились два последовательных оператора взятия адреса.

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

У нас нет понятия токен. Это безлексерный парсер.

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

H>Замечательная последовательность лексем. Но, конечно, я посмотрю что там внутри получается.
H>Дело в том, что генератор парсеров проектируется с расчетом на использование в механизмах автокомплита, так что парсить нужно все что можно распарсить.

У нас какое-то недопонимание. Любой парсер расчитывает на ошибки в исходном коде. Поэтому компилятор выдаёт тебе все ошибки, а не только первую. Вы не открыли Америку парсером, который разбирает некорректный код.
Абсолютно нормальное требование для автокомплита, чтобы предыдущий код был более или менее корректен. Это поведение можно наблюдать везде. Я не понимаю зачем вы вносите явные баги в свой парсер ради весьма всомнительной выгоды.

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

N>>Но это ведь даже другой токен. Ну здесь это в любом случае ошибочный код, но ведь есть ситуации, когда убирание пробела между токенами превращает правильный код в ошибочный. Кто в таком случае сообщит об ошибке? Ведь и парсер будет доволен, и дерево получится правильное.
H>У нас нет понятия токен. Это безлексерный парсер.

А как ты собираешься выдавать ошибки вида "XYZ expected"?

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

H>У нас нет понятия токен. Это безлексерный парсер.

А в грамматике C# есть.

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

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

N>>>Но это ведь даже другой токен. Ну здесь это в любом случае ошибочный код, но ведь есть ситуации, когда убирание пробела между токенами превращает правильный код в ошибочный. Кто в таком случае сообщит об ошибке? Ведь и парсер будет доволен, и дерево получится правильное.
H>>У нас нет понятия токен. Это безлексерный парсер.

A>А как ты собираешься выдавать ошибки вида "XYZ expected"?

PEG это сделает за меня. Парсер создавался не ради C#, а ради нового движка макросов Nemerle. Он вообще стал фактически побочным продуктом.

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

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

Не разобравшись до конца в вопросе вы делаете поспешные выводы.

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

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

Ну так помогите разобраться.

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

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

H>>У нас нет понятия токен. Это безлексерный парсер.

N>А в грамматике C# есть.

И что? C# здесь это не самоцель а лишь полигон для маневров

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

N>>А в грамматике C# есть.
H>И что? C# здесь это не самоцель а лишь полигон для маневров

Мне показалось сейчас или вы можете забросить этот парсер как только у вас пропадёт к нему какой-либо интерес:

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

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

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

A>Ну так помогите разобраться.

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

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

H>И что? C# здесь это не самоцель а лишь полигон для маневров

В таком случае с этими недостатками можно смириться.
А то некоторые (несознательные?) люди уже пропагандируют этот парсер в качестве замены тому, который используется в РеШарпере, и тому, который разрабатывется в Microsoft.

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

S_>А вроде ничего страшного на первый взгляд в этом не видно, если с большой буквы:

S_>

S_>match (ast)
S_>{
S_>  | Alias(Id) => WriteLine(Id);
S_>  ... // другие образцы
S_>}
S_>

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

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

Нет. Это именно введение переменной. Она может и не для поля использоваться.

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

A>Мне показалось сейчас или вы можете забросить этот парсер как только у вас пропадёт к нему какой-либо интерес:

Сейчас он подключен как плагин к компилятору Nemerle и будет релизнут вместе с компилятором, так что вряд ли он будет заброшен.

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

H>>>Так и должно быть.

N>>Почему это?

H>Логично что нужно парсить все что можно распарсить. Что не так пускай думает код, который будет анализировать AST.

Мне кажется, что это все же баг.

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

H>У нас нет понятия токен. Это безлексерный парсер.

И все же && отличить от & можно, а в случае шарпа — нужно.

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

N>>А в грамматике C# есть.

H>И что? C# здесь это не самоцель а лишь полигон для маневров

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

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

H>>И что? C# здесь это не самоцель а лишь полигон для маневров
VD>Тут ты не прав. Раз мы компилируем шарп, то синтаксис его должны воспроизвести точно.

Со всеми багами существующего компилятора, кстати.

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

H>>И что? C# здесь это не самоцель а лишь полигон для маневров
VD>Тут ты не прав. Раз мы компилируем шарп, то синтаксис его должны воспроизвести точно.

вот типичное расхождение со стандартом
http://blogs.msdn.com/b/ruericlippert/archive/2010/07/26/ignoring-parentheses.aspx

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

N>Ещё:

N>

N>class A{
N>    object x = from from in "" select 1;
N>}
N>

Это... Может лучше баги в трекер?

http://code.google.com/p/nemerle/issues/list

...Только добавляя описание бага в трекер лучше добавлять тег "[CSharpParser]" чтобы фильтровать можно было.