Пожалуй что мое представление о том каким должен быть типизатор Н2 созрело и я могу им поделиться.

Некоторые предпосылки... из чего я исхожу...
1. Следует изобретать новые идеи только тогда когда старые не удовлетворяют требованиям и нет путей изменить это.
2. Создание макросов в Н2 должно упроститься и не в коем случае не усложняться. Ради упрощения создания сложных макросов нельзя жертвовать простотой написания простых.
3. Если есть выбор между декларативным описанием и кодом, то лучше предпочесть декларацию (К.О.).
4. Framework разрабатываемый в процессе работы над Н2 должен брать на себя максимум работы. Писатель макросов и создатель новых языков должен делать только необходимый минимум.
5. Поддержка IDE и бэкэндов должны даваться получаться автоматически, за исключением тех фич котоыре которые полностью зависят от языка (например, рефакторинги). Для зависящих от языка фич должны предоставляться стандартные решения упрощающих реализацию.

Для того чтобы было понятнее как проходит процесс типизации придется начать с парсинга. Итак синтаксический макрос Н2 будет описывать:
1. Правило грамматики разбирающее строку.
2. Ветку SST описывающую все данные разобранные из строки. По сути это будут отдельные вхождения вариантного типа + разная информация необходимая для работы IDE (о токенах, подсветке, фолдинге, ...).
3. Тело макроса, вызываемое для раскрытия макроса.
4. Необязательные декларации, описывающие требования к макросу и его параметрам.

Стадии работы:
1. Парсинг. На этой стадии файл проекта парсится макросами, которые загружаются для отдельных типов файлов и могут по ходу разбора кода подгружать дополнительные макросы в точки ресширения. В конце этого процесса мы получаем CompileUnit содержащий SST (Specific Syntax Tree) файла.
2. Производится раскрытие макросов уровня типов не требующих информации о типах. В результате получается набор TypeBuilder-ов (возможно их нужно назвать особо, но подходящее имя в голову не приходит) по одному для каждого типа. Это не окончательные TypeBuilder-ы, так как могут быть partial-типы. На этом этапе TypeBuilder-ы содержат только MemberBuilder-s – типы описывающие AST членов. Эти типы содержат SST тел и преобразованные в стандартное AST описание члена. Кроме того TypeBuilder и MemberBuilder могут содержать любую дополнительную информацию обеспечивающую их специализацию.
3. Производится слияние TypeBuilder-ов всего проекта и формирование дерева типов проекта. В результате получается дерево ветвями которого являются пространства имен, а листьями – TypeBuilder-ы и реализации ITypeInfo полученные из внешних сборок и других проектов.
4. Выполнятся макросы уровня типов не требующие информации о наследовании.
5. Производится предварительное вычисление наследования и реализации интерфейсов для TypeBuilder-ов.
6. Выполняются макросы которым требуется информация о наследовании, но не требуется информация о типах членов.
7. Производится связывание типов членом.
8. Производится разложение MemberBuilder-ов на MethodBuilder-ы. В конечном счете в исполнимом коде могут быть только функции. Значит все члены типов должны быть в итоге преобразованы в них. Например, свойства должны быть преобразованы в методы гетыры и/или сетеры.
8. Производится связывание типов сгенерированных методов.
9. Выполняются макросы которые зависят от типов членов.
10. Производится типизация тел методов. До этого момента в них находится SST, точнее корнем является AST-ветка-заглушка которая ссылается на SST. На выходе получается TAST. Кроме того в процессе работы генерируется AST. При этом в ветки SST помещается ссылки на сгенерированные по ним ветку AST и TAST.
11. Результат работы – TypeBuilder-ы, MethodBuilder-ы и TAST передается бэкэнду который по ним генерирует исполняемые модули в которые помещаются код и метаданные.

Описание процесса типизации тел методов привожу отдельно...

Типизация тел методов

Обратите внимание на то, что под термином «типизация» вы можете понимать нечто отличное от того что понимаю я!

Перед началом процесса типизации в методе (объекте MethodBuilder) присутствует информация о типах параметров и возвращаемого значения, название метода, кастом-атрибуты, модификаторы, (возможно) дополнительная информация и код тела метода в виде SST.

Процесс типизации тела метода:
1. Типизатор обрабатывает ветку AST метода одну за одной (начиная с корневой ветки ссылка на которую находится в MethodBuilder).
2. Если ветка является ссылкой на SST, то производится процесс раскрытия макроса.
3. Полученная в результате раскрытия ветка макроса анализируется и если это снова оказывается ссылка на SST, то выполнение продолжается с пункта 1.
4. Если текущая ветка не ссылка на SST, то вызывается функция трансформации AST в TAST. В процессе этой трансформации вычисляются типы AST, производится разрешение перегрузки и т.п. Кроме всего прочего ссылка на TAST помещается в AST, а ссылка на AST в SST. Таким образом, после окончания процесса типизации выражения, по SST можно получить порожденное по нему AST и TAST. Точно такие же ссылки помещаются и TAST, так что через любой вид деревьев можно получить связанные с ними другие виды деревьев.

В процессе типизации ветки AST получают ссылки на TAST и типы. Среди веток TAST могут быть неоднозначные ветки. Если в TAST имеются неоднозначные ветки, производится повторный проход по TAST и попытка разрешить неоднозначности. Если в процессе повторного прохода изменился список неоднозначностей, то производится еще одна попытка до тех пор, пока список неоднозначностей не станет пуст – что считается успешным завершением типизации, или пока список неоднозначностей не перестанет изменяться – что является ошибкой типизации. В процессе разрешения неоднозначностей одни ветки TAST могут заменяться на другие. Например, MemberAccess заменен на Overloaded, а Overloaded на Resolved.


Процесс раскрытия макроса:
1. SST-ветке может соответствовать более одного макроса (Н2 будет поддерживать перегрузку макросов по условиям), по этому процесс раскрытия макроса включает процесс разрешения перегрузки макроса.
2. Получается список макросов соответствующих раскрываемому SST.
3. Список сортируется по приоритетам и его элементы перебираются в порядке убывания приоритета.
4. Для каждого макроса проверяются декларативные условия. Если условие истинно, запускается макрос (раскрытие макроса). В ином случае производится проверка условия для следующего элемента списка.
5. Если макрос успешно раскрылся, перебор списка останавливается, а результат раскрытия возвращается процессу типизации. Если в процессе раскрытия макроса произошла ошибка, то результат раскрытия запоминается и процесс продолжается с пункта 4.
6. Если декларативные условия не были удовлетворены ни для одной перегрузки выдается сообщение об ошибке (которое может быть задана авторами макроса или сформирована на основе декларативных условий).
7. Если некоторые из макросов были запущены, но ни один из них не смог успешно раскрыться, то формируется ветка Ast.Errors() в которую помещается список сообщений об ошибках выданный обломавшимися макросами.

Примеры

Пример перегруженного макрос (foreach):

  macro ForEach : Ast.Expression
    syntax: "foreach" "(" pattern "in" collection ")" body
      where: pattern    = Ast.PatternWithGuard,
             collection = Ast.Expression,
             body       = Ast.Expression;
    require: collection.Type as X && !X.IsPrimitive
    require: X has <[ method GetEnumerator() : $E ]>
  {
    <[ /* реализация по умолчанию реализующая паттерн "перечислитель" */ ]>
  }

  // Перегрузка макры ForEach. 
  macro ForEachIEnumarableT overload ForEach
    require: collection.Type is IEnumarable[_]
    priority: < ForEach // Срабатывает только если не срабатывает основной вариант
  {
    <[ /* реализация для IEnumarable[T] */ ]>
  }
  ...
  // Где-то в другом месте... возможно в другой сборке...
  macro ForEachArray overload ForEach
    require: collection.Type is array[_]
    priority: > ForEachIEnumarableT // попытка раскрыть этот макрос будет предпринята перед ForEachIEnumarableT
  {
    <[ /* реализация для массива */ ]>
  }

Декларативные условия и порядок типизации

В макросах Н2 можно будет задать декларативные условия. Они позволяют описать зависимость макроса от типов выводимых для параметров макроса.

По умолчанию макрос получает на вход нетипизированное SST. Если макрос хочет чтобы ему на вход пришло типизированное SST для некоторого параметра, то он может задать условие (путем добавления секции «require»).

Минимальным условием является требование наличия выведенного типа. Это может выглядеть так:

require: collection.Type

Кроме того можно задать более конкретное условие, что тип должен быть фиксированным:

require: collection.Type is fixed

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

require: collection.Type is fixed[]

означает, что ожидается что выведен хотя бы сам тип, без учета параметров типов. «fixed» — это ключевое слово заменяющее любой имя типа.
Конструкция:

require: collection.Type is fixed[_]

означает, что должен быть выведен тип имеющий один параметр типа. Через запятую можно указывать нужное количество параметров типов.
Конструкция:

require: collection.Type is Name[_]

означает, что ожидается тип Name с одним параметром типов (вместо Name может быть подставлено любое имя типа, например IEnumarable). Аналогично fixed могут быть вариации с другим количеством параметров типов или без них.
Конструкция macroParameter.Type as Name позволяет задать имя для переменной типа. Далее в выражениях можно оперировать этим именем.
Так же в require могут использоваться операторы «&&» и «||», а так же произвольные выражения над типами (использующими API типов). Например, !X.IsPrimitive (из примера выше) означает, что тип не должен быть примитивным (например, int).
Так же возможно задавать условия на наличие у типа некоторых членов. Например:

X has <[ method GetEnumerator() : $E ]>

означает, что у типа X ожидается наличие метода GetEnumerator. Причем тип E можно в дальнешем использовать в рамках макроса или других условий. Например, мы можем проверить, что у типа E есть свойство Current:

E has <[ property Current : $D ]>

Если тип задан без $, то можно ссылаться на конкретные типы. При этом параметры типов так же могут быть переменными. Кроме того можно использовать «_» или ключевое слово fixed.

Условие

priority: < ИмяДругогоМакроса

позволяет задать приоритет относительно другого макроса. Это позволяет вызвать раскрытие данного макроса до или после того как будет произведена попытка раскрыть другой макрос.

Если в макросе задано условие на тип одного из параметров макроса, то компилятор вначале раскрывает и типизирует SST находящееся в этом параметре, а потом вызывает макрос передавая ему SST в котором имеется ссылка на AST и TAST, а поле Type содержит ссылку на выведенный тип.

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

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

Здравствуйте, VladD2.

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

Но вот мое предположение:

Не ограничиваться чисто макроссами. А сделать какойто-то тип элемента АСТ ктоторые будет служыть для росшырения

напр:

PExpr
{
Assign(left : PExpt, righr :PExpr);
//.....
Custom(custType : Tag, customData : object);

}

и потом в методах которые разбирают АСТ в случае обнаружения типа Custom вызвать обработчик в зависимости от тега ( а сами обработчики добавляются в систему во время подгрузи макро-сборки)

Таким образом макрос нижнего уровня не будет делать всю работу, а просто создаст кастомный тип элемента АСТ а потом на этапе типизации и возможно даже кодо-генерации будет вызван нужный обработчик. Без необходимости пилять напильником сам компилятор.

BM>Не ограничиваться чисто макроссами. А сделать какойто-то тип элемента АСТ ктоторые будет служыть для росшырения

BM>...Таким образом макрос нижнего уровня не будет делать всю работу, а просто создаст кастомный тип элемента АСТ а потом на этапе типизации и возможно даже кодо-генерации будет вызван нужный обработчик. Без необходимости пилять напильником сам компилятор.

Я мало чего понял из сказанного.

Попробую ответить... Макрос не будет раскрываться во время парсинга (никогда). Вместо этого часть макроса отвечающего за парсинг будет генерировать SST. Код раскрытия (т.е. код самого макроса) будет привязан к SST. Само же раскрытие будет производиться потом (в зависимости от стадии макроса и его типа). Например, макросы уровня выражения будут раскрываться в процессе типизации.

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

Любой макрос сможет в вернуть в результате своей работы АСТ содержащее обращение к другим макросам. Так что схема будет гибкой.

Для представления несинтаксических макросов в АСТ будет предусмотрена специальная ветка. Она будет похожа на предложенную тобой, но без object и другой грязи. Это будет ссылка на макрос и список его параметров.

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

VD>Для представления несинтаксических макросов в АСТ будет предусмотрена специальная ветка. Она будет похожа на предложенную тобой, но без object и другой грязи. Это будет ссылка на макрос и список его параметров.

Прикольно. А возможность расширить кодо-генерацию (плагин для бекенда) будет?

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

BM>Прикольно. А возможность расширить кодо-генерацию (плагин для бекенда) будет?

Бэкэнды и есть плагины. Их архитектура уже проблемы тех кто их будет писать.

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

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

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

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

WH>О... уже пошли уровни в TAST.

Они были с самого начала. Просто ты игнорируешь все что мешает построению твоей теории заговора.

WH>Что я тебе про иерархию языков говорил...
WH>Через полгода ты дойдешь до того что говорю я.
WH>А через год ты мне начнёшь доказывать, что все придумал ты.

У тебя проблемы с ЧСВ. Серьезные, такие.

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

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

ЗЫ

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

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

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

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

VD>Они были с самого начала. Просто ты игнорируешь все что мешает построению твоей теории заговора.
Начинаем тыкать носом:

TAST и AST не расширяемы. Точнее их можно расширять в процессе эволюционирования фрэймворка. Если у нас появляется язык который, например, для повышения производительности получаемого кода требует новую конструкцию, то мы посовещаемся и добавим новый подтипа TAST и/или AST.

(С)

Автор: VladD2
Дата: 24.05.11

VD>У тебя проблемы с ЧСВ. Серьезные, такие.
Это у тебя проблемы с памятью.

VD>Мне очень хотелось бы, чтобы ты отбросил ЧСВ, перестал вести учет того что и когда ты предложил,
Это очень трудно не делать особенно когда я тебе полгода вколачиваю в голову некоторую идею, а потом вдруг оказывается что ее придумал ты.

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

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

Пока всё обсуждение больше завёрнуто вокруг синтаксических макросов. Но ведь возможны и другие.

Допустим вот возникла идея создания макроса "dynamic-наоборот".

def f(o : dynamic)
{
  o.StringProp = "MaxValue = ";
  def max = Math.Max(o.Prop1 : int, o.Prop2 : int);
  Console.WriteLine(o.StringProp + max.ToString());
  o.Method(max);

  o.| //тут автокомплит показывает что o уже имеет StringProp, Prop1, Prop2 и Method(max : int) : void;
}

Ну а дальше по ситуации и воле разработчика. Например этот dynamic может создавать интерфейс IDynamic_f_o { String, Prop1, Prop2, Method }, а может просто записывать куда-нить в аттрибуты сигнатуру для o, чтобы давать по рукам если при использовании f(x) 'x' заведомо не поддерживает { String, Prop1, Prop2 }, и т.п.

Т.е. синтаксис не меняется ну совсем, а вот тип меняется с каждой операцией над o.

Как сейчас реализовать такое для N1 я примерно представляю (не уверен что получится, но хотя бы знаю куда копать). Но в Н2 типизация тел методов — это 10-й шаг, а для макросов такого вида может понадобиться возможность добавить на этом шаге в неймспейс свой генерённый TypeBuilder или ITypeInfo. А если кто-то захочет у себя отнаследоваться от IDynamic_f_o, то его наследование должно быть обработано только после типизации метода, потому что до того — самого IDynamic_f_o просто нету. А если макрос генерирует не IDynamic_f_o а допустим добавляет поля в существуюшую структуру, нужно ведь макро-аттрибуты этой структуры вызывать, например генераторы ISerializable или HashCode, только после того как поля добавятся.

В общем вопрос как такое, и другие "макросы виртуальных типов", например типизированные индесы массивов

Автор: hi_octane
Дата: 14.02.11

, впишутся в концепцию Н2? Будут ли стадии работы выполнятся циклически пока последнее SST не превратится в TAST?

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

VD>>Мне очень хотелось бы, чтобы ты отбросил ЧСВ, перестал вести учет того что и когда ты предложил,
WH>Это очень трудно не делать особенно когда я тебе полгода вколачиваю в голову некоторую идею, а потом вдруг оказывается что ее придумал ты.

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

Все кто следит за проектом видят и ценят твои предложения. Они действительно свежи и оригинальны. Кто не следит тому пофиг чьи они.

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

_>Пока всё обсуждение больше завёрнуто вокруг синтаксических макросов. Но ведь возможны и другие.

_>Допустим вот возникла идея создания макроса "dynamic-наоборот".

Обобщу, проблему составляют анонимные классы, создание вью-модели на лету, dynamic-наоборот.
Все подобные идеи сводятся к изобретению собственной структурной типизации и более глобальному выводу типов. Поскольку это фреймворк для языков, структурная типизация из коробки должна быть.

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

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

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

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

Автор: hi_octane
Дата: 14.02.11

, впишутся в концепцию Н2? Будут ли стадии работы выполнятся циклически пока последнее SST не превратится в TAST?
В концепцию Влада это не впишется никак.
В моей системе это будет из коробки. Причем что характерно я про такой вариант даже не думал. Просто изначально строил целостную и не противоречивую систему.

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

VD>>Да, и мне уже порядком осточертели твое наезды и хамство. Я стараюсь держаться, но желание вести беседу в подобном ключе стремительно улетучивается.
WH>Ты бы на себя посмотрел.

Я, как представитель коллектива разработчиков корпоративного софта, планирующий использование в будущем Nemerle для разработки софта, подумываю — а нужен ли мне Nemerle, если внутри коллектива творится такая грызня ?
Представляю, что не выносится на публику

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

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

Нормальный рабочий процесс поиска архитектурного решения

А>Я, как представитель коллектива разработчиков корпоративного софта, планирующий использование в будущем Nemerle для разработки софта, подумываю — а нужен ли мне Nemerle, если внутри коллектива творится такая грызня ?
А>Представляю, что не выносится на публику

Не парься Процесс спора двух умных людей, даже если они время от времени переходят на личности, намного более продуктивен чем если бы один из них был начальником, навыдумывал себе чего-то, а потом выставил другому таску "делай как я сказал, и без самодеятельности". Так что как представитель коллектива разработчиков успешно использовавший ещё Nemerle 1 для разработки софта, могу тебя заверить, что повод для меланхолии ваш коллектив выбрал совершенно надуманный

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

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

Коллектив в настоящий момент насчитывает свыше 30 участников, из которых около десятка принимают активное в развитии проекта прямо сейчас. То, что между некоторыми из них периодически возникают трения и конфликты — совершенно нормальное и ожидаемое явление, было бы странно, если бы их не возникало. Для проекта важно не столько то, что происходит и как происходит, сколько что получается на выходе. Однажды, на выходе после точно такого же спора получился Nemerle.Peg...

Ты лучше представь, какой rocket science тут начнется, когда они наконец найдут общий язык

WH>В моей системе это будет из коробки. Причем что характерно я про такой вариант даже не думал. Просто изначально строил целостную и не противоречивую систему.
А как? И как твоя система справится если макросы взаимно перевязаны, например функция f(o : dynamic) : IEnumerable[o:dynamic] где внутри макрос yield генерит стэйт-машину для ещё не до конца сгенерированного типа описывающего 'o'?

Короче можно какой-то список шагов, как у Влада, пройдя который мы сможем гарантировать что тип выведен, все макросы отработали, можно генерить MSIL? Пусть даже пока и без особенностей синтаксиса отдельных макросов.

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

_>Как сейчас реализовать такое для N1 я примерно представляю (не уверен что получится, но хотя бы знаю куда копать). Но в Н2 типизация тел методов — это 10-й шаг, а для макросов такого вида может понадобиться возможность добавить на этом шаге в неймспейс свой генерённый TypeBuilder или ITypeInfo. А если кто-то захочет у себя отнаследоваться от IDynamic_f_o, то его наследование должно быть обработано только после типизации метода, потому что до того — самого IDynamic_f_o просто нету. А если макрос генерирует не IDynamic_f_o а допустим добавляет поля в существуюшую структуру, нужно ведь макро-аттрибуты этой структуры вызывать, например генераторы ISerializable или HashCode, только после того как поля добавятся.

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

Автор: hi_octane
Дата: 14.02.11

, впишутся в концепцию Н2? Будут ли стадии работы выполнятся циклически пока последнее SST не превратится в TAST?

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

А если раскрывать такие макросы не во время типизации тел методов, а раньше? Раскрываем (фактически это и есть выполнеие макроса) на более раннем этапе, а типизируем сформированное макросом выражение уже когда сформировано дерево для всего проекта. По моему вопрос двух(или более)-фазной работы макросов здесь уже обсуждался. Эти идеи не вошли в N2?

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

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

_>>Как сейчас реализовать такое для N1 я примерно представляю (не уверен что получится, но хотя бы знаю куда копать). Но в Н2 типизация тел методов — это 10-й шаг, а для макросов такого вида может понадобиться возможность добавить на этом шаге в неймспейс свой генерённый TypeBuilder или ITypeInfo. А если кто-то захочет у себя отнаследоваться от IDynamic_f_o, то его наследование должно быть обработано только после типизации метода, потому что до того — самого IDynamic_f_o просто нету. А если макрос генерирует не IDynamic_f_o а допустим добавляет поля в существуюшую структуру, нужно ведь макро-аттрибуты этой структуры вызывать, например генераторы ISerializable или HashCode, только после того как поля добавятся.

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

Автор: hi_octane
Дата: 14.02.11

, впишутся в концепцию Н2? Будут ли стадии работы выполнятся циклически пока последнее SST не превратится в TAST?

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

S>А если раскрывать такие макросы не во время типизации тел методов, а раньше? Раскрываем (фактически это и есть выполнеие макроса) на более раннем этапе, а типизируем сформированное макросом выражение уже когда сформировано дерево для всего проекта. По моему вопрос двух(или более)-фазной работы макросов здесь уже обсуждался. Эти идеи не вошли в N2?

А какие ограничения есть объединение всех стадий в одну?
почему не проводить все вместе по мере возможности?

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

_>А как? И как твоя система справится если макросы взаимно перевязаны, например функция f(o : dynamic) : IEnumerable[o:dynamic] где внутри макрос yield генерит стэйт-машину для ещё не до конца сгенерированного типа описывающего 'o'?
Такого не будет.
Я изначально предлагаю типизировать код до того как начнутся преобразования.
Соответственно мы просто описываем связи между типами и узлами АСТ.
Далее просто запускается алгоритм вывода типов, который на основе описанных для каждого куска АСТ правил выводит все типы.
Понижение уровня языка начинается уже после того как все типы выведены.

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

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

_>>А как? И как твоя система справится если макросы взаимно перевязаны, например функция f(o : dynamic) : IEnumerable[o:dynamic] где внутри макрос yield генерит стэйт-машину для ещё не до конца сгенерированного типа описывающего 'o'?
WH>Такого не будет.
WH>Я изначально предлагаю типизировать код до того как начнутся преобразования.
WH>Соответственно мы просто описываем связи между типами и узлами АСТ.
WH>Далее просто запускается алгоритм вывода типов, который на основе описанных для каждого куска АСТ правил выводит все типы.
WH>Понижение уровня языка начинается уже после того как все типы выведены.

Я правильно понимаю, что ты предлагаешь типизировать результат раскрытия макроса только на основании информации о его констрейнтах (правилах), не принимая во внимание информацию из "внешней" части ast?

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

S>А если раскрывать такие макросы не во время типизации тел методов, а раньше? Раскрываем (фактически это и есть выполнеие макроса) на более раннем этапе, а типизируем сформированное макросом выражение уже когда сформировано дерево для всего проекта.

Понял, что для работы макроса может понадобиться информация о типе, поэтому раскрыть его до типизаци нельзя. Например это может быть макрос, производящий маппинг датаридеров на объекты. Может на самом деле выделять в макросе участки, отрабатывающие на разных фазах компиляции? Как бонус, в режиме IDE часть фаз вообще можно будет не запускать. Что то вроде rewrite WolfHound-а, но более многоуровневый.

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

S>Я правильно понимаю, что ты предлагаешь типизировать результат раскрытия макроса только на основании информации о его констрейнтах (правилах), не принимая во внимание информацию из "внешней" части ast?
Правила могут ссылаться на "внешний" АСТ.
Без этого вообще ничего типизировать нельзя.

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

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

S>Что то вроде rewrite WolfHound-а, но более многоуровневый.
Мой rewrite многоуровневый что звездец.
Он понижает уровень языка. А дальше будут вызваны переписыватели для языка более низкого уровня, которые понизят уровень языка еще сильнее и так пока не будет получен код на целевом языке.

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

А>Представляю, что не выносится на публику

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

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

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

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

S>>Я правильно понимаю, что ты предлагаешь типизировать результат раскрытия макроса только на основании информации о его констрейнтах (правилах), не принимая во внимание информацию из "внешней" части ast?
WH>Правила могут ссылаться на "внешний" АСТ.
WH>Без этого вообще ничего типизировать нельзя.

А можно пример ссылки на внешний AST?
И как будет типизовываться такая конструкция:

def x = macro(a);

где macro() раскрывается в
<[ another_macro(a) ]>

а another_macro() в свою очередь раскрывается в a.ToString()? ведь пока не раскроются macro и another_macro тип x не может быть определен. Тут нужно или описывать возвращаемый another_macro тип в его констрейнтах, либо раскрыать его до типизации.

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

S>а another_macro() в свою очередь раскрывается в a.ToString()? ведь пока не раскроются macro и another_macro тип x не может быть определен. Тут нужно или описывать возвращаемый another_macro тип в его констрейнтах, либо раскрыать его до типизации.
Остается выяснить, какую задачу ты решаешь.
Судя по названию макросов никакую.

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

_>>А как? И как твоя система справится если макросы взаимно перевязаны, например функция f(o : dynamic) : IEnumerable[o:dynamic] где внутри макрос yield генерит стэйт-машину для ещё не до конца сгенерированного типа описывающего 'o'?
WH>Такого не будет.
WH>Я изначально предлагаю типизировать код до того как начнутся преобразования.

Т.е. ты предлагаешь разделить преобразования типов и преобразования кода на разные, возможно даже независимые, стадии. Значит каждый макрос должен содержать минимум две программы (декларативные или императивные — сейчас не важно): 1) это преобразование типов; 2) это реврайтинг кода с уже зафиксированными типами, так? А некий тайпер довывыводит то чего нехватает между этими стадиями?

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

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

S>>а another_macro() в свою очередь раскрывается в a.ToString()? ведь пока не раскроются macro и another_macro тип x не может быть определен. Тут нужно или описывать возвращаемый another_macro тип в его констрейнтах, либо раскрыать его до типизации.
WH>Остается выяснить, какую задачу ты решаешь.
WH>Судя по названию макросов никакую.

WH>Ты пойми, я не собираюсь делать систему, в которой можно делать какие угодно выкрутасы.
WH>Я хочу сделать систему для решения практических задач.
WH>И ты не придумаешь ни одной практический задачи, в которой нельзя описать правила типизации АСТ.

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

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

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

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

_>Т.е. ты предлагаешь разделить преобразования типов и преобразования кода на разные, возможно даже независимые, стадии. Значит каждый макрос должен содержать минимум две программы (декларативные или императивные — сейчас не важно):
3.
Парсинг. Типизация. Понижение уровня языка.

_>1) это преобразование типов; 2) это реврайтинг кода с уже зафиксированными типами, так? А некий тайпер довывыводит то чего нехватает между этими стадиями?
Не очень понял что за "преобразование типов".
Смысл в том, что после парсинга запускается типизатор который на основе правил описанных для АСТ произведет всю типизацию всего кода.

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

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

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

С этим я не спорю. Данные есть, но где будет располагаться логика, выводящая тип по этим данным? В самом макросе? В компиляторе? Он может не иметь представления о семантике макроса.

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

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

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

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

_>Допустим вот возникла идея создания макроса "dynamic-наоборот".

_>

_>def f(o : dynamic)
_>{
_>  o.StringProp = "MaxValue = ";
_>  def max = Math.Max(o.Prop1 : int, o.Prop2 : int);
_>  Console.WriteLine(o.StringProp + max.ToString());
_>  o.Method(max);

_>  o.| //тут автокомплит показывает что o уже имеет StringProp, Prop1, Prop2 и Method(max : int) : void;
_>}
_>

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

Я бы предложит тут другое решение:

def f(o : dynamic[IFakeInterface])
{
  o.StringProp = "MaxValue = ";
  def max = Math.Max(o.Prop1 : int, o.Prop2 : int);
  Console.WriteLine(o.StringProp + max.ToString());
  o.Method(max);

  o.| //тут автокомплит показывает что o уже имеет StringProp, Prop1, Prop2 и Method(max : int) : void;
}

IFakeInterface — это интерфейс привязываемый к динамику только для целей поддержки интелисенса. В рантайме будет данимическая диспетчеризация.

Что же касается поддержки массивов с типизированными индексерами, то мне кажется тут лучше всего подошел бы класс-обертка, а не навороты на макросах.

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

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

Очень часто данных у тебя не будет. Я уже устал повторять христоматийные примеры: linq, foreach, ... В них конкретные типы зависят от того во что макрос раскрывается. Это прямо в спецификацию C# записано.

Сколтько можно игнорировать факты и упираться рогом в стену?

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

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

На самом деле новые типы не могут влиять на старые, так как старые формировались когда они отсутствовали. Новые типы как бы дополняют систему. Если бы это было не так, то в Н1 нельзя было бы добавить типы на поздних стадиях компиляции. А это сделать можно.

S>А если раскрывать такие макросы не во время типизации тел методов, а раньше? Раскрываем (фактически это и есть выполнеие макроса) на более раннем этапе, а типизируем сформированное макросом выражение уже когда сформировано дерево для всего проекта. По моему вопрос двух(или более)-фазной работы макросов здесь уже обсуждался. Эти идеи не вошли в N2?

Есть только одна проблема — тела методов во время работы IDE могут типизироваться многократно и в хаотическом порядке. Это делает сложным добавление типов из процесса раскрытия (или типизации) макросов внутри тел методов.

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

VD>Очень часто данных у тебя не будет. Я уже устал повторять христоматийные примеры: linq, foreach, ... В них конкретные типы зависят от того во что макрос раскрывается. Это прямо в спецификацию C# записано.
А уже устал повторять, что вся информация есть.

VD>Сколтько можно игнорировать факты и упираться рогом в стену?
Вот. Вот.
Перестань упираться рогом в стену и прекрати нести пургу.
Самому же потом стыдно будет, когда это все заработает.

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

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

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

Это заблуждение. На самом деле бывает по разному. Макросы вроде linq нельзя раскрывать после типизации, так как типизация возможна только на раскрытом представлении. Почитай спецификацию C#. Там ясно сказано, что семантика linq-запросов выражается исключительно через нетипизированное переписывание в query-паттерн.

Иногда наличие типов для отдельных параметров макроса является необходимым. Но это далеко не частый случай.

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

VD>>Они были с самого начала. Просто ты игнорируешь все что мешает построению твоей теории заговора.
WH>Начинаем тыкать носом:

Перестань хамить.

WH>

WH>TAST и AST не расширяемы. Точнее их можно расширять в процессе эволюционирования фрэймворка. Если у нас появляется язык который, например, для повышения производительности получаемого кода требует новую конструкцию, то мы посовещаемся и добавим новый подтипа TAST и/или AST.

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

Я для себя до сих пор не решил нужно ли заводить разные типы для TAST или можно свалить все в один тип, и программно контролировать отсутствие неких конструкций после преобразования (как это сделано в Н1).

VD>>Мне очень хотелось бы, чтобы ты отбросил ЧСВ, перестал вести учет того что и когда ты предложил,
WH>Это очень трудно не делать особенно когда я тебе полгода вколачиваю в голову некоторую идею, а потом вдруг оказывается что ее придумал ты.

Я бы описал ситуацию с точностью до наборот. Вот как-то (месяца три назад) я тебе подсунул идею использования Pratt-а, а через месяц ты меня задолбал объяснением того, что ты это все придумал.

Причем, мне в общем-то по фигу. Но вот это вот постоянная заносчивость действительно напрягает.

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

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

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

VD>>Да, и мне уже порядком осточертели твое наезды и хамство. Я стараюсь держаться, но желание вести беседу в подобном ключе стремительно улетучивается.
WH>Ты бы на себя посмотрел.

Я пытаюсь быть с тобой максимально корректным.

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


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

Проблема в том, что ты достал подчеркиванием свой значимости. Ziwa совершенно прав. Мы в целом, и я в частности высоко ценим твое мнение и с интересом рассматриваем твои предложения, когда они четко сформулированы и не имеется веских аргументов против.

WH>И что я бы до этого никогда не додумался.

Это уже какие-то совершенно не понятные домыслы. Мне по барабану додумается кто-то до чего-то или нет. Если идея здравая, я ее рассматриваю и пытаюсь адаптировать к проекту в целом. Если нет — высказываю критику.

Если бы ты был конструктивен, то вместо того чтобы постоянно якать (Это придумал я! Тебя надо тыкать носом! Ты будешь говорить что это твои идеи!...) лучше бы реагировал на критику своих идей.

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

Вот такие идеи нам не нужны. Твое поведение не конструктивно. Идеи нужно не только генерировать, но отстаивать и развивать.

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

А>Я, как представитель коллектива разработчиков корпоративного софта, планирующий использование в будущем Nemerle для разработки софта, подумываю — а нужен ли мне Nemerle, если внутри коллектива творится такая грызня ?
А>Представляю, что не выносится на публику

На самом деле не на публике разговоры обычно спокойнее. Просто товарищ решил использовать форум для логирования обсуждения, так как боится что кто-то забудет об авторстве его идеи типизации до раскрытия макросов (которая до него была озвучена в ряде работ, например xoc).

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

Z>так уж сложилось, что немного грубости в рсдн дискуссиях — норма.

Надо как-то с этим бороться. А то что-то ее многовато. Плюс троли совсем распоясались.

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

VD>Я бы описал ситуацию с точностью до наборот. Вот как-то (месяца три назад) я тебе подсунул идею использования Pratt-а, а через месяц ты меня задолбал объяснением того, что ты это все придумал.
Я придумал то, как скрестить ПЕГ с Праттом.
А ты очень долго мне объяснял, что это не возможно и нахрен никому не нужно. Ибо все могут ручками по распарсенному пробежаться и все что нужно получить.
А потом заявил что я бы без тебя не смог парсер оптимизировать

VD>Сейчас вот я тебе уже неделю пытаюсь доходчиво и спокойно объяснить, что полная предварительная типизация — это плохая идея, так как она зачастую просто избыточна, а иногда невозможна, так как семантика изначально задумывалась в терминах переписывания кода (является чистым синтаксическим сахаром). Но ты по прежнему упирашся рогом, не признаешь очевидного и постоянно терроризируешь меня своим "тыканьем носом" (попросту говоря — хамством).
Про соединения ПЕГа с праттом ты мне тоже самое говорил.
А до этого пытался убедить в том, что 2-3 деревья фигня и нужно обязательно делать RB дерево. При этом еще предлагал использовать кортежи, которые тормозят.
История повторяется в очередной раз.

VD>Я тебя понял. Идея типизации по SST придумана сильно раньше чем ты до нее дошел.
Я до нее дошел, когда начал вопросом интересоваться.
Просто раньше я не знал, как это сделать. А теперь знаю.

VD>Я ее видел и долго обдумывал возможность ее применения. В результате я пришел к выводу, что в чистом виде она не работает.
Поправка: Ты не смог придумать алгоритм, который будет работать.

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

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

VD>На самом деле не на публике разговоры обычно спокойнее. Просто товарищ решил использовать форум для логирования обсуждения, так как боится что кто-то забудет об авторстве его идеи типизации до раскрытия макросов (которая до него была озвучена в ряде работ, например xoc).
Ты опять передергиваешь.
Эта идея столь очевидна что на ней можно ставить "(С)КО".
Я логирую это обсуждение для того чтобы ты потом не заявил мне что ты всегда говорил что типизация АСТ хорошая идея.

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

WH>>И что я бы до этого никогда не додумался.
VD>Это уже какие-то совершенно не понятные домыслы.
Кто там мне втирал, что я никогда бы не додумался использовать в ПЕГ парсере один инт для всего?
Особенно учитывая то, что я это и придумал.

VD>Вот такие идеи нам не нужны. Твое поведение не конструктивно. Идеи нужно не только генерировать, но отстаивать и развивать.
Неконструктивно твое поведение.
Ты постоянно говоришь мне, чтобы я не изобретал алгоритмы.
Потом говоришь: ВАУ! Какой классный алгоритм!
А потом я всегда говорил что так и надо, а ты тут вообще не причем.
ДОСТАЛ!
Я теперь ВСЕ логировать буду.

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

VD>>Очень часто данных у тебя не будет. Я уже устал повторять христоматийные примеры: linq, foreach, ... В них конкретные типы зависят от того во что макрос раскрывается. Это прямо в спецификацию C# записано.
WH>А уже устал повторять, что вся информация есть.

Это треп. Пустой и бесполезный. Тебе еще раз привести цитату из спецификации linq?

Как говорится — show me code!

VD>>Сколтько можно игнорировать факты и упираться рогом в стену?
WH>Вот. Вот.
WH>Перестань упираться рогом в стену и прекрати нести пургу.
WH>Самому же потом стыдно будет, когда это все заработает.

Да где же я упираюсь то? Я всего лишь прошу тебя описать то как ты будешь реализовывать спецификацию C# 3.0.

WH>И что характерно ты точно также упирался рогом, когда я алгоритм парсинга изобретал.

Я! Я! Я! Тебе не стыдно?

Я тебе напомню как дело было. Ты пришел с идеей использовать PEG и Пакрат как алгорит его разбора. Оценив Пакрат я тебе сразу сказал, что это не приемлемо по производительности. Ты поупирался, но в итоге выкинул его и начал оптимизировать обычный алгоритм рекурсивного спуска. Точно так же ты долго упирался с применением ДКА, в итоге таки реализовал его.
Если бы ты еще не отбросил идею создания списка возможных начальных символов для правила и проверку их до входа в правило, то глядишь мы еще процентов 10-20 отиграли.

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

О таких мелочах, как предложение использовать один int вместо двух переменных из оригинального Пакрата, ты уже целиком и полоностью забы. О том что скорость C#-пного парсера в значительной степени является заслугой Хардкейса ты даже и не думал.

Но, зато, от тебя постоянно слышно "Я! Я! Я!". Слово мы тебе похоже не знакомо.

Кстати, код порождаемый PegGrqammar-ом очень далек от совершенства. Там еще очень много можно (и нужно) оптимизировать. Достаточно взглянуть на результат декомпилятором, чтобы это стало очевидно.

ЗЫ

Мне по фигу кто какие иди предложил. Меня интересует результат. Я за свои идеи не держусь. Идеи — это не самоцель. Это всего лишь средство к достижению цели. А цель у меня одна — создать удобный, легко расширяемый, переносимый на другие платформы и мощный язык программирования. Язык который можно было бы расширять без приседаний и геморроя.

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

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

WH>>У нас на входе макроса есть все данные, чтобы вывести тип.

VD>Очень часто данных у тебя не будет. Я уже устал повторять христоматийные примеры: linq, foreach, ... В них конкретные типы зависят от того во что макрос раскрывается. Это прямо в спецификацию C# записано.

VD>Сколтько можно игнорировать факты и упираться рогом в стену?

Ты можешь хоть обставиться минусами, если у тебя нет чего сказать — это ничего не изменит.

Тебе предъявили факты которые ломают твою стройную систему. Тебе придется или менять свою систему, или отказываться от нее. Третьего не дано.

И вот когда ты будешь менять свою систему (адаптировать ее к реалиям мира), ты вспомни свои наезды в мой адрес.

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

VD>Это треп. Пустой и бесполезный. Тебе еще раз привести цитату из спецификации linq?
Да хоть заприводись.
У нас есть ссылка на объект.
По ней мы можем получить тип этого объекта.
У типа этого объекта мы можем получить методы с соответствующим именем.
Далее мы можем разрешить перегрузку.

Типизация линка ничем. ПОВТОРЯЮ АБСОЛЮТНО НИЧЕМ не отличается от типизации точки.
Но ты продолжаешь махать линком и даже не замечаешь что в спецификации типизация линка фактически сводится к типизации точки.
Разница лишь в том что в линке имена методов захардкожены.

Короче повторяю в пятисотый раз: У меня нет проблем с линком. У меня проблемы с поиском имен. Причем даже не проблемы, а просто слишком много вариантов того как это можно реализовать.

Я сейчас думаю над формализаций областей видимости и организации поиска имен.

VD>Я тебе напомню как дело было.
Я теперь все логировать буду

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

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

VD>>Я бы описал ситуацию с точностью до наборот. Вот как-то (месяца три назад) я тебе подсунул идею использования Pratt-а, а через месяц ты меня задолбал объяснением того, что ты это все придумал.
WH>Я придумал то, как скрестить ПЕГ с Праттом.

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

Якать то чего? Ты придумал как Пратт связать с Пегом. Я нашел этот самый всеми забытый Пратт и предложил скрестить его с ПЕГ-ом. В сумме мы молодцы.

WH>А ты очень долго мне объяснял, что это не возможно и нахрен никому не нужно.

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

WH>Ибо все могут ручками по распарсенному пробежаться и все что нужно получить.
WH>А потом заявил что я бы без тебя не смог парсер оптимизировать

У тебя какие-то необоснованные фантомные страхи. Я знаю, что ты хороший программист. Любой хороший программист может оптимизировать программу.

Но как это соотносится с обоснованиями идей?

WH>Про соединения ПЕГа с праттом ты мне тоже самое говорил.

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

Автор: VladD2
Дата: 09.02.11

тему создавал?

WH>А до этого пытался убедить в том, что 2-3 деревья фигня и нужно обязательно делать RB дерево. При этом еще предлагал использовать кортежи, которые тормозят.

Я никогда не убеждал тебя, что 2-3. Я тебе только пытался донести мысль о том, что они не дадут зримого ускорения компилятора. И то что я не хочу заниматься их реализаций. В результате так и вышло. Ты заменил реализацию на 2-3, но компиляция не ускорилась ни на йоту.

WH>История повторяется в очередной раз.

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

А уже устал повторять, что вся информация есть...
Начинаем тыкать носом:...
Это у тебя проблемы с памятью...
Я знал все что ты напишешь еще до того как ты это написал...
В моем варианте у компилятора всегда есть вся информация...
Он знает все типы...

Ну, кому интересна эта пурга? Тебя просят привести пример того как ты будешь решать реальные задачи. Видел я примеры приводил? Вот что-то вроде этого. С обоснованиями и комментариями. Так чтобы было понятно откуда таки взялись типы, которые "есть".

Ты вот привел пример простого if-а, и оказалось, что он во много раз сложнее того что было в Н1. Возникает резонный вопрос, если сложным стало простое, то насколько должно будет усложниться сложное? И мне не надо ответа в стиле "все будет просто". Мне нужна демонстрация. Так чтобы было что осмысливать, и если что, критиковать.

VD>>Я тебя понял. Идея типизации по SST придумана сильно раньше чем ты до нее дошел.
WH>Я до нее дошел, когда начал вопросом интересоваться.
WH>Просто раньше я не знал, как это сделать. А теперь знаю.

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

VD>>Я ее видел и долго обдумывал возможность ее применения. В результате я пришел к выводу, что в чистом виде она не работает.
WH>Поправка: Ты не смог придумать алгоритм, который будет работать.

Ну, да я не смог. Ты же просто воздух сотрясаешь.

Заметь, ты 3 месяца не можешь реализовать интеграцию Пратта в ПЕГ. А там алгоритм, с твоих же слов, очень простой ведь. А тут ты рассуждаешь о сложнейшем алгоритме вывода типов. У тебя его тоже нет. Есть только общие мысли не учитывающие кучи деталей. А что, как известно, кроется именно в них.

VD>>Ты пока что не занимался глубоким анализом, от того и думаешь, что все будет шоколадно. Если бы ты просто потрудился рассмотреть все аспекты, то наверняка согласился бы со мной.
WH>В том то и дело что занимался.
WH>У меня остался всего один пробел.

Ты очень наивен. Я еще раз предлагаю тебе привести пример макроса типизирующий упрощенный линк (from x in xs where x.Test()).

WH>Формализация поиска имен.

В чем тут проблема? Ты и это предлагаешь на плечи прикладников возложить?

WH>Но интуитивно понятно, что это вопрос техники и ничего принципиально невозможного тут нет.
WH>Когда я с ней закончу я тебе нарисую все твои "невозможные" примеры на раз-два.

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

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

WH>Я логирую это обсуждение для того чтобы ты потом не заявил мне что ты всегда говорил что типизация АСТ хорошая идея.

Это как это? Я именно за эту идею и выступал всегда. А ты перелагаешь всегда типизировать SST.

Более того, я в общем-то не против возможности типизации SST. Но как необязательной возможности, а не как единственной.

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

WH>Кто там мне втирал, что я никогда бы не додумался использовать в ПЕГ парсере один инт для всего?

Не знаю. Я тебе всего лишь предложил это сделать. А додумался бы ты до этого или нет мне все равно.

WH>Особенно учитывая то, что я это и придумал.

Это не правда, так что учитывать мы это не будет .

ЗЫ

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

В следующий раз отвечу только на сообщение содержащее пример реализации linq и foreach с подробным объяснением происходящего. До тех пор считаю твою идею нежизнеспособной в чисто виде.

Здравствуйте, VladD2, Вы писали:
VD>Бэкэнды и есть плагины. Их архитектура уже проблемы тех кто их будет писать.

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

А теоретически возможно так внедриться в этот механизм, чтобы, скажем, получить перобразованное TAST в котором паттерн матчинг уже заменен на if'ы , но yield'ы (в том смысле как в C#) еще не раскрыты? Или там получится путаница с уровнями, с порядком раскрытия макросов, или чем-то подобным?
Чтобы это TAST преобразовать (заменить другое) и передать дальше.

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

VD>>Это треп. Пустой и бесполезный. Тебе еще раз привести цитату из спецификации linq?
WH>У нас есть ссылка на объект.

Нет никаких ссылок ни на какие объекты. Есть выражение "from x in xs select x.Test()". Для того чтобы правильно вычислить тип x надо подставить его в выражение xs.Select(x => x.Test()) и типизировать его по правилам языка. Только после этого можно будет сказать какой реально тип у "x". При этом должны учитываться такие вещи как наличие в xs реализации Select с подходящей сигнатурой, наличие открытых пространств имен открывающих методы расширения. То какая из перегрузок Select будет выбрана типизатором влияет на тип x. Например, может иметься перегрузка Select оперирующая с деревьями выражений. Это приведет к тому, что "x" станет не переменной, а частью дерева выражений. Плюс в дело могут вмешаться такие вещи как неявное приведение типов. Это тоже надо учитывать. В итоге, если попытаться выполнить всю эту работу, то получится, что ты повторишь все действия что производятся при типизации переписанного кода. А зачем это надо, если можно просто переписать код и произвести его типизацию? Ведь она уже есть.

WH>По ней мы можем получить тип этого объекта.

Не можем. У нас есть только имя. И еще у нас есть код x.Test() который так же зависит от наличия имеющихся перегрузок метода Select, и от того какую из перегрузок выберет типизатор.

Повторять эту работу просто глупо.

WH>У типа этого объекта мы можем получить методы с соответствующим именем.
WH>Далее мы можем разрешить перегрузку.

Какую такую перегрузку? Напомню — ты предлагаешь типизировать SST. В SST нет даже вызова методов! В нем есть синтаксическая конструкция запроса. Макрос получит на входе всего лишь параметры содержащие имена и нетипизированные выражения.

WH>Типизация линка ничем. ПОВТОРЯЮ АБСОЛЮТНО НИЧЕМ не отличается от типизации точки.

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

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

WH>Но ты продолжаешь махать линком и даже не замечаешь что в спецификации типизация линка фактически сводится к типизации точки.

Ага. Продолжаю. Потому что это приговор твоему подходу. И всем это будет очевидно как только ты начнешь писать код.

WH>Разница лишь в том что в линке имена методов захардкожены.

Как ты там говоришь? Сейчас я буду тыкать тебя носом! Вроде так?
В твоем подходе нет методов. Методы — это сущности более низкоуровневого языка. А ты хочешь типизировать до разложения.
Иначе чем это все будет отличаться от тупого раскрытия макроса без анализа типов и последующей типизации?

WH>Короче повторяю в пятисотый раз: У меня нет проблем с линком. У меня проблемы с поиском имен. Причем даже не проблемы, а просто слишком много вариантов того как это можно реализовать.

У тебя есть одни слова. Из них каши не сваришь.

Я же прелагаю не переваливать на прикладников задачи типизации и поиска имен. Это слишком сложные задачи. Можно дать прикладникам возможность типизировать SST в тех случаях когда это упрощает решение задачи. Для этого практически и делать то ничего не придется. Только предоставить АПИ. Это и сейчас можно делать.

WH>Я сейчас думаю над формализаций областей видимости и организации поиска имен.

Это по любому полезная работа. Давай! Но проблем с линком это не решает.

VD>>Я тебе напомню как дело было.
WH>Я теперь все логировать буду

Давай! Только не интерпретируй по своему . ОК?

VD>>По сему я рассматриваю все идеи критически. Мне интересны не сами идеи, а идеи в разрезе конечной цели. Так что если ты что-то предлагаешь, то будь готов защищать свои идеи, и изменять их, если они не вписываются в общие задачи.
WH>А критики не было.

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

WH>Есть упертая вера в то, что это сделать нельзя.

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

Что-то в твоей идее, несомненно, есть. Но проблем куда больше.

WH>Все мои объяснения, почему это сделать можно проигнорированы.

Да нет никаких обяснений. Ты путаешь свои голословные заявления с объяснениями. Объяснением могла бы быть демонстрация макроса linq-а и foreach с описанием происходящего. А фразы вроде "В моем варианте у компилятора всегда есть вся информация." это не более чем сотрясение воздуха. Они ровным счетом ничего не значат.

WH>Уверен аргументы из этого сообщения ты также не воспримешь.

Аргументы? Нет, конечно! Их попросту нет. Ты же не глупый человек и должен понимать чем аргумент отличается от голословных заявлений.

Пока что ты демонстрируешь не аргументы, а веру. А я в веру не верю .

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

VD>Это как это? Я именно за эту идею и выступал всегда. А ты перелагаешь всегда типизировать SST.
Это все из-за твоей левой терминологии.

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

S_S> А теоретически возможно так внедриться в этот механизм, чтобы, скажем, получить перобразованное TAST в котором паттерн матчинг уже заменен на if'ы , но yield'ы (в том смысле как в C#) еще не раскрыты? Или там получится путаница с уровнями, с порядком раскрытия макросов, или чем-то подобным?
S_S>Чтобы это TAST преобразовать (заменить другое) и передать дальше.

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

Бэкэнд волен вызывать те преобразователи которые он считает нужным.

Вклиниться между этими вызовами, несомненно, будет можно.

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

В общем, это уже слишком глубокие детали, чтобы на них можно было ответить точно.

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

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

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

Автор: VladD2
Дата: 09.02.11

тему создавал?
Вот сам эту тему и прочитай.
Что ты там мне про Пратт "сбоку" говорил...

VD>Ты вот привел пример простого if-а, и оказалось, что он во много раз сложнее того что было в Н1. Возникает резонный вопрос, если сложным стало простое, то насколько должно будет усложниться сложное? И мне не надо ответа в стиле "все будет просто". Мне нужна демонстрация. Так чтобы было что осмысливать, и если что, критиковать.
Я привел набросок без грамма сахара.
Можешь посмотреть на обновленный вариант

Автор: WolfHound
Дата: 02.06.11

.

VD>Проблема в том, что ты и сейчас не знаешь как это сделать. То что ты предлагаешь вызывает много вопросов. Но ты упорно их игнорируешь.
Это ты упорно игнорируешь ответы.

VD>Заметь, ты 3 месяца не можешь реализовать интеграцию Пратта в ПЕГ. А там алгоритм, с твоих же слов, очень простой ведь.
Мне просто лень это делать.

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

VD>Ты очень наивен. Я еще раз предлагаю тебе привести пример макроса типизирующий упрощенный линк (from x in xs where x.Test()).
Я абсолютно реалистичен.
Все что мне нужно это механизм поиска имен.
Его я пока не формализовал.

VD>В чем тут проблема? Ты и это предлагаешь на плечи прикладников возложить?
В простых случаях это будет не надо. Но для чего-то более сложного чем if он и так на их плечах.
Вон в том же PegGrammar приходится имена искать.
Жутким императивным кодом, между прочим.

VD>ОК, с нетерпением жду. За одно подумай нед тем как твой подход облегчит интеграцию с IDE.
Он изначально создается для интеграции с ИДЕ.
Так как вся типизация будет производиться декларативным кодом, по которому можно сгенерировать, что угодно то вся информация нужная ИДЕ будет автоматом.
Так что я уже подумал.

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

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

Как насчет описать это представление расширенно на вики Н2? С более детальным описанием аббревиатур типа SST и так далее.

Чтобы не искать в лесах веток форума всякие уточнения, дополнения и так далее.
Там же и примеры для if, foreach и linq.

И может вольфхаунд так сделает.

И можно будет посмотреть лишь описание, без драмы.

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

VD>Не можем. У нас есть только имя. И еще у нас есть код x.Test() который так же зависит от наличия имеющихся перегрузок метода Select, и от того какую из перегрузок выберет типизатор.
У тебя в твоей системе есть только имя.
У меня есть все что нужно.
Читай тут.

Автор: WolfHound
Дата: 02.06.11

Там есть половина ответов.
Остальная половина будет, когда завершу формализацию поиска имен.

VD>Повторять эту работу просто глупо.
А я и не собираюсь.

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

VD>Оно в одиночку вообще не типизируется.
Я в курсе.
И я собираюсь его бесшовно вписать в систему.

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

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

VD>Это по любому полезная работа. Давай! Но проблем с линком это не решает.
Само по себе нет. Но в сочетании с остальным легко.

VD>Ты заблуждаешься. Если будут продемонстрировано что твой подход решает все проблемы и при этом не создает других, я тот част же стану сторонником твоей идеи. Но пока что я вижу обратное.
Так твои взгляды постоянно эволюционируют вот по такому паттерну:
1)Невозможно!
2)Круто!
3)Я всегда говорил что так и надо.

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

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

VD>>Очень часто данных у тебя не будет. Я уже устал повторять христоматийные примеры: linq, foreach, ... В них конкретные типы зависят от того во что макрос раскрывается. Это прямо в спецификацию C# записано.
WH>А уже устал повторять, что вся информация есть.

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

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

хорошо известный факт. Меркури при тщательной оптимизации на 1-2 порядка быстрее пролога, но склонен в отличии от пролога к потере решений в общем случае.

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

S_S>По этому абстрактному представлению код построить нельзя, но можно провести типизацию с точно таким же результатом как по получилось бы макросу, но с лучшим перфомансом.
Результат будет лучше, чем сейчас.
Производительность тоже.
Но все это затевается не столько для этого сколько для того чтобы:
1)Переложить типизацию с пользователя на компилятор. Сейчас сложные макросы приходится типизировать руками.
2)Дать ИДЕ всю информацию о коде. Это позволит получить автокомплит, навигацию итп для сложных ДСЛ полностью автоматом.

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

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

WH>Ты доказывал что Пратт "сбоку" это хорошо.

Ты маньяк, максималист .

Я не доказывал, что что-то сбоку — это хорошо. Я показал, что встроить Пратт в Пег вовсе не сложно. Как только я это сделал, ты придумал как их интегрировать лучшим образом.

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

Автор: VladD2
Дата: 09.02.11

тему создавал?
WH>Вот сам эту тему и прочитай.
WH>Что ты там мне про Пратт "сбоку" говорил...

Почитал. Ничего такого не нашел. Видимо ты опять домыслы какие-то строишь.

VD>>Ты вот привел пример простого if-а, и оказалось, что он во много раз сложнее того что было в Н1. Возникает резонный вопрос, если сложным стало простое, то насколько должно будет усложниться сложное? И мне не надо ответа в стиле "все будет просто". Мне нужна демонстрация. Так чтобы было что осмысливать, и если что, критиковать.
WH>Я привел набросок без грамма сахара.
WH>Можешь посмотреть на обновленный вариант

Автор: WolfHound
Дата: 02.06.11

.

Посмотрел. К if-у и тем более linq-у это имеет отдаленное отношение.

Идея привязывать типизацию к макрам в принципе нормальная. Я тоже над этим думал. Синтаксис опять таки взывает много вопросов, ну да Бог с ним. Эту идею можно применить к типизации AST.

Однако ты не учитываешь одной очень важной вещи. Кроме расстановки типов процесс типизации подразумевает кучу сложных действий связанных с разрешением неоднозначностей (перегрузка, приведение типов и т.п.). Кроме того так же еще имеется процесс генерации TAST (где все уже однозначно).

Type()
{
    ConvertibleTo(InType, literal.Type)
        @@@ $"Can't match $InType over $(literal.Type).";

    PatternType()
}

VD>>Проблема в том, что ты и сейчас не знаешь как это сделать. То что ты предлагаешь вызывает много вопросов. Но ты упорно их игнорируешь.
WH>Это ты упорно игнорируешь ответы.

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

VD>>Заметь, ты 3 месяца не можешь реализовать интеграцию Пратта в ПЕГ. А там алгоритм, с твоих же слов, очень простой ведь.
WH>Мне просто лень это делать.

Зашибись! Но хотя бы честно.
Может чем бестолку спорить о черт знает чем все же доделаешь парсер и мы начнем хотя бы работать над парсером на языка?

WH>Черт в деталях это к твоему подходу. Ибо он бессистемный.
WH>Как ты собрался снимать работу с пользователя по типизации собственных ДСЛ? PegGrammar без типизации не сделать.

Еще раз. Я не против пользовательской типизации если это действительно нужно. PegGrammar когда она нам понадобилась, мы ее сделали. Только это не тотальная типизация, а типизация вполне понятных частей (описаний типов правил и проверка их соответствия обработчикам).

Но зачем же заставлять тотально все типизировать?

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

Кто захочет сможет произвести типизацию вручную, а кто не захочет сможет воспользоваться автоматикой.

WH>Как ты собрался делать автокомплит для пользовательских ДСЛ?

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

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

А как ты в своем?

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

VD>>Ты очень наивен. Я еще раз предлагаю тебе привести пример макроса типизирующий упрощенный линк (from x in xs where x.Test()).
WH>Я абсолютно реалистичен.
WH>Все что мне нужно это механизм поиска имен.

Нет. Тебе нужно будет повторить полную цепочку типизации. Имена тебе не спасут. К тому же в данном случае имени не будет. Оно должно ввести новые переменные и не одну.

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

Ты посмотри на год макросов Н1. Там есть 1-2 места где понадобилось что-то химичить. А ты предлагаешь усложнить жизнь везеде и на всегда.

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

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

S_S>>По этому абстрактному представлению код построить нельзя, но можно провести типизацию с точно таким же результатом как по получилось бы макросу, но с лучшим перфомансом.
WH>Результат будет лучше, чем сейчас.
WH>Производительность тоже.
WH>Но все это затевается не столько для этого сколько для того чтобы:
WH>1)Переложить типизацию с пользователя на компилятор. Сейчас сложные макросы приходится типизировать руками.
WH>2)Дать ИДЕ всю информацию о коде. Это позволит получить автокомплит, навигацию итп для сложных ДСЛ полностью автоматом.

Наложатся ли при этом такие ограничения? : Тип выражения которое вернет макрос, зависит только от типов входных параметров, но не от содержимого этих параметров (что конкретно там за дерево).
Например:
Если макросу приходит параметр(узел) "a:uint + b:uint" , и второй вариант "a:uint — b:uint", в обоих случаях a и b типа uint.
Можно ли будет сделать, чтобы в первом случае макрос вернул выражение типа uint, а во втором int ?
Т.е. чтобы то, как пойдет типизация, зависело от содержимого входного дерева, а не его типа?

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

VD>Однако ты не учитываешь одной очень важной вещи. Кроме расстановки типов процесс типизации подразумевает кучу сложных действий связанных с разрешением неоднозначностей (перегрузка, приведение типов и т.п.). Кроме того так же еще имеется процесс генерации TAST (где все уже однозначно).
Это ты себе придумал, что я ее не учитываю.
Но это не так.

VD>

VD>Type()
VD>{
VD>    ConvertibleTo(InType, literal.Type)
VD>        @@@ $"Can't match $InType over $(literal.Type).";

VD>    PatternType()
VD>}
VD>

Что это?
Не нужно делать из предикатов порядок выполнения которых произволен функцию.
Ни к чему хорошему это не приведет.

VD>Да, это первое сообщение которое можно назвать овтетом. Хотя поять что ты тут напридумывал и зачем все так сложно не просто.
Я это все повторил уже раз 20 разными словами.
Наконец-то я нашёл последовательность слов, которую ты хоть частично понял.

VD>Еще раз. Я не против пользовательской типизации если это действительно нужно. PegGrammar когда она нам понадобилась, мы ее сделали. Только это не тотальная типизация, а типизация вполне понятных частей (описаний типов правил и проверка их соответствия обработчикам).
Это тотальная типизация PegGrammar.
Все это размазано по коду, но проверяется там абсолютно все.

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

VD>Макрос сможет отдать список строк автодополнения. Детали еще надо продумать, конечно. Для встроенных выражений будет работать готовая реализация.
Опять гора императива по типу GoToInfoMap?
Люди не осилят.

WH>>Как ты собрался реализовать ?. в своем подходе?
VD>А как ты в своем?
А в моем у ИДЕ будет вся информация.
Ибо вся типизация будет задана на языке понятном ИДЕ.
И я думаю, ты и сам прекрасно понимаешь, что из ДСЛ можно сгенерировать любой код.

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

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

typing
{
    Type = void;
}

Либо типизация так и проситься, ибо тот код, что есть неадекватно сообщает об ошибках.
Либо сообщения об ошибках вместе с проверками просто переедут в секцию типизации.

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

S_S>Можно ли будет сделать, чтобы в первом случае макрос вернул выражение типа uint, а во втором int ?
S_S>Т.е. чтобы то, как пойдет типизация, зависело от содержимого входного дерева, а не его типа?
Можно.

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

WH>Но все это затевается не столько для этого сколько для того чтобы:
WH>1)Переложить типизацию с пользователя на компилятор. Сейчас сложные макросы приходится типизировать руками.
WH>2)Дать ИДЕ всю информацию о коде. Это позволит получить автокомплит, навигацию итп для сложных ДСЛ полностью автоматом.

Сложные макросы это типа того что : макросу для правильного раскрытия нужна информация о типах, а какие будут типы зависит от того как макрос раскроется? И приходится его исполнять дважды и переносить часть работы на фазу после типизации? Особенно если создает побочные эффекты, которые надо создавать не более одного раза.

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

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

S_S> Потому что, если макрос не создает побочных эффектов, и может корректно раскрыться не зная типов, то тут с виду все что можно улучшить дополнительными декларативными констрейнтами это только быстродействие, да и то не всегда.
Ну и будет куда приткнуть правильные сообщения об ошибках. В C# для LINQ по сообщениям об ошибках видно что MS сачконули, не полностью "Language Integrated". Для юзеров конечно было бы лучше полноценный LINQ. Только вот сколько времени его пришлось бы разрабатывать.

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

Вот посуди сам — и ты и Wolfhound хотите описать тип макроса как описываемую декларативно, неизменяемую структуру данных. Т.е. пользователь описывает входы, выходы, правила преобразования, всё константное и дальше компилятор раскрывает макрос и выводит типы, ну или выводит типы и потом раскрывает. В обоих случаях вывод типов это какая-то внешняя по отношению к иммутабельным данным операция.

А теперь посмотри с другой стороны — если в языке все типы будут макро-программами, способными вызывать другие, вложенные в них или подписанные на их события, макро-программы. Тогда типизация/компиляция начинается с корневого макроса CompileProject, который находит все файлы, создаёт им фиктивные макротипы описывающие эти файлы, и запускает итерацию "парсинг-типизация" в них. Затем каждый файл разбирается парсером, который тоже макрос, поставляющий пачками ITypeInfo. Когда какому-то макросу, хоть по таймеру, приспичило себе типы обновить — он обновляет, и те кто эти типы использовали как входные, или выходные, или вообще хоть как основу для генерации например БД по коду — автоматом получают уведомление, что тип такой-то обновился (а то и удалился, или заменился на новый если они там все immutable будут), и если изменение их затронуло — то они выполняют какую-то программу в себе, возможно обновляя типы которые они породили, и так пока последний тип не устаканится. Ну и какой-нить счётчик обновлений чтобы замкнутый цикл, если случится, грохнуть и написать что макросы такой-то и такой-то рекурсивно-клеманутые.
Даже обычный Int32 в таком подходе — это макротип, который знает операции которые он умеет, знает экстеншн-методы которые на него навесили и т.п. И обращение Int32.ToString(220) отвергнет на этапе компиляции не какой-то типизатор, который не найдёт у типа Int32 перегрузки ToString с параметром Int32, а сам макро-тип Int32, который будет дёрнут макро-оператором '.'. В таком ракурсе подобный обратный-dynamic — это просто метод, который принимает на вход макро-тип, и возвращает макро-тип. Этот тип постоянно доуточняется хоть по всей программе и поддерживает любой метод который у него пытаются вызвать, но при этом обновляет выходной макро-тип IDynamic_f_o, заставляя обновится выходной тип функции, которая в свою очередь может обновить сигнатуру класса, и т.п. Каждый оператор linq — это тоже метод принимающий макро-тип на вход (пусть даже там реально не макро, а самый обычный тип), пробегающий по видимым ему перегрузкам и подбирающий тип для своего выхода, или делегирующий подбор типа другому макро-типу. В случае с "from x in xs select x.Test()", цепочка делегирования будет идти от макроса к макросу, от xs к x и потом к Test(), перебирая доступные сигнатуры Select и Test.

И теперь взять тот же Int32, вот представь что мы доуточняем его, оборачивая каким-то другим макросом, например

for(interlocked int x = 0; x < 10; x++)
{  
}

В этот момент int резко мутирует в interlocked, и все обращения к нему и операции с ним идут теперь через Interlocked.Increment, Interlocked.Add, Interlocked.Read и т.п. При том что макрос interlocked вообще может не знать с каким конкретно типом (int или long) его вызвали. Он просто возьмёт тип, и завернёт его в свой новый тип, подменив все известные ему сигнатуры на Interlocked операции, и бросая ошибки компиляции на все которые он преобразовывать не умеет, например на впихвание себя в ref или out.

Или другой пример:

class C
{
  ... - куча методов и пропертей
}

def c = remote C();

c.| Используем кучу методов и пропертей у C

Аналогично. макрос remote обернёт тип C в какой-то новый тип, скопирует все сигнатуры, а реально методы будет вызывать например через WCF.

Ну и квазицитаты в таком случае — тоже получаются макросы, также входные, выходные типы, можно даже с where, правило преобразования, просто для них есть упрощённый синтаксис.

Локальные функции — тоже макротипы, у них есть входные типы, выходные, имя. Кто завязывается на типы такой функции — тот получит уведомление. Ну и вывод типов это решалка для неуточнённых типов, с рассылкой уведомлений всем кто на них завязан.

В пределе становится возможен ацкий ад, например просто навесив макро-атрибут на класс получить override операции new для него по всему проекту, и создавать его через фабрику например, или вообще подсовывать thread-static singleton вместо новых экземпляров. Можно сделать инопланетный dependency injection, ответить на их service locator нашим service radar'ом, и другие ужасы, за которые в разделе "священные войны" слабые духом будут нас анафеме предавать

VD>Я бы предложит тут другое решение:
VD>IFakeInterface — это интерфейс привязываемый к динамику только для целей поддержки интелисенса. В рантайме будет данимическая диспетчеризация.

Есть такое решение, даже вроде в msconnect народ его пихает. Но как корректность программы проверяется на граничных случаях, так и потенциальные возможности компилятора, особенно самого лучшего компилятора, нужно проверять на конструкциях запредельной улётности. Вон посмотри на находки nikov'а, а ведь он за макросы не брался

VD>Что же касается поддержки массивов с типизированными индексерами, то мне кажется тут лучше всего подошел бы класс-обертка, а не навороты на макросах.

А int'ы которые для индексации тоже в обёртки? И все операции переписать, comparable поддержать и т.п. Там тормоз тормозом погнять будет при таком раскладе

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

S_S> Сложные макросы это типа того что : макросу для правильного раскрытия нужна информация о типах, а какие будут типы зависит от того как макрос раскроется? И приходится его исполнять дважды и переносить часть работы на фазу после типизации? Особенно если создает побочные эффекты, которые надо создавать не более одного раза.
Не понял о чем ты.
Пример можно?

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

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

S_S> Ну и будет куда приткнуть правильные сообщения об ошибках. В C# для LINQ по сообщениям об ошибках видно что MS сачконули, не полностью "Language Integrated". Для юзеров конечно было бы лучше полноценный LINQ. Только вот сколько времени его пришлось бы разрабатывать.
Учитывая что они все пишут на С++ причем два раза(компилятор и ИДЕ)...
У меня все уложится в несколько простых строк и один раз.

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

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

Много букв поскипано.

То что ты хочешь не взлетит. Пойми, дерево типов перестраивается при изменении любой буквы вне тел членов (методов). Единственное что позволяет работать этой схеме приемлемо — это высокая скорость обработки.

Высокая скорость обработки дерева типов достигается за счет того, что самая объемная и затрантая по времени работа — типизация тел методов не производится. Фактически самое медленной при построении дерева типов — это парсинг и макросы. Результаты парсинга мы можем кэшировать, так что от размера проекта мы не зависим. Остаются макросы. С ними хуже, но они так же могут работать вполне быстро откладывая затратные операции до поздних стадий компиляции (не выполняя их во время перестроения дерева типов).

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

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

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

Кроме того можно позволить генерировать типы на стадиях идущих после типизации методов. Эти стадии просто не будут производиться в режиме IDE, так что их производительность будет не так важна. Кроме того это позволит типизировать методы пареллельно, так как они не будут изменять к глобальное состояние (дерево типов), а всего лишь будут ставить задания в очередь которая будет разбираться позднее. Понятно, что не все варианты можно будет накрыть таким образом. Но все же многие сценарии будут возможны.

_>А int'ы которые для индексации тоже в обёртки? И все операции переписать, comparable поддержать и т.п. Там тормоз тормозом погнять будет при таком раскладе

Я давно хотел в вести в язык псевдо-наследование от встроенных типов. Чтобы можно было написать нечто вроде

struct Idx : int
{
  переопределение внутренностей
}

так же были бы к месту жесткие typedef-ы, так чтобы тип жестко проверялся компилятором. Ну, а на поздних стадиях компилятора рассахаривать это дело (и тайпдефы, и наследников встроенных типов) в базовые типы.

Надо будет подумать как сделать такую штуку не хардкодя это в компилятор. Что-то типа плагинов для системы типов.

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

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

S_S>> Сложные макросы это типа того что : макросу для правильного раскрытия нужна информация о типах, а какие будут типы зависит от того как макрос раскроется? И приходится его исполнять дважды и переносить часть работы на фазу после типизации? Особенно если создает побочные эффекты, которые надо создавать не более одного раза.
WH>Не понял о чем ты.
WH>Пример можно?

Тогда можно поскипать. Т.к. я и сам не до конца понимаю как там все работает и сейчас и как будет, и о чем конкретно спросил.
А имел ввиду, что-то типа такого непрактичного этюда.

def d=Dictionary();
d[4] = MyMacro(d);

Допустим макросу зачем-то надо знать тип ключа у d (а тип значения тут естейственно неопределен т.к. зависит от самого макроса). Т.е. макросу надо наполовину типизированный Dictionary.
Макрос смотрит какого типа ключ у этого Dictionary, и в зависимости от этого возвращает значения разных типов либо int либо string (допустим если ключ типа byValue тогда вернуть 3, если тип reference то вернуть "a").

В Н1 сейчас такое можно? Если можно, то на какой стадии вызывать, после типизации? Но полностью все типизировать нельзя пока макрос не раскроется.
Или это вредная фича, лишняя степень свободы, не нужная на практике, которую лучше заблокировать?

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

S_S>def d=Dictionary();
S_S>d[4] = MyMacro(d);
S_S>Допустим макросу зачем-то надо знать тип ключа у d (а тип значения тут естейственно неопределен т.к. зависит от самого макроса). Т.е. макросу надо наполовину типизированный Dictionary.
Получается что-то типа такого:

ast MyMacro : Expression
syntax "MyMacro" "(" expr ")"
{
    expr : Expression;
}
typing
{
    Dictionary[key, _] = expr.Type;
    Type = (key, key);
}

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

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

S_S>def d=Dictionary();
S_S>d[4] = MyMacro(d);

S_S>Допустим макросу зачем-то надо знать тип ключа у d (а тип значения тут естейственно неопределен т.к. зависит от самого макроса). Т.е. макросу надо наполовину типизированный Dictionary.
S_S>Макрос смотрит какого типа ключ у этого Dictionary, и в зависимости от этого возвращает значения разных типов либо int либо string (допустим если ключ типа byValue тогда вернуть 3, если тип reference то вернуть "a").

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

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

C>Как насчет описать это представление расширенно на вики Н2? С более детальным описанием аббревиатур типа SST и так далее.

Там кое что есть. Оформится до конца, опишем детальнее.

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

А>хорошо известный факт. Меркури при тщательной оптимизации на 1-2 порядка быстрее пролога, но склонен в отличии от пролога к потере решений в общем случае.

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

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

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

VD>>Однако ты не учитываешь одной очень важной вещи. Кроме расстановки типов процесс типизации подразумевает кучу сложных действий связанных с разрешением неоднозначностей (перегрузка, приведение типов и т.п.). Кроме того так же еще имеется процесс генерации TAST (где все уже однозначно).
WH>Это ты себе придумал, что я ее не учитываю.

Перестань хамить.

WH>Но это не так.

Я не вижу в твоих рассуждениях даже упоминаний об этом. Что я еще должен думать? Описывай и вопрос отпадет.

VD>>

VD>>Type()
VD>>{
VD>>    ConvertibleTo(InType, literal.Type)
VD>>        @@@ $"Can't match $InType over $(literal.Type).";

VD>>    PatternType()
VD>>}
VD>>

WH>Что это?
WH>Не нужно делать из предикатов порядок выполнения которых произволен функцию.
WH>Ни к чему хорошему это не приведет.

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

WH>Я это все повторил уже раз 20 разными словами.

Ты все это время пустословил бросясь ничем не подкрепляемыми заявлениями вроде "Все будет ОК...", "Вся информация есть...".

WH>Наконец-то я нашёл последовательность слов, которую ты хоть частично понял.

Ну, ты на будущее сразу пропускай общие заявления и переходи к конкретике. Хотя бы так как в прошлом сообщении. Хотя и там ее маловато.

WH>Это тотальная типизация PegGrammar.
WH>Все это размазано по коду, но проверяется там абсолютно все.

Что там проверяется? Кот когда ты это дело в код преобразуешь, то проверяется в сто раз больше.

VD>>Кто захочет сможет произвести типизацию вручную, а кто не захочет сможет воспользоваться автоматикой.
WH>Эта "автоматика" ведет к жутким сообщения об ошибках.
WH>А там где сообщения нормальные мы наблюдаем хардкод в ядро компилятора.

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

VD>>Макрос сможет отдать список строк автодополнения. Детали еще надо продумать, конечно. Для встроенных выражений будет работать готовая реализация.
WH>Опять гора императива по типу GoToInfoMap?
WH>Люди не осилят.

Гору пока что ты тут демонстрируешь. Для того же PegGrammar ты ничего умнее не придумаешь как отдать список правил.
Продемонстрируй как ты видишь обработку того же комплита для PegGrammar. Поглядим на то какая гора получится у тебя.

WH>>>Как ты собрался реализовать ?. в своем подходе?
VD>>А как ты в своем?
WH>А в моем у ИДЕ будет вся информация.

А в моем тоже. Вот и поговорили. Язык ведь он без костей.

WH>Ибо вся типизация будет задана на языке понятном ИДЕ.

Это пустой треп. Ты покажи код и расскажи как IDE из него извлечет информацию для комплита. А мы на него посмотрим и оценим.

WH>И я думаю, ты и сам прекрасно понимаешь, что из ДСЛ можно сгенерировать любой код.

Я пока что вижу ничем не подкрепленный треп. Я устал его слушать. Показывай псевдо-код. Тогда будет что обсуждать. А заявления твои идут в лес. Из них никакой информации почерпнуть нельзя.

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

Пока что горы непонятной хрени показываешь ты.

VD>>Ты посмотри на год макросов Н1. Там есть 1-2 места где понадобилось что-то химичить. А ты предлагаешь усложнить жизнь везеде и на всегда.
WH>Посмотрел.
WH>Там либо типизация будет тривиальной типа:
WH>

WH>typing
WH>{
WH>    Type = void;
WH>}
WH>

А зачем это вообще кому-то надо?

WH>Либо типизация так и проситься, ибо тот код, что есть неадекватно сообщает об ошибках.

Треп. Давай примеры.

WH>Либо сообщения об ошибках вместе с проверками просто переедут в секцию типизации.

Давай примеры.

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

WH>>Это ты себе придумал, что я ее не учитываю.
VD>Перестань хамить.
Здесь-то ты чего выдумал?

VD>Про порядок ты тоже забыл упомянуть. И про то что это предикаты — тоже. Твой код выглядит как императивные присвоения.
А про то что это упрощенный меркури я еще в первом сообщении сказал.
И потом еще несколько раз повторил.
Это кстати отлично показывает как ты "пытаешься" понять что тебе говорят.

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

VD>Это кому претензии? Я что ли это делал? В других местах хардкода нет, а сообщения нормальные. Так что это от рук зависит, а не от модели.
Там где в макросах сообщения нормальные либо хардкод в компиляторе, либо сообщения генерирует макрос.

VD>Гору пока что ты тут демонстрируешь. Для того же PegGrammar ты ничего умнее не придумаешь как отдать список правил.
Я уже придумал.
Я опишу правила типизации и поиска имен.
По ним ИДЕ получит всю информацию сама.
Разработчику макроса ничего делать не придется.

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

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

VD>Это пустой треп. Ты покажи код и расскажи как IDE из него извлечет информацию для комплита. А мы на него посмотрим и оценим.
Код я уже показал.
Далее все просто.
У нас есть код, который полностью описывает типизацию всей программы.
Код написан на ДСЛ.
Исполняемый код генерируется из этого ДСЛ так как нам надо.
Какие проблемы сгенерировать код для поддержки автокомплита?

VD>Я пока что вижу ничем не подкрепленный треп. Я устал его слушать.
Вот ты жалуешься на то что я тебе "хамлю"...

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

VD>А зачем это вообще кому-то надо?
А зачем надо задавать сигнатуры методов?

WH>>Либо типизация так и проситься, ибо тот код, что есть неадекватно сообщает об ошибках.
VD>Треп. Давай примеры.
Да хотябы все теже if, while, when,...
Error: expected bool, got int in type-enforced expression: System.Int32 is not a subtype of System.Boolean [simple require]

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

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

WH>А про то что это упрощенный меркури я еще в первом сообщении сказал.
WH>И потом еще несколько раз повторил.
WH>Это кстати отлично показывает как ты "пытаешься" понять что тебе говорят.

Это показывает то как ты объясняешь. Я тебе гарантирую, что остальные поняли еще меньше чем я. Думаешь почему они все молчат?

Меркури же здесь никто не знает. В лучше случае немного Пролога. Рассчитывай на это и явно описывай семантику того о чем ты говоришь.

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

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

VD>>Это кому претензии? Я что ли это делал? В других местах хардкода нет, а сообщения нормальные. Так что это от рук зависит, а не от модели.
WH>Там где в макросах сообщения нормальные либо хардкод в компиляторе,

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

WH>либо сообщения генерирует макрос.

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

VD>>Гору пока что ты тут демонстрируешь. Для того же PegGrammar ты ничего умнее не придумаешь как отдать список правил.
WH>Я уже придумал.
WH>Я опишу правила типизации и поиска имен.
WH>По ним ИДЕ получит всю информацию сама.

Это очередной рассказ про самолеты. Он никому не интересен. Интересны детали. Я устал это повторять.
Описание правил может оказаться очень сложным. Намного более сложным чем простая возможность возвратить список строк.

Вот давай разберем тот же PegGrammar.

У нас есть грамматика вида:

A = X
X = B
B = c

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

WH>Разработчику макроса ничего делать не придется.

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

VD>>Продемонстрируй как ты видишь обработку того же комплита для PegGrammar. Поглядим на то какая гора получится у тебя.
WH>У меня кода для этих целей вообще не будет.
WH>Ни буквы.

Тогда объясни схему по которой все это будет работать.

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

В моем то может и протаскиваю (хотя я варианта для Н2 еще не показывал). Но ты свой вообще не описываешь.
Не удивлюсь если окажется, что на практике ты предложишь отдельно типизировать и "?." и ".". А это гора кода. Там тебе и разрешение перегрузки и прочая фигня.

VD>>Это пустой треп. Ты покажи код и расскажи как IDE из него извлечет информацию для комплита. А мы на него посмотрим и оценим.
WH>Код я уже показал.
WH>Далее все просто.

Где? Я его не заметил. Ты пойди погляди каков код типизации для той же ".". Там гора нетривиального кода. Ты его предлагаешь писателям макросов написать? Или ты веришь в чудо и гора кода вдруг сама собой превратится в одну строку?

WH>У нас есть код, который полностью описывает типизацию всей программы.

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

WH>Код написан на ДСЛ.
WH>Исполняемый код генерируется из этого ДСЛ так как нам надо.
WH>Какие проблемы сгенерировать код для поддержки автокомплита?

Проблем несколько.
1. Кода типизации для не тривиальных случаев будет море. Заставлять его писать не проффесионалав (т.е. писателей макросов) нельзя. Это четкий фэйл.
2. Описывая типизацию для каждого частного случая ты неминуемо будешь вынужден дублировать тучу кода. Значит нужны средства повторного использования. Переписывание и есть такой способ. Переписывание можно сделать декларативно. А переписанный код будет типизирован уже написанным профессионалами кодом.
3. Типизация может быть отложенная (зависеть от кода идущего ниже), стало быть нужны какие-то средства возвратов к процессу типизации.
4. Типизация может быть невозможна для отдельного участка АСТ. PegGrammar отличный тому пример.

VD>>Я пока что вижу ничем не подкрепленный треп. Я устал его слушать.
WH>Вот ты жалуешься на то что я тебе "хамлю"...

Сори. Ничем не подкрепленные слова. Так пойдет?

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

VD>>А зачем это вообще кому-то надо?
WH>А зачем надо задавать сигнатуры методов?

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

VD>>Давай примеры.
WH>Да хотябы все теже if, while, when,...
WH>Error: expected bool, got int in type-enforced expression: System.Int32 is not a subtype of System.Boolean [simple require]

И что тут не ясно? Разве что "in type-enforced expression" лишнее.
Ну, дык я не против возможности задать подобные связи явно и указать более человеческое сообщение об ошибке. Но зачем же из-за этого типизировать все и тотально?

Вполне разумно предоставлять выбор. Хочет человек просто преобразовать код без типизации? Пожалуйста! Хочет произвести типизацию исходного подязыка — тоже, милости просим! А хочет — указывает, что ему нужен автоматически типизированный код, а он его перепишет в некий другой (именно так происходит в случае поддержки деревьев выражения и компьютейшон-экспрешенов).

В чем проблема то?

В любом случае в итоге код будет типизирован.

Зачем людей заставлять делать то что им не нужно?

WH>>>Либо сообщения об ошибках вместе с проверками просто переедут в секцию типизации.
VD>>Давай примеры.
WH>Я уже показывал как сообщать о ошибках в моем подходе.

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

WH>Чего тебе еще не ясно?

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

WH>Или ты не понял, про какие такие сообщения в макросах я говорю?
WH>Так я про Message.* вестимо.

Я понял. И то что ты показал с некоторыми переделками и доделками может пойти для типизации типизации. Но ты не показал реализации тех моментов которые которые не вписываются в твои концепции.

Здравствуйте, 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> Если вопрос только в каком формате описывать констрейнты, то это, наверно, можно в любой момент безболезненно переписать,дополнить?

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

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

WH>1)Переложить типизацию с пользователя на компилятор. Сейчас сложные макросы приходится типизировать руками.

Этого можно добиться смешением типизации до раскрытия с типизацией после раскрытия макроса.

WH>2)Дать ИДЕ всю информацию о коде. Это позволит получить автокомплит, навигацию итп для сложных ДСЛ полностью автоматом.

В смешанном режиме она так же будет.

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

Глупо отбрасывать возможность раскрыть макросы и получить типизацию из коробки. А раз так, то это не два разных процесса, а части единого процесса.

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

S_S> Наложатся ли при этом такие ограничения? : Тип выражения которое вернет макрос, зависит только от типов входных параметров, но не от содержимого этих параметров (что конкретно там за дерево).
S_S>Например:
S_S>Если макросу приходит параметр(узел) "a:uint + b:uint" , и второй вариант "a:uint — b:uint", в обоих случаях a и b типа uint.
S_S>Можно ли будет сделать, чтобы в первом случае макрос вернул выражение типа uint, а во втором int ?
S_S>Т.е. чтобы то, как пойдет типизация, зависело от содержимого входного дерева, а не его типа?

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