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

VD>Если бы это было так, то любая пропущенная фигня приводила бы краху в рантайме. А оно приводит к ошибкам времени компиляции.
Если ошибки возникают на этой стадии, то это ошибка в реализации макроса.
А не в его использовании.
Это примой аналог ICE. Его наверное можно назвать Internal Macro Error.

VD>Ну, ты найди еще хотя бы один хардкод в компиляторе, чтобы не быть голословным.
Я тебе уже два раза приводил цитату из Typer.n но ты оба раза ее "не заметил".

VD>Ага. И что? Так значит для этого на надо типизировать все и вся заранее?
Это значит что в этом случае накладных расходов по сравнению с моим вариантом нет.

VD>К тому же далеко не везде есть обработка. Во многих случаях сообщения от компиляции переписанного кода вполне себе нормально выглядят.
Пример показать можешь?

VD>Описание правил может оказаться очень сложным. Намного более сложным чем простая возможность возвратить список строк.
Его по любому нужно описывать.
Ибо язык нужно типизировать.
PegGrammar без типизации работать не может.
Совсем.

VD>имя X и B описаны за местами их использования. Получается что пока не спарсишь всю грамматику разрешить имена невозможно. Выходит надо иметь полную модель грамматики чтобы с ней разбираться.
И?
Типизация происходит после парсинга.
В чем проблема то?
В любом случае сейчас PegGrammar типизируется когда распарсено все дерево.

VD>Имею такую модель выдать список автодополений — это тривиальная работа. Функция от модели в список строк.
А это треп! (С) Сам знаешь кто.
Ты опять забыл про магию в "?."?
А ведь этот оператор несравнимо проще, чем PegGrammar.
Давайка ты нарисуешь псевдокод для автодополнения в PegGrammar.

VD>Не удивлюсь если окажется, что на практике ты предложишь отдельно типизировать и "?." и ".". А это гора кода. Там тебе и разрешение перегрузки и прочая фигня.
Ты меня совсем за дебила держишь?
Ты что думаешь, я повторно код использовать не умею?

VD>Ты объем этого кода для перегрузки и
Правила разрешения перегрузки один раз придется написать.

VD>отложенного вывода типов представляешь?
А этим займется компилятор ДСЛ описания типизации.
Это одна из причин, почему и занялся созданием языка.

VD>Проблем несколько.
VD>1. Кода типизации для не тривиальных случаев будет море. Заставлять его писать не проффесионалав (т.е. писателей макросов) нельзя. Это четкий фэйл.
Есть всего один не тривиальный случай.
Перегрузка.
Ее можно засунуть в один предикат и использовать по необходимости.

VD>3. Типизация может быть отложенная (зависеть от кода идущего ниже), стало быть нужны какие-то средства возвратов к процессу типизации.
Для этого я и делаю ДСЛ.
Ибо модель выполнения ДСЛ может быть любой.
В том числе итеративной.

VD>4. Типизация может быть невозможна для отдельного участка АСТ. PegGrammar отличный тому пример.
Учитывая, что PegGrammar стал последней каплей после которой я начал разрабатывать язык описания типизации...
Ты на самом деле, думаешь, что я о нем не думал?

VD>Это публичный интерфейс. А вот задавать типы переменных и локальных функций не надо. И многие считают это огромным достижением.
А что сигнатура макроса это не публичный интерфейс?

VD>И что тут не ясно? Разве что "in type-enforced expression" лишнее.
После дрессировки все понятно.

VD>Ну, дык я не против возможности задать подобные связи явно и указать более человеческое сообщение об ошибке. Но зачем же из-за этого типизировать все и тотально?
Задавая эти связи ты по факту все тотально и затипизируешь.

VD>Да ничего! Ты же, если что-то и придумал, то все равно держишь это все в своем мозгу. Скорее всего ты просто не продумал многих тонких моментов. И когда ты их начнешь продумывать, то придешь к тому о чем тебе говорю я. Только, скорее всего, назавешь это по другому и будешь говорить, что ты так всегда думал (с) ты.
Сто пятидесятый раз.
Я пока не придумал поиск имен.
Со всем остальным мне все ясно.
Поиск имен технически решаемая задача.
Поэтому я уверен, что у меня нет никаких пробелов.

VD>Я понял. И то что ты показал с некоторыми переделками и доделками может пойти для типизации типизации. Но ты не показал реализации тех моментов которые которые не вписываются в твои концепции.
Таких нет.
Повторяю сто пятьдесят первый раз: Мне не хватает поиска имен.

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

[утирает тряпкой пот со лба]
Уфф, мужики, ну вы даёте!
Надо бы полегче.

P.S.
Со своей стороны, я за тот вариант, который предлагает максимум возможностей при максимальной производительности!

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

VD>>Если бы это было так, то любая пропущенная фигня приводила бы краху в рантайме. А оно приводит к ошибкам времени компиляции.
WH>Если ошибки возникают на этой стадии, то это ошибка в реализации макроса.

А мы живем в идеальном мире?

WH>А не в его использовании.
WH>Это примой аналог ICE. Его наверное можно назвать Internal Macro Error.

Это из серии "нешмагла". Толку от такой информации — 0. А вот сообщение от компилятора типизирующего результат преобразования дают куда больше информации. Если в высокоуровневых проверках дыра, то это позволяет хотя бы получить внятное сообщение об ошибке которое можно использовать для поиска причины ошибки (как в ДСЛ-е, так и в коде макроса).

Так что отказаться от типизации раскрытого кода никак не выйдет.

VD>>К тому же далеко не везде есть обработка. Во многих случаях сообщения от компиляции переписанного кода вполне себе нормально выглядят.
WH>Пример показать можешь?

Да их тысячи. Вот плохие можно по пальцам пересчиать. И то обобщив сообщение можно получить нужный результат.
Ну, например, если написать:

    for (def x = 1; x < 0; x++)
      ...

то получишь логичное сообщение, что в выражении "x++" требуется изменяемое значение:

needed a writable location for assignment target, got a reference to local symbol 'a local value x', which is read-only

а этот "x" ведь в двух макросах завернут (for и ++).
И никто ничего специально не делал. Просто сгенерировали код и все.

Ты предлагаешь подобные ошибки вручную выявлять?

VD>>Описание правил может оказаться очень сложным. Намного более сложным чем простая возможность возвратить список строк.
WH>Его по любому нужно описывать.

Когда ты переписываешь код, то тем самым и описываешь эти правила.

WH>Ибо язык нужно типизировать.
WH>PegGrammar без типизации работать не может.
WH>Совсем.

Мне не слышат? Я согласен, что макросы вроде PegGrammar имеет смысл типизировать по верхам. Но есть еще linq который не следует типизировать. А есть куча разных "." и "х(...)" которые задолбашся типизировать. Код их типизации должен быть написан один раз и использоваться везде повторно. Переписывание — это и есть повторное использование.

А как ты предлагаешь повторно использовать уже имеющуюся типизацию?

VD>>имя X и B описаны за местами их использования. Получается что пока не спарсишь всю грамматику разрешить имена невозможно. Выходит надо иметь полную модель грамматики чтобы с ней разбираться.
WH>И?
WH>Типизация происходит после парсинга.

В твои примерах ты привязал отдельные ее части прямо к результатам парсинга.

WH>В чем проблема то?
WH>В любом случае сейчас PegGrammar типизируется когда распарсено все дерево.

Ага. Это потому что он тпизируется имеющимися средствами. А в них нет привязки к веткам АСТ.
Так что, в любом случае сейчас PegGrammar и дальше будет типизируется когда будет распарсено все дерево. А попытка разрешить ссылку на правило внутри обработки этой ссылки обречена на провал. Надо по прежнему сформировать отдельное дерево и обрабатывать его целиком. И это по прежнему же будет делаться большими функциями обходящими это дерево по много раз.

VD>>Имею такую модель выдать список автодополений — это тривиальная работа. Функция от модели в список строк.
WH>А это треп! (С) Сам знаешь кто.
WH>Ты опять забыл про магию в "?."?

А ты опять не описал то как это будет работать у тебя. Когда опишешь, обсудим.

WH>А ведь этот оператор несравнимо проще, чем PegGrammar.

С точки зрения автодополнения он несравнимо сложнее. Ведь при его типизации нем нужно разгребать списко перегрузки. А в
PegGrammar тупо оплюнуть список правил. Это в сто раз проще для макроса. Если бы поддерживался комплит для кастом-атрибутов, я бы тебе реализовал такой комплит за 10 минут.

WH>Давайка ты нарисуешь псевдокод для автодополнения в PegGrammar.

Давай:

when (token is Token.IdentifierToComplete)
{
  def completionList = rules.Map(_.Name);
  throw CompletionResult(completionList); // это исключение перехватывается IDE
}

Проблема только в том, что для атрибутов комплит не реализован и всегда вовзращает список ключевых слов. Если бы это было сделано, то этого кода было бы достаточно.

VD>>Не удивлюсь если окажется, что на практике ты предложишь отдельно типизировать и "?." и ".". А это гора кода. Там тебе и разрешение перегрузки и прочая фигня.
WH>Ты меня совсем за дебила держишь?
WH>Ты что думаешь, я повторно код использовать не умею?

Я думаю, что тебе следовало бы показать как ты это видишь. Боюсь, что это будет слишком громоздко.
У переписывания есть офигительное преимущество в этом плане.

VD>>Проблем несколько.
VD>>1. Кода типизации для не тривиальных случаев будет море. Заставлять его писать не проффесионалав (т.е. писателей макросов) нельзя. Это четкий фэйл.
WH>Есть всего один не тривиальный случай.
WH>Перегрузка.
WH>Ее можно засунуть в один предикат и использовать по необходимости.

Начнем с того, что случаев перегрузки много (операторы, функции, члены, теперь вот еще макросы по видимому будут).
А нетривиальные случае будет везде где тип может потом определиться.
К тому же сложность начинается когда несколько перегрузок начинают зависеть друг от друга и влиять друг на друга.

VD>>3. Типизация может быть отложенная (зависеть от кода идущего ниже), стало быть нужны какие-то средства возвратов к процессу типизации.
WH>Для этого я и делаю ДСЛ.
WH>Ибо модель выполнения ДСЛ может быть любой.
WH>В том числе итеративной.

Здорово. Но надо описать как ты это видишь. Ведь мелки детали могут препятствовать этой итеративности.

Вот представь себе, что для типизации макроса надо иметь выведенным тип одного из его параметров. Что будет делать твой язык, если этот тип еще не вывелся?

VD>>4. Типизация может быть невозможна для отдельного участка АСТ. PegGrammar отличный тому пример.
WH>Учитывая, что PegGrammar стал последней каплей после которой я начал разрабатывать язык описания типизации...
WH>Ты на самом деле, думаешь, что я о нем не думал?

Да даже согласен с тобой что такой язык нужен. Я только не согласен, что нужно все типизировать в исходном виде.

Что нам помешает часть кода раскрывать до типизации, а потом полученный вариант типизировать вместе с другим кодом (не раскрытым)? Чем он будет отличаться?

Ну, вот представь себе тот же linq. Ну, что там типизировать то? Ну, проверим мы, что у коллекции есть методы Where(). И что дальше? Проще преобразовать код и отдать его стандартному тайперу. Он выведет типы по правилам разрешения перегрузки и можно будет эти типы уже использовать дальше (если захочется). Зачем же заниматься мазохизом и пытаться повторить тот же процесс вручную? Да и что это даст?

VD>>Это публичный интерфейс. А вот задавать типы переменных и локальных функций не надо. И многие считают это огромным достижением.
WH>А что сигнатура макроса это не публичный интерфейс?

Сигнатура макроса задается в терминах других макросов. А вот типы — это уже дело внутреннее.

VD>>Ну, дык я не против возможности задать подобные связи явно и указать более человеческое сообщение об ошибке. Но зачем же из-за этого типизировать все и тотально?
WH>Задавая эти связи ты по факту все тотально и затипизируешь.

Вовсе нет. Многие вопросы мня просто не будут колыхать. Переписав код в другую форму я выражу все то что будут вынужден выражать явно. А значит я сэкономлю кучу своих сил.

Плюс еще надо не забывать о том, что многие макросы будут писаться с целью опробовать идею. Нагружать типизацией тех кто пишет экспериментальный макрос просто не разумно. Многие просто бросят это дело. Скажут "вот на Лиспе все в сто раз проще".

Все должно быть по желанию. Хочет человек хорошей диагностики — мы ему предоставляем средства для этого. Хочет он просто и быстро реализовать задуманное — мы его не напрягаем лишними деларациями. Ну, подумаешь, получит он не сообщение "в if выражения должны приводиться к одному типу", а "разные ветви вычисления должны приводиться к одному типу". И что? Он это переживет.

WH>Поиск имен технически решаемая задача.

А зачем ее решать, когда компилятор сам ее решит после переписывания код? Считай переписывание мегу-супер-пупер-ДСЛ-ем позволяющим иногда решить задача типизации не написав ни одной строчки косающейся типов.

Почему нельзя совместить два подхода? Ну, вот есть, предположим, проблемы с типизацией "?.". Предположим твой подход действительно решает задачу, а сам алгоритм перегрузки ты как-то вынес в отдельную функцию. Но зачем при этом вручную типизировать linq-запрос? Почему не переписать его и не позволить типизатору решить эту проблему на известных ему данных? Ведь мы от этого ничего не потеряем.

VD> То что ты хочешь не взлетит.
Сложно так сразу сказать без нормальной оценки. Если Н2 на компах которые выйдут в массы девелоперов через 2 года (т.е. какие-то 8-12 ядерники с 12+ гигами на борту), будет со всеми наворотами тормозить так, как два года назад тормозил Н1 на одноядернике, но при этом давать просто нереальные даже для самых насквозь динамических языков фичи — думаешь не взлетит? Игры вот пишут с расчётом на железо которое только в роадмапах есть, и ничего — взлетают.

VD> Пойми, дерево типов перестраивается при изменении любой буквы вне тел членов (методов). Единственное что позволяет работать этой схеме приемлемо — это высокая скорость обработки.
А теперь представь что дерево типов сплошь состоит из подписчиков друг на друга. При изменении любой буквы вне методов — не перестраивается всё дерево типов, а только уведомляются/перестраиваются те кто подписан, остальные спят в шапку (подписка притом автоматическая — сохранил у себя в проперте ссылку на какой-то тип, значит на него подписался). При изменениий буквы — интеллисенс в окрестности начинает работать уже после первой итерации. А следующая итерация уведомлений идёт только по тем кто подписан на уже произошедшие изменения, и то она может быть отброшена/остановлена сразу, как только пользователь вторую букву поменял. Т.е. меняешь что-то в классе — обновляются те кто используют этот класс, и то наверняка не все, какие-нить пропертя/поля/параметры — им по-барабану что там у класса поменялось. Вот повешенный на поле макро-аттрибут — это зависимость которая уже может что-то поменять вовне, но не все же меняют, так что скорее всего получит уведомление и заглохнет. Меняешь что-то в namespace — обновляются те кто использует этот namespace (в такой логике namespace — тоже макро-тип, который может содержать всего 3-4 вида сущностей).

VD>Высокая скорость обработки дерева типов достигается за счет того, что самая объемная и затрантая по времени работа — типизация тел методов не производится. Фактически самое медленной при построении дерева типов — это парсинг и макросы. Результаты парсинга мы можем кэшировать, так что от размера проекта мы не зависим. Остаются макросы. С ними хуже, но они так же могут работать вполне быстро откладывая затратные операции до поздних стадий компиляции (не выполняя их во время перестроения дерева типов).
Ну парсинг можно кэшировать в любом выбранном подходе, и в этом соответственно тоже. А типизация — пусть будет проект при первом открытии тормозить ровно так, будто он полностью компилируется. Думаешь кого-то это будет волновать? А остальное время изменения будут инкрементальные, расходящиеся волнами от места где пользователь правит код. И что-то сомневаюсь я что это будет суровый оверхэд. Вот Н1 ухитрялся и на одном ядре ещё сколько лет назад всё дерево типов перефигачивать, и взлетел же.

VD>С телами методов все сложнее. Их полная обработка в больших проектах будет неприемлемо медленной даже, если мы разгоним компилятор до космических скоростей.
VD>Посему мы не можем полагаться на результаты обработки тел методов.
Так вот фокус в том что не будет полной обработки. Если и найдётся человек который по делу будет зависимости толпами плодить, и тормозить себе интеллисенс — так это же личное дело. Апгрейд компа в любом случае будет копьём, лишь бы человеко-месяцы работы экономились.

VD>Единственное что мы можем сделать — это пометить некоторые методы и выполнять их типизацию при каждом перестроении дерева типов. Если таких методов будет не много и их тела будут относительно простыми, это не должно сильно повлиять на производительность, но позволит извлекать информацию из их обработки.
Можно то можно. Но смысл городить частное решние, если общее будет покрывать и его, и десятки других вариантов о которых мы даже не предполагаем.

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

VD>Это из серии "нешмагла". Толку от такой информации — 0. А вот сообщение от компилятора типизирующего результат преобразования дают куда больше информации.
А ты сломай кодогенерацию в том же PegGrammar.
Возврати где-нибудь строку вместо инта.

VD> Если в высокоуровневых проверках дыра, то это позволяет хотя бы получить внятное сообщение об ошибке которое можно использовать для поиска причины ошибки (как в ДСЛ-е, так и в коде макроса).
Ну а я не отказываюсь от этого.
Я покажу ошибку сгенерированную языком более низкого уровня.
Но при этом не буду делать вид, что все в порядке.
А помечу ее соответствующе и предложу обратиться к разработчику макроса.
Ибо это его косяк.

VD>Так что отказаться от типизации раскрытого кода никак не выйдет.
А я предлагал?

А всего-навсего сказал, что ошибка в раскрытом коде это ошибка реализации макроса.
Считать это нормальным поведением нельзя.

VD>И никто ничего специально не делал. Просто сгенерировали код и все.
VD>Ты предлагаешь подобные ошибки вручную выявлять?
В данном случае моя система будет поступать идентичным образом.
Данную проверку для for'а задать напрямую невозможно.
Просто потому что про выражения внутри for'а известно:
1)Первое выражение может быть объявлением переменной.
2)Второе и третье выражения должны иметь доступ к этой переменной.
3)Второе выражение должно быть типа bool.
Кстати for все ту же байду на это говорит Error: expected bool, got int in type-enforced expression: System.Int32 is not a subtype of System.Boolean [simple require]

VD>>>Описание правил может оказаться очень сложным. Намного более сложным чем простая возможность возвратить список строк.
WH>>Его по любому нужно описывать.
VD>Когда ты переписываешь код, то тем самым и описываешь эти правила.
Ты вообще за контекстом то следишь?
Как ты собрался задать автокомплит для PegGrammar переписыванием?

VD>Но есть еще linq который не следует типизировать.
А вот тут

Автор: Silver_S
Дата: 03.06.11

человек с тобой не согласен.

VD>А есть куча разных "." и "х(...)" которые задолбашся типизировать. Код их типизации должен быть написан один раз и использоваться везде повторно. Переписывание — это и есть повторное использование.
В том же ПегГраммар для создания расширяемых парсеров понадобится свой поиск имен.

VD>А как ты предлагаешь повторно использовать уже имеющуюся типизацию?
Засуну в предикат и вперед.

VD>В твои примерах ты привязал отдельные ее части прямо к результатам парсинга.
Ну да. И что?
Правила действительно привязаны к результатам парсинга.
Больше их некуда привязать.

VD>Ага. Это потому что он тпизируется имеющимися средствами. А в них нет привязки к веткам АСТ.
ОН ТИПИЗИРУЕТСЯ РУКАМИ!!!!!!!!!!

VD>Так что, в любом случае сейчас PegGrammar и дальше будет типизируется когда будет распарсено все дерево. А попытка разрешить ссылку на правило внутри обработки этой ссылки обречена на провал. Надо по прежнему сформировать отдельное дерево и обрабатывать его целиком. И это по прежнему же будет делаться большими функциями обходящими это дерево по много раз.
Ох.
Типизация начинается после парсинга.
Те дерево уже построено.
К корневому правилу ПегГраммар цепляем пространство имен.
В это пространство имен складываем все ссылки на правила.
При типизации ссылки на правила запускаем поиск имен.
Он бежит вверх по дереву.
Находит пространство имен.
Получает из него ссылку на правило.
Радуется.

Если у нас интелисенс то мы запрашиваем все имена по префиксу.

Также у нас автоматом начинает работать навигация. Ибо ИДЕ знает, куда показывает каждая ссылка в коде.

Те 0 букв и для автокомплита и для навигации.

VD>А ты опять не описал то как это будет работать у тебя. Когда опишешь, обсудим.
А вот давай ты ради разнообразия опишешь, как ты собрался делать автокомплит для ПегГраммар.

VD>С точки зрения автодополнения он несравнимо сложнее. Ведь при его типизации нем нужно разгребать списко перегрузки. А в PegGrammar тупо оплюнуть список правил.
Это не правда. Ему тоже нужно отплюнуть список членов типа и не более того.

VD>Проблема только в том, что для атрибутов комплит не реализован и всегда вовзращает список ключевых слов. Если бы это было сделано, то этого кода было бы достаточно.
Это я так понимаю нужно написать внутри парсера?
Могу тебя обрадовать. Пока все не распарсим список правил не получим.

А вообще предложение просто феерично.
Логика на исключениях это наше все.
Ты бы меня за такой код еще год нехорошими словами вспоминал.

VD>Начнем с того, что случаев перегрузки много (операторы, функции, члены,
Разницы никакой.

VD>теперь вот еще макросы по видимому будут).
Это отдельная история.

VD>А нетривиальные случае будет везде где тип может потом определиться.
VD>К тому же сложность начинается когда несколько перегрузок начинают зависеть друг от друга и влиять друг на друга.
Ну так я взял меркури за основу ибо он для таких задач создан.

VD>Вот представь себе, что для типизации макроса надо иметь выведенным тип одного из его параметров. Что будет делать твой язык, если этот тип еще не вывелся?
Так порядок выполнения не определен.
Просто пойдет выводить что можно.
И если тип выводиться, то на очередном заходе он завершит типизацию.

WH>>А что сигнатура макроса это не публичный интерфейс?
VD>Сигнатура макроса задается в терминах других макросов. А вот типы — это уже дело внутреннее.
Чего?

VD>А зачем ее решать, когда компилятор сам ее решит после переписывания код? Считай переписывание мегу-супер-пупер-ДСЛ-ем позволяющим иногда решить задача типизации не написав ни одной строчки косающейся типов.
Искать имена нужно много где.
Например, в том же ПегГраммар.
А раз он нужен там то почему бы не сделать обобщенный поиск имен и искать им все?
Зачем делать одну и туже работу сначала создавая компилятор ДСЛя, а потом еще и ручками поиск имен наворачивать?

VD>Но зачем при этом вручную типизировать linq-запрос? Почему не переписать его и не позволить типизатору решить эту проблему на известных ему данных? Ведь мы от этого ничего не потеряем.
1)Вот тут

Автор: Silver_S
Дата: 03.06.11

человек с тобой не согласен.
2)Это просто.

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

VD>> То что ты хочешь не взлетит.
_>Сложно так сразу сказать без нормальной оценки. Если Н2 на компах которые выйдут в массы девелоперов через 2 года (т.е. какие-то 8-12 ядерники с 12+ гигами на борту), будет со всеми наворотами тормозить так, как два года назад тормозил Н1 на одноядернике, но при этом давать просто нереальные даже для самых насквозь динамических языков фичи — думаешь не взлетит? Игры вот пишут с расчётом на железо которое только в роадмапах есть, и ничего — взлетают.

Думаю не взлетит. Проблеме в том, что тормоза будут пропорциональны объемам проектов. Так что язык превратится в игрушку для тестов.

Плюс не стоит сбрасывать со счетов недетерминированность. Если методы могут обрабатываться по сто раз и в разной последовательности, но делать какие-либо императивные действия из них нельзя.

_>А теперь представь что дерево типов сплошь состоит из подписчиков друг на друга. При изменении любой буквы вне методов — не перестраивается всё дерево типов, а только уведомляются/перестраиваются те кто подписан, остальные спят в шапку (подписка притом автоматическая — сохранил у себя в проперте ссылку на какой-то тип, значит на него подписался). При изменениий буквы — интеллисенс в окрестности начинает работать уже после первой итерации. А следующая итерация уведомлений идёт только по тем кто подписан на уже произошедшие изменения, и то она может быть отброшена/остановлена сразу, как только пользователь вторую букву поменял. Т.е. меняешь что-то в классе — обновляются те кто используют этот класс, и то наверняка не все, какие-нить пропертя/поля/параметры — им по-барабану что там у класса поменялось. Вот повешенный на поле макро-аттрибут — это зависимость которая уже может что-то поменять вовне, но не все же меняют, так что скорее всего получит уведомление и заглохнет. Меняешь что-то в namespace — обновляются те кто использует этот namespace (в такой логике namespace — тоже макро-тип, который может содержать всего 3-4 вида сущностей).

Это слишком сложно. Проще:
1. Помечать методы которые надо типизировать сразу за перестройкой типов.
2. Позволить макросам уровня выражения давать отложенные запросы на создание типов. А сами запросы отрабатывать позже при компиляции. А в режиме интеграции вообще игнорировать подобные вещи.

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

_>А типизация — пусть будет проект при первом открытии тормозить ровно так, будто он полностью компилируется. Думаешь кого-то это будет волновать?

Думаю, да. Тормоза — это одна из самых часто называемых проблем Н1. В Н2 это недопустимо. Да и медленная компиляция тоже недопустима. Ее надо разгонять.

_>А остальное время изменения будут инкрементальные, расходящиеся волнами от места где пользователь правит код.

Не будут. Если допустить императив в методах, то единственный шанс сделать работу макросов неотличимой в режиме IDE и режиме компиляции — это перетипизировать все тела методов на каждый чих. Макросы — это императивные сущности. Мы не можем гарантировать, что изменение А не вызовет изменение в любом из методов. А значит или их надо запрещать, или перестраивать все данные.

_>И что-то сомневаюсь я что это будет суровый оверхэд. Вот Н1 ухитрялся и на одном ядре ещё сколько лет назад всё дерево типов перефигачивать, и взлетел же.

Интеграция никогда не перестраивала тела методов. Из-за этого макросы которые изначально не рассчитывались на работу в режиме IDE под ней частенько не работали.

_>Так вот фокус в том что не будет полной обработки. Если и найдётся человек который по делу будет зависимости толпами плодить, и тормозить себе интеллисенс — так это же личное дело. Апгрейд компа в любом случае будет копьём, лишь бы человеко-месяцы работы экономились.

Мне кажется идея с зависимостями не перспективной. Если кто-то сможет создать тип из метода и этот тип сможет увидеть другой метод, то многие будут наступать на грабли и писать код который не будет работать корректно в режиме IDE. Надо делать так, чтобы макрос, как бы он не был написан, работал под управлением IDE точно так же как при компиляции.

Теоретически можно зацепить несколько методов друг за друга и при изменении одного перепарсивать все. Но это взывает ряд проблем:
1. Не ясно как это сделать автоматически. Если делать это вручную, будет куча ошибок.
2. Скорость все равно будет проседать. В прочем, тут можно покумекать. Ведь методы можно типизировать параллельно и в бэкграунде. Ведь пользователю нужен интерактив только для текущего метода.
3. Появятся проблемы с параллельной компиляцией тел методов. А она нужна для ускорения работы компиляции за счет масштабирования на многоядерных процессорах.

VD>>Единственное что мы можем сделать — это пометить некоторые методы и выполнять их типизацию при каждом перестроении дерева типов. Если таких методов будет не много и их тела будут относительно простыми, это не должно сильно повлиять на производительность, но позволит извлекать информацию из их обработки.
_>Можно то можно. Но смысл городить частное решние, если общее будет покрывать и его, и десятки других вариантов о которых мы даже не предполагаем.

Я пока что не вижу приемлемого общего решения. Тормоза неприемлемы. Плюс функциональная чистота макросов — это большое благо с разных точек зрения. Это и легкость распараллеливания. И уменьшение ошибок. И безопасная работа в режиме IDE. И возможность кэширования результатов.

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

VD>Думаю не взлетит. Проблеме в том, что тормоза будут пропорциональны объемам проектов. Так что язык превратится в игрушку для тестов.
Если применить идеи реактивного программирования то может и взлететь.

VD>Не будут. Если допустить императив в методах, то единственный шанс сделать работу макросов неотличимой в режиме IDE и режиме компиляции — это перетипизировать все тела методов на каждый чих. Макросы — это императивные сущности. Мы не можем гарантировать, что изменение А не вызовет изменение в любом из методов. А значит или их надо запрещать, или перестраивать все данные.
Надо просто использовать мой подход.
Нет императива.
Нет проблемы.

VD>Интеграция никогда не перестраивала тела методов. Из-за этого макросы которые изначально не рассчитывались на работу в режиме IDE под ней частенько не работали.
Это тоже проблемы императивного подхода.
У ИДЕ нет информации и она ничего не может сделать.

VD>Мне кажется идея с зависимостями не перспективной. Если кто-то сможет создать тип из метода и этот тип сможет увидеть другой метод, то многие будут наступать на грабли и писать код который не будет работать корректно в режиме IDE. Надо делать так, чтобы макрос, как бы он не был написан, работал под управлением IDE точно так же как при компиляции.
Мой подход это решает.

VD>1. Не ясно как это сделать автоматически. Если делать это вручную, будет куча ошибок.
Компилятор ДСЛ все сделает в лучшем виде.

VD>2. Скорость все равно будет проседать. В прочем, тут можно покумекать. Ведь методы можно типизировать параллельно и в бэкграунде. Ведь пользователю нужен интерактив только для текущего метода.
Еще можно прикрутить алгоритмы созданные для реактивного программирования.
У нас же ДСЛ

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

WH>В данном случае моя система будет поступать идентичным образом.
WH>Данную проверку для for'а задать напрямую невозможно.
WH>Просто потому что про выражения внутри for'а известно:
WH>1)Первое выражение может быть объявлением переменной.
WH>2)Второе и третье выражения должны иметь доступ к этой переменной.
WH>3)Второе выражение должно быть типа bool.

Ну, и как ты себе видишь полную типизацию фор-а без раскрытия и типизации результата?

WH>Как ты собрался задать автокомплит для PegGrammar переписыванием?

Для него переписывать нет смысла. Тут действительно комплит идет по ДСЛ-ю. Тут нужно просто ловить комплейшон-токен и генерировать исключение содержащее список автодополнения.

А вот для макросов for, foreach, linq переписывание автоматом обеспечит комплит.

VD>>Но есть еще linq который не следует типизировать.
WH>А вот тут

Автор: Silver_S
Дата: 03.06.11

человек с тобой не согласен.

Человек ламер в этом деле. Вот и несет что попало. А мы как серьезные люди должны отталкиваться от спецификации.

WH>В том же ПегГраммар для создания расширяемых парсеров понадобится свой поиск имен.

Что?

Кстати, они вообще появятся? Уже скоро будет 4 месяца как ты сформулировал гениальный алгоритм. Эдак на твой ДСЛ вывода типов уйдет лет 30.

VD>>А как ты предлагаешь повторно использовать уже имеющуюся типизацию?
WH>Засуну в предикат и вперед.

Я тебе уже показывал, что типизация — это не только предикаты. Не надо так наивно об этом говорить.

WH>К корневому правилу ПегГраммар цепляем пространство имен.
WH>В это пространство имен складываем все ссылки на правила.
WH>При типизации ссылки на правила запускаем поиск имен.
WH>Он бежит вверх по дереву.

Вверх? Может вниз?

WH>Находит пространство имен.
WH>Получает из него ссылку на правило.
WH>Радуется.

Это и есть отдельный обход всего дерева. Ничего нового ты не придумал. Именно так ты и делаешь сейчас. Ну, разве что со скопами и неким универсальным обходильщиком деревьев вроде того что Хардкейс сделал можно этот код упрессовать в более компактный.

WH>Если у нас интелисенс то мы запрашиваем все имена по префиксу.

Это в очень примитивных случаях. А в сложных (с разрешением неоднозначностей) все будет очень не просто.

WH>Также у нас автоматом начинает работать навигация. Ибо ИДЕ знает, куда показывает каждая ссылка в коде.

WH>Те 0 букв и для автокомплита и для навигации.

VD>>А ты опять не описал то как это будет работать у тебя. Когда опишешь, обсудим.
WH>А вот давай ты ради разнообразия опишешь, как ты собрался делать автокомплит для ПегГраммар.

Я тебе уже это описывал. Если бы небыло косяка с атрибутами, то там там нужно было бы вставить 4 строчки кода:

when (tok == Token.IdentifierToComplete)
  throw CompletionResult(grammar.GetNames())

GetNames() возвращает список имен правил.

VD>>С точки зрения автодополнения он несравнимо сложнее. Ведь при его типизации нем нужно разгребать списко перегрузки. А в PegGrammar тупо оплюнуть список правил.
WH>Это не правда. Ему тоже нужно отплюнуть список членов типа и не более того.

Хрен там. Типов бывает много. Я же говорю — неоднозначность.

xs.Where(x => x.S|

Where может быть штук 10 перегрузок. Это дело перемножается на количество перегрузок методв начинающихся на S.
Вывод типов кружит по куче альтернатив, а специальный код записывает их, а потом еще специальным образом обрабатывает.

WH>Это я так понимаю нужно написать внутри парсера?

Да там все сложнее.

WH>А вообще предложение просто феерично.
WH>Логика на исключениях это наше все.

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

Своеобразный глобальный return.

WH>Ты бы меня за такой код еще год нехорошими словами вспоминал.

Это код был написан сильно раньше чем год назад. Я сам таких финтов не люблю. Но в данном случае он оправдан. Иначе слишком многое пришлось бы менять.

VD>>Начнем с того, что случаев перегрузки много (операторы, функции, члены,
WH>Разницы никакой.

Разница в том, что это все особые случаи перегрузки. Их под одну гребенку не зачешешь.

VD>>А нетривиальные случае будет везде где тип может потом определиться.
VD>>К тому же сложность начинается когда несколько перегрузок начинают зависеть друг от друга и влиять друг на друга.
WH>Ну так я взял меркури за основу ибо он для таких задач создан.

Что твой меркури даст? Тормоза разве что. Сейчас используется специализированный алгоритм. На меркури его озверешь повторять. Тормозить будет. Потом сам меркури ты не сможешь использвать. Не будешь же ты повторять часть не самого простого языка только чтобы типы выводить?

VD>>Вот представь себе, что для типизации макроса надо иметь выведенным тип одного из его параметров. Что будет делать твой язык, если этот тип еще не вывелся?
WH>Так порядок выполнения не определен.
WH>Просто пойдет выводить что можно.
WH>И если тип выводиться, то на очередном заходе он завершит типизацию.

ОК. Тогда добавь в свою логику возможность по ходу дела соединить параметры в общий код и типизировать его. И у тебя получится рабочий вариант. Причем мало чем отличающийся от Н1.

WH>>>А что сигнатура макроса это не публичный интерфейс?
VD>>Сигнатура макроса задается в терминах других макросов. А вот типы — это уже дело внутреннее.
WH>Чего?

Того. У параметров макросов нет типов. Они им не нужны. Они же выражения. Они парсятся.

VD>>А зачем ее решать, когда компилятор сам ее решит после переписывания код? Считай переписывание мегу-супер-пупер-ДСЛ-ем позволяющим иногда решить задача типизации не написав ни одной строчки косающейся типов.
WH>Искать имена нужно много где.
WH>Например, в том же ПегГраммар.

Прекрасно. Я не против. Но зачем их искать вручную в foreach? Ведь можно тупо подставить код и заработает поиск уже написанный для общего случая.

WH>А раз он нужен там то почему бы не сделать обобщенный поиск имен и искать им все?

Да я не против. Но это не отменяет того, что иногда проще сгенеритть код без типизации и типизировать его.

WH>Зачем делать одну и туже работу сначала создавая компилятор ДСЛя, а потом еще и ручками поиск имен наворачивать?

Уж точно не зачем. Но как ты собрался искать имя переменной, если переменной еще не сформировано? В foreach у тебя есть имя, но это не имя переменной. Оно станет таковым только кода подставится в код. Например, это может быть кортеж внутри которого будет три других имени. Или еще какой-то паттетрн.

VD>>Но зачем при этом вручную типизировать linq-запрос? Почему не переписать его и не позволить типизатору решить эту проблему на известных ему данных? Ведь мы от этого ничего не потеряем.
WH>1)Вот тут

Автор: Silver_S
Дата: 03.06.11

человек с тобой не согласен.

Ты бы еще на Шаридана дал ссылку. Есть спецификация и ее надо выполнять. Мнения разных людей улицы никого при этом волновать не будет. Иначе это будет не C#, а другой язык. А мы же хотим этими же механизмами обрабатывать и C#? Правда?

WH>2)Это просто.

Ты скажешь мне просто это или нет, когда напишешь код демонстрирующий эту простоту.

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

VD>>Не будут. Если допустить императив в методах, то единственный шанс сделать работу макросов неотличимой в режиме IDE и режиме компиляции — это перетипизировать все тела методов на каждый чих. Макросы — это императивные сущности. Мы не можем гарантировать, что изменение А не вызовет изменение в любом из методов. А значит или их надо запрещать, или перестраивать все данные.
WH>Надо просто использовать мой подход.
WH>Нет императива.
WH>Нет проблемы.

Какой на фиг твой подход? Человек хочет менять типы во время работы макроса уровня выражения. Да так, чтобы при раскрытии макросов в других телах эти типы были видны. Это по любому императив. И никакой подход тут не спасет.

WH>У нас же ДСЛ

У вас явно панацея называемая в народе серебреной пулей. Мысль о том, что есть супер-молоток позволяющий забить все как гвозди посещает многих. Но это обычно проходит.

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

VD>Какой на фиг твой подход? Человек хочет менять типы во время работы макроса уровня выражения. Да так, чтобы при раскрытии макросов в других телах эти типы были видны. Это по любому императив. И никакой подход тут не спасет.
Не обязательно.
Можно еще использовать реактивное программирование.
Смысл в том, что рантайм языка знает откуда и какие данные пришли.
И если источник данных изменился то происходит пересчет тех узлов, которые от него зависят.
Если после пересчета по факту ничего не поменялось то пересчет останавливается.

Например, известный тебе http://knockoutjs.com/ так и работает.
Еще очень известный пример MS Excel.

Кроме всего прочего реактивный подход обеспечивает отложенную типизацию из коробки.

VD>У вас явно панацея называемая в народе серебреной пулей. Мысль о том, что есть супер-молоток позволяющий забить все как гвозди посещает многих. Но это обычно проходит.
В моем случае такой молоток обычно появляется.
И в данном случае я не вижу ни одной проблемы, которая бы не решалась.

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

WH>Можно еще использовать реактивное программирование.

И чего только люди не выдумают, чтобы не писать императивщину

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

VD>Ну, и как ты себе видишь полную типизацию фор-а без раскрытия и типизации результата?
Если в первом выражении объявлена переменная, то создам новую область видимости и остальные выражения типизирую с ее помощью.

VD>Для него переписывать нет смысла. Тут действительно комплит идет по ДСЛ-ю. Тут нужно просто ловить комплейшон-токен и генерировать исключение содержащее список автодополнения.
И ты предлагаешь это как решение?

VD>Человек ламер в этом деле. Вот и несет что попало. А мы как серьезные люди должны отталкиваться от спецификации.
А от чего отталкивалась спецификация не задумывался?
Уж точно не от здравого смысла, а от того как мелкософты смогли это реализовать.

WH>>В том же ПегГраммар для создания расширяемых парсеров понадобится свой поиск имен.
VD>Что?
Поиск имен в другой грамматике вот что.

VD>Я тебе уже показывал, что типизация — это не только предикаты. Не надо так наивно об этом говорить.
Предикат может содержать произвольное количество логики.

VD>Это и есть отдельный обход всего дерева. Ничего нового ты не придумал. Именно так ты и делаешь сейчас. Ну, разве что со скопами и неким универсальным обходильщиком деревьев вроде того что Хардкейс сделал можно этот код упрессовать в более компактный.
Ну да.
Алгоритм все тот же.
Другой не придумать.
А вот реализация существенно отличается.
Разница больше чем между пакратом и тем как работает PegGrammar.

VD>Я тебе уже это описывал. Если бы не было косяка с атрибутами, то там там нужно было бы вставить 4 строчки кода:
Это эпик фейл.
Данный код срабатывает во время прарсинга, а пока все не разобрано список правил отдать нельзя.

VD>Where может быть штук 10 перегрузок. Это дело перемножается на количество перегрузок методв начинающихся на S.
VD>Вывод типов кружит по куче альтернатив, а специальный код записывает их, а потом еще специальным образом обрабатывает.
Не вопрос ваще.

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

VD>Что твой меркури даст? Тормоза разве что. Сейчас используется специализированный алгоритм. На меркури его озверешь повторять. Тормозить будет. Потом сам меркури ты не сможешь использвать. Не будешь же ты повторять часть не самого простого языка только чтобы типы выводить?
1)Тормоза зависят от реализации.
2)Твой "специализированный" алгоритм все тот же поиск с откатами.
3)Меркури проще, чем кажется. Тем более что я собрался взять лишь часть его возможностей.

VD>Того. У параметров макросов нет типов. Они им не нужны. Они же выражения. Они парсятся.
У тебя нет. А у меня есть.

VD>Прекрасно. Я не против. Но зачем их искать вручную в foreach? Ведь можно тупо подставить код и заработает поиск уже написанный для общего случая.
1)Где я предлагал foreach?
2)Не заработает. В PegGrammar свой поиск имен.

VD>Уж точно не зачем. Но как ты собрался искать имя переменной, если переменной еще не сформировано? В foreach у тебя есть имя, но это не имя переменной. Оно станет таковым только кода подставится в код. Например, это может быть кортеж внутри которого будет три других имени. Или еще какой-то паттетрн.
В foreach'е у нас всегда паттерн.
И он будет иметь свой тип.
Тип паттерна это словарь отражающий имя связанного значения в тип.
Я просто на основе текущей области видимости создам новую и помещу туда эти переменные.
Потом с помощью новой области видимости типизирую тело.

VD>Ты бы еще на Шаридана дал ссылку. Есть спецификация и ее надо выполнять. Мнения разных людей улицы никого при этом волновать не будет. Иначе это будет не C#, а другой язык. А мы же хотим этими же механизмами обрабатывать и C#? Правда?
Если код получится идентичный, но сообщения об ошибках будут лучше, то это все еще будет C#.

А почему типизацию не проводить с раскрытием макросов в одной стадии? А раскрытие макросов не являющихся реентабельными обязать сделать не зависящим от типов и только однократным.

Здравствуйте, <Аноним>, Вы писали:

А>А почему типизацию не проводить с раскрытием макросов в одной стадии? А раскрытие макросов не являющихся реентабельными обязать сделать не зависящим от типов и только однократным.
Н1 так и работает.
Но это плохой подход.
От него нужно уходить.

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

WH>Здравствуйте, <Аноним>, Вы писали:

А>>А почему типизацию не проводить с раскрытием макросов в одной стадии? А раскрытие макросов не являющихся реентабельными обязать сделать не зависящим от типов и только однократным.
WH>Н1 так и работает.
WH>Но это плохой подход.
WH>От него нужно уходить.
А какие недостатки?

Здравствуйте, Аноним, Вы писали:

А>А какие недостатки?

Очень медленно.

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

А>>А какие недостатки?
H>Очень медленно.
Это не самое плохое.
Гораздо хуже тонна ручной работы в случаях чуть сложнее if'а.

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

VD>>Ну, и как ты себе видишь полную типизацию фор-а без раскрытия и типизации результата?
WH>Если в первом выражении объявлена переменная, то создам новую область видимости и остальные выражения типизирую с ее
помощью.

Параметры макросов не связаны. У тебя есть три независимых выражения: var, collection и body.
Ты собираешься создавать эту область видимости только для body?

Но для body не просто имя нужно, а объявление переменной. Причем тип переменной вычисляется по разному в зависимости от типа collection.

Зачем делать какие-то лишние действия, если можно просто дождаться когда тип для collection будет выведен, и просто сгенерировать код в котором уже будет нужная переменная?

Короче, покажи код. Уверен, что это будет ужасный код.

VD>>Для него переписывать нет смысла. Тут действительно комплит идет по ДСЛ-ю. Тут нужно просто ловить комплейшон-токен и генерировать исключение содержащее список автодополнения.
WH>И ты предлагаешь это как решение?

Если есть лучшее — я не буду не против. Но во-первых, оно должно быть действительно лучше, а во-вторых, не должно быть лишних телодвижений для случаев когда комлит идет не по ДСЛ-ю, а по подвыражениям которые являются базовым языком или синтаксическим сахаром над ним.

VD>>Человек ламер в этом деле. Вот и несет что попало. А мы как серьезные люди должны отталкиваться от спецификации.
WH>А от чего отталкивалась спецификация не задумывался?

А это не важно. Спецификации нужно тупо выполнять. Если дизайн твоего решения конфликтует с этим, то это проблемы твоего дизайна. С реалиями мира нужно считаться.

WH>Уж точно не от здравого смысла, а от того как мелкософты смогли это реализовать.

Ты можешь обсудить это где-нибудь в Философии. Здесь и сейчас этот вопрос не уместен.
Надо просто принять как аксиому то, что многие вещи в ЯП являются синтаксическим сахаром и, следственно, выражаются выражаются в терминах синтакических преобразований.

Иногда такие преобразования выигрывают от наложения дополнительны ограничений на типы (как в случае с if). Собственно даже linq выиграет от дополнительных проверок. Например, можно проверить если ли у коллекции методы в которые переписывается запрос

WH>>>В том же ПегГраммар для создания расширяемых парсеров понадобится свой поиск имен.
VD>>Что?
WH>Поиск имен в другой грамматике вот что.

Что-то я не пойму о чем ты. Расширяющий парсер просто встраивается в список приоритетного выбора базового парсера.

VD>>Я тебе уже это описывал. Если бы не было косяка с атрибутами, то там там нужно было бы вставить 4 строчки кода:
WH>Это эпик фейл.
WH>Данный код срабатывает во время прарсинга, а пока все не разобрано список правил отдать нельзя.

Ты несешь несуразицу. Разберись в проблеме, тогда поговорим. Доказывать тебе очевидные вещи вроде того что код комплита, в этом случае, должен вызываться из кода макроса я не намерен.

WH>1)Тормоза зависят от реализации.

В первую очередь от алгоритма. Если он квадратичный, то ничего ты не сделаешь.

WH>2)Твой "специализированный" алгоритм все тот же поиск с откатами.

Он сразу учитывает подтипы и позволяет делать вывод икрементально. Плюс он компилированный и оптимизированный на конкретные нужды. Я обсуждал с Москалем идею использования универсального теорем-прувера. Москаль сказал, что специализированный алгоритм по любому будет быстрее, так как его можно будет оптимизировать под задачи. С этим трудно спорить.

WH>3)Меркури проще, чем кажется. Тем более что я собрался взять лишь часть его возможностей.

А в каком виде ты его собрался использовать? Как ты его в компилятор то втащишь? Решил написать небольшой логический ДСЛ для Н1?

VD>>Того. У параметров макросов нет типов. Они им не нужны. Они же выражения. Они парсятся.
WH>У тебя нет. А у меня есть.

Да у тебя черт знает что есть. Вот только кому будет нужна вся эта хрень, если в ней один ты сможешь разобараться. Плюс она никогда написана не будет. Ты вот расширяемость четыре месяца прикруитить не можешь, а только в этой теме ты нафанатазировал на 20 лет вперед.

Не нужны макросам типы. Не нужны!

VD>>Прекрасно. Я не против. Но зачем их искать вручную в foreach? Ведь можно тупо подставить код и заработает поиск уже написанный для общего случая.
WH>1)Где я предлагал foreach?

Ты предлагаешь их всюду вручную искать. Стало быть и в foreach. Я давно тебя прошу показать код foreach-а написанный в твоей идеологии.

WH>2)Не заработает. В PegGrammar свой поиск имен.

Он там вручную за 2 минуты на коленке пишется. Это не интересный случай. Вот foreach — да.

VD>>Уж точно не зачем. Но как ты собрался искать имя переменной, если переменной еще не сформировано? В foreach у тебя есть имя, но это не имя переменной. Оно станет таковым только кода подставится в код. Например, это может быть кортеж внутри которого будет три других имени. Или еще какой-то паттетрн.
WH>В foreach'е у нас всегда паттерн.

Я тебе заранее сказал, что рассмотрим упрощенный случай. Случай паттерна еще сложнее, так что его лучше не рассматривать.

WH>И он будет иметь свой тип.
WH>Тип паттерна это словарь отражающий имя связанного значения в тип.

Это какая-то чушь. Оставь паттерны. Твой паттерн в любом случае должен в переменную разложиться.

WH>Я просто на основе текущей области видимости создам новую и помещу туда эти переменные.
WH>Потом с помощью новой области видимости типизирую тело.

Ну и зачем этот гимор? Ты сдублируешь часть типизации которая будет осуществляться над преобразованным кодом. При этом ты ровным счетом ничего не получишь. Зачем делать бессмысленные действия?

VD>>Ты бы еще на Шаридана дал ссылку. Есть спецификация и ее надо выполнять. Мнения разных людей улицы никого при этом волновать не будет. Иначе это будет не C#, а другой язык. А мы же хотим этими же механизмами обрабатывать и C#? Правда?
WH>Если код получится идентичный, но сообщения об ошибках будут лучше, то это все еще будет C#.

Код не получится идентичным. Ты собрался делать лишнюю работу. Сообщений никаких новых ты тоже не сможешь породить.

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

В принципе если рассматривать твои отдельные идеи они не противоречат такому подходу.

Еще один аспект, который нужно продумать, это вычисление отладочной информации.

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

WH>Посмотри на реализацию ?. никто кроме Влада его никогда не напишет.

Да ладно гнать то. Народ написал же похожий макрос инициализации (<-)?
По любому для переноса отладочной информации нужно будет правильно протаскивает локешоны. Так что нужно придумывать что-то для их качественного переноса.

Макросов таких 1-2 от силы. И ради их упрощения нет нужды ставить раком написание всех остальных макросов.

В общем, ты снова скатываешся к демагогии. Эксплуатируешь тему частного случая имевшего проблему в прошлой версии.

WH>Я глядя на реализацию даже не понимаю, что там происходить. Ясно только одно что некая магия вокруг автокомплита.

Там все просто как дважды два. Просто вместо квази-цитирования используется ПМ по PExpr, так как требуется корректно протащить локешоны.

WH>Также умрет страшный костыль IsIntelliSenseMode.

Все равно проблемы протаскивания локейшонов останутся. Они нужны для для корректных сообщениях об ошибках и для отладки.
Ты не решишь таким образом все проблем. Зато взамен ты создашь проблемы на ровном месте в других макросов. А их во много раз больше (макросов вроде ?. две штуки на весь Н1).

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

S_S>Информация то конечно есть но хотелось бы подробностей что такой механизм даст.
S_S>Ты предлагаешь, условно говоря, для макроса кроме тела хранить еще абстрактное представление. Это абстрактное представление закодировано констрейнтами, неважно в каком виде, хоть через require:..., хоть на урезаном mercury.

+1

S_S>По этому абстрактному представлению код построить нельзя,

+1
Придется каждый раз преседать. Потому я и говорю о наличии более низкоуровневого представления — TAST.

S_S>но можно провести типизацию с точно таким же результатом как по получилось бы макросу, но с лучшим перфомансом.

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

Единственно что можно таким образом улучшить — это качество сообщений об ошибках. Скажем, в том же if-е можно будет четка написать "У васт тут разные типы для trueExpr и falseExpr в if-е вылезли, а так нельзя!" вместо "Разные ветви вычисления одного выражения должны иметь одинаковый тип". Происходит это потому что мы будем делать таких проверок множество и будем иметь контекст (if, when и т.п.).

S_S> А сам запутанный процесс типизации-раскрытия макросов, где макросы друг в друга вложены, перемешаны, повязаны связями, он как-то изменится? И как пострадают от этого возможности?

Если взять решение Вольфхаунда в исходном виде, то даже простенькие макросы будут напичканы тучей дублирующейся работы по типизации. Такие случаи как linq или типизация тела для foreach будут нарочито избыточными. Специйикация linq-а из C# 3.0 вообще таким образом повторить неудастся. Если только полностью сдублировать типизация развернутого выражения (так как linq — это чистый синтаксический сахар не имеющий своей семантики).

Выгода от предложенного Вольфхаундом подхода будет только для ДСЛ-ей обладающих свой семантикой.

И все это можно достичь смешением подхода — разрешением как типизации до раскрытия, так и после.

S_S> Если вопрос только в каком формате описывать констрейнты, то это, наверно, можно в любой момент безболезненно переписать,дополнить?

Самое смешное, что независимо от того когда производится типизация (до или после раскрытия макросов) сам механизм типизации будет единым.