_>В случае Nemerle — я могу навести мыша на макрос и посмотреть в тултипе во что он переписывается, могу подключиться отладчиком к макросу в момент его применения и посмотреть что же он делает с AST и почему делает именно это, могу наконец добавить логгирование в код макроса и получить дамп по всем применениям этого макроса.
и опять же речь идет о человеке, а не об автоматическом решении обратной задачи.
в данном случае, есть следующие автоматически решаемые задачи, которые требуют решения обратной задачи:
1. выведение типов
2. подсветка синтаксиса
3. intellisense
4. определение области видимости
5. определение что переменные не используются без своих объявления
и т.д.
если using — макрос, то как автоматически решать все вышеприведенные задачи?
задачи 1, 4, 5 — можно пробовать решать через раскрытие макроса, и анализ получившегося кода,
но если случилась ошибка, то непонятно как привязать ошибку к месту в исходном коде.
DG>если using — макрос, то как автоматически решать все вышеприведенные задачи?
Всё уже давно решено. Автокомплит подхватывает, интеллисенс подсказывает, синтаксис подсвечивается, типы выводятся лучше чем в C#, области видимости определяются корректно. Если действительно хочешь знать как — посмотри на сорцы Nemerle. Пруф например здесь
Здравствуйте, DarkGray, Вы писали:
DG>задачи 1, 4, 5 — можно пробовать решать через раскрытие макроса, и анализ получившегося кода, DG>но если случилась ошибка, то непонятно как привязать ошибку к месту в исходном коде.
Вот только у немерла работает и подсветка синтаксиса и автокомплит и навигация и отладка и сообщения об ошибках.
И это при том что код чуть меньше чем польностью состоит из макросов.
Если не веришь можешь поставить интеграцию и посмотреть.
А во всем виноват класс
public class Located
{
public mutable loc : Location;
public this ()
{
loc = LocationStack.Top();
}
public this (loc : Location)
{
this.loc = loc;
}
public IsGenerated : bool { get { loc.IsGenerated } }
public Location : Location
{
get { loc }
set { loc = value; }
}
}
От которого наследуется AST
public variant PExpr : Located
Location содержит номер файла, позицию начала и позицию конца.
Те вся информация у нас есть.
Все что нам нужно это не потерять ее при решении прямой задачи.
И на практике в подавляющем большенстве случаев для этого вообще ничего делать не приходится.
Короче заканчивай искать фатальные недостатки в том о чем ты не знаешь ровным счетом ничего.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, DarkGray, Вы писали:
DG>в немерле может и не решают, а в других системах решают.
Ссылки на статьи с описанием решения "обратной задачи" показать можешь?
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, Кэр, Вы писали:
Кэр>Дон прямо сейчас рассказывает о type providers. Кэр>http://bit.ly/bfWDkA
Да, забавно. Эдакий интером с динамичским миром для статически-типизированных языков. Намного лучше чем денамики в 4-ом Шарпе. Еще бы не затягивать презентацию на столько времени, а говорить по сути... плюс по больше информации и было бы совсем здорово.
Кэр>Выглядит очень круто. Никакого генеренного кода — все типы являются виртуальными и получаются на лету, пока пишется код. При этом есть поддержка сторогой типизации и интеллисенс(!).
Это явные домыслы. Генерация кода есть и делается она компилятором во время компиляции. Типы тоже получаются не налету, а в во время компиляции. Как правильно заметил вольфхаунд, такие вещи лучше в виде макросов реализовывать.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, mrTwister, Вы писали:
H>>Ты видел в стандартной библиотеке реализацию DependencyProperty? Или автоматическое INotifyPropertyChange? H>>Или автоматический маппинг объектов? T>Нет, и что?
А то, что это как раз то что невозможно положить в обычную библиотеку потому, но слишком специфично чтобы встраивать в язык. По этому ты никогда не увидишь средств автоматизирующих DependencyProperty и INotifyPropertyChange. Меж тем в виде макроса эти проблемы автоматизируются на раз. Вот здесь можно найти пример автоматизации DependencyProperty.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, FR, Вы писали:
WH>>Я двумя руками за то чтобы на систему типов переложить все что можно но: Попробуй на досуге из системы типов приконектиться к БД или файлик прочитать. Или как в этой теме поднять произвольный ITypeProvider и по нему нагенерировать типы и код для доступа к внешним источникам данных.
FR>Чтобы файлик прочитать и т. п. нужна только нормальная поддержка compile-time вычислений (как например в D), а не мощная система типов.
Он об этом и говорил. Только мощная как в Немреле, а не как в Ди. Потому как в Ди пока что жалкое подобие.
ЗЫ
Вообще, конечно надо реализовать немерл в нэйтив виде и закрыть тем самым тему Ди .
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, WolfHound, Вы писали:
WH>А во всем виноват класс
WH> public class Located
WH> {
WH> public mutable loc : Location;
WH> public this ()
WH> {
WH> loc = LocationStack.Top();
WH> }
WH> public this (loc : Location)
WH> {
WH> this.loc = loc;
WH> }
WH> public IsGenerated : bool { get { loc.IsGenerated } }
WH> public Location : Location
WH> {
WH> get { loc }
WH> set { loc = value; }
WH> }
WH> }
WH>От которого наследуется AST
WH>Короче заканчивай искать фатальные недостатки в том о чем ты не знаешь ровным счетом ничего.
Мне это только кажется, или во главе всего, получается, изменяемый тип, который, в дефолтовом конструкторе использует некое изменяемое глобальное состояние
Кстати, как на счёт слов о том, что свойства-акессоры к открытым полям не есть гуд? А что же мы видим здесь? Открытое изменяемое поле
Help will always be given at Hogwarts to those who ask for it.
Здравствуйте, _FRED_, Вы писали:
_FR>Мне это только кажется, или во главе всего, получается, изменяемый тип,
От этого никуда не деться ибо в режиме интелисенса при редактировании нужно корректировать локешены.
_FR>который, в дефолтовом конструкторе использует некое изменяемое глобальное состояние
Изначально компилятор писали студенты.
Там еще много страшного если посмотреть.
Во второй версии ничего подобного не будет.
_FR>Кстати, как на счёт слов о том, что свойства-акессоры к открытым полям не есть гуд? А что же мы видим здесь? Открытое изменяемое поле
Осталось по недосмотру. Ща сделаю его приватным.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
WH>От этого никуда не дется ибо в режиме интелисенса при редактировании нужно корректировать локешены. WH>Изначально компилятор писали студенты. WH>Там еще много страшного если посмотреть. WH>Во второй версии ничего подобного не будет. WH>Осталось по недосмотру. Ща сделаю его приватным.
Спасибо, всё понятно, всё отлично
Help will always be given at Hogwarts to those who ask for it.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, mrTwister, Вы писали:
H>>>Ты видел в стандартной библиотеке реализацию DependencyProperty? Или автоматическое INotifyPropertyChange? H>>>Или автоматический маппинг объектов? T>>Нет, и что?
VD>А то, что это как раз то что невозможно положить в обычную библиотеку потому, но слишком специфично чтобы встраивать в язык. По этому ты никогда не увидишь средств автоматизирующих DependencyProperty и INotifyPropertyChange. Меж тем в виде макроса эти проблемы автоматизируются на раз. Вот здесь можно найти пример автоматизации DependencyProperty.
Здравствуйте, WolfHound, Вы писали:
WH>Осталось по недосмотру. Ща сделаю его приватным.
Вот собственно все что пришлось поправить: http://code.google.com/p/nemerle/source/detail?r=9326#
3 использования в компиляторе.
1 в стандартной библиотеке
13 в интеграции. Причем как я понимаю тот кусок по факту не используется.
2 в сниппетах.
Короче это поле почти не использовалось.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, _FRED_, Вы писали:
_FR>Здравствуйте, hardcase, Вы писали:
_FR>>>А автосвойств с авто-mutable полем нет?
H>>Их есть: _FR>
H>>class Foo { public Bar : string { get; set; } }
_FR>
_FR>Отлично, а почему не используется (в данном конкретном месте)?
Можно, но особого резону, я, например, пока не вижу — к сожалению есть куча других проблем.
Если уж специально садиться и заниматься подобным рефакторингом, то нужно комплексно анализировать АПИ компилятора. Но этим займемся после релиза.
_FR>>>"Util.ice" — замечательно H>>Это тот самый "internal compiler error".
_FR>Util.vodka и Util.juice в стандартной поставке имеются или нужно самому изобретать?
H>>class Foo { public Bar : string { get; set; } }
_FR>
_FR>Отлично, а почему не используется (в данном конкретном месте)?
Есть даже круче вещи:
class Foo {
public Bar : string { mutable bar : string; get { bar } set { bar = value } }
}
Вообще сейчас код компилятора можно точно сократить процентов на 20 использованием одних только стандартных макросов и удалением дублированного кода. Вот только чтобы это сделать нужно кучу времени, которого у меня например хватает только на исправление багов.
.
Открытое изменяемое поле 
