Здравствуйте, adontz, Вы писали:
A>Здравствуйте, Tom, Вы писали:
Tom>>1. Что значит Compiler As Service? Означает ли это что все елементы компилятора будет возможно реюзить. Скажем просто парсер C# можно ли будет использовать?
A>Я этого жду
Здравствуйте, adontz, Вы писали:
H>>И библиотеку эту можно легко использовать из программ на C# и VB.NET.
A>То есть оно оформлено как библиотека?
Естественно оно оформлено как отдельная библиотека.
При том сейчас она входит в наш инсталлятор, но всегда можно собирать свежую версию из исходников (сейчас активно допиливается генератор парсера).
По сути сейчас единственное ограничение парсера — отсутствие процессинга директив (они просто игнорируются), но этот недостаток скоро устраним.
Здравствуйте, hardcase, Вы писали:
H>Естественно оно оформлено как отдельная библиотека. H>При том сейчас она входит в наш инсталлятор, но всегда можно собирать свежую версию из исходников (сейчас активно допиливается генератор парсера). H>По сути сейчас единственное ограничение парсера — отсутствие процессинга директив (они просто игнорируются), но этот недостаток скоро устраним.
Здравствуйте, hardcase, Вы писали:
H>И библиотеку эту можно легко использовать из программ на C# и VB.NET.
А это совсем не факт. Немерле имеет особенность, особенно при активном использовании МП, делать использование его кода из других языков довольно сложным, особенно если об этом специально не позаботились.
... << RSDN@Home 1.2.0 alpha 4 rev. 1476 on Windows 7 6.1.7600.0>>
Здравствуйте, AndrewVK, Вы писали:
AVK>А это совсем не факт. Немерле имеет особенность, особенно при активном использовании МП, делать использование его кода из других языков довольно сложным, особенно если об этом специально не позаботились.
МП использутся там в двух местах:
1) генератор парсера,
2) обход дерева с целью поиска синтаксических ошибок
На выходе синтаксическое дерево CompilationUnit-а, которое можно анализировать.
Скажи, а чем будет отличаться библиотека написанная МС-ом? Они ведь тебе исходники точно не дадут. Радуйся если они их обфускации не подвергнут.
A>на языке, который я не знаю.
Ой, дело только в этом? Ну, так зачем дело встало. Головастые люди изучивают немерле за месяц.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, AndrewVK, Вы писали:
H>>И библиотеку эту можно легко использовать из программ на C# и VB.NET.
AVK>А это совсем не факт. Немерле имеет особенность, особенно при активном использовании МП, делать использование его кода из других языков довольно сложным, особенно если об этом специально не позаботились.
А причем тут ПМ? ПМ вам — мэйнстримовцам — недоступен. Ты наверно говоришь об описании AST в вдие вариантов?
Ага. AST там именно в таком виде. Но варианты реализованы на базе классов. Вот как выглядит AST в Рефлекторе:
public abstract class Expr : Located
{
// Methodsprotected Expr();
protected Expr(Location location);
public override string ToString();
[VariantOption]
public sealed class Alias : Expr
{
// Fieldspublic readonly Identifier id;
// Methodspublic Alias(Identifier id);
public Alias(Location location, Identifier id);
public override int _N_GetVariantCode();
}
[VariantOption]
public sealed class Assign : Expr
{
// Fieldspublic readonly Identifier op;
public readonly Expr to;
public readonly Expr value;
// Methodspublic Assign(Expr to, Expr value, Identifier op);
public Assign(Location location, Expr to, Expr value, Identifier op);
public override int _N_GetVariantCode();
}
[VariantOption]
public sealed class Base : Expr
{
// Methodspublic Base();
public Base(Location location);
public override int _N_GetVariantCode();
}
[VariantOption]
public sealed class BinaryOperator : Expr
{
// Fieldspublic readonly Expr left;
public readonly Identifier op;
public readonly Expr right;
// Methodspublic BinaryOperator(Expr left, Expr right, Identifier op);
public BinaryOperator(Location location, Expr left, Expr right, Identifier op);
public override int _N_GetVariantCode();
}
[VariantOption]
public sealed class Call : Expr
{
// Fieldspublic readonly list<FunctionArgument> arguments;
public readonly Expr expr;
// Methodspublic Call(Expr expr, list<FunctionArgument> arguments);
public Call(Location location, Expr expr, list<FunctionArgument> arguments);
public override int _N_GetVariantCode();
}
Любой представитель мэйнстрима может написать Визетер для этого дела и использовать в свое удовольствие на подчеркнуто мэйнстрим-яызке. Для генерации Визетера можно даже воспользоваться ульта-современными технологиями вроде T4.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Ага. AST там именно в таком виде. Но варианты реализованы на базе классов. Вот как выглядит AST в Рефлекторе:
VD> [VariantOption]
VD> public sealed class Alias : Expr
VD> {
VD> // Fields
VD> public readonly Identifier id;
А можно что-либо сделать (на сколько это принципиально и как крепко прибито), что бы имена полей получались бы в UpperCase или в виде private readonly-полей и public-свойств? За это отвечает описание граматики (то есть достаточно переписать граматику парсера C#) или компилятор Немерле?
Help will always be given at Hogwarts to those who ask for it.
Здравствуйте, _FRED_, Вы писали:
_FR>А можно что-либо сделать (на сколько это принципиально и как крепко прибито), что бы имена полей получались бы в UpperCase или в виде private readonly-полей и public-свойств? За это отвечает описание граматики (то есть достаточно переписать граматику парсера C#) или компилятор Немерле?
За генерацию вариантов отвечает компилятор. А парсер скорее всего очень жестко завязан на варианты.
Здравствуйте, samius, Вы писали:
_FR>>А можно что-либо сделать (на сколько это принципиально и как крепко прибито), что бы имена полей получались бы в UpperCase или в виде private readonly-полей и public-свойств? За это отвечает описание граматики (то есть достаточно переписать граматику парсера C#) или компилятор Немерле?
S>За генерацию вариантов отвечает компилятор. А парсер скорее всего очень жестко завязан на варианты.
Но имена, в частности, "id" из моего примера, не компилятор же выдумывает — это имя же где-то человек указал. Так вот, если указать "Id", "то есть … переписать граматику парсера C#", значит в результате, в классе, будет поле "Id"? Или там всё сложнее?
Help will always be given at Hogwarts to those who ask for it.
Здравствуйте, _FRED_, Вы писали:
_FR>Здравствуйте, samius, Вы писали:
_FR>>>А можно что-либо сделать (на сколько это принципиально и как крепко прибито), что бы имена полей получались бы в UpperCase или в виде private readonly-полей и public-свойств? За это отвечает описание граматики (то есть достаточно переписать граматику парсера C#) или компилятор Немерле?
S>>За генерацию вариантов отвечает компилятор. А парсер скорее всего очень жестко завязан на варианты.
_FR>Но имена, в частности, "id" из моего примера, не компилятор же выдумывает — это имя же где-то человек указал. Так вот, если указать "Id", "то есть … переписать граматику парсера C#", значит в результате, в классе, будет поле "Id"? Или там всё сложнее?
Имя пишет человек. А вот за генерацию поля (а не свойства) отвечает компилятор.
Здравствуйте, _FRED_, Вы писали:
S>>За генерацию вариантов отвечает компилятор. А парсер скорее всего очень жестко завязан на варианты.
_FR>Но имена, в частности, "id" из моего примера, не компилятор же выдумывает — это имя же где-то человек указал. Так вот, если указать "Id", "то есть … переписать граматику парсера C#", значит в результате, в классе, будет поле "Id"? Или там всё сложнее?
Expr.n
Обойдется рефакторингом. Но думаю, что авторы будут против такого коммита.
Здравствуйте, samius, Вы писали:
S>>>За генерацию вариантов отвечает компилятор. А парсер скорее всего очень жестко завязан на варианты.
_FR>>Но имена, в частности, "id" из моего примера, не компилятор же выдумывает — это имя же где-то человек указал. Так вот, если указать "Id", "то есть … переписать граматику парсера C#", значит в результате, в классе, будет поле "Id"? Или там всё сложнее?
S>Expr.n S>Обойдется рефакторингом. Но думаю, что авторы будут против такого коммита.
Ну, если не удастся договориться с авторами, то коммитить, конечно, не стоит.
Help will always be given at Hogwarts to those who ask for it.
Здравствуйте, VladD2, Вы писали:
A>>На Немерле. Мне нужна библиотека с понятным интерфейсом, а не куча исходникков VD>Я так и знал. Главная проблема найдена. VD>Скажи, а чем будет отличаться библиотека написанная МС-ом? Они ведь тебе исходники точно не дадут. Радуйся если они их обфускации не подвергнут.
На момент написания этого сообщения, я не знал, что парсер оформлен как самостоятельная библиотека.
Здравствуйте, _FRED_, Вы писали:
_FR>А можно что-либо сделать (на сколько это принципиально и как крепко прибито), что бы имена полей получались бы в UpperCase или в виде private readonly-полей и public-свойств? За это отвечает описание граматики (то есть достаточно переписать граматику парсера C#) или компилятор Немерле?
Я пока не вижу пракического смысла в таком переписывании. Объекты всеравно иммутабельные.
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, VladD2, Вы писали:
VD>>Любой представитель мэйнстрима может написать Визетер для этого дела
AVK>И визитер в сотню, если не больше, узлов, да еще без контроля со стороны компилятора, придется, как я понимаю, писать ручками?
Ну а как ты хотел? Посмотри на объектную модель Рефлектора или на тот же Expression линка, там тоже классов не две штуки
Здравствуйте, AndrewVK, Вы писали:
AVK>И визитер в сотню, если не больше, узлов, да еще без контроля со стороны компилятора, придется, как я понимаю, писать ручками?
А вообще авоматический Визитор у нас сейчас есть (ага, на макросе . Его текущая задача — сбор синтаксических ошибок во всем CompilationUnit-е.
Если кому-то нужно что-то еще этот механизм всегда можно задействовать.
Здравствуйте, AndrewVK, Вы писали:
AVK>И визитер в сотню, если не больше, узлов, да еще без контроля со стороны компилятора,
"Визитер без контроля со стороны компилятора" — это ты замечательно ляпнул. Но лучше такое при людях знающих этот паттерн не говорить. За смеют.
AVK>придется, как я понимаю, писать ручками?
Это обратно пропорционально коэффициенту интеллекта того кто будет писать. При IQ ниже среднего, конечно, без ручной работы не обойтись. Если интеллекта чуть по более, становятся доступны рефлексия и T4. При IQ чуть выше среднего можно пользоваться Nemerle и паттер-матчингом (но тут еще, конечно, придется не дюжую смелость проявить).
Мне казалось, что твоего IQ должно быть достаточно, чтобы оценить объемы ручной работы по приведенному куску года.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, hardcase, Вы писали:
_FR>>А можно что-либо сделать (на сколько это принципиально и как крепко прибито), что бы имена полей получались бы в UpperCase или в виде private readonly-полей и public-свойств? За это отвечает описание граматики (то есть достаточно переписать граматику парсера C#) или компилятор Немерле?
H>Я пока не вижу пракического смысла в таком переписывании. Объекты всеравно иммутабельные.
Есть широко известны гайдлайны, которые регламентируют, с использованием какого кейса предподчтительно называть открытые поля типов. Жаль, если разработчики библиотеки Немерле не принимают их врасчёт.
По поводу свойств — именно на свойствах работает, например, такой механизм как дефолтовый TypeDescriptionProvider, который позволяет биндится (то есть отображать в UI значения) к свойствам объекта. Написать свой, предоставляющий поля, конечно можно. Но readonly поле и public get свойство неизменяемости повредить не сможет, а вот и гайдлайнам удовлетворит и лучшую поддержку фреймворка и прочих библиотек обеспечит.
Help will always be given at Hogwarts to those who ask for it.
Причём тут вообще IQ, я даже при очень большом желании использовать немерл не смогу пробить стену мэнеджмента который справедливо боится что поддержка сего проекта закончится сразу после того как кто то не ухватится за новую супер пупер идею, как это было с R#
Здравствуйте, _FRED_, Вы писали:
_FR>Здравствуйте, hardcase, Вы писали:
_FR>>>А можно что-либо сделать (на сколько это принципиально и как крепко прибито), что бы имена полей получались бы в UpperCase или в виде private readonly-полей и public-свойств? За это отвечает описание граматики (то есть достаточно переписать граматику парсера C#) или компилятор Немерле?
H>>Я пока не вижу пракического смысла в таком переписывании. Объекты всеравно иммутабельные.
_FR>Есть широко известны гайдлайны, которые регламентируют, с использованием какого кейса предподчтительно называть открытые поля типов. Жаль, если разработчики библиотеки Немерле не принимают их врасчёт.
А еще variant-ов нет в .NET. Они из ML-я приехали. — это по повду кейсов.
Конечно, вопрос (и свойствами тоже) этот решаемый, и я прекрасно представляю как. Но пока никому не нужно было столь плотно работать с вариантами из C# и тем более, отображать их на интерфейсе.
Здравствуйте, hardcase, Вы писали:
H>А еще variant-ов нет в .NET. Они из ML-я приехали. — это по повду кейсов.
Ну и что? Под кейсами я понимаю UpperCase и LowerCase. И variant есть не что иное как всего лишь понятие языка. Гайдлайны как раз позволяют единообразно использовать типы в рамках платформы.
H>Конечно, вопрос (и свойствами тоже) этот решаемый, и я прекрасно представляю как. Но пока никому не нужно было столь плотно работать с вариантами из C# и тем более, отображать их на интерфейсе.
Странно, что он небыл решён в самом начале. Майкрософт уже со времён второго фреймворка успешно избегает public instance fields в своих типах.
Help will always be given at Hogwarts to those who ask for it.
Здравствуйте, _FRED_, Вы писали:
_FR>Здравствуйте, hardcase, Вы писали:
H>>А еще variant-ов нет в .NET. Они из ML-я приехали. — это по повду кейсов.
_FR>Ну и что? Под кейсами я понимаю UpperCase и LowerCase. И variant есть не что иное как всего лишь понятие языка. Гайдлайны как раз позволяют единообразно использовать типы в рамках платформы.
Я тоже под ними понимаю регистр написания идентификаторов.
Проблема в том, что шаблоны паттерн матчинга обладают неоднозначностью и именование полей варианты в нижнем регистре позволяет ее разрешать (это у нас by design).
H>>Конечно, вопрос (и свойствами тоже) этот решаемый, и я прекрасно представляю как. Но пока никому не нужно было столь плотно работать с вариантами из C# и тем более, отображать их на интерфейсе.
_FR>Странно, что он небыл решён в самом начале. Майкрософт уже со времён второго фреймворка успешно избегает public instance fields в своих типах.
Во фреймворке нет вариантных классов, как и паттерн матчинга усложнять и без того непростую логику никому было не нужно.
Опять же проблем из-за public instance полей никто не имел.
Здравствуйте, hardcase, Вы писали:
H>>>А еще variant-ов нет в .NET. Они из ML-я приехали. — это по повду кейсов. _FR>>Ну и что? Под кейсами я понимаю UpperCase и LowerCase. И variant есть не что иное как всего лишь понятие языка. Гайдлайны как раз позволяют единообразно использовать типы в рамках платформы. H>Я тоже под ними понимаю регистр написания идентификаторов. H>Проблема в том, что шаблоны паттерн матчинга обладают неоднозначностью и именование полей варианты в нижнем регистре позволяет ее разрешать (это у нас by design).
То есть, если поля варинтов буду названы в верхнем регистре, что-то (паттерн-матчинг) в Немерле работать не будет? Неужели это так? Можно пример посмотреть?
H>>>Конечно, вопрос (и свойствами тоже) этот решаемый, и я прекрасно представляю как. Но пока никому не нужно было столь плотно работать с вариантами из C# и тем более, отображать их на интерфейсе. _FR>>Странно, что он небыл решён в самом начале. Майкрософт уже со времён второго фреймворка успешно избегает public instance fields в своих типах. H>Во фреймворке нет вариантных классов, как и паттерн матчинга усложнять и без того непростую логику никому было не нужно. H>Опять же проблем из-за public instance полей никто не имел.
Это, конечно, весомые аргументы
Help will always be given at Hogwarts to those who ask for it.
Здравствуйте, _FRED_, Вы писали:
_FR>То есть, если поля варинтов буду названы в верхнем регистре, что-то (паттерн-матчинг) в Немерле работать не будет? Неужели это так? Можно пример посмотреть?
Это так. В противном случае будет неразрешимый на уровне парсера конфликт:
| something => ...
something — это что? Конструктор или просто переменная?
Здравствуйте, hardcase, Вы писали:
H>Я тоже под ними понимаю регистр написания идентификаторов. H>Проблема в том, что шаблоны паттерн матчинга обладают неоднозначностью и именование полей варианты в нижнем регистре позволяет ее разрешать (это у нас by design).
Это у вас кривой design значит, если написав идентификатор в другом регистре получаешь другое поведение. Вы пишете сперва под .Net и уже потом на Nemerle. Любые другие приоритеты делают вас закрытым клубом.
Здравствуйте, VladD2, Вы писали:
VD>Это обратно пропорционально коэффициенту интеллекта того кто будет писать. При IQ ниже среднего, конечно, без ручной работы не обойтись. Если интеллекта чуть по более, становятся доступны рефлексия и T4. При IQ чуть выше среднего можно пользоваться Nemerle и паттер-матчингом (но тут еще, конечно, придется не дюжую смелость проявить).
Влад, ну причём тут интеллект? C# и T4 официально поддерживаемые продукты, Nemerle — нет. Вне зависимости от конкретного положения дел, стоящего за словами "официально поддерживаемый" менеджменту сложно согласиться использовать Nemerle. Я понимаю, что ситуация как в анекдоте "Не трахают, потому прыщи. Прыщи, потому не трахают.", но это реальность.
Здравствуйте, adontz, Вы писали:
A>Это у вас кривой design значит, если написав идентификатор в другом регистре получаешь другое поведение. Вы пишете сперва под .Net и уже потом на Nemerle. Любые другие приоритеты делают вас закрытым клубом.
Т.е. то, что в AST используются поля и называются они в нижнемРегистре делает невозможным работу с ним?
Здравствуйте, _FRED_, Вы писали:
VD>>Ага. AST там именно в таком виде. Но варианты реализованы на базе классов. Вот как выглядит AST в Рефлекторе: _FR>
VD>> [VariantOption]
VD>> public sealed class Alias : Expr
VD>> {
VD>> // Fields
VD>> public readonly Identifier id;
_FR>
_FR>А можно что-либо сделать (на сколько это принципиально и как крепко прибито), что бы имена полей получались бы в UpperCase или в виде private readonly-полей и public-свойств? За это отвечает описание граматики (то есть достаточно переписать граматику парсера C#) или компилятор Немерле?
Это поля вариантов. Для вариантов есть свои гайдлайны и свои правила. Причем, в отличии от правил форматирования эти правила влияют на работу паттерн-матчинга.
Вариантный тип — это не просто класс. Если присмотреться к коду по внимательнее, то можно заметить, что описание полей полностью совпадают с описанием параметров одного из конструкторов. Это не случайно! В это есть большой смысл. Немерл гарантирует это. В результате мы можем в распозновать объекты вариантных типов типов с помощью образцов описывающих конструктор такого типа. Скажем, конкретный экземпляр Alias-а можно распознать таким образом:
match (ast)
{
| Alias(id) => WriteLine(id);
... // другие образцы
}
По этому если сделать имена полей с большой буквы, то с большой буквы будут и имена параметров конструкторов. Это еще хуже соотносится с гайдлайнами.
Конечно можно сгенерировать (причем автоматически) свойства дублирующие эти поля. Но на мой взгляд — это все вкусовщина на которую не стоит тратить время. Плюс дублирование сущностей (поля и свойства будут мало чем отличаться) не есть гуд.
Так что если нужно ехать, а не шашечки лучше переступить через свои привычки и все будет ОК.
Ну, а еще лучше попробовать освоить немерл. Ведь распознавание АСТ в десятки раз проще осуществлять с помощью паттерн-матчинга. Немерл ничем не отличается от Шарпа по возможнсотям. И на нем можно очень просто и быстро реализовать ту логику обработки АСТ которая вам нужна. Ну, а на выходе вы можете создать DLL которая предоставляет данные или методы в полном соответствии с вашими гайдлайнами. И уже эту сборку использовать в проекте.
В общем, надо просо понять, что Немерл имеет тотальное приемущество перед Шарпом в вопросе работы с иерархиями. Визитер (паттерн "Посетитель") не идет ни в какое сравнение с паттерн-матчингом. А ведь этот самый посетитель вам еще придется сгенерировать (нам он не нужен, по понятным причинам). В прочем, сгенерировать его можно написав немерловый макрос.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Tom>Причём тут вообще IQ, я даже при очень большом желании использовать немерл не смогу пробить стену мэнеджмента который справедливо боится что поддержка сего проекта закончится сразу после того как кто то не ухватится за новую супер пупер идею, как это было с R#
А чем опен-сорс компилятор отличается в данном случае от опен-сорс библиотеки? Тоже менеджмент использовать не разрешает, даже если можно кучу человеко-месяцев сэкономить? А как же основная работа менеджера — свои прибыли на максимум вытягивать и красивые графики клиентам показывать?
Если вы общаетесь с МС как все, через connect, и прямой линии к Хельсбергу и Co у вас нету — то поддержка которую оказывает МС де факто _хуже_ чем поддержка которую можно получить на форуме Nemerle. Кроме того у вас есть возможность и смотреть в сорцы компилятора, и в крайнем случае даже поправить самим. Код компилятора на самом деле вполне обозримого размера, именно из-за того что написан на себе-же и при сборке сам себя тестирует.
Да и никто не заставляет вас сразу хватать проект на 5 лет разработки кучей народу и всё на Nemerle. Сделайте пилотный проект, пройдите пару майлстонов и окажетесь на светлой стороне
Здравствуйте, _FRED_, Вы писали:
_FR>Ну и что? Под кейсами я понимаю UpperCase и LowerCase. И variant есть не что иное как всего лишь понятие языка. Гайдлайны как раз позволяют единообразно использовать типы в рамках платформы.
По этому поводу ответы уже прозвучали. Повторяться не буду.
_FR>Странно, что он небыл решён в самом начале. Майкрософт уже со времён второго фреймворка успешно избегает public instance fields в своих типах.
В МС в большей части работают орлы которые или не догадываются о существовании readonly в C#, или искренне считают его рудиментом неизвестно зачем всунутым в язык.
Сейчас ситуация постепенно выправляется, но все же императивная идеология крепко засела во многих головах (и в вашей, кстати, тоже).
Меж тем никаких проблем с публичными полями нет, если, конечно, они доступны только на чтение. Более того, в таких условиях свойства просто не ясно зачем нужны.
Ну, и еще раз повторюсь, это все же не классы. Это варианты. Их идеология идет от ML-подобных языков. Этой иделогии больше лет чем самому Майкрософту (не говоря уже о Шарпе). Она проверенна временем. Посему менять ее ради соответсвия гайдлайнам другого язык, конечно же никто не будет. Надо просто понять, что никаких реальных проблем тут нет. Это просто не привычно для кто много лет слушал только то что говорят в МС.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, hardcase, Вы писали:
H>Проблема в том, что шаблоны паттерн матчинга обладают неоднозначностью и именование полей варианты в нижнем регистре позволяет ее разрешать (это у нас by design).
Не, ты ошибаешся. К неоднозначностям это не приводит. Вот если бы ты назвал с большой буквы переменную в образце, то да. Но поля в принципе могут иметь названия с большой буквы.
Проблема тут в другом. Поля вхождения варианта одновременно описывают и параметры конструктора. По этому сделав их с большой буквы ты автоматом получишь их ПаскальКейсе. А это будет выглядеть намного хуже. Как ты помнишь в немерле к полям вариантов очень редко обращаются через точку. В большинстве случаев их получают при паттерн-матчинге. А при этом очень даже удобно, что поля называются с маленькой буквы, так как общепринято давать переменным вводимым в образцах имена полей. Но это тоже традиция которую в принципе можно нарушать. Так можно иметь поле "Id", но в образце получать его значение в переменную "id".
H>Во фреймворке нет вариантных классов, как и паттерн матчинга усложнять и без того непростую логику никому было не нужно.
Все проще. Просто традиции брались вместе с фичами. Если клссы брались из C#, то и традиции названий для публичного API брались из шарпа, а если фича бралась из ML, то и традиции шли от туда. В конце концов они почти полностью совпадают.
H>Опять же проблем из-за public instance полей никто не имел.
Вот именно.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Воронков Василий, Вы писали:
ВВ>Здравствуйте, _FRED_, Вы писали:
_FR>>То есть, если поля варинтов буду названы в верхнем регистре, что-то (паттерн-матчинг) в Немерле работать не будет? Неужели это так? Можно пример посмотреть?
ВВ>Это так.
Нет, не так.
ВВ>В противном случае будет неразрешимый на уровне парсера конфликт:
ВВ>| something => ...
ВВ>something — это что? Конструктор или просто переменная?
Просто переменная. Даже так: "| Aliase(id)" — это будет просто переменная введенная в паттерне и связанная с параметром конструктора варианта (т.е. с его соответствующим полем). И имя переменной может отличаться от имени поля.
Ограничение имеется только на название вариантов, их вхождений и переменных объявляемых в паттерне. Первые должны быть всегда с большой буквы (что совпадает с гайдлайнами), последнее (переменная) должна быть всегда с маленькой (что так же совпадает с гайдлайнами).
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>По этому если сделать имена полей с большой буквы, то с большой буквы будут и имена параметров конструкторов. Это еще хуже соотносится с гайдлайнами.
Что происходит чаще: создание объекта или обращение в его члену? Тем более что при создании имена параметров не используются, а при обращении к члену имена членов используются.
VD>Так что если нужно ехать, а не шашечки лучше переступить через свои привычки и все будет ОК.
Как ты размахнулся, привычки. Это не привычни, это номенклатура. Правила, позволяющие разным людям одни и те же вещи называть одинаково и, таким образом, понимать друг друга.
VD>В общем, надо просо понять, что Немерл имеет тотальное приемущество перед Шарпом в вопросе работы с иерархиями.
Пропаганда неуместа, время одноязычных программ давно прошло. Ты либо интегируешься, либо умираешь. Максимум на что ты можешь сегодня расчитывать — это использование твоего парсера из C#. Причём удобное использование, чтобы Nemerle не торчал из библиотеки во все стороны.
Здравствуйте, hardcase, Вы писали:
A>>Это у вас кривой design значит, если написав идентификатор в другом регистре получаешь другое поведение. Вы пишете сперва под .Net и уже потом на Nemerle. Любые другие приоритеты делают вас закрытым клубом. H>Т.е. то, что в AST используются поля и называются они в нижнемРегистре делает невозможным работу с ним?
Заметно затрудняет. Плохое начало, если ты хочешь чтобы библиотеку использовали где-то ещё.
Здравствуйте, adontz, Вы писали:
A>Это у вас кривой design значит, если написав идентификатор в другом регистре получаешь другое поведение. Вы пишете сперва под .Net и уже потом на Nemerle. Любые другие приоритеты делают вас закрытым клубом.
Вообще-то гайдлайны — это ело каждого. Сто раз видел как константы, например, называют в С-стиле "MY_CONST". Как-то это не делало языки на которых так писали закрытым клубом.
Что касается кейсов, то для переменных в паттернах и для имен вариантных типов они строго определены. Это традиции ML-я. Точнее даже не традиции, а часть дизайна паттерн-матчинга.
Вариантных типов нет в мэйнстрим-языках. По этому, если кто-то хочет использовать их в своих проектах, то придется привыкнуть к чужим традициям. Поверь, это с лихвой окупается.
Кстати, в F# используются похожие соглашения.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, adontz, Вы писали:
A>Здравствуйте, hardcase, Вы писали:
H>>Т.е. то, что в AST используются поля и называются они в нижнемРегистре делает невозможным работу с ним?
A>Заметно затрудняет. Плохое начало, если ты хочешь чтобы библиотеку использовали где-то ещё.
Эмм я не понимаю как это может затрудить. Правда — не понимаю.
Здравствуйте, VladD2, Вы писали:
VD>Вообще-то гайдлайны — это ело каждого. Сто раз видел как константы, например, называют в С-стиле "MY_CONST". Как-то это не делало языки на которых так писали закрытым клубом.
Для меня указ — FxCop в данном случае.
VD>Что касается кейсов, то для переменных в паттернах и для имен вариантных типов они строго определены. Это традиции ML-я. Точнее даже не традиции, а часть дизайна паттерн-матчинга. VD>Вариантных типов нет в мэйнстрим-языках. По этому, если кто-то хочет использовать их в своих проектах, то придется привыкнуть к чужим традициям. Поверь, это с лихвой окупается.
Мне нужен парсер C#, а не Nemerle или F# со всеми их прелястми. Меня не должно волновать на каком языке он написан, это не должно быть видно снаружи. Всё что с модификатором internal может называть как угодно, всё что public должно называться так, как принято под .Net. Это следование правилам платформы, а не мои личные капризы. Если вы собираетесь предоставлять свой код для использующих другие языки, то лучше бы переделать правила именования у себя, чем пытаться навязать их сообществу куда большего размера чем ваше.
Здравствуйте, hardcase, Вы писали:
A>>Заметно затрудняет. Плохое начало, если ты хочешь чтобы библиотеку использовали где-то ещё. H>Эмм я не понимаю как это может затрудить. Правда — не понимаю.
Я не знаю как помочь понять тебе. Я лишь могу донести до тебя факт, что я и ещё многие другие затрудняются читать код, где публичные свойства или поля называны в нижнем регистре. Считайся с этим фактом, даже если не разделяешь мнения. Этого достаточно.
Здравствуйте, Tom, Вы писали:
Tom>Причём тут вообще IQ, я даже при очень большом желании использовать немерл не смогу пробить стену мэнеджмента который справедливо боится что поддержка сего проекта закончится сразу после того как кто то не ухватится за новую супер пупер идею, как это было с R#
Как причем? Боятся как рез те у кого IQ низкий. Те что с IQ повыше просто разбираются в вопросе и бояться им не чего.
Тут можно только сказать бессмертную фразу из Золотого теленка — "Пилите Шура, пилите! Они золотые...".
Все кому не нравится немерл или они его боятся, идут пилить гири (создавать парсеры самостоятельно). Те у кого IQ совсем низкий при этом напишут все руками (точнее в большинстве случаев, просто ничего не сделают), так как генератор парсеров тоже продукт неизвестно чей и все аргументы боязливых товарищей к нему так же применимы. Те кто имеет немного больший IQ возьмут какой-нить ANTLR и с помощь какой-то матери за пол годика получают требуемый результат. Далее они начинают всю жизнь его поддерживать. Ну, а те чей IQ достаточен чтобы разобраться в немреле и посему его не бояться, просто берут готовое и используют. Если что не так подкручивают самостоятельно. Могу похвастаться. Моего IQ хватило разобраться с немрелом. И как только я это сделал мне стало совсем не страшно его использовать. Сейчас я его использую при написании любого кода. Скажем новая версия RSDN Authoring Pack
практически (если не считать запускающих макросов) целиком написана на Немерле и отлично работает. Его пользователи, наверно, даже не знают об этом и смело им пользуются.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Вариантный тип — это не просто класс. Если присмотреться к коду по внимательнее, то можно заметить, что описание полей полностью совпадают с описанием параметров одного из конструкторов. Это не случайно! В это есть большой смысл. Немерл гарантирует это. В результате мы можем в распозновать объекты вариантных типов типов с помощью образцов описывающих конструктор такого типа. Скажем, конкретный экземпляр Alias-а можно распознать таким образом:
VD>По этому если сделать имена полей с большой буквы, то с большой буквы будут и имена параметров конструкторов. Это еще хуже соотносится с гайдлайнами.
ОК, но тут нет никакого обращения к полям/свойствам варианта. Если я правильно понимаю "id" в примере — это переменная, имя которой матчится с именем параметра конструктора варианта. Имя переменной матчится с именем параметра конструктора. Ни слова об имени свойства!
Вспомним, ка кобъявляется вариант:
variant RgbColor
{ | Red
| Yellow
| Green
| Different { red : float; green : float; blue : float; }
}
А теперь представим сеье такое объявление:
variant RgbColor
{ | Red
| Yellow
| Green
| Different { Red : float; Green : float; Blue : float; }
}
Что мешает по такому определению сгенерировать класс с полями (пускай пока с полями) Red, Green и Blue и с консруктором, параметры в котором называются red, green, blue — так же как и поля, только в lowerCase? Это не вызовет никаких конфликтов с темми, кто предпочитает имеющийся синтаксис.
Таким образом Alias(id) отматчится верно по имени параметра конструктора.
VD>Конечно можно сгенерировать (причем автоматически) свойства дублирующие эти поля. Но на мой взгляд — это все вкусовщина на которую не стоит тратить время. Плюс дублирование сущностей (поля и свойства будут мало чем отличаться) не есть гуд.
Совершенно верног, _дублировать_ (то есть иметь и открытые поля и открытые свойства) не нужно совсем, уж лучше как есть.
VD>Так что если нужно ехать, а не шашечки лучше переступить через свои привычки и все будет ОК.
Ну в таком случае может вам свои гайдлайны начать писать? Имеющиеся-то не подходят, оказывается Нет уж. До тех пор, пока я не знал _почему_ имена полей вариантов таким образом выглядят было одно — просто необычно и неприятно. А теперь вот недоумеваэ.
VD>Ну, а еще лучше попробовать освоить немерл. Ведь распознавание АСТ в десятки раз проще осуществлять с помощью паттерн-матчинга. Немерл ничем не отличается от Шарпа по возможнсотям.
Не спорю. Но правильно ли я понимаю, что в самом Немерле нет необходимости [часто?] обращаться явно к полям варианта? Потому что иначе получается странно — у одних типов свойства "как у людей" по гайдлайнам, а у других — с маленькой буквы. Тогда, может, в Немерле стоит придерживаться гайдлайна что поля в lower а свойства в Upper вне зависимости от открытости?
Help will always be given at Hogwarts to those who ask for it.
Здравствуйте, VladD2, Вы писали:
Tom>>Причём тут вообще IQ, я даже при очень большом желании использовать немерл не смогу пробить стену мэнеджмента который справедливо боится что поддержка сего проекта закончится сразу после того как кто то не ухватится за новую супер пупер идею, как это было с R# VD>Как причем? Боятся как рез те у кого IQ низкий. Те что с IQ повыше просто разбираются в вопросе и бояться им не чего.
Ты предлагаешь менеджменту выучить язык Nemerle и осознать его мощь?
VD>Тут можно только сказать бессмертную фразу из Золотого теленка — "Пилите Шура, пилите! Они золотые...".
Как мы все помним Паниковский ошибался.
VD>Все кому не нравится немерл или они его боятся, идут пилить гири (создавать парсеры самостоятельно). Те у кого IQ совсем низкий при этом напишут все руками (точнее в большинстве случаев, просто ничего не сделают), так как генератор парсеров тоже продукт неизвестно чей и все аргументы боязливых товарищей к нему так же применимы. Те кто имеет немного больший IQ возьмут какой-нить ANTLR и с помощь какой-то матери за пол годика получают требуемый результат. Далее они начинают всю жизнь его поддерживать.
Влад, ты глубоко не прав. ANTLR и Nemerle сравнивать просто смешно. У вас нет большого многолетнего опыта использования в разных промышленных проектах. Меня как менеджера не волнует что Nemerle крут, это не аргумент. Но меня волнует если кто-то успешно решил с помощью Nemerle реальную задачу и остался доволен. Ну и не забываем про порог вхождения. Сколько у нас есть опубликовых книжек про Nemerle на русском языке, которые можно купить в каждом городе?
VD>Ну, а те чей IQ достаточен чтобы разобраться в немреле и посему его не бояться, просто берут готовое и используют. Если что не так подкручивают самостоятельно. Могу похвастаться. Моего IQ хватило разобраться с немрелом. И как только я это сделал мне стало совсем не страшно его использовать.
Влад, ты борешься не с тем врагом. Проблема не в том что все вокруг трусы-тупицы. То есть да, все вокруг трусы-тупицы, но Nemerle не популярен не из-за этого.
VD>Сейчас я его использую при написании любого кода. Скажем новая версия RSDN Authoring Pack
практически (если не считать запускающих макросов) целиком написана на Немерле и отлично работает. Его пользователи, наверно, даже не знают об этом и смело им пользуются.
Я им не пользуюсь, его инсталлятор блокируется антивирусом, а VB скрипты в ворде глючны. Об этом писали многократно, это настоящие проблемы. Мне как пользователю и правда плевать на чём это написано, на C# или на Nemerle, если не работает как надо.
Здравствуйте, adontz, Вы писали:
A>Влад, ну причём тут интеллект? C# и T4 официально поддерживаемые продукты, Nemerle — нет.
Да ладно. Это где T4 официально поддерживается. И где хотя бы одна гарантия? Если завтра его бросят (как это было с кучей продуктов МС), то ты только локти покусать сможешь.
А немерле тоже официально поддерживается. Причем с теми же гарантиями что и C# (т.е. с никакими ).
Но при этом у него есть дно несомненное достоинство. Он идет с исходными кодами и наилебиральнейшей лицензией.
А интеллект он позволяет разобраться в предмете и перестать его бояться.
A>Вне зависимости от конкретного положения дел, стоящего за словами "официально поддерживаемый" менеджменту сложно согласиться использовать Nemerle. Я понимаю, что ситуация как в анекдоте "Не трахают, потому прыщи. Прыщи, потому не трахают.", но это реальность.
Да кто же вас заставляет. Пилите Шура, пилите! Пишите парсеры C# 4.0 сами. Ищите готовые. Только они, скорее всего, все равно будут созданы на базе некоторых генераторов парсеров которые так же являются внешними зависимостями и которых так же будут бояться ваши менеджеры.
Я уже не раз говорил, что это даже хорошо. Так как те кто рискнет не бояться (гы-гы, хорошо звучит!) будет реальное конкурентное преимущество.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Да кто же вас заставляет. Пилите Шура, пилите! Пишите парсеры C# 4.0 сами. Ищите готовые. Только они, скорее всего, все равно будут созданы на базе некоторых генераторов парсеров которые так же являются внешними зависимостями и которых так же будут бояться ваши менеджеры.
Влад, я бы и рад использовать парсер на Nemerle, но пока что это просто кусок кода, пусть даже оформленный в виде библиотеки, но никак не продукт.
VD>Я уже не раз говорил, что это даже хорошо. Так как те кто рискнет не бояться (гы-гы, хорошо звучит!) будет реальное конкурентное преимущество.
Пожалуйства не испугайся написать примеры использования на C# и документацию. Это даст конкурентное преимущество.
Здравствуйте, adontz, Вы писали:
A>Заметно затрудняет. Плохое начало, если ты хочешь чтобы библиотеку использовали где-то ещё.
Это... Неправильный акцент. Этого никто не хочет. Мы просто не против этого. Но библиотека создавалась в своих личных целях. Нам нужно было просто научить компилятор немерла компилировать C#-Файлы в составе проектов немерла. Ну, и на будущее сделать автоматический конвертер из шарпа в немерл.
АСТ это, конечно же, разрабатывалось для исползования в Немерле. Просто кое-кто ошибочно считает, что варианты невозможно использовать из C#. Вот это не так, что я собственно и популярно разъяснил.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
A>>Заметно затрудняет. Плохое начало, если ты хочешь чтобы библиотеку использовали где-то ещё. VD>Это... Неправильный акцент. Этого никто не хочет. Мы просто не против этого.
Учитывая правильный акцент такой парсер становится для меня неподдерживаемым продуктом. Потому что если завтра в нём будет что-то, что удобно (естественно) использоват из Nemerle и не удобно использовать из C# я получу порцию пропаганды Nemrele, а не исправление под C#.
Здравствуйте, VladD2, Вы писали:
_FR>>Странно, что он небыл решён в самом начале. Майкрософт уже со времён второго фреймворка успешно избегает public instance fields в своих типах.
VD>В МС в большей части работают орлы которые или не догадываются о существовании readonly в C#, или искренне считают его рудиментом неизвестно зачем всунутым в язык.
Я вот наоборот, просматривая исходники четвёртого фреймворка нарадоваться не мог тому, что количество sealed классов (даже с private областью вилимости) увеличилось и readonly поля стали использоваться заметно чаще.
VD>Сейчас ситуация постепенно выправляется, но все же императивная идеология крепко засела во многих головах (и в вашей, кстати, тоже).
Не понимаю почему вытравление императивной диалогии должно быть обязательно связано с гайдлайнами к именованию членов классов Этот аргумент в данном обсуждении по силе не хуже того, что у меня ухи торчком или нос пяточком.
VD>Меж тем никаких проблем с публичными полями нет, если, конечно, они доступны только на чтение. Более того, в таких условиях свойства просто не ясно зачем нужны.
Я же показал один пример — биндинг. Глубже думать пока нет необходимости.
VD>Ну, и еще раз повторюсь, это все же не классы. Это варианты. Их идеология идет от ML-подобных языков. Этой иделогии больше лет чем самому Майкрософту (не говоря уже о Шарпе). Она проверенна временем. Посему менять ее ради соответсвия гайдлайнам другого язык, конечно же никто не будет. Надо просто понять, что никаких реальных проблем тут нет. Это просто не привычно для кто много лет слушал только то что говорят в МС.
Ещё раз — я говорю не о гайдлайнах языка. Я говорю о гайдлайнах платформы. Классов может не быть в ваших функциональных головах (уж простите мне мой добрый и ненарошный укол) но классы есть в ваших сборках, которые может кто-то использовать из языков-конкурентов. И если нет желания обсудить всплывший вопрос в конструктивном ключе окромя как "а у вас… а у нас… да вы(мы) все…" давайте прекратим. В противном случае, может отделить топик откудато-отсюда
Здравствуйте, VladD2, Вы писали:
ВВ>>В противном случае будет неразрешимый на уровне парсера конфликт: ВВ>>| something => ... ВВ>>something — это что? Конструктор или просто переменная? VD>Просто переменная. Даже так: "| Aliase(id)" — это будет просто переменная введенная в паттерне и связанная с параметром конструктора варианта (т.е. с его соответствующим полем). И имя переменной может отличаться от имени поля. VD>Ограничение имеется только на название вариантов, их вхождений и переменных объявляемых в паттерне. Первые должны быть всегда с большой буквы (что совпадает с гайдлайнами), последнее (переменная) должна быть всегда с маленькой (что так же совпадает с гайдлайнами).
Ну вот если убрать ограничение на название вариантов и переменных, то и получится конфликт, о чем, собственно, и спрашивалось, если я правильно понял.
Здравствуйте, adontz, Вы писали:
A>Для меня указ — FxCop в данном случае.
FxCop он умный. Ему многое можно объяснить .
A>Мне нужен парсер C#, а не Nemerle или F# со всеми их прелястми. Меня не должно волновать на каком языке он написан, это не должно быть видно снаружи. Всё что с модификатором internal может называть как угодно, всё что public должно называться так, как принято под .Net. Это следование правилам платформы, а не мои личные капризы. Если вы собираетесь предоставлять свой код для использующих другие языки, то лучше бы переделать правила именования у себя, чем пытаться навязать их сообществу куда большего размера чем ваше.
Ты все же определись, что тебе больше нужно. Качественная, быстрая, поддерживаемая, используемая на практике библиотека или гайдлайны. Если последнее так важно, что ты готов взять библиотеку с худшими качествми, но удовлетворяющую гайдлайнам, то конечно это не твой выбор.
Если есть хорошая альтернатива и она удовлетворяет гайдлайнам, то конечно же ты прав и тебе стоит взять ее. Но если ее нет, то я вообще не понимаю о чем тут можно вести речь.
Что касается конкретно свойств, то их можно нагенерировать за пять минут средствами тех же макросов. Так что если это табокой уж страшный батхерт, то его можно устранить.
Но я тебе открою одну маленькую тайну. Дело в том, что разговоры про регистры полей — это просто смешные придирки по сравнению с тем, что могло бы дать применение паттерн-матчинга для обработки полученного АСТ.
Тебе нужен парсер шарпа не просто так? Это ведь не самоцель? Ты, наверно, с его помощью хочешь делать что-то хитрое с кодом, да? Если задачи, стоящие перед тобой, не тривиальные, ты можешь получить очень существенную (да что там, НЕСРАВНИМУЮ) выгоду, если потратишь день на изучение вариантных типов и паттерн-матчинга, и в результате напишешь код обработки АСТ на Немерле, а не на Шарпе. Разница будет настолько существенной, что твои опасения, и тем более недовольство регистрами полей, померкнут на фоне тех преимущество, что ты получишь. Ну, а результат ты можешь завернуть в библиотеку которая будет иметь кошерный публичный интерфейс в лучших традициях FxCop. И уже его можно будет использовать из проекта на шарпе.
Если подумать, то просто выбирая библиотеку парсера ты уже даешь добро на использование кода скомпилированного немерловым компилятором. А раз так, то сделать еще один мелкий шажок будет не так сложно и страшно. И я тебе гарантирую, ты не пожалеешь об этом.
Ну, а страх можно побороть аутотренингом вроде такого — Утилита обработки кода мне нужна не для продакшена. Это просто внутренняя утилита. Если что перепишу ее на шарпе. А пока сэкономлю кучу времени используя инструмент намного лучше подходящий для решения задачи.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, adontz, Вы писали:
A>Что происходит чаще: создание объекта или обращение в его члену?
Конечно создание объектов, если мы говорим о вариантах и их использование в немерле.
В немерле увидить код в котором к полям вариантов обращаются через точку можно очень редко.
А вот увидеть "создание объекта" можно очень часто, так как именно синтаксис конструкторов используется при паттерн-матчинге.
Сам понимаешь, так как библиотека писалась в первую очередь для использования из немрела, то о выборе гайдлайнов даже речи не шло.
A>Тем более что при создании имена параметров не используются, а при обращении к члену имена членов используются.
Почему же? Используются иногда. В немерле с самого начала были именованные параметры. В Шарпе они появились в 4.0. Но теперь и в нем они могут использоваться. Иногда это повышает выразительность.
VD>>Так что если нужно ехать, а не шашечки лучше переступить через свои привычки и все будет ОК.
A>Как ты размахнулся, привычки. Это не привычни, это номенклатура. Правила, позволяющие разным людям одни и те же вещи называть одинаково и, таким образом, понимать друг друга.
Нет, нет, нет дорогой товарищ! Ты все же оцени за и против. Насколько твои привычки дороги? Можно ими пожертвовать ради резкого упрощения реализации?
VD>>В общем, надо просо понять, что Немерл имеет тотальное приемущество перед Шарпом в вопросе работы с иерархиями.
A>Пропаганда неуместа, время одноязычных программ давно прошло. Ты либо интегируешься, либо умираешь. Максимум на что ты можешь сегодня расчитывать — это использование твоего парсера из C#. Причём удобное использование, чтобы Nemerle не торчал из библиотеки во все стороны.
ОК. Хочешь я тебя удивлю? Обращайся ко мне на Скайп (логин такой же как ник тут) и я тебя за вечер научу как устранить проблему с именами полей. Уверяю тебя, что при этом ты к тому же получишь массу удовольствия.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
_FR>ОК, но тут нет никакого обращения к полям/свойствам варианта. Если я правильно понимаю "id" в примере — это переменная, имя которой матчится с именем параметра конструктора варианта.
Правильно понимаешь. Но бывают и более сложные случаи. Если параметров более одного, то чтобы вписывать вместо игнорируемых плэйсхолдеры ("_") используется такой синтаксис:
match (ast)
{
| Alias(имяПараметраКонструктора=образец) => ...
... // другие образцы
}
Этот образец соответствует синтаксису вызова конструктора с именованными параметрами принятому в немерле.
В этом случае имя параметра будет сильно мозолить глаз.
Да и сам объект может быть создан с помощью конструктора с использованием имен параметров.
ЗЫ
В общем, я не спорю. Можно называть поля и с большой буквы, но это уже идет в разрез с традициями ML откуда взят ПМ и вариантные типы.
_FR>Имя переменной матчится с именем параметра конструктора. Ни слова об имени свойства! _FR>Вспомним, ка кобъявляется вариант: _FR>
_FR>variant RgbColor
_FR>{ | Red
_FR> | Yellow
_FR> | Green
_FR> | Different { red : float; green : float; blue : float; }
_FR>}
_FR>
_FR>А теперь представим сеье такое объявление: _FR>
_FR>variant RgbColor
_FR>{ | Red
_FR> | Yellow
_FR> | Green
_FR> | Different { Red : float; Green : float; Blue : float; }
_FR>}
_FR>
_FR>Что мешает по такому определению сгенерировать класс с полями (пускай пока с полями) Red, Green и Blue и с консруктором, параметры в котором называются red, green, blue — так же как и поля, только в lowerCase? Это не вызовет никаких конфликтов с темми, кто предпочитает имеющийся синтаксис.
_FR>Таким образом Alias(id) отматчится верно по имени параметра конструктора.
VD>>Конечно можно сгенерировать (причем автоматически) свойства дублирующие эти поля. Но на мой взгляд — это все вкусовщина на которую не стоит тратить время. Плюс дублирование сущностей (поля и свойства будут мало чем отличаться) не есть гуд.
_FR>Совершенно верног, _дублировать_ (то есть иметь и открытые поля и открытые свойства) не нужно совсем, уж лучше как есть.
VD>>Так что если нужно ехать, а не шашечки лучше переступить через свои привычки и все будет ОК.
_FR>Ну в таком случае может вам свои гайдлайны начать писать? Имеющиеся-то не подходят, оказывается Нет уж. До тех пор, пока я не знал _почему_ имена полей вариантов таким образом выглядят было одно — просто необычно и неприятно. А теперь вот недоумеваэ.
VD>>Ну, а еще лучше попробовать освоить немерл. Ведь распознавание АСТ в десятки раз проще осуществлять с помощью паттерн-матчинга. Немерл ничем не отличается от Шарпа по возможнсотям.
_FR>Не спорю. Но правильно ли я понимаю, что в самом Немерле нет необходимости [часто?] обращаться явно к полям варианта? Потому что иначе получается странно — у одних типов свойства "как у людей" по гайдлайнам, а у других — с маленькой буквы. Тогда, может, в Немерле стоит придерживаться гайдлайна что поля в lower а свойства в Upper вне зависимости от открытости?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, hi_octane, Вы писали:
Tom>>Причём тут вообще IQ, я даже при очень большом желании использовать немерл не смогу пробить стену мэнеджмента который справедливо боится что поддержка сего проекта закончится сразу после того как кто то не ухватится за новую супер пупер идею, как это было с R# _>А чем опен-сорс компилятор отличается в данном случае от опен-сорс библиотеки?
Ну, я же говорю! Для него IQ нужен больше. Кода ведь больше и он сложнее!
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>это все вкусовщина на которую не стоит тратить время
... VD>Так что если нужно ехать, а не шашечки лучше переступить через свои привычки и все будет ОК.
... VD>Ну, а еще лучше попробовать освоить немерл.
... VD>В общем, надо просо понять, что Немерл имеет тотальное приемущество перед Шарпом
... VD>этот самый посетитель вам еще придется сгенерировать
Вот именно поэтому немерле так и останется игрушкой для небольшого количества товарищей.
... << RSDN@Home 1.2.0 alpha 4 rev. 1476 on Windows 7 6.1.7600.0>>
Здравствуйте, hardcase, Вы писали:
AVK>>И визитер в сотню, если не больше, узлов, да еще без контроля со стороны компилятора, придется, как я понимаю, писать ручками?
H>Ну а как ты хотел?
Я хотел чтобы он генерировался, как у всех нормальных людей. Иначе — в морг.
H> Посмотри на объектную модель Рефлектора или на тот же Expression линка, там тоже классов не две штуки
У ET сильно меньше типов узлов. Ну и тоже — не сахар.
... << RSDN@Home 1.2.0 alpha 4 rev. 1476 on Windows 7 6.1.7600.0>>
Здравствуйте, VladD2, Вы писали:
VD>Правильно понимаешь. Но бывают и более сложные случаи. Если параметров более одного, то чтобы вписывать вместо игнорируемых плэйсхолдеры ("_") используется такой синтаксис:
VD>Этот образец соответствует синтаксису вызова конструктора с именованными параметрами принятому в немерле. VD>В этом случае имя параметра будет сильно мозолить глаз.
Что-то я тут не увидел разницы Можно пример подробнее?
VD>Да и сам объект может быть создан с помощью конструктора с использованием имен параметров.
И какие сложности будут тут?
VD>ЗЫ VD>В общем, я не спорю. Можно называть поля и с большой буквы, но это уже идет в разрез с традициями ML откуда взят ПМ и вариантные типы.
ОК, то есть дело не принципиальное в устройстве компилятора, а в традициях? ОК.
Теперь далее, к свойствам. Есть ли технические проблемы, требующие необходимость именно в полях в вариантах или это тоже лишь дань традиции?
Help will always be given at Hogwarts to those who ask for it.
Здравствуйте, VladD2, Вы писали:
VD>Ты все же определись, что тебе больше нужно. Качественная, быстрая, поддерживаемая, используемая на практике библиотека или гайдлайны. Если последнее так важно, что ты готов взять библиотеку с худшими качествми, но удовлетворяющую гайдлайнам, то конечно это не твой выбор.
Не льсти себе. Она быстрая, это я тебе просто поверю на слово. Качественная? Нет, не все синтаксические конструкции разбираются. Поддерживается? Ты можешь назвать сроки когда парсер будет поддерживать unsafe? А если я найду ошибку кому писать? А когда ответят? А за три рабочих дня исправят?
VD>Если есть хорошая альтернатива и она удовлетворяет гайдлайнам, то конечно же ты прав и тебе стоит взять ее. Но если ее нет, то я вообще не понимаю о чем тут можно вести речь.
ANTLR. Найти человека понимающего Nemerle сложнее, чем найти человека понимающего ANTLR. Их просто больше.
VD>Что касается конкретно свойств, то их можно нагенерировать за пять минут средствами тех же макросов. Так что если это табокой уж страшный батхерт, то его можно устранить.
Для этого нужно желание. А вы, всего лишь, не против.
VD>Но я тебе открою одну маленькую тайну. Дело в том, что разговоры про регистры полей — это просто смешные придирки по сравнению с тем, что могло бы дать применение паттерн-матчинга для обработки полученного АСТ.
Может быть. Но использовать библиотеку на Nemerle и переводить проект на Nemerle — разные бизнес-риски.
VD>Тебе нужен парсер шарпа не просто так? Это ведь не самоцель? Ты, наверно, с его помощью хочешь делать что-то хитрое с кодом, да? Если задачи, стоящие перед тобой, не тривиальные, ты можешь получить очень существенную (да что там, НЕСРАВНИМУЮ) выгоду, если потратишь день на изучение вариантных типов и паттерн-матчинга, и в результате напишешь код обработки АСТ на Немерле, а не на Шарпе. Разница будет настолько существенной, что твои опасения, и тем более недовольство регистрами полей, померкнут на фоне тех преимущество, что ты получишь. Ну, а результат ты можешь завернуть в библиотеку которая будет иметь кошерный публичный интерфейс в лучших традициях FxCop. И уже его можно будет использовать из проекта на шарпе.
Может ты и прав, но для этого у меня должен быть бюджет для экспериментов. Обычно, у меня такого бюджета нет.
VD>Если подумать, то просто выбирая библиотеку парсера ты уже даешь добро на использование кода скомпилированного немерловым компилятором.
Влад, я не рассит какой-нибудь. Мне всё равно если код скомпилирован еомпилятором Nemerle. Я не хочу на данном этапе писать и читать код Nemerle.
VD>А раз так, то сделать еще один мелкий шажок
Маленький шаг для программиста, но гигантский скачок для всей компании.
VD>Ну, а страх можно побороть аутотренингом вроде такого — Утилита обработки кода мне нужна не для продакшена. Это просто внутренняя утилита. Если что перепишу ее на шарпе. А пока сэкономлю кучу времени используя инструмент намного лучше подходящий для решения задачи.
Ой, не всё так просто, увы. Стоит если не переехать, то вплотную познакомиться. Вот Питон я недавно начал трогать, было надо. А Немерле пока не надо. Можно, но не надо.
Здравствуйте, VladD2, Вы писали:
VD>Сам понимаешь, так как библиотека писалась в первую очередь для использования из немрела, то о выборе гайдлайнов даже речи не шло.
Влад, ну а когда будете общаться не только между собой? Ты правда хочешь захватить мир? Может стоит подумать о постепенной интеграции. Я вот когда пишу на C# думаю о том, что может быть, когда-нибудь... Нет, серьёзно у меня был факт внесения правок в C# код потенциально несовместимый с IronPython. И я не доказывал что IronPython — говно. Мне кажется, я был дружелюбнее и конструктивнее.
VD>Почему же? Используются иногда. В немерле с самого начала были именованные параметры. В Шарпе они появились в 4.0. Но теперь и в нем они могут использоваться. Иногда это повышает выразительность.
Я про шарп.
VD>Нет, нет, нет дорогой товарищ! Ты все же оцени за и против. Насколько твои привычки дороги? Можно ими пожертвовать ради резкого упрощения реализации?
Это не мои привычки, это привычки сообщества .Net. Я не буду использовать что-то нестантдартное в публичной библиотеке. Даже в приватной не буду, потому чтот новый программист потратит больше времени чтобы разобраться. Я не единственный программист в компании и как бы ни был крут Nemerle я не готов сейчас оплачивать кучу часов на его изучение.
A>>Пропаганда неуместа, время одноязычных программ давно прошло. Ты либо интегируешься, либо умираешь. Максимум на что ты можешь сегодня расчитывать — это использование твоего парсера из C#. Причём удобное использование, чтобы Nemerle не торчал из библиотеки во все стороны. VD>ОК. Хочешь я тебя удивлю? Обращайся ко мне на Скайп (логин такой же как ник тут) и я тебя за вечер научу как устранить проблему с именами полей. Уверяю тебя, что при этом ты к тому же получишь массу удовольствия.
Не впаривай мне шестёрку, которая зверь-машина если кое-что подкрутить. Впаривай мне S-класс. Не общайся со мной как программист, общайся как бизнесмен. Инвестиции, риски, сроки — вот что меня волнует. Ты просишь у меня кредит — один вечер, не давая ничего в залог.
Здравствуйте, VladD2, Вы писали:
A>>На момент написания этого сообщения, я не знал, что парсер оформлен как самостоятельная библиотека. VD>Ну, можно же было предположить, что окружающие не идиоты?
Парсер мог быть ЧАСТЬЮ другой библиотеки, а не самостоятельной библиотекой.
Здравствуйте, VladD2, Вы писали:
AVK>>Вот именно поэтому немерле так и останется игрушкой для небольшого количества товарищей.
VD>Не забудь свои слова лет через 10.
Уже 10?! А пару лет назад до мирового господства не хватало всего лишь допилить интеграцию.
Здравствуйте, _FRED_, Вы писали:
_FR>Что-то я тут не увидел разницы Можно пример подробнее?
Возьмем к примеру BinaryOperator. Для шарпа он выглядит так:
[VariantOption]
public sealed class BinaryOperator : Expr
{
// Fieldspublic readonly Expr left;
public readonly Identifier op;
public readonly Expr right;
// Methodspublic BinaryOperator(Expr left, Expr right, Identifier op);
public BinaryOperator(Location location, Expr left, Expr right, Identifier op);
public override int _N_GetVariantCode();
}
Для немерла так:
[Record]
public variant Expr : Located
{
...
| BinaryOperator { left : Expr; left : Expr; op : Identifier; }
...
Предположим, что нам надо отловить оператор "==". При этом нам совершенно все равно что за подвыражения в этом операторе (т.е. все равно что содержат поля left и right).
Для этого мы можем написать образец:
В нем вместо параметров left и left указаны плэйсходеры — "_". Так как плэйсхолдеры сопоставляются со всем чем угодно (даже с null), то мы получим требуемый результат. Кстати, Identifier — это не вариант, а простой класс. Так что "Identifier where(id="==")" — это поттерн-матчинг по объекту.
Так вот того же самого эффекта можно добиться если вместо приведенного выше паттерна можно использовать вот такой:
Понятно, что на вхождение варианта с тремя полями выигрыш неощутим, но если представить себе вхождение с десятью полями, то это становится удобно. Кроме того понято что происходит.
Собственно с классами только такой синтаксис пока и доступен. Плюс надо еще ключевое слово where со скобками добавлять.
VD>>Да и сам объект может быть создан с помощью конструктора с использованием имен параметров.
_FR>И какие сложности будут тут?
Никаких, но будет видно что параметры в ПаскальКейсе.
_FR>ОК, то есть дело не принципиальное в устройстве компилятора, а в традициях? ОК.
Да.
_FR>Теперь далее, к свойствам. Есть ли технические проблемы, требующие необходимость именно в полях в вариантах или это тоже лишь дань традиции?
Да. В варианта всегда описываются поля. Причем поле у которого не указан атрибут [RecordIgnore] автоматом попадает в конструктор. Вся суть вариантов в этом и заключается. Компилятор знает о соответствии полей параметрам конструктора и на основании этого знания позволяет описывать паттерны в виде конструкторов (возможно вложенных, и даже рекурсивных).
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Почему себе? Автор не я. Я только в дизайне и эволюции участие принимал.
A>Она быстрая, это я тебе просто поверю на слово.
Можешь проверить.
A>Качественная? Нет, не все синтаксические конструкции разбираются.
Это еще почему? Не, я не спорю, баги конечно везде возможны. Но вроде как спецификация шарпа отработана. Парсер проверен на большом количестве реальных исходников.
A>Поддерживается? Ты можешь назвать сроки когда парсер будет поддерживать unsafe?
Да, конечно. Но не точно. Приблизительно — вчера .
Ты видимо нашел сообщения где Хардкейс рассказывал о фичах не поддерживаемых конвертером шарпа в немерл. Дык это потому, что компилятор немерла некоторые фичи не поддерживает в принципе. Но это не имеет отношения к парсеру. Парсер выдает честное АСТ 4-го шарпа.
A>А если я найду ошибку кому писать?
Багтрекеру, вестимо. Можно еще продублировать в форум или Хардкейсу лично, так как это его детище.
A>А когда ответят? А за три рабочих дня исправят?
Дык обычно отвечают прямо сразу. Мы ведь, как и ты, в Интернете живем . Если нужен интерактив, то у всех есть Скайп-экаунт. Можно по скайпу постучаться.
VD>>Если есть хорошая альтернатива и она удовлетворяет гайдлайнам, то конечно же ты прав и тебе стоит взять ее. Но если ее нет, то я вообще не понимаю о чем тут можно вести речь.
A>ANTLR. Найти человека понимающего Nemerle сложнее, чем найти человека понимающего ANTLR. Их просто больше.
Ну, бери ANTLR. Можешь даже взять то и другое, а потом сравнить. Я вот не остался в восторге от использования ANTLR-а под дотнетом. В прочем, выбор за тобой.
VD>>Что касается конкретно свойств, то их можно нагенерировать за пять минут средствами тех же макросов. Так что если это табокой уж страшный батхерт, то его можно устранить.
A>Для этого нужно желание. А вы, всего лишь, не против.
Ну, да. У нас и желания этим заниматься нет, так как оно нам не нужно.
Но если тебе нужно, то мы поможем. Мы же не звери (розовый слоник застенчиво водит по полу правой лапкой)?
VD>>Но я тебе открою одну маленькую тайну. Дело в том, что разговоры про регистры полей — это просто смешные придирки по сравнению с тем, что могло бы дать применение паттерн-матчинга для обработки полученного АСТ.
A>Может быть. Но использовать библиотеку на Nemerle и переводить проект на Nemerle — разные бизнес-риски.
Дык проект и не надо, ну, по крайне мере пока сам не втянешься. А вот код который занимается анализом и/или трансформацией АСТ-а очень даже полезно было бы перевести.
VD>>Тебе нужен парсер шарпа не просто так? Это ведь не самоцель? Ты, наверно, с его помощью хочешь делать что-то хитрое с кодом, да? Если задачи, стоящие перед тобой, не тривиальные, ты можешь получить очень существенную (да что там, НЕСРАВНИМУЮ) выгоду, если потратишь день на изучение вариантных типов и паттерн-матчинга, и в результате напишешь код обработки АСТ на Немерле, а не на Шарпе. Разница будет настолько существенной, что твои опасения, и тем более недовольство регистрами полей, померкнут на фоне тех преимущество, что ты получишь. Ну, а результат ты можешь завернуть в библиотеку которая будет иметь кошерный публичный интерфейс в лучших традициях FxCop. И уже его можно будет использовать из проекта на шарпе.
A>Может ты и прав, но для этого у меня должен быть бюджет для экспериментов. Обычно, у меня такого бюджета нет.
Э... время на треп со мной ты нашел? Бюджет на это не понадобился? Ну, вот и это тоже можно попробовать по вечерам. Подумаешь, пропустишь 1-2 флэйма.
Начни с того, что опиши задачу. Глядишь мы тебе что-то умное подскажем. Все же мы уже на парсинге свору собак употребили.
A>Влад, я не рассит какой-нибудь. Мне всё равно если код скомпилирован еомпилятором Nemerle. Я не хочу на данном этапе писать и читать код Nemerle.
Не читай. Я не заставляю. Я просто говорю, что на самом деле это скорее всего было бы полезно для твоей задачи! И это ко всему прочему еще и очень увлекательно! А дальше каждый сам себе друг, враг и злобный Буратина.
VD>>А раз так, то сделать еще один мелкий шажок
A>Маленький шаг для программиста, но гигантский скачок для всей компании.
Агя. Я тоже хотел этот штампик употребить, но понял что штампик и отказался .
На самом деле шажок и правда мелкий, но это как шажок Алисы в зазеркалье. Никто не знает... а... опять штамп!
VD>>Ну, а страх можно побороть аутотренингом вроде такого — Утилита обработки кода мне нужна не для продакшена. Это просто внутренняя утилита. Если что перепишу ее на шарпе. А пока сэкономлю кучу времени используя инструмент намного лучше подходящий для решения задачи.
A>Ой, не всё так просто, увы. Стоит если не переехать, то вплотную познакомиться. Вот Питон я недавно начал трогать, было надо. А Немерле пока не надо. Можно, но не надо.
Дык, пойми, чудак-человек. Питон ты не знал. Он из другого мира. А Немрел ты уже процентов на 50 знаешь. Ты можешь прямо с места (в карьер — опять штампик) начать писать на нем как на шарпе. А после пары подсказок освоить то что тебе реально нужно для твоей задачи. А нужно тебе по сути только одно — паттерн-матчинг.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Воронков Василий, Вы писали:
ВВ>Ну вот если убрать ограничение на название вариантов и переменных, то и получится конфликт, о чем, собственно, и спрашивалось, если я правильно понял.
С полями (о которых идет речь) конфликта не будет. Будет другое несоответствие гайдлайну. Поля станут кошерно-ПаскальКейсными, но такими же станут и параметры конструкторов.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, adontz, Вы писали:
A>Вопрос касался не конкретно unsafe, А чего-то нереализованного.
Дык тебе и говорят. Реализована спецификация C# 4.0. Баги конечно возможны, но поправить их не составит труда, так как все весьма декларативно. Рукописного кода парсинга практически нет (если не считать за таковой код разбора операторов, введенный для упрощения).
Парсер прогоняли на куче исходников. От Януса, до исходников дотнета. Вроде пашет.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, _FRED_, Вы писали:
_FR>Я вот наоборот, просматривая исходники четвёртого фреймворка нарадоваться не мог тому, что количество sealed классов (даже с private областью вилимости) увеличилось и readonly поля стали использоваться заметно чаще.
Я тоже этому рад. Только вот в моем коде (а так же в коде Вольфхаунда и Хардкеса, которые так же работают над проектом), как раз трудно встретить изменяемые поля. И это правильно!
VD>>Сейчас ситуация постепенно выправляется, но все же императивная идеология крепко засела во многих головах (и в вашей, кстати, тоже).
_FR>Не понимаю почему вытравление императивной диалогии должно быть обязательно связано с гайдлайнами к именованию членов классов Этот аргумент в данном обсуждении по силе не хуже того, что у меня ухи торчком или нос пяточком.
Да не связано это с именованием. Это связано с отношением к полям. Есть изменяемые поля, а есть не изменяемые, и это две большие разницы! Неизменяемые поля на практике проблем не создают.
Плюс именно иделогия влияет на твое восприятие объектов с публичными полями. Но это однобокая идеология! Есть и другие идеологии в которых открытая структура типов не является огромной проблемой. Варианты — это не совсем объекты. Они предлагают другую идеологию.
VD>>Меж тем никаких проблем с публичными полями нет, если, конечно, они доступны только на чтение. Более того, в таких условиях свойства просто не ясно зачем нужны.
_FR>Я же показал один пример — биндинг. Глубже думать пока нет необходимости.
А что биндинг? Биндинг твой — это как раз и есть проявление той самой императивной идеологии. Где-то это удобно. Но намного чаще рулят неизменяемые объекты. С ними логика становится проще.
_FR>Ещё раз — я говорю не о гайдлайнах языка. Я говорю о гайдлайнах платформы. Классов может не быть в ваших функциональных головах (уж простите мне мой добрый и ненарошный укол) но классы есть в ваших сборках, которые может кто-то использовать из языков-конкурентов. И если нет желания обсудить всплывший вопрос в конструктивном ключе окромя как "а у вас… а у нас… да вы(мы) все…" давайте прекратим. В противном случае, может отделить топик откудато-отсюда
и перенести в Немерле или оставить тут, но всё-таки отделить?
Мне все равно. Проголосовал за отделение.
Что же до обсуждения, я уже все сказал. С кейсом — это такие же традиции, как и те гайдлайны о которых ты говоришь.
Сделать эксесоры конечно можно. Но поля сдеать приватными нельзя, так как это только для C#-а — это классы.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, adontz, Вы писали:
A> Ты правда хочешь захватить мир?
Нет. Мне его пока что ставить некуда.
A>Может стоит подумать о постепенной интеграции. Я вот когда пишу на C# думаю о том, что может быть, когда-нибудь...
Дык я когда пишу библиотеку которая будет использоваться из других языков тоже продумываю ее интерфейс. Но парсер — это не тот случай. Использование ООП для анализа АСТ — это жуткое уныло говно. Совместимость нашей библиотеки с Шарпом обусловлена исключительно дизайном вариантов основанных на классах. Я сразу сказал, что ее можно использовать из Шарпа или Васика, но лучше испльзоват из Немерла. В нем такой дизайн дает больше 9000 преимуществ.
A>Нет, серьёзно у меня был факт внесения правок в C# код потенциально несовместимый с IronPython. И я не доказывал что IronPython — говно. Мне кажется, я был дружелюбнее и конструктивнее.
Ну, значит ты больше любишь змей .
VD>>Почему же? Используются иногда. В немерле с самого начала были именованные параметры. В Шарпе они появились в 4.0. Но теперь и в нем они могут использоваться. Иногда это повышает выразительность.
A>Я про шарп.
И я тоже, если ты не заметил.
VD>>Нет, нет, нет дорогой товарищ! Ты все же оцени за и против. Насколько твои привычки дороги? Можно ими пожертвовать ради резкого упрощения реализации?
A>Это не мои привычки, это привычки сообщества .Net.
Ну, не знаю. Если мне дадут Бугати Веерон с правым рулем, я пожалуй забью на все лишь бы на Веероне прокатиться.
A>Я не единственный программист в компании и как бы ни был крут Nemerle я не готов сейчас оплачивать кучу часов на его изучение.
А зачем его учить всем чтобы написать одну утилиту которую пишешь ты?
A>Не впаривай мне шестёрку, которая зверь-машина если кое-что подкрутить. Впаривай мне S-класс. Не общайся со мной как программист, общайся как бизнесмен. Инвестиции, риски, сроки — вот что меня волнует. Ты просишь у меня кредит — один вечер, не давая ничего в залог.
Я тебе вообще ничего впаривать не собираюсь. И бизнесмен из меня тоже хреновый наверно. Я тебе предлагаю показать зазеркалье. Но конечно тебе решать. Можешь и дальше жить в своем мире.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
A>>Я не единственный программист в компании и как бы ни был крут Nemerle я не готов сейчас оплачивать кучу часов на его изучение. VD>А зачем его учить всем чтобы написать одну утилиту которую пишешь ты?
Потому что так не бывает, что я что-то пишу и никто в компании этого больше не понимает. Это не нормально.
VD>Я тебе предлагаю показать зазеркалье. Но конечно тебе решать. Можешь и дальше жить в своем мире.
Я мог бы такие слова сказал девушке, которую уламываю на секс. страшно подумать что же такое Nemerle на самом деле. Надо как-нибудь попробовать. Но чтоб никто не видел. Один раз — не немерлист.
Здравствуйте, Lloyd, Вы писали:
L>Уже 10?! А пару лет назад до мирового господства не хватало всего лишь допилить интеграцию.
Что значит уже? Покажи мне хотя бы один язык который стал популярным быстрее и при этом за ним не стояла мега-корпорация. Даже с наличием мега-корпорации все равно проходит много лет пока придется популярность.
По дотнету только сейчас перестали просить показать что на нем написано.
Руби, Питон и многие другие шли к популярности не меньше десяти лет. Так что я реалист.
Но единственное, что может помещать Немерлу стать популярным — это появление сопоставимого по возможностям и (главное) расширяемости языка. Вот если в Шарпе воплотят хотя бы 70% того что есть в немерле, то немерлу конечно не жить. Но все идет к обратному.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, adontz, Вы писали:
A>Потому что так не бывает, что я что-то пишу и никто в компании этого больше не понимает. Это не нормально.
Да ладно тебе. Вот исходники Булкита, например, никто кроме IT в полном объеме не понимают. Но ведь Булкит все же используют?
VD>>Я тебе предлагаю показать зазеркалье. Но конечно тебе решать. Можешь и дальше жить в своем мире.
A>Я мог бы такие слова сказал девушке, которую уламываю на секс. страшно подумать что же такое Nemerle на самом деле. Надо как-нибудь попробовать. Но чтоб никто не видел. Один раз — не немерлист.
Надо. Тем более что ты вроде не девушка, а я старомодный гетеросексуал. Так что никаких задних мыслей у меня нет .
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, adontz, Вы писали:
A>Учитывая правильный акцент такой парсер становится для меня неподдерживаемым продуктом. Потому что если завтра в нём будет что-то, что удобно (естественно) использоват из Nemerle и не удобно использовать из C# я получу порцию пропаганды Nemrele, а не исправление под C#.
Тут оно как. Мы же не звери. Если кто-то начнет использовать продукт, то конечно с его интересами будут считаться.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
A>>Потому что так не бывает, что я что-то пишу и никто в компании этого больше не понимает. Это не нормально. VD>Да ладно тебе. Вот исходники Булкита, например, никто кроме IT в полном объеме не понимают. Но ведь Булкит все же используют?
Но язык-то на котором он написан знают многие! Мы говорим о языке, а не о библиотеке. Для бизнеса это больший риск.
Здравствуйте, adontz, Вы писали:
A>Но язык-то на котором он написан знают многие! Мы говорим о языке, а не о библиотеке. Для бизнеса это больший риск.
Не, не знают. В любом проекте как не крути появляются собственные подязыки. Не поняв их понять реализацию нельзя. Скажем у IT применяется эмуляция паттерн-матчинга. Причем выглядит она жутко. Но без нее задача была бы совсем неподъемной. И чтобы понять его проект нужно понимать, что делает этот паттерн-марчинг.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
A>>Потому что так не бывает, что я что-то пишу и никто в компании этого больше не понимает. Это не нормально. VD>Да ладно тебе. Вот исходники Булкита, например, никто кроме IT в полном объеме не понимают. Но ведь Булкит все же используют?
Я сам там не всё понимаю, приходится каждый раз по-новой разбираться. Было бы всё это на Немерле, было бы гораздо проще и понятнее.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, adontz, Вы писали:
VD>>Парсер прогоняли на куче исходников. От Януса, до исходников дотнета. Вроде пашет.
A>Ну, это уже показатель.
Кстати, о парсере шарпа. Вот тут можно взять парсер на на основе АНТЛР-а.
Вот только для сборки нужна Ява и есть одна проблема. Для сравнения наш парсер в релизе работает примерно в 10 раз быстрее. И это при том что PegParser значительно гибче АНТЛР-а (например, рассчитан на динамическое расширение грамматики).
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
VD>В нем вместо параметров left и left указаны плэйсходеры — "_". Так как плэйсхолдеры сопоставляются со всем чем угодно (даже с null), то мы получим требуемый результат. VD>Кстати, Identifier — это не вариант, а простой класс. Так что "Identifier where(id="==")" — это поттерн-матчинг по объекту.
Ага, и поэтому Id с большой буквы? Имхо, в этом плохого ничего нет, наоборот понятно, что проверяется свойство Id. То, что Identifier с большой буквы тоже говорит о том, что это имя типа.
VD>Так вот того же самого эффекта можно добиться если вместо приведенного выше паттерна можно использовать вот такой:
VD>Понятно, что на вхождение варианта с тремя полями выигрыш неощутим, но если представить себе вхождение с десятью полями, то это становится удобно. Кроме того понято что происходит.
Спасибо, теперь понятно.
VD>Собственно с классами только такой синтаксис пока и доступен. Плюс надо еще ключевое слово where со скобками добавлять. VD>>>Да и сам объект может быть создан с помощью конструктора с использованием имен параметров. _FR>>И какие сложности будут тут? VD>Никаких, но будет видно что параметры в ПаскальКейсе.
в ПаскальКейсе только "Identifier" и "Id" — о каких параметрах речь? Непосредственно к вариантам класс "Identifier" отношения не имеет. То есть сейячас речь о Record-ах? Так там тоже поля получаются Почему нельзя сделать так же: пользователь указывает
[Record]
public class Identifier : Located
{
[Accessor] Id : string;
public override ToString() : string
{
id
}
}
а параметр конструктора называется "id"? А свойство — Id. (другое дело, если пользователь объявил два свойстьва: id и Id — тогда и параметра конструктора должно быть два в разном регистре. Это не сложно разрулить).
Дальше: в where(Id="==") "Id" — это параметр конструктора, тогда можно (то есть даже придётся) будет писать where(id="==") а если Id — это поле/свойство, то должно быть написано с большой буквы и "параметры в ПаскальКейсе" всё-таки будут отсутствовать.
_FR>>ОК, то есть дело не принципиальное в устройстве компилятора, а в традициях? ОК. VD>Да.
Тут разве что могу предложить принять точку зрения того, что данные традиции противоречат традициям дотнета.
_FR>>Теперь далее, к свойствам. Есть ли технические проблемы, требующие необходимость именно в полях в вариантах или это тоже лишь дань традиции? VD>Да. В варианта всегда описываются поля. Причем поле у которого не указан атрибут [RecordIgnore] автоматом попадает в конструктор. Вся суть вариантов в этом и заключается. Компилятор знает о соответствии полей параметрам конструктора и на основании этого знания позволяет описывать паттерны в виде конструкторов (возможно вложенных, и даже рекурсивных).
ИМХО, знание о том, как свойства соответствуют параметрам конструктора (с учётом разлиций в написании) не есть большая сложность для компилятора. А, субъективно конечно же, ценности работы компилятора это прибавит совершенно точно.
Help will always be given at Hogwarts to those who ask for it.
Здравствуйте, VladD2, Вы писали:
_FR>>Я вот наоборот, просматривая исходники четвёртого фреймворка нарадоваться не мог тому, что количество sealed классов (даже с private областью вилимости) увеличилось и readonly поля стали использоваться заметно чаще. VD>Я тоже этому рад. Только вот в моем коде (а так же в коде Вольфхаунда и Хардкеса, которые так же работают над проектом), как раз трудно встретить изменяемые поля. И это правильно! VD>>>Сейчас ситуация постепенно выправляется, но все же императивная идеология крепко засела во многих головах (и в вашей, кстати, тоже).
А надо мной на последних работах коллеги стебались: что всё у меня sealed да internal/private, никак не расширить.не добавить полезного функциолнала
_FR>>Не понимаю почему вытравление императивной диалогии должно быть обязательно связано с гайдлайнами к именованию членов классов Этот аргумент в данном обсуждении по силе не хуже того, что у меня ухи торчком или нос пяточком. VD>Да не связано это с именованием. Это связано с отношением к полям. Есть изменяемые поля, а есть не изменяемые, и это две большие разницы! Неизменяемые поля на практике проблем не создают.
Да и изменяемые не создают, если их не изменять Я привык относиться к полям как к сущностям, хранящим информиацию, а к свойствам — как к сущностям, предоставляющим хранящуюся информацию. И очень не хочу разубеждаться в этом. Будет жаль, если этот поставит крест на моём желании работать более "функционально" с помощью Немерла. Придётся курить F# — синтаксис там конечно покучерявее, зато обсуждаемой проблемы нет. И в рекордах и в дискриминайтед юнионах честные, привычные, старые добрые свойства. Почему-то функциональное программирование на F# не заставляет меня по другому относиться к полям.
VD>Плюс именно иделогия влияет на твое восприятие объектов с публичными полями. Но это однобокая идеология! Есть и другие идеологии в которых открытая структура типов не является огромной проблемой. Варианты — это не совсем объекты. Они предлагают другую идеологию.
Варианты — это же дискриминайтед юнионы? Ну так где-то они сделаны по-другому.
VD>>>Меж тем никаких проблем с публичными полями нет, если, конечно, они доступны только на чтение. Более того, в таких условиях свойства просто не ясно зачем нужны. _FR>>Я же показал один пример — биндинг. Глубже думать пока нет необходимости. VD>А что биндинг? Биндинг твой — это как раз и есть проявление той самой императивной идеологии. Где-то это удобно. Но намного чаще рулят неизменяемые объекты. С ними логика становится проще.
И как неизменяемость объектов позволит проще отобразить список этих объектов в гриде?
VD>Что же до обсуждения, я уже все сказал. С кейсом — это такие же традиции, как и те гайдлайны о которых ты говоришь. VD>Сделать эксесоры конечно можно. Но поля сдеать приватными нельзя, так как это только для C#-а — это классы.
Весьма жаль. В таком виде дополнительные свойства конечно же лишь будут мешать.
Help will always be given at Hogwarts to those who ask for it.
Здравствуйте, VladD2, Вы писали:
VD>Кстати, о парсере шарпа. Вот тут можно взять парсер на на основе АНТЛР-а. VD>Вот только для сборки нужна Ява и есть одна проблема. Для сравнения наш парсер в релизе работает примерно в 10 раз быстрее. И это при том что PegParser значительно гибче АНТЛР-а (например, рассчитан на динамическое расширение грамматики).
Здравствуйте, VladD2, Вы писали:
VD>С полями (о которых идет речь) конфликта не будет. Будет другое несоответствие гайдлайну. Поля станут кошерно-ПаскальКейсными, но такими же станут и параметры конструкторов.
Ну можно, наверное, сделать так, чтобы названия параметров конструкторов всегда переводились в кэмел, раз людей сей факт так беспокоит.
Здравствуйте, Воронков Василий, Вы писали:
VD>>С полями (о которых идет речь) конфликта не будет. Будет другое несоответствие гайдлайну. Поля станут кошерно-ПаскальКейсными, но такими же станут и параметры конструкторов.
ВВ>Ну можно, наверное, сделать так, чтобы названия параметров конструкторов всегда переводились в кэмел, раз людей сей факт так беспокоит.
Как верно указал Влад где-то выше, это будет ещё хуже.
Help will always be given at Hogwarts to those who ask for it.
Здравствуйте, _FRED_, Вы писали:
ВВ>>Ну можно, наверное, сделать так, чтобы названия параметров конструкторов всегда переводились в кэмел, раз людей сей факт так беспокоит. _FR>Как верно указал Влад где-то выше, это будет ещё хуже.
Здравствуйте, VladD2, Вы писали:
VD>Что же до обсуждения, я уже все сказал. С кейсом — это такие же традиции, как и те гайдлайны о которых ты говоришь. VD>Сделать эксесоры конечно можно. Но поля сдеать приватными нельзя, так как это только для C#-а — это классы.
Вот кстати написал на F# такой тип:
type XColor = { X : double; Y: double; Z: double; }
Конструктор, что для меня лично не удивительно, компилятор сгенерировал такой:
public XColor(double x, double y, double z);
Help will always be given at Hogwarts to those who ask for it.
Здравствуйте, Воронков Василий, Вы писали:
ВВ>>>Ну можно, наверное, сделать так, чтобы названия параметров конструкторов всегда переводились в кэмел, раз людей сей факт так беспокоит. _FR>>Как верно указал Влад где-то выше, это будет ещё хуже.
ВВ>Ссылочку не дашь? Я что-то не нахожу.
По этому если сделать имена полей с большой буквы, то с большой буквы будут и имена параметров конструкторов. Это еще хуже соотносится с гайдлайнами.
_FR>По этому если сделать имена полей с большой буквы, то с большой буквы будут и имена параметров конструкторов. Это еще хуже соотносится с гайдлайнами.
Я имел в виду можно сделать так, чтобы компилятор, генерируя названия полей для конструктора, автоматически приводил бы их в кэмел-регистр. Т.е. поля бы ты назвал в Паскале, названия параметров получились бы в Кэмеле — и все довольны.
_FR>>По этому если сделать имена полей с большой буквы, то с большой буквы будут и имена параметров конструкторов. Это еще хуже соотносится с гайдлайнами.
ВВ>Я имел в виду можно сделать так, чтобы компилятор, генерируя названия полей для конструктора, автоматически приводил бы их в кэмел-регистр. Т.е. поля бы ты назвал в Паскале, названия параметров получились бы в Кэмеле — и все довольны.
А, понял. Только вот фраза "названия полей для конструктора" неочём: у конструктора есть параметры.
Здравствуйте, VladD2, Вы писали:
VD>Парсер прогоняли на куче исходников. От Януса, до исходников дотнета. Вроде пашет.
Ты мог бы дать мне консольную утилитку, которой я скармливаю имя файла с исходником C#, а она его парсит и дампит дерево в какой-нибудь текстовой форме? Если найду баги, обещаю сообщить.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, adontz, Вы писали:
VD>Парсер прогоняли на куче исходников. От Януса, до исходников дотнета. Вроде пашет.
Что пашет? AST разбирается без выброса Exception. Или эти исходники без правки, целиком компильнулись (парсинг вместе с Немерлевской кодогениерацией) в работающее приложение ?
VD>По этому если сделать имена полей с большой буквы, то с большой буквы будут и имена параметров конструкторов. Это еще хуже соотносится с гайдлайнами.
А вроде ничего страшного на первый взгляд в этом не видно, если с большой буквы:
match (ast)
{
| Alias(Id) => WriteLine(Id);
... // другие образцы
}
Даже лучше заметно что это имя привязано к члену класса а не произовльно выбираемые имена как в | h::t ->
Хотя это все мелочи.
Это же все скорее примерный аналог доступа к полям, чем объявление локальной переменной.
Смесь VB с C#
if(obj is ...)
{
var ast=(Alias)obj;
With ast
WriteLine(.Id);
End With
}
Здравствуйте, adontz, Вы писали:
A> ...Максимум на что ты можешь сегодня расчитывать — это использование твоего парсера из C#. Причём удобное использование, чтобы Nemerle не торчал из библиотеки во все стороны.
К сожалению с парсером немного другая ситуация. Максимум на что мы можем расчитывать это подарок свыше (от MS), парсер C# и то через несколько лет, хорошо если 1-2, а может через 4 года. А тут любители сели за пару дней себе написали парсер C# на коленке. Практически полный.
Здравствуйте, nikov, Вы писали:
N>Здравствуйте, VladD2, Вы писали:
VD>>Парсер прогоняли на куче исходников. От Януса, до исходников дотнета. Вроде пашет.
N>Ты мог бы дать мне консольную утилитку, которой я скармливаю имя файла с исходником C#, а она его парсит и дампит дерево в какой-нибудь текстовой форме? Если найду баги, обещаю сообщить.
Утиллитка подобная у нас есть, но дамп она не делает — она просто сообщает произошел ли разбор, и если он произошел, были ли (и в каких местах) синтаксические ошибки.
В принципе возможно сделать так, чтобы она дампила дерево.
Здравствуйте, hardcase, Вы писали:
N>>Ты мог бы дать мне консольную утилитку, которой я скармливаю имя файла с исходником C#, а она его парсит и дампит дерево в какой-нибудь текстовой форме? Если найду баги, обещаю сообщить.
H>Утиллитка подобная у нас есть, но дамп она не делает — она просто сообщает произошел ли разбор, и если он произошел, были ли (и в каких местах) синтаксические ошибки.
using System;
unsafe class C
{
int* x = (int*) -1;
}
3)
class A
{
static void Main()
{
object[] p = null;
var q = from x in p
where x is int?
select x;
}
}
4)
using System;
class C : IDisposable
{
public void Dispose() {}
public static C operator *(C x, C y)
{
using (x * y * y)
{
return x;
}
}
}
5)
class P
{
static void Main()
{
using (C? x = new C() + from y in new[] { 1 }
join z in new[] { 1 } on y equals z
let s = y + z
select s is int ? "" : null) { }
}
}
На таком упало по OutOfMemoryException:
class A
{
static void Foo()
{
a:
}
}
Здесь без ошибок распарсил грамматически некорректный код:
1)
class A
{
object x = List<List<>>.Foo;
}
2)
class A
{
object x = &&1;
}
3)
class C
{
bool? b = i is int?? true : false;
}
Директивы препроцессора вообще не работают (пока не реализованы?)
Здравствуйте, nikov, Вы писали:
N>Такой код не распарсился: N>На таком упало по OutOfMemoryException: N>Здесь без ошибок распарсил грамматически некорректный код: N>Директивы препроцессора вообще не работают (пока не реализованы?)
А теперь товарищи незвери, называем сроки исправления и придерживаемся этих сроков.
Здравствуйте, adontz, Вы писали:
A>Здравствуйте, nikov, Вы писали:
N>>Такой код не распарсился: N>>На таком упало по OutOfMemoryException: N>>Здесь без ошибок распарсил грамматически некорректный код: N>>Директивы препроцессора вообще не работают (пока не реализованы?)
A>А теперь товарищи незвери, называем сроки исправления и придерживаемся этих сроков.
Здравствуйте, hardcase, Вы писали:
H>Логично что нужно парсить все что можно распарсить. Что не так пускай думает код, который будет анализировать AST.
Здравствуйте, hardcase, Вы писали:
H>>>Так и должно быть. N>>Почему это? H>Логично что нужно парсить все что можно распарсить. Что не так пускай думает код, который будет анализировать AST.
Логично выдавать диагностическое сообщение и проводить процедуру восстановления. Текущее поведение никак не коррелирует с общепринятыми методиками восстановления после ошибки.
Здравствуйте, nikov, Вы писали:
N>Здравствуйте, hardcase, Вы писали:
H>>Логично что нужно парсить все что можно распарсить. Что не так пускай думает код, который будет анализировать AST.
N>А как парсится оператор && без левого аргумента?
Скорее всего там распарсились два последовательных оператора взятия адреса.
Здравствуйте, adontz, Вы писали:
A>Здравствуйте, hardcase, Вы писали:
H>>>>Так и должно быть. N>>>Почему это? H>>Логично что нужно парсить все что можно распарсить. Что не так пускай думает код, который будет анализировать AST.
A>Логично выдавать диагностическое сообщение и проводить процедуру восстановления. Текущее поведение никак не коррелирует с общепринятыми методиками восстановления после ошибки.
Логичное диагностическое сообщение выдадет типизатор AST.
Здравствуйте, hardcase, Вы писали:
A>>Логично выдавать диагностическое сообщение и проводить процедуру восстановления. Текущее поведение никак не коррелирует с общепринятыми методиками восстановления после ошибки. H>Логичное диагностическое сообщение выдадет типизатор AST.
Обработчик AST должен искать семантические ошибки, а не синтаксические. Построение AST для "from from" нельзя объяснить ничем другим, кроме как ограниченностью вашего инструментария. "from from" — это недопустимая последовательность лексем и в AST она попадать не должна.
Здравствуйте, hardcase, Вы писали:
H>Скорее всего там распарсились два последовательных оператора взятия адреса.
Но это ведь даже другой токен. Ну здесь это в любом случае ошибочный код, но ведь есть ситуации, когда убирание пробела между токенами превращает правильный код в ошибочный. Кто в таком случае сообщит об ошибке? Ведь и парсер будет доволен, и дерево получится правильное.
Здравствуйте, adontz, Вы писали:
A>Обработчик AST должен искать семантические ошибки, а не синтаксические. Построение AST для "from from" нельзя объяснить ничем другим, кроме как ограниченностью вашего инструментария. "from from" — это недопустимая последовательность лексем и в AST она попадать не должна.
Замечательная последовательность лексем. Но, конечно, я посмотрю что там внутри получается.
Дело в том, что генератор парсеров проектируется с расчетом на использование в механизмах автокомплита, так что парсить нужно все что можно распарсить.
Здравствуйте, nikov, Вы писали:
N>Здравствуйте, hardcase, Вы писали:
H>>Скорее всего там распарсились два последовательных оператора взятия адреса.
N>Но это ведь даже другой токен. Ну здесь это в любом случае ошибочный код, но ведь есть ситуации, когда убирание пробела между токенами превращает правильный код в ошибочный. Кто в таком случае сообщит об ошибке? Ведь и парсер будет доволен, и дерево получится правильное.
Здравствуйте, hardcase, Вы писали:
H>Замечательная последовательность лексем. Но, конечно, я посмотрю что там внутри получается. H>Дело в том, что генератор парсеров проектируется с расчетом на использование в механизмах автокомплита, так что парсить нужно все что можно распарсить.
У нас какое-то недопонимание. Любой парсер расчитывает на ошибки в исходном коде. Поэтому компилятор выдаёт тебе все ошибки, а не только первую. Вы не открыли Америку парсером, который разбирает некорректный код.
Абсолютно нормальное требование для автокомплита, чтобы предыдущий код был более или менее корректен. Это поведение можно наблюдать везде. Я не понимаю зачем вы вносите явные баги в свой парсер ради весьма всомнительной выгоды.
Здравствуйте, hardcase, Вы писали:
N>>Но это ведь даже другой токен. Ну здесь это в любом случае ошибочный код, но ведь есть ситуации, когда убирание пробела между токенами превращает правильный код в ошибочный. Кто в таком случае сообщит об ошибке? Ведь и парсер будет доволен, и дерево получится правильное. H>У нас нет понятия токен. Это безлексерный парсер.
А как ты собираешься выдавать ошибки вида "XYZ expected"?
Здравствуйте, adontz, Вы писали:
A>Здравствуйте, hardcase, Вы писали:
N>>>Но это ведь даже другой токен. Ну здесь это в любом случае ошибочный код, но ведь есть ситуации, когда убирание пробела между токенами превращает правильный код в ошибочный. Кто в таком случае сообщит об ошибке? Ведь и парсер будет доволен, и дерево получится правильное. H>>У нас нет понятия токен. Это безлексерный парсер.
A>А как ты собираешься выдавать ошибки вида "XYZ expected"?
PEG это сделает за меня. Парсер создавался не ради C#, а ради нового движка макросов Nemerle. Он вообще стал фактически побочным продуктом.
Здравствуйте, adontz, Вы писали:
A>Абсолютно нормальное требование для автокомплита, чтобы предыдущий код был более или менее корректен. Это поведение можно наблюдать везде. Я не понимаю зачем вы вносите явные баги в свой парсер ради весьма всомнительной выгоды.
Не разобравшись до конца в вопросе вы делаете поспешные выводы.
Здравствуйте, hardcase, Вы писали:
A>>Абсолютно нормальное требование для автокомплита, чтобы предыдущий код был более или менее корректен. Это поведение можно наблюдать везде. Я не понимаю зачем вы вносите явные баги в свой парсер ради весьма всомнительной выгоды. H>Не разобравшись до конца в вопросе вы делаете поспешные выводы.
Здравствуйте, adontz, Вы писали:
A>Здравствуйте, hardcase, Вы писали:
A>>>Абсолютно нормальное требование для автокомплита, чтобы предыдущий код был более или менее корректен. Это поведение можно наблюдать везде. Я не понимаю зачем вы вносите явные баги в свой парсер ради весьма всомнительной выгоды. H>>Не разобравшись до конца в вопросе вы делаете поспешные выводы.
A>Ну так помогите разобраться.
Автокомплит выполняется далеко не парсером. И чем больше информации механизму типизации будет сообщено, тем лучше он будет.
В конечном счете конкретно этот парсер нужен для разбора корректных C# программ и обкатки генератора парсеров.
Здравствуйте, hardcase, Вы писали:
H>И что? C# здесь это не самоцель а лишь полигон для маневров
В таком случае с этими недостатками можно смириться.
А то некоторые (несознательные?) люди уже пропагандируют этот парсер в качестве замены тому, который используется в РеШарпере, и тому, который разрабатывется в Microsoft.
А вот так делать нельзя. Переменные должны быть с маленькой буквы.
К тому же это тоже против всех гайдлайнов.
S_>Это же все скорее примерный аналог доступа к полям, чем объявление локальной переменной.
Нет. Это именно введение переменной. Она может и не для поля использоваться.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, hardcase, Вы писали:
H>>>Так и должно быть.
N>>Почему это?
H>Логично что нужно парсить все что можно распарсить. Что не так пускай думает код, который будет анализировать AST.
Мне кажется, что это все же баг.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
H>>И что? C# здесь это не самоцель а лишь полигон для маневров VD>Тут ты не прав. Раз мы компилируем шарп, то синтаксис его должны воспроизвести точно.
Со всеми багами существующего компилятора, кстати.
Здравствуйте, VladD2, Вы писали:
H>>И что? C# здесь это не самоцель а лишь полигон для маневров VD>Тут ты не прав. Раз мы компилируем шарп, то синтаксис его должны воспроизвести точно.
Здравствуйте, hi_octane, Вы писали:
Tom>>Причём тут вообще IQ, я даже при очень большом желании использовать немерл не смогу пробить стену мэнеджмента который справедливо боится что поддержка сего проекта закончится сразу после того как кто то не ухватится за новую супер пупер идею, как это было с R#
_>Если вы общаетесь с МС как все, через connect, и прямой линии к Хельсбергу и Co у вас нету — то поддержка которую оказывает МС де факто _хуже_ чем поддержка которую можно получить на форуме Nemerle. Кроме того у вас есть возможность и смотреть в сорцы компилятора, и в крайнем случае даже поправить самим. Код компилятора на самом деле вполне обозримого размера, именно из-за того что написан на себе-же и при сборке сам себя тестирует.
Когда берётся стороннее решение, то оно берётся не столько из-за того, что оно уже написано. Сколько из-за того, что издержки на поддержку этого решения нулевые. Неважно, опен-сорс или нет.
Здравствуйте, adontz, Вы писали:
A>Пусть будет два рабочих дня и ещё умножим на ва, как поступают менеджеры со сроками программистов. Итого 11го числа баги будут исправлены. Ну-ну.
Синтаксические ошибки обычно достаточно быстро исправляются. Единственный затык который возможен это проблемы с генератором парсеров, например он что-то не умеет и тогда приходится приделывать костыли.
Здравствуйте, VladD2, Вы писали:
H>>У нас нет понятия токен. Это безлексерный парсер. VD>И все же && отличить от & можно, а в случае шарпа — нужно.
А это сложно сделать, если нет лексера? За счет приоритетов как-то решается?
++v парсится как инкремент а не два плюса из за того что у ++ приоритет при парсинге выше?
Здравствуйте, Silver_s, Вы писали:
S_> А это сложно сделать, если нет лексера? За счет приоритетов как-то решается? S_> ++v парсится как инкремент а не два плюса из за того что у ++ приоритет при парсинге выше?
Это решается через синтаксические предикаты.
Те + нужно парсить не так
"+"
а вот так
"+" !"+"
!правило
Проверяет матчится ли правило и если матчится то происходит откат.
При этом в любом случае текст скушан не будет.
Тк можно использовать любое правило то это фактически способ заглянуть вперед на произвольное колличество символов.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, Silver_s, Вы писали:
H>>>У нас нет понятия токен. Это безлексерный парсер. VD>>И все же && отличить от & можно, а в случае шарпа — нужно.
S_> А это сложно сделать, если нет лексера?
Нет, не трудно.
S_>За счет приоритетов как-то решается?
В PEG работает правило — кто первый тот и папа. Так что если перед разбором оператора "&" попытаться разобрать "&&" и попытка окажется удачной, то попытки разобрать "&" даже не будет производиться.
Я не знаю в чем конкретная ошибка, но скорее всего дело в том, что "&" — это унарный префиксный оператора, а "&&" бинарный инфиксный. Они разбираются в отдельных контекстах, и так как в контексте префиксных операторов нет "&&", то последовательность && разбирается как & & expr (т.е. как последовательное применение оператора & к своему же результату). В принципе — это не проблема, так как на этапе семантического анализа такое применение будет отвергнуто.
Но конечно же можно потребовать, чтобы за оператором "&" не мог идти второй такой же. Сделать это не сложно. Для этого нужно задать негативный предикат. Выглядеть это будет примерно так:
"&" ! "&"
При этом, если парсер встретит последовательность "&&" в контексте разбора оператора "&", то он просто сфайлит и будет разобран другой путь, или выдано сообщение об ошибке.
S_> ++v парсится как инкремент а не два плюса из за того что у ++ приоритет при парсинге выше?
Здравствуйте, VladD2, Вы писали:
VD>В PEG работает правило — кто первый тот и папа. Так что если перед разбором оператора "&" попытаться разобрать "&&" и попытка окажется удачной, то попытки разобрать "&" даже не будет производиться.
А что мешает применить жадное правило (кто больше символов съел, тот и папа), или даже совместить и использовать приоритеты и жадные правила вместе по контексту?
У жадного разбора один недостаток — нужно попробовать ВСЕ варианты. Реальную проблему это приносит лишь при больших откатах.
Здравствуйте, Silver_s, Вы писали:
H>>>У нас нет понятия токен. Это безлексерный парсер. VD>>И все же && отличить от & можно, а в случае шарпа — нужно.
S_> А это сложно сделать, если нет лексера? За счет приоритетов как-то решается? S_> ++v парсится как инкремент а не два плюса из за того что у ++ приоритет при парсинге выше?
Поясню еще раз. Безлексерный парсер штука очень гибкая. Но эта же гибкость может приводить к казусам подобным обсуждаемому, так как операторы и ключевые словам по сути становятся контекстными. Это требует предпринимать дополнительные действия чтобы обеспечить их "глобальность".
Это правило говорит, что префиксными операторами могут быть перечисленные строки за которыми могут идти необязательные пробельные символы (которые описываются правилом s). Другими словами пробелов может и не идти.
А вот как выглядит правило описывающее выражение с префиксными операторами:
Не трудно понять, что по этому правил допустимой будет любая строка состоящая из символов "+-~!&*". Таким образом строка "&&" и даже строка "&&&" считаются допустимыми. Чтобы предотвратить это можно добавить предикат запрещающий разбор идущих подряд символов "&":
Здравствуйте, Алексей., Вы писали:
A>>Пусть будет два рабочих дня и ещё умножим на ва, как поступают менеджеры со сроками программистов. Итого 11го числа баги будут исправлены. Ну-ну.
А>Синтаксические ошибки обычно достаточно быстро исправляются. Единственный затык который возможен это проблемы с генератором парсеров, например он что-то не умеет и тогда приходится приделывать костыли.
С PEG-ом — это не тот случай. Предикаты позволяют разрулить любые проблемы.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, samius, Вы писали:
S>А что мешает применить жадное правило (кто больше символов съел, тот и папа), или даже совместить и использовать приоритеты и жадные правила вместе по контексту?
Все привила в PEG-е жадные. Они будут "есть" столько символов сколько смогут. А приоритетный выбор позволяет предпочесть одно из правил, если есть два правила которые способны разобрать строку.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
VD>>В нем вместо параметров left и left указаны плэйсходеры — "_". Так как плэйсхолдеры сопоставляются со всем чем угодно (даже с null), то мы получим требуемый результат. VD>>Кстати, Identifier — это не вариант, а простой класс. Так что "Identifier where(id="==")" — это поттерн-матчинг по объекту.
_FR>Ага, и поэтому Id с большой буквы?
Да, так как это свойство.
_FR>Имхо, в этом плохого ничего нет, наоборот понятно, что проверяется свойство Id.
Плохо в этом — многословность. При некоторых объемах образцы становятся нечитабельными. Краткость очень важна для образцов.
_FR>То, что Identifier с большой буквы тоже говорит о том, что это имя типа.
Да. В принципе класс конечно же можно назвать с маленькой буквы, но при этом будут проблемы в паттерн-матчинге. Они тоже могут быть обойдены за счет задания квалифицированного имени, но все же.
_FR>В строке _FR>
_FR>в ПаскальКейсе только "Identifier" и "Id" — о каких параметрах речь? Непосредственно к вариантам класс "Identifier" отношения не имеет.
Параметром, в данном случае является "op".
_FR>То есть сейячас речь о Record-ах?
Нет. [Record] — это просто макрос автоматически формирующий конструктор для всех полей. Собственно для вхождений вариантов он и используется.
_FR>Так там тоже поля получаются Почему нельзя сделать так же: пользователь указывает _FR>
_FR> [Record]
_FR> public class Identifier : Located
_FR> {
_FR> [Accessor] Id : string;
_FR> public override ToString() : string
_FR> {
_FR> id
_FR> }
_FR> }
_FR>
_FR>а параметр конструктора называется "id"? А свойство — Id.
Почему нельзя? Можно. Просто бессмысленно делать свойство для публичного поля. А делать его не публичным нельзя по той причине, что поля варианта входящие в конструктор должны быть публичными.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, samius, Вы писали:
S>>А что мешает применить жадное правило (кто больше символов съел, тот и папа), или даже совместить и использовать приоритеты и жадные правила вместе по контексту?
VD>Все привила в PEG-е жадные. Они будут "есть" столько символов сколько смогут. А приоритетный выбор позволяет предпочесть одно из правил, если есть два правила которые способны разобрать строку.
Я про то, что вместо приоритетов выбирать то правило из альтернативных, которое откусило больше от строки.
Здравствуйте, VladD2, Вы писали:
VD>Но конечно же можно потребовать, чтобы за оператором "&" не мог идти второй такой же. Сделать это не сложно. Для этого нужно задать негативный предикат. Выглядеть это будет примерно так: VD>
VD>"&" ! "&"
VD>
Так наверно лучше, в том числе учесть и &=
И наверно не только для C# . А вобще для всех операторов составленых из нескольких терминальных символов, лучше гибкость парсера в этом месте попридержать.
v1-+v2 Это в C# бинарный минус и унарный плюс, а это ошибка v1--v2
Можно конечно придумать грамматику в которой так и задумано — если нет слева операнда то распознается как декремент --v2,
если есть то распознается как v1 — (-v2). Но это была бы нехорошая грамматика, трудно читаемая. Что-то я не припомню чтобы такое было хоть в одном языке, такая контекстная зависимость (по крайней мере для операторов из нескольких терминальных символов).
Для языков где много таких составных операторов, может какие-то костыли приделать?
Чтобы указать все такие цепочки символов (операторы), и указать ограничение что они взаимно исключающие — если одна длинная цепочка подходит, значит нельзя считать как две коротких. А по ним уже автоматом нагенерировать правил с негативными предикатами.
Иначе, если захочется добавить новый оператор +- , прийдется его описать, потом еще "+" изменять.
Гибкость от этого сильно не пострадает, как от введения отдельной фазы лексического анализа.
Хотя может и руками не проблема вбить все предикаты с негативными частями.
Здравствуйте, Silver_s, Вы писали:
S_>И наверно не только для C# . А вобще для всех операторов составленых из нескольких терминальных символов, лучше гибкость парсера в этом месте попридержать. S_> v1-+v2 Это в C# бинарный минус и унарный плюс, а это ошибка v1--v2 S_>Можно конечно придумать грамматику в которой так и задумано — если нет слева операнда то распознается как декремент --v2, S_>если есть то распознается как v1 — (-v2). Но это была бы нехорошая грамматика, трудно читаемая. Что-то я не припомню чтобы
Особенно как читать
v1-----v2
Пятый левый минус бинарный потом два декремента. Или справа два минуса это декремент, слева бинарный, а между ними унарные. Черезмерно интеллектуальный гибкий парсер бы это разобрал, нашел правильный вариант, т.к. два декремента нельзя.
Но читатель бы не осилил такую запись. Так что такие ограничения в грамматике на предикатах с ! очень нужны для таких операторов
Здравствуйте, Silver_s, Вы писали:
VD>>Но конечно же можно потребовать, чтобы за оператором "&" не мог идти второй такой же. Сделать это не сложно. Для этого нужно задать негативный предикат. Выглядеть это будет примерно так: VD>>
VD>>"&" ! "&"
VD>>
S_> Так наверно лучше, в том числе учесть и &=
Зачем? На всякий пожарный? "=" и так отсутствует в списке.
S_> v1-+v2 Это в C# бинарный минус и унарный плюс, а это ошибка v1--v2
Ну, так и будет ошибка. "--" распознается как постфиксный оператор.
ЗЫ
Не надо искать глубокий философский смысл в баге.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали: S_>> Так наверно лучше, в том числе учесть и &= VD>Зачем? На всякий пожарный? "=" и так отсутствует в списке.
Оно из другого списка. Наверно, на всякий случай , для большей гарантии, что именно та ошибка отловится, и что лишнего не распарсит.
Как-то мне неочевидно в такой грамматике какая ошибка здесь будет:
4 &= v1
Это ошибка в любом случае. Но какая. Правый операнд у бинарного & неправильный, или левый операнд у &= неправильный
VD>Не надо искать глубокий философский смысл в баге.
Смысл бы только был в сообщениях компилятора об ошибках. И лучше не философский о высоком как сейчас в F#, а поконкретнее как в C#
S_>Как-то мне неочевидно в такой грамматике какая ошибка здесь будет: S_>4 &= v1 S_>Это ошибка в любом случае. Но какая. Правый операнд у бинарного & неправильный, или левый операнд у &= неправильный
Нет, я тут погрорячился. Тут неоднозначности быть не может.
Здравствуйте, Silver_s, Вы писали:
S_>Здравствуйте, VladD2, Вы писали: S_>>> Так наверно лучше, в том числе учесть и &= VD>>Зачем? На всякий пожарный? "=" и так отсутствует в списке. S_> Оно из другого списка. Наверно, на всякий случай , для большей гарантии, что именно та ошибка отловится, и что лишнего не распарсит.
Вот делать что-то на всякий случай, то есть бездумного, не стоит. Будет только хуже. Когда что-то делаешь нужно понимать зачем это делается и к чему это приведет. А то можно такого накосячить.
S_>Как-то мне неочевидно в такой грамматике какая ошибка здесь будет: S_>4 &= v1 S_>Это ошибка в любом случае. Но какая. Правый операнд у бинарного & неправильный, или левый операнд у &= неправильный
Тут как раз все очевидно. Постфиксного "&" нет.
VD>>Не надо искать глубокий философский смысл в баге. S_> Смысл бы только был в сообщениях компилятора об ошибках. И лучше не философский о высоком как сейчас в F#, а поконкретнее как в C#
Для создания парсера F# использует дремучее и кривое средство — клон yacc-а. Он основан на LALR-алгоритме, что сильно ухудшает диагностику ошибок.
В нашем парсере над диагностикой особо не работали, но по крайней мере он будет указывать место ошибки и писать что ожидалось в этом месте. Плюс есть возможность обеспечить более тонкую обработку (не усложняя при этом грамматику).
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Алексей., Вы писали:
A>>Пусть будет два рабочих дня и ещё умножим на ва, как поступают менеджеры со сроками программистов. Итого 11го числа баги будут исправлены. Ну-ну.
А>Синтаксические ошибки обычно достаточно быстро исправляются. Единственный затык который возможен это проблемы с генератором парсеров, например он что-то не умеет и тогда приходится приделывать костыли.
Да, и нужно учитывать, что "генератор" парсеров наш, т.е. делается нами же. Плюс — это не отдельное приложение, а макрос, что сильно упрощает его разработку, и как следствие, его развитие.
Так что если что-то будет нужно — прикрутим.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Silver_s, Вы писали:
VD>>Парсер прогоняли на куче исходников. От Януса, до исходников дотнета. Вроде пашет. S_> Что пашет? AST разбирается без выброса Exception.
Исключения — то уже явный баг. Само собой разумеется их точно быть не должно.
В даннымй момент речь идет о парсере. Он только разбирает код (текст) в AST. И делает это без сообщений об ошибках.
S_>Или эти исходники без правки, целиком компильнулись (парсинг вместе с Немерлевской кодогениерацией) в работающее приложение?
Это уже следующий этап. Для этого мы сделали плагин к компилятору немерла (который использует этот парсер). Полностью это вообще невозможно потому что языки не на 100% совместимы. Но думаю, что через месяцок можно будет проект средней руки перекомпилировать немерлом. Пока что некоторый код вызывает проблемы. Но многое компилируется.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Ты как думаешь, надо грамматику переписывать так чтобы она не допускала применение параметров типов к предопределенным типам?
Это зависит от задач парсера. Например, если это парсер для интерактивной работы в редакторе, то с точки зрения юзабилити хотелось бы, чтобы дерево в таком случае всё равно построилось (например, должен работать рефакторинг Rename для алиаса с таким некорректным типом), но обязательно была подсветка ошибки с понятным объяснением, что тип int не может использоваться с типами-аргументами. Наверно, это ошибку надо выдавать на отдельной стадии сематического анализа (или каком-нибудь пост-парсинге).
Здравствуйте, nikov, Вы писали:
VD>>Это некорректный код. У предопределенных ключевых слов параметров типов быть не должно
N>Вот поэтому парсер должен выдавать на нём ошибку. А он не выдаёт.
Ну, так ты описывай ожидаемое поведение. Телепатия не является нашим коньком .
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, adontz, Вы писали:
A>Влад, препроцессор серьёзная штука как ни крути.
Я в курсе. Хотя по всей видимости во второй версии немерла его не будет (за ненадобностью).
Просто делать как все — писать рукопашную реализацию не хочется. Надо подправить PegGrammar, чтобы он позволял некоторым обработчикам "файлить" в зависимости от переданного в них АСТ. Тогда препроцессор можно будет описать почти декларативно.
Думаю в ближайшее время поддержка препроцессора появится.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, nikov, Вы писали:
N>Здравствуйте, VladD2, Вы писали:
VD>>Ты как думаешь, надо грамматику переписывать так чтобы она не допускала применение параметров типов к предопределенным типам?
N>Это зависит от задач парсера. Например, если это парсер для интерактивной работы в редакторе, то с точки зрения юзабилити хотелось бы, чтобы дерево в таком случае всё равно построилось (например, должен работать рефакторинг Rename для алиаса с таким некорректным типом), но обязательно была подсветка ошибки с понятным объяснением, что тип int не может использоваться с типами-аргументами. Наверно, это ошибку надо выдавать на отдельной стадии сематического анализа (или каком-нибудь пост-парсинге).
Я подхожу к этому делу проще. Ошибка все равно появится, так как не удастся создать такой тип. А парсер может использоваться в для очень разных задач. Кроме того важна его скорость. Дополнительные проверки будут понемногу снижать скорость. Так что лучше это дело на семантику переложить, наверно.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Надо подправить PegGrammar, чтобы он позволял некоторым обработчикам "файлить" в зависимости от переданного в них АСТ. Тогда препроцессор можно будет описать почти декларативно.
Это как? Псевдокод покажи?
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
VD>>Надо подправить PegGrammar, чтобы он позволял некоторым обработчикам "файлить" в зависимости от переданного в них АСТ. Тогда препроцессор можно будет описать почти декларативно. WH>Это как? Псевдокод покажи?
Ты бы в Скайпе появлялся ЧАЩЕ, мы бы мы бы тебе Хардкейсом все рассказали.
Нужно следующее.
Если правило помечено атрибутом, ну скажем, [ManualControl], то к его обработчику добавлялся бы дополнительный парметр "pos : ref int". Это позволило бы правилу сфэйлить и тем самым отправить парсер по другому пути. Псевдокод:
Здравствуйте, VladD2, Вы писали:
VD>Если правило помечено атрибутом, ну скажем, [ManualControl], то к его обработчику добавлялся бы дополнительный парметр "pos : ref int". Это позволило бы правилу сфэйлить и тем самым отправить парсер по другому пути. Псевдокод:
Вы с Хардкейсом опять что-то странное придумали.
1)Просто игнорировать комментарии и дериктивы препроцессовра нельзя.
Нам нужен их АСТ для подсветки синтаксиса.
2)То что вы сделали вы озвереете отлаживать.
Красивое решение я пока не вижу.
Самое простое и быстрое решение это передлать парсер на разбор массива char'ов и перед основным парсером проходить парсером который парсит препроцессор и комментарии после чего заменяет их на пробелы.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
WH>Красивое решение я пока не вижу.
WH>Самое простое и быстрое решение это передлать парсер на разбор массива char'ов и перед основным парсером проходить парсером который парсит препроцессор и комментарии после чего заменяет их на пробелы.
То есть нужно сделать то же, что делает cl.exe /E, а потом уже обычгым компилятором пройтись? #line ещё нужно учесть (есть такая в Немерле?).
Help will always be given at Hogwarts to those who ask for it.
Здравствуйте, _FRED_, Вы писали:
_FR>То есть нужно сделать то же, что делает cl.exe /E, а потом уже обычгым компилятором пройтись? #line ещё нужно учесть (есть такая в Немерле?).
Их есть в Nemerle.
Но сейчас она не вписывается в механизм работы парсера, и пока поддержки её в C# не будет.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, hardcase, Вы писали:
H>>Эскейпы в именах \uXXXX не поддерживаются (только в литералах).
VD>А почему? Думаю — это не должно быть проблемой.
Когда начинал работу над записью грамматики PEG был в зачаточном состоянии.
А теперь я думаю, что обработка таких эскейпнутых крокодилов может некисло затормозить парсер — дело ли, на кажом символе идентификатора проверять \u.
Здравствуйте, WolfHound, Вы писали:
WH>Вы с Хардкейсом опять что-то странное придумали.
Как раз самое простое решение.
WH>1)Просто игнорировать комментарии и дериктивы препроцессовра нельзя. WH>Нам нужен их АСТ для подсветки синтаксиса.
А их никто игнорировать не будет. Игнорироваться будет то, что в неактивной части #if-а будет. Студия такой код серым закрашивает.
Что до второй версии немрела, то я бы отказался бы от препроцессора и вместо него добавил бы несколько макросов сходной функциональности.
WH>2)То что вы сделали вы озвереете отлаживать.
Что там отлаживать? Просто правило может сфайлить на основании того что оно прочитало из АСТ.
WH>Красивое решение я пока не вижу.
Ты просто не понял озвученного. Оно как раз самое что не наесть красивое и простое в реализации. И что самое главное практически декларативное.
WH>Самое простое и быстрое решение это передлать парсер на разбор массива char'ов и перед основным парсером проходить парсером который парсит препроцессор и комментарии после чего заменяет их на пробелы.
Вот это самое что ни на есть кривое решение.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, _FRED_, Вы писали:
_FR>То есть нужно сделать то же, что делает cl.exe /E, а потом уже обычгым компилятором пройтись? #line ещё нужно учесть
Примерно так.
#line при двупроходном парсенге то же не трудно поддержать.
_FR>(есть такая в Немерле?).
Немерле тут не причем. Это совершенно отдельный парсер.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, VladD2, Вы писали:
VD>Как раз самое простое решение.
Ну-ну.
VD>А их никто игнорировать не будет. Игнорироваться будет то, что в неактивной части #if-а будет. Студия такой код серым закрашивает.
И как ты из правила s : void собрался AST возвращать?
VD>Что там отлаживать? Просто правило может сфайлить на основании того что оно прочитало из АСТ.
Ту кучу императива которая образуется вокруг этого.
Кстати как ты собрался #line поддерживать?
VD>Ты просто не понял озвученного. Оно как раз самое что не наесть красивое и простое в реализации. И что самое главное практически декларативное.
Ты посмотри на ту грязь что ты уже накатал. А ведь там еще писать и писать.
Прикинь как ты в своей схеме будешь вот это ловить:
#if ASD
#region qwe
#endif
#endregion
или это
#if ASD
#region qwe
#else
#endregion
#endif
А я еще кучу страшного кода придумаю.
И про #line не забывай.
Тоже очень пакостная директива.
VD>Вот это самое что ни на есть кривое решение.
За то его можно заставить работать в отличии от твоего.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
VD>>А их никто игнорировать не будет. Игнорироваться будет то, что в неактивной части #if-а будет. Студия такой код серым закрашивает. WH>И как ты из правила s : void собрался AST возвращать?
Никак. АСТ препроцессора и комментарии — это параллельная вещь. Информацию о них просто нужно сложить в отдельный массив/массивы.
VD>>Что там отлаживать? Просто правило может сфайлить на основании того что оно прочитало из АСТ. WH>Ту кучу императива которая образуется вокруг этого. WH>Кстати как ты собрался #line поддерживать?
Это штука каверзная. Причем главным образом тем, что она не всегда должна влиять на локешоны. Скажем для целей интеграции и компилятора она вообще не должна существовать, чтобы все сообщения об ошибках и навигация работали корректно. А нужна она для разных тексто-генерирующих утилит донемерловой эры.
По сему информацию о #line так же нужно поместить в отдельный массив и использовать в SourceSnapshot.PositionToLineColumn()
VD>>Ты просто не понял озвученного. Оно как раз самое что не наесть красивое и простое в реализации. И что самое главное практически декларативное. WH> Ты посмотри на ту грязь что ты уже накатал. А ведь там еще писать и писать. WH>Прикинь как ты в своей схеме будешь вот это ловить: WH>
Никак. Это некорректный код. Регионы не могут выходить (по спекам шарпа) за пределы блоков #if-а.
Так что все ОК.
WH>А я еще кучу страшного кода придумаю.
Ага. Только, если можно без ошибок.
WH>И про #line не забывай. WH>Тоже очень пакостная директива.
Ага. Но с отдельным парсером с ней проще не станет. Другого способа как массив пересчета все равно не придумаешь. В прочем, мы похожую фигню уже и так используем.
VD>>Вот это самое что ни на есть кривое решение. WH>За то его можно заставить работать в отличии от твоего.
Да ладно тебе. Что там заставлять работать то?
Ты бы все же в скайпе появлялся иногда. А то используем непрофильные форумы для чатов.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, hardcase, Вы писали:
H>Когда начинал работу над записью грамматики PEG был в зачаточном состоянии. H>А теперь я думаю, что обработка таких эскейпнутых крокодилов может некисло затормозить парсер — дело ли, на кажом символе идентификатора проверять \u.
Вольфхаунд прикрутил ДКА для латеральных грамматик. Возможно, что скорость не замедлится (заметно). Так что попробовать можно.
Как вариант, можно сделать через препроцессор. Кому надо сделает дефайн и получит парсер поддерживающий эту фичу.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
WH>>Самое простое и быстрое решение это передлать парсер на разбор массива char'ов и перед основным парсером проходить парсером который парсит препроцессор и комментарии после чего заменяет их на пробелы. VD>Вот это самое что ни на есть кривое решение.
Оно не столько кривое, сколько расширяющие возможности препроцессор за счёт его независимости. Что неподустмое вообще может оказатсья допустимым при отдельном препроцессоре.
С другой стороны я не уверен что задача препроцессора иенно выкидывать код. Если мы говорим про IntelliSence, то пусть подкрашивается в серый цвет, но
1) В нём работает автодополнение и проч.
2) Remove Usings не будет выкидывать простраинсива имён типов из для неактивной ветки.
И вообще можно найти много случаев, когда надо анализировать все варианты.
Ну и с другой стороны выражение может охватывать #if/#else
Здравствуйте, adontz, Вы писали:
A>С другой стороны я не уверен что задача препроцессора иенно выкидывать код. Если мы говорим про IntelliSence, то пусть подкрашивается в серый цвет, но A>1) В нём работает автодополнение и проч. A>2) Remove Usings не будет выкидывать простраинсива имён типов из для неактивной ветки. A>И вообще можно найти много случаев, когда надо анализировать все варианты.
Препроцессор — это текстовая подстановка. Никто и никогда не будет анализировать не активные части в контексте основного языка, так как они просто могут быть консистенция. Скажем #if можно использовать так:
#if symbol
class
#elseif
struct
#endif
Test
{
}
Так что никакой интеллисенс в "серой" области работать не будет.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Препроцессор — это текстовая подстановка. Никто и никогда не будет анализировать не активные части в контексте основного языка, так как они просто могут быть консистенция.
А как ты в данном случае активную часть обраатывать? Можно встатить private или partial, но private лишь для вложенных классов. Тоже самое можно сделать и с неактивной частью. Вообще не вижу проблемы.
Здравствуйте, adontz, Вы писали:
A>А как ты в данном случае активную часть обраатывать? Можно встатить private или partial, но private лишь для вложенных классов. Тоже самое можно сделать и с неактивной частью. Вообще не вижу проблемы.
В неактивной части даже не обязан быть корректный код. Это может быть любая грязь.
Кроме того неактивных частей может быть несколько и корректный код в них может получаться только при определенном сочетании.
А ты знаешь хотя бы один продукт анализирующий неактивные части препроцессора?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
A>>А как ты в данном случае активную часть обраатывать? Можно встатить private или partial, но private лишь для вложенных классов. Тоже самое можно сделать и с неактивной частью. Вообще не вижу проблемы. VD>В неактивной части даже не обязан быть корректный код. Это может быть любая грязь.
Поэтому для неё ты выдашь Warning, а не Error.
VD>Кроме того неактивных частей может быть несколько и корректный код в них может получаться только при определенном сочетании.
Количество версий код есть 2^(количество пременных компиляции). DEBUG, TRACE, CODE_ANALYSIS и ещё парочка пользовательских это всего 32 версии. Если хранить их не целиком, а как граф с циклами, будет весбма эффективно.
VD>А ты знаешь хотя бы один продукт анализирующий неактивные части препроцессора?
Нет, ведь такое на С# не написать Я не особо-то не и подкалываю сейчас. Вообщето это было бы действительно полезно. Из-за каких-то директив анализ кода может оказаться некорректным — какие-то метод или пременная станут unreferenced и их предложат удалить, хотя правильнее было бы предложить их обернуть в те же условия. Открываются новые возможности рефакторинга для тех кто поддерживает множество конфигураций. Такая функция вРешарпере мне бы пригодилась.
Здравствуйте, adontz, Вы писали:
A>Поэтому для неё ты выдашь Warning, а не Error.
Ага. Здесь мы играем, здесь — нет, а здесь мы рыбу заворачивали. (с)
A>Количество версий код есть 2^(количество пременных компиляции). DEBUG, TRACE, CODE_ANALYSIS и ещё парочка пользовательских это всего 32 версии. Если хранить их не целиком, а как граф с циклами, будет весбма эффективно.
Вообще-то люди разные дефайны делают для разных целей. Да и 32 — это тоже уже круто получается. Процессоры современные не потянут.
VD>>А ты знаешь хотя бы один продукт анализирующий неактивные части препроцессора?
A>Нет, ведь такое на С# не написать
Тут дело не в том можно ли это написать. Тут дело в бессмысленности сего занятия.
VD>Я не особо-то не и подкалываю сейчас. Вообщето это было бы действительно полезно. Из-за каких-то директив анализ кода может оказаться некорректным — какие-то метод или пременная станут unreferenced и их предложат удалить, хотя правильнее было бы предложить их обернуть в те же условия. Открываются новые возможности рефакторинга для тех кто поддерживает множество конфигураций. Такая функция вРешарпере мне бы пригодилась.
Это можно было бы сделать для ряда указанных конфигураций. Тупо спарсить с тем или иным набором символов. Но строить какой-то общий АСТ — это не реально.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Это можно было бы сделать для ряда указанных конфигураций. Тупо спарсить с тем или иным набором символов. Но строить какой-то общий АСТ — это не реально.
Здравствуйте, VladD2, Вы писали:
A>>С некоторой вероятностью придётся делать свою IDE. Правда, не скоро, и это очень радует. VD>Зачем? Есть же Экспресы и #Develop.
Задача очень специфическая, речь не идёт о написании самостоятельного приложения.
Здравствуйте, adontz, Вы писали:
A>>>С некоторой вероятностью придётся делать свою IDE. Правда, не скоро, и это очень радует. VD>>Зачем? Есть же Экспресы и #Develop.
A>Задача очень специфическая, речь не идёт о написании самостоятельного приложения.
Тогда что ты имеешь в виду под своей IDE?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
A>>Задача очень специфическая, речь не идёт о написании самостоятельного приложения. VD>Тогда что ты имеешь в виду под своей IDE?
Здравствуйте, adontz, Вы писали:
ВВ>>Для встраивания что ли? A>Да.
ИМХО не очень идея. Представь вот, что в Ворде, Экселе и проч. были бы свои собственные встроенные студии — причем реализованные по-разному. Ну, собственно, раньше так и было Куда как удобнее в нормальной студии создать специальный проект, потом нажать на кнопочку Install — и все.
Здравствуйте, Воронков Василий, Вы писали:
ВВ>Куда как удобнее в нормальной студии создать специальный проект, потом нажать на кнопочку Install — и все.
Это может быть слишком громоздко в рамках моей задачи.
Здравствуйте, adontz, Вы писали:
A>>>Задача очень специфическая, речь не идёт о написании самостоятельного приложения. VD>>Тогда что ты имеешь в виду под своей IDE?
A> Редактирование: подсветка синтаксиса, автодополнение. A> Компиляция A> Отладка
C#-а? Тогда что тут специфического?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
A>> Редактирование: подсветка синтаксиса, автодополнение. A>> Компиляция A>> Отладка VD>C#-а? Тогда что тут специфического?
Сцепифичны причины подобных требований, а не сами требования