Здравствуйте, m e, Вы писали:
ME>да, непонимание может быть следствием как того, что я не в теме, так и удручающе неподходящего стиля изложения
Ну, да. Только вот то, что ты взялся за статью не рассчитанную на начинающего, как бы наталкивает на первое. Хотя, конечно, это не исключает того, что изложение можно улучшить.
ME>собственно, я и не собираюсь чтобы из моей затеи что-то "получилось" в твоем понимании — мне достаточно, чтобы я имел у себя описание немерле, соответствующее действительности, и написанное тем языком, который я считаю подходящим для спецификации, а не охами-вздохами "ай как это сложно" (можешь посчитать охи в 4-й части)
ME>можно, конечно, попросить вашу команду написать описание немерле 1 на человеческом языке, но я подозреваю, что это не будет сделано -- вы скорее будете заниматься немерле 2 (кстати, по нему я тоже потом задам вопросы)
Думаю, что тут основная проблема в том, что ты под "человеческим" понимаешь что-то отличное от того, что под этим понимают остальные. По сему угодить тебе трудно. Да и нет задачи огождать отдельным людям.
Разумные замечания, вроде уточнения терминологии или префразирования неоднозначных раз учтем. Но переименовывать номера в фазы или называть контейнерами определяемые пользователями типы явно неконструктивно. Вот пройтись по 5-ой части и заменить "фазы компиляции" на "фазы раскрытия макросов" можно.
VD>> А текст этот рассчитан на тех кто в теме и ни разу не претендует на описание языка или даже компилятора. Это просто вводная для темы типизации в макросах.
ME>в эн+1 раз спрашиваю: а где описание немерле 1?
В 6-й и 7-й части (которая появится вскоре). Так же на сайте в разделе Reference Manual.
ME>кстати, 6-я часть опять описывает скорее парсер, чем синтаксис!
Это явно высосанное из пальца утверждение. В прочем, с интересом послушаю, что в твоем понимании является синтаксисом. И чем не удовлетворяет синтаксис описанный в EBNF/PEG.
ME>мне видимо опять-таки придется для себя из нее сделать выжимку, с моей точки зрения подходящую под описание языка, и задать вопросы
Для себя каждый может сколько угодно. Вот только очень хотелось бы вместо громких и бессмысленных фраз вроде "скорее парсер, чем синтаксис!" услышать какую-то конструктивную критику с примерами и объяснением того, что не нравится.
ME>да, я бы тебе эти так беспокоящие тебя выжимки не показывал, но, похоже, это единственный способ выяснить, где я понял что-то неверно
Так может вместо этой самодеятельности приводить цитаты из текста и просить объяснить непонятные моменты? А я уж на основании этого подумаю, что и как поправить, чтобы подобных вопросов не возникало.
Это будет куда проще и объективнее. Пояснять написанное куда проще, чем интерпретировать вольный пересказ.
В прочем, еще раз повторюсь, что без практики все равно язык не изучить. У языка есть только одно точное описание — его компилятор. По понятным причинам полностью вместить в могз его невозможно. По сему любые стандарты, спецификации или вольные рассказы — это всего лишь абстрактные описания приближающиеся к описанию языка не более чем учебники истории к описанию реальной жизни.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
VD>Думаю, что тут основная проблема в том, что ты под "человеческим" понимаешь что-то отличное от того, что под этим понимают остальные. По сему угодить тебе трудно. Да и нет задачи огождать отдельным людям.
конечно, на отдельных людей нет смысла заморачиваться
однако есть такое понятие как целевая аудитория
и у немерле это скорее всего весьма продвинутые программисты, которые, честно говоря, не особо оценят доки в стиле "а теперь нажми эту кнопочку... а теперь эту... молодец! хороший мальчик! возьми конфетку!", а то и обидятся на подобный стиль изложения
да, никто не спорит, что показать интеграцию с VS необходимо и полезно, но упор, мне кажется надо делать на тех, кто знает, что им надо -- так как те, кто не знают, спокойно пишут себе на шарпе (а то и на РНР) и не ищут чего-то иного
VD>Так может вместо этой самодеятельности приводить цитаты из текста и просить объяснить непонятные моменты? А я уж на основании этого подумаю, что и как поправить, чтобы подобных вопросов не возникало.
эта самодеятельность -- почти всегда немного измененные (в соответствии с моим пониманием) цитаты из твоего текста
VD>Разумные замечания, вроде уточнения терминологии или префразирования неоднозначных раз учтем.
да, уточнить было бы весьма полезно -- скажем, сделать глоссарий-и-одновременно-определение-части-понятий, удалить дубликаты, почисть *языковую* терминологию от названий классов в компиляторе
VD> Но переименовывать номера в фазы
пусть стадии, не важно -- главное не номера
VD> или называть контейнерами определяемые пользователями типы явно неконструктивно.
агрегаты это, а не контейнеры
кстати -- энумы это определяемые пользователями типы, но есть ли у них члены, которые типизируются на фазе Х? а?
Здравствуйте, m e, Вы писали:
VD>> За одно почему-то посчитал, что фазы используемые макросах должны иметь четкое отображение на этапы компиляции. Зависимость несоменнно есть, но фазы макросов идут как бы между этапами компиляции.
ME>вот и хорошо ME>осталось заменить слова "как бы" на более точные (или выбросить вообще?)
Можешь выбросить.
VD>>2. Ты взялся за чтение текста предназначенного для тех кто уже разбирается в макросах и языке и хочет углубить свои знания. Читать "расширенный курс" не зная языка и не имея опыта создания макросов — это не верный шаг. Так ты только запутаешься.
ME>ровно наоборот -- создавать макросы, не имея общей картины -- это признак code monkey
Я делю программистов на группы исключительно по их интеллектуальным способностям, которые можно оценить только поработав с ними бок о бок, а не по признакам. Сто раз встречал случаи когда сыплющие (вроде бы впопад) терминами люди на деле оказывались мало на что способными. Так что не надо про обезьянок и т.п. Никто не способен закгрузить в себя все знания. С чего-то всегда надо начинать и чем-то ограничиваться. Начинать с продвинутых тем — глупо. Они могут легко дать неверное впечатление.
ME>пожалуста перестань мне советовать стать code monkey -- это бесполезно
Я советую последовательное изучение. Сначала азы и реальное применение. А вот когда на практике начнут появляться вопросы, то переходить к продвинутым темам и изучать эти вопросы со знанием дела.
ME>>>для начала назовем агрегатами
VD>>Не. Так мы делать не будем. Это какая-то самодеятельность.
ME>не делайте -- оно сделано для того, чтобы мне было легче выяснить, что спрашивать о немерле (впрочем, будь я дизайнером языка, я бы ввел это понятие)
Ну, так просто изучи терминологию. 5-я и 6-я часть дает ее достатке. А если каждый будет вводить свои понятия и общаться с их применением, то никого понять будет нельзя.
VD>>Наследование поддерживается только в классах, интерфейсах и от части в структурах и перечислениях. При этом есть масса нюансов. Полностью наследование доступно только для классов и интерфейсов.
ME>а есть ли члены в чем-то, кроме как в классах, интерфейсах, в структурах? в перечислениях скажем?
Естественно. Фактически члены есть у всех типов. Все типы виртуально наследуются от типа object. По сему такие методы как GetType() или ToString() есть у экземпляров всех типов. Кроме того есть разные хэлпер-типы вроде System.Enum и т.п. Но все это относится не к немерлу как языку, а к донтету, как к рантайму и базовой платформе. Посему их описание нет смысла включат в язык. Их описания доступны на MSDN .
Используя немерл нужно быть знакомым с дотентом в той или иной степени. Конечно изучать язык можно и не вадаваясь в дотнет, но эффективно его использовать без дотенат не получится.
Более того, во многом семантика немерла близка к семантике шарпа. Так что зная шарп изучить немерл очень просто.
ME>ммм... у вас макросы -- это части компилятора; почему нельзя отвести часть фаз компиляции под части работы макросов?
Потому что для создания макросов нет нужды забивать голову деталями работы компилятора. Макрос работает с компилятор через определенные интерфейсы. И только их и нужно описывать (по крайней мере в описании языка). Иначе объем информации будет слишком велик для программиста (пользователя языка).
Для использования макросов достаточно знать о фазах когда они работают. Их 3 для макросов верхнего уровня и для макросов уровня выражений. Можно считать ее 4-й стадией идущей после трех предыдущих, но все же она относится к макросам другого вида.
В Н2, возможно стадии исчезнут. Вместо этого будет использоваться реактивная модель. Но это уже уход от темы.
ME>что такое скобки? это "(){}[]" или есть еще какие? почему это названо несовершенством?
Да — они. Плюс еще <[ ]> используется для квази-цитат. Это описано в одной из частей расширенного курса, если не ошибаюсь и должно появиться в 7-й части.
ME>и где в 6-й части дано *определение* TopDeclaration? там такого слова вообще нет
.
Делегат — это определяемый пользователем тип.
ME>есть ли у него члены?
Есть, но в основном встроенные, унаследованные от System.Delegate. Плюс компилятор генерирует такие члены как Invoke. Все что связано с делегатами является одинаковым для всех языков дотнета поддерживающих их. Так что если нужны детали, то можно читать любой материла по C# или делегатам в дотнете (включая спецификация CLI).
ME>типизируются ли члены делегатов на этой фазе?
Да, те что генерируются компилятором.
Добавить свои члены в делегат нельзя. Но можно добавить методы расширения (статические методы которые можно вызвать как экзеплярные, через точку).
ME>"текстовые описания типов параметров" -- описания это не имена
ОК, подумаю как переформулировать, чтобы звучало по лучше.
ME>или у вас описание типов параметров может состоять только из имени? и не-имена List[T] (или если пофантазировать List[T+U+V-W]) в качестве описание типов параметров недоступны? или все еще они неразобраны (т.е. в тексте)?
Ты снова полез в дебри. Имена бывают составными, а бывают простыми. В итоге любое имя разбивается на несколько строк. Если же говорить о деталях, то там еще цвета, окружения и много чего прочего есть. Это все не нужно и даже вредно для поверхностного объяснения. Если вдаваться в детали, то сути читатель уже не поймет. Его голова разбухнет от деталей и он бросит читать.
ME>>>Для методов это означает, что становятся известны типы аргументов и типы возвращаемых значений.
VD>>Масло масляное. ME>гыгы
ME>это я перенес твое "типы аргументов и возвращаемых значений известны перед началом процесса типизации" в то место, где оно должно было бы стоять, и чуть изменил формулировку
Это какой-то jpeg-перенос. С потерей смысла.
ME>>>раскрываются макросы WithTypedMembers и производится вывод типов.
VD>>Нет. Макрос работающие на фазе WithTypedMembers отрабатывают до начала типизации тел членов. Опять же читае 5-ю часть "Язык Немерле", где это хорошо расписано. Все фазы относятся к макросам верхнего уровня. Макросы раскрываемые при типизации тел относятся к макросам уровня выражений.
ME>почти ясно
А что не ясно?
ME>а на какой фазе (между какими фазами) работают макросы уровня выражений?
Они выделены в отдельный тип макросов и работают отдельно. Более того, в отличии от макросов верхнего уровня (по сути своей императивных), макросы уровня выражения "скрываются" (т.е. являются функциями преобразующими параметры в свой выхлоп). Раскрываются они во время типизации тел членов. Все фазы макросов верхнего уровня к этому моменту уже закончены.
Это так же описано в 5-й части и разжевано до неприличия.
VD>>Опять же, если бы ты прочел что написано дальше, то понял бы, что это очень поверхностное описание. Далее в статье было дано более глубокое и более точное описание: VD>>[q] VD>>Типизация осуществляется объектом Typer (из пространства имен Nemerle.Compiler)
ME>естественно я это прочитал, но это относится к деталям реализации
Забавный у тебя взгляд на вещи. То тебе нужны детали, то это уже детали реализации. Еще раз повторюсь, все детали языков доступны только в исходниках их компиляторов. Более того, язык имеющий несоклько компиляторов по факту имеет несколько диалектов. Ну, а любое описание языка — это приближение с некоторой детализацией. Описание из 4-й части расширенного курса, идущее в него начале — это очень поверхностное описание цель которого дать очень общее представление. Открою секрет — формально оно во многом некорректно.
VD>>Основная мысль заключается в том, что макросы раскрываются во время типизации, но до типизации непосредственно конкретного выражения которое поражается макросом. Кроме того макрос возвращает выражения в которых так же могут встречаться макросы. Типизатор разбирает результирующее выражение (которое возвратил макрос) и типизироует его по путно раскрывая те макросы которые есть в нем. Результатом работы типизатор всегда является TExpr. В TExpr макросов уже быть не может. Зато в нем есть типы и разрешенные имена. Однако типы могут быть не вывденными, а подветки TExpr могут содержать объект отложенной типизации.
ME>так, это я обдумаю
Это, кстати, чуть ли не важнейшая ведь которую нужно понять о макросах уровня выражения.
ME>
ME>насчет агрегатов -- хотя язык и не мой, но я могу (и буду) вводить свою терминологию для его описания;
Не стоит. Это явно тупиковый путь. Терминология должна быть одна.
ME> я, естественно, постараюсь излишне не перегружать всех вас этой самопальной терминологией, но использовать ее скорее всего продолжу, т.к. она позволяет мне лучше задавать вопросы
Вопросы еще нужно понимать. И если, скажем я уже настроил в своей голове отображение между принятой терминалогией и твоей, то кто-то другой тебя просто не поймет. Мы ведь не в личной переписке общаемся...
Потом твоя терминология не корректна. Ты наверно заметил, что члены есть у любых типов. Даже тех которым они не особо то и нужны (например, функциональному типу). По сему данное деление неверно.
Есть более точное понятие — определяемые пользователем типы. Их можно так же называть: декларируемые типы или пользовательские типы. Им противопоставляются встроенные типы (предопределенные). Суть их различия в том, что встроенные типы заранее предопределены. Пользовательские же типы являются позволяют декларировать новые, конкретные, типы.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
VD>Потому что для создания макросов нет нужды забивать голову деталями работы компилятора. Макрос работает с компилятор через определенные интерфейсы. И только их и нужно описывать (по крайней мере в описании языка). Иначе объем информации будет слишком велик для программиста (пользователя языка).
фазы (или стадии) это не детали работы компилятора, епрст, это то, без чего я не сяду писать макрос, и предложения написать макрос без такого знания -- это предложение стать code monkey
я это сказал последний раз
дальше ты можешь конечно повторять свою тему "нет нужды забивать голову деталями работы компилятора", но я буду это тихо игнорировать
VD>В Н2, возможно стадии исчезнут. Вместо этого будет использоваться реактивная модель. Но это уже уход от темы.
ME>>кстати, 6-я часть опять описывает скорее парсер, чем синтаксис! VD>Это явно высосанное из пальца утверждение. В прочем, с интересом послушаю, что в твоем понимании является синтаксисом.
разница между синтаксисом и парсером примерно как между задачей и решением
впрочем, это мелкая претензия -- забей
дальше, на место агрегатов в свое описание я поставлю пользовательские типы -- ты меня убедил
теперь насчет ошибок в описании -- есть ли мне смысл изучать 4-ю часть дальше -- причем именно для понимания фаз, и не надо пожалуста мне советовать что-то попроще, или стоит подождать новое, более точное описание?
Здравствуйте, m e, Вы писали:
ME>дальше, на место агрегатов в свое описание я поставлю пользовательские типы -- ты меня убедил
ME>теперь насчет ошибок в описании -- есть ли мне смысл изучать 4-ю часть дальше -- причем именно для понимания фаз, и не надо пожалуста мне советовать что-то попроще, или стоит подождать новое, более точное описание?
Смысла нет никакого. 4-я часть расширенного курса посвящена типизации внутри макросов уровня выражения. Так что фаз макросов она не затрагивает.
VD>Более того, во многом семантика немерла близка к семантике шарпа. Так что зная шарп изучить немерл очень просто.
на шарпе я не писал, но основные его отличия от явы знаю, хотя и кое-какие не знаю
скажем, я так полагал что специализация дженериков под типы-значения происходит компилятором шарпа, а не где-то ниже, на уровне IL или рантайма
ME>> TopDeclaration VD>Мне тоже кажется, что название говорит само за себя .
наоборот -- я *название* долго не понимал (должно быть TopLevelDeclaration), и понял только исходя из анализа логики работы фаз
VD>Добавить свои члены в делегат нельзя. Но можно добавить методы расширения (статические методы которые можно вызвать как экзеплярные, через точку).
полиморфизм методов расширения в немерле разрешается статически? (в дотнете вроде же статически?)
VD> Если же говорить о деталях, то там еще цвета, окружения и много чего прочего есть.
что это такое? (только в *самых* общих чертах)
ME>>>>Для методов это означает, что становятся известны типы аргументов и типы возвращаемых значений. VD>>>Масло масляное. ME>>это я перенес твое "типы аргументов и возвращаемых значений известны перед началом процесса типизации" в то место, где оно должно было бы стоять, и чуть изменил формулировку VD>Это какой-то jpeg-перенос. С потерей смысла.
фазы надо описывать по шаблону:
1. название фазы
2. описание работы
3. постусловие фазы, например "все члены пользовательских классов полностью типизированы"
4. можно чуть добавить масляного масла, но по вкусу
VD>>>Типизация осуществляется объектом Typer (из пространства имен Nemerle.Compiler) ME>>естественно я это прочитал, но это относится к деталям реализации VD>Забавный у тебя взгляд на вещи. То тебе нужны детали, то это уже детали реализации.
как я понял, уравнения типизации составляются только после полного раскрытия макросов, так?
тогда для понимания работы макросистемы способ вывода типов не имеет значения
(с ним я буду разбираться отдельно, да там и paper вроде есть)
>Макросы верхнего уровня могут применяться на уровне: >сборки (Assembly level); >типа; >члена (метода, свойства, поля, события); >параметра.
>Макросы верхнего уровня выполняются в момент, когда компилятор обрабатывает конструкции верхнего уровня целевой программы, такие как: >атрибуты уровня сборки; >типы; >члены типов; >параметры членов типов
эти два списка обозначают одно и то же, или разное?
в любом из этих случаев, наличие двух похожих, но текстуально (или даже по-смысловому) разных сущностей существенно затрудняет обучение — т.к. обучающемуся первоначально приходится держать в уме в значительной степени не смысл, а текст!
кстати, похоже это повсеместно во введениях -- и в частности это я имел в виду, когда жаловался на стиль изложения
(а не стоит ли мне постить такие вопросы в раздел "немерле"?)
заодно:
параметры членов типов это на самом деле параметры методов (аргументы методов)?
Здравствуйте, m e, Вы писали:
ME>на шарпе я не писал, но основные его отличия от явы знаю, хотя и кое-какие не знаю
Отличий знать мало. Тем более, что их куда больше, чем ты себе представляешь. Многие твои вопросы — это вопросы не по языку, а по дотнету. И они подробно описаны много раз. Потому в описании языка на них и нет ответов.
ME>скажем, я так полагал что специализация дженериков под типы-значения происходит компилятором шарпа, а не где-то ниже, на уровне IL или рантайма
Это не верное представление. Дотнет поддерживает дженерики в рантайме. И они порождают специализации для значимых типов в рантайме же. Компилятор может только подставить конекретные типы в параметры типов. А уж остальная магия на совести рантайма.
Это дает как плюсы, так и минуся. Плюс в "компонентости" решений. Можно породить новый тип в рантайме. В рантайме же есть вся метаинформация о типе. Но это же порождает и минуся. Один из них — невозможность вмешаться в ход специализации макросом.
ME>наоборот -- я *название* долго не понимал (должно быть TopLevelDeclaration), и понял только исходя из анализа логики работы фаз
Ну, знаете ли!...
ME>полиморфизм методов расширения в немерле разрешается статически? (в дотнете вроде же статически?)
Если под полиморфизмом понимать перегрузку, то — да. Если аналог виртуальности методов, то для методов расширений виртуальность не поддерживается. Это просто синтаксический сахар, чтобы можно было вызвать метод "через точку".
VD>> Если же говорить о деталях, то там еще цвета, окружения и много чего прочего есть.
ME>что это такое? (только в *самых* общих чертах)
Ох, ох, ох... Это не простая тема. Попробую.
Каждое имя это объект содержащий в себе окружение в котором оно было создано и "цвет" (целочисленный идентификатор контекста в котором оно было создано). Цвета — это часть гигиены макросов. Иначе идентификаторы из макросов пересекались бы с одноименными идентификаторами из других макросов или кода полученного из исходников. При запуске макроса в текущий контекст устанавливается новый цвет. Так что все идентификаторы созданные из квази-цитат (средства формироания кода) получат именно его.
Окружение же — это информация о том какие пространства имен или типы были "открыты" при формировании некоторого имени. Имя ведь может быть перегружено. В процессе разрешения перегрузки используется, в том числе, и окружение.
ME>фазы надо описывать по шаблону:
ME>1. название фазы ME>2. описание работы ME>3. постусловие фазы, например "все члены пользовательских классов полностью типизированы" ME>4. можно чуть добавить масляного масла, но по вкусу
Примерно так они и описаны в 5-й части Язык Немерле на которую я уже устал давать ссылку.
ME>как я понял, уравнения типизации составляются только после полного раскрытия макросов, так?
Не. И я уже раз 5 это объяснял. Не после, а в процессе. Читается ветка нетипизированного АСТ, проверяется не макрос ли это, если макрос вызвается макрос который должен раскрыться. Результат снова проверяется, если это не макрос, то типизируется. Но типизируется именно отдельная ветка. При этом часть кода уже может быть типизирован, а часть (более глубоко лежащая) — нет.
Так что не после, а в процессе.
Макрос может сам вызвать типизацию и вернуть типизированное АСТ завернутое в специальную ветку. Кроме того, есть объекты отложенной типизации которые могут легко захватывать куски нетипизированного АСТ и делать с ними потом что-то. А это означает, что в типизированном АСТ может находиться ссылка на нетипзированное.
Сюда же еще добавляется многопроходность алгоритма вывода типов Немерле. Так что все становится весьма не просто.
ME>тогда для понимания работы макросистемы способ вывода типов не имеет значения
Для примитивного макроса — да. Но для сложного — нет. Именно этому и была посвящена 4-я часть расширенного курса. А сам курс посвящен написанию сложных макр, которые не отличаются по возможностям от того, что можно впихнуть в компилятор.
ME>(с ним я буду разбираться отдельно, да там и paper вроде есть)
С кем?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
>>Макросы верхнего уровня могут применяться на уровне: >>сборки (Assembly level); >>типа; >>члена (метода, свойства, поля, события); >>параметра.
>>Макросы верхнего уровня выполняются в момент, когда компилятор обрабатывает конструкции верхнего уровня целевой программы, такие как: >>атрибуты уровня сборки; >>типы; >>члены типов; >>параметры членов типов
ME>эти два списка обозначают одно и то же, или разное?
Одно — это к чему можно применять макросы, а втрое перечисление того они выполняются. Очевидно, что если макрос применен к типу, то он будет обрабатываться при обработке типа компилятором.
Так что перво "к чему", второе "когда", но они конечно же связаны.
ME>в любом из этих случаев, наличие двух похожих, но текстуально (или даже по-смысловому) разных сущностей существенно затрудняет обучение — т.к. обучающемуся первоначально приходится держать в уме в значительной степени не смысл, а текст!
Во втором случае можно заменить на что-то вроде "Макросы верхнего уровня выполняются в момент, когда компилятор обрабатывает конструкции верхнего уровня целевой программы, к которой применен макрос."
ME>кстати, похоже это повсеместно во введениях -- и в частности это я имел в виду, когда жаловался на стиль изложения
Идеальных тестов не бывает. А процесс их улучшения бесконечный. При этом одному нравится одно, а другому другое.
ME>(а не стоит ли мне постить такие вопросы в раздел "немерле"?)
Стоит.
ME>заодно: ME>параметры членов типов это на самом деле параметры методов (аргументы методов)?
Члены бывают разные. Например, индексированные свойства тоже имеют параметры, но формально являются свойствами. Привыкай.
Аргументы — это значения. Параметры — формальные описания.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
эта самодеятельность -- почти всегда немного измененные (в соответствии с моим пониманием) цитаты из твоего текста
