Re: Размышления о типизаторе для Н2
От: WolfHound  
Дата: 05.06.11 18:24
Оценка:
Здравствуйте, WolfHound, Вы писали:

Чем больше я думаю, на эту тему тем больше убеждаюсь в том, что ядро системы должно быть реактивным.
1)У нас будет очень простой и предельно декларативный язык описания типизации.
2)Не смотря на это код, сгенерированный по этому языку будет императивный до мозга костей, что положительно скажется на производительности.
3)Реактивное программирование это, по сути, формализм для инкрементального обновления модели. Т.к. не будет полного пересчета всего то это даст заметное ускорение.
4)Обсчет реактивной модели можно автоматически распараллелить.
5)Реактивность позволит из тел методов создавать и модифицировать типы.

Руками все это сделать не возможно. Как следствие от языка описания типизации никуда не уйти.
Другого способа сделать быстрое, надежное и простое в использовании решение я не вижу.
Ручной императив а-ля Н1 не вариант ваще.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[2]: Размышления о типизаторе для Н2
От: Аноним  
Дата: 06.06.11 12:35
Оценка:
Здравствуйте, WolfHound, Вы писали:

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


WH>Чем больше я думаю, на эту тему тем больше убеждаюсь в том, что ядро системы должно быть реактивным.

WH>1)У нас будет очень простой и предельно декларативный язык описания типизации.
WH>2)Не смотря на это код, сгенерированный по этому языку будет императивный до мозга костей, что положительно скажется на производительности.
WH>3)Реактивное программирование это, по сути, формализм для инкрементального обновления модели. Т.к. не будет полного пересчета всего то это даст заметное ускорение.
WH>4)Обсчет реактивной модели можно автоматически распараллелить.
WH>5)Реактивность позволит из тел методов создавать и модифицировать типы.

WH>Руками все это сделать не возможно. Как следствие от языка описания типизации никуда не уйти.

WH>Другого способа сделать быстрое, надежное и простое в использовании решение я не вижу.
WH>Ручной императив а-ля Н1 не вариант ваще.

Реактивное программирование тут сомнительно, так как изменения могут касаться самого существования узлов с перестройкой графа в целом.
Re[3]: Размышления о типизаторе для Н2
От: WolfHound  
Дата: 06.06.11 12:52
Оценка:
Здравствуйте, <Аноним>, Вы писали:

А>Реактивное программирование тут сомнительно, так как изменения могут касаться самого существования узлов с перестройкой графа в целом.

И в чем проблема?
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[4]: Размышления о типизаторе для Н2
От: Аноним  
Дата: 06.06.11 14:02
Оценка:
Здравствуйте, WolfHound, Вы писали:

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


А>>Реактивное программирование тут сомнительно, так как изменения могут касаться самого существования узлов с перестройкой графа в целом.

WH>И в чем проблема?

В том что аналогия с excel не верна, так как там граф всзоимодействий меняется локально
Re[16]: Размышления о типизаторе для Н2
От: VladD2 Российская Империя www.nemerle.org
Дата: 06.06.11 15:15
Оценка:
Здравствуйте, WolfHound, Вы писали:

VD>>Гы-гы. Только что ты мне тыкал общими сообщениями об ошибках в Н1, а сейчас тоже самое предлагаешь.

WH>Вовсе нет.
WH>Сообщения, выдаваемые при разрешении перегрузки вполне подходят в данном случае.

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

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

VD>>Нет. Оно не изменится. Ты же только имя меняешь. Разве что ли для выявления случайных перекрытий.

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

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

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


Это все на словах. Реально там нужно очень многое продумывать. В любом случае разрешать в макросах уровня выражения генерировать типы которые будут видны в других методах слишком опасны. Это голимый императив. От него добра ждать не приходится.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[5]: Размышления о типизаторе для Н2
От: WolfHound  
Дата: 06.06.11 17:04
Оценка:
Здравствуйте, <Аноним>, Вы писали:

А>В том что аналогия с excel не верна, так как там граф всзоимодействий меняется локально

И в чем проблема?
Удаление и изменение узла графа мало чем отличаются.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[17]: Размышления о типизаторе для Н2
От: WolfHound  
Дата: 06.06.11 17:13
Оценка:
Здравствуйте, VladD2, Вы писали:

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

Я то почитал. А ты?

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

Не поставит.
Реактивную систему можно параллелить.
Руками это делать, конечно, застрелишься, но я и не предлагаю делать это руками.
ДСЛ наше все.

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

То, что не видишь хорошего решения не значит что его нет.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[18]: Размышления о типизаторе для Н2
От: VladD2 Российская Империя www.nemerle.org
Дата: 06.06.11 17:39
Оценка:
Здравствуйте, WolfHound, Вы писали:

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

WH>Я то почитал.

Хреново значит читал.

WH>А ты?


Я их писал.

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

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

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

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

WH>То, что не видишь хорошего решения не значит что его нет.

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

Короче, идею впихнуть сюда реактивность я на ус намотал. Но ее надо серьезно продумывать и проверять. Пока что я не могу сказать что она точно взлетит.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[19]: Размышления о типизаторе для Н2
От: WolfHound  
Дата: 06.06.11 18:06
Оценка:
Здравствуйте, VladD2, Вы писали:

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

Нас посетил КО.

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

Реактивность успешно применяют во множестве решений.

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

Модель вычислений взлету не мешает.
С реализацией придется повозиться.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re: Размышления о типизаторе для Н2
От: WolfHound  
Дата: 07.06.11 08:14
Оценка:
Здравствуйте, WolfHound, Вы писали:

pred ConvertibleTo(from : Type, itemType : Type)
mode (in, in) is semidet //Проверяет что один тип приводим к другому.
mode (in, out) is multi  //При помощи бектрекинга перебирает все типы к которым можно привести данный.
//Реализацию выдумавать лень.


//Предикат, который достает тип элемента коллекции.
//Предикат объявлен абстрактным, чтобы его можно было расширять
//Это позволит реализовать этот предикат для коллекций, у которых нет IEnumirable
abstract pred CollectionItemType(collectionType : Type :: in, itemType : Type :: out) is nondet;

//Конкретный предикат.
pred GenericIEnumirableItemType(collectionType, itemType) extends CollectionItemType
{
    ConvertibleTo(collectionType, type);//Перебираем типы
    IEnumerable[itemType] = type;//Проверяем есть ли среди них IEnumerable[_] и связываем itemType
}
//Как вариант можно написать так:
//ConvertibleTo(collectionType, IEnumerable[itemType]);


pred IEnumirableItemType(collectionType, itemType) extends CollectionItemType
{//Тут все тоже самое
    ConvertibleTo(collectionType, type);
    IEnumerable = type;
    itemType = object;//Только возвращаем всегда object.
}

//Задаем порядок.
//Если GenericIEnumirableItemType нашол ответ то IEnumirableItemType проверяться не будет
order IEnumirableItemType < GenericIEnumirableItemType;

//При желании можно воткнуть что-то между ними
order IEnumirableItemType < MyCollectionItemType < GenericIEnumirableItemType;

Теперь при помощи расширяемого предиката CollectionItemType можно получить тип коллекции.
Далее типизируем паттерн
Автор: WolfHound
Дата: 02.06.11
.
ast ForEach : Expression
{
    syntax "foreach" "(" pattern "in" collection ")" body;
    pattern    : Pattern;
    collection : Expression;
    body       : Expression;
}
typing
{
    CollectionItemType(collection.Type, pattern.InType);
    newscope body add VarsFromPatternType(pattern.Type);
    ConvertibleTo(body.Type, #void);
    Type = #void;
}

newscope создает пространство имен, вложенное в текущее и типизирует с его помощью указанные выражения. В данном случае body.
VarsFromPatternType превращает тип паттерна в список переменных.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[3]: Размышления о типизаторе для Н2
От: VladD2 Российская Империя www.nemerle.org
Дата: 07.06.11 15:41
Оценка:
Здравствуйте, Аноним, Вы писали:

А>Реактивное программирование тут сомнительно, так как изменения могут касаться самого существования узлов с перестройкой графа в целом.


Это как раз решаемая задача. Например, в knockout (реактивная библиотека для построения Web UI) реактивная модель позволяет динамически менять DOM HTML-я. А DOM HTML-я — это тоже себе дерево. Раз можно менять его, то можно менять и деревья описывающие данные о программе.

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

Единственная надежда на DSL-изацию вывода типов. Тут я согласен с WolfHound-ом. DSL-изацию может позволить удержать сложность в разумных рамках при этом не скупясь на хамские (для гражданского кода) оптимизации.

В общем, идею реактивности надо как следует рассмотреть (а значит не сбрасывать со счетов). Если она прокатит, то это может быть решением очень многих проблем. От допущения псевдо-императивного изменения дерева типов из макросов уровня выражения, до обеспечения инкрементального обновления проекта. А это может существенно поднять производительность в режиме IDE.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[2]: Размышления о типизаторе для Н2
От: VladD2 Российская Империя www.nemerle.org
Дата: 07.06.11 18:19
Оценка:
Здравствуйте, WolfHound, Вы писали:

О! Хоть что-то конкретное. Поглядел, но как-то не увидел многих деталей.

В моем варианте
Автор: VladD2
Дата: 06.06.11
приведено решение соответствующее спецификации C#. Плюс у меня приведен код переписывания. Другими словами из моего варианта можно понять как все будет работать в целом.

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

Ниже вопросы и критика того что есть.

WH>pred ConvertibleTo(from : Type, itemType : Type)


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

WH>mode (in, in) is semidet //Проверяет что один тип приводим к другому.

WH>mode (in, out) is multi //При помощи бектрекинга перебирает все типы к которым можно привести данный.

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

Потом что это за птичий язык? Что за невнятные сокращения — "semidet", "multi", "mode"? Я так понимаю этот стиль почерпнут из Меркури? Не надо сдирать у него плохоие черты. Имена должны быть внятными и поясняться перед использованием.

WH>При помощи бектрекинга перебирает все типы к которым можно привести данный.


Зачем? Почему нельзя просто возвратить список? В общем, ничего не понятно.

WH>//Реализацию выдумавать лень.

Она и не нужна, если это встроенные функции. Но нужно объяснить семантику. Иначе это очередная реинкарнация притчи об утюге. Знаешь такую?

WH>//Предикат, который достает тип элемента коллекции.

WH>//Предикат объявлен абстрактным, чтобы его можно было расширять
WH>//Это позволит реализовать этот предикат для коллекций, у которых нет IEnumirable
WH>abstract pred CollectionItemType(collectionType : Type :: in, itemType : Type :: out) is nondet;

Вот и покажи как будет выглядеть реализация этого предиката для коллекции не реализующей IEnumirable. Причем, чем детальнее, тем лучше. При этом загляни в спецификацию C# и повтори ее на своем языке. Интересны:
1. Как осуществляется анализ членов типа коллекции.
2. Как из членов добывается информация о типах возвращаемого значения и параметров. Для типов не реализующих IEnumirable нужно:
2.1. Убедиться, что у тип коллекции не является встроенным типом или делегатом (является структурой или классом).
2.2. Коллекция реализует метод GetEnumerator с сигнатурой "GetEnumerator() : e".
2.2. Тип возвращаемого значения GetEnumerator, т.е. тип "e" должен реализовывать метод MoveNext с сигнатурой "MoveNext() : bool" и свойство Current с сигнатурой "Current : elemType { get; }". Если метод или свойство не определено или у них неподходящие сигнатуры, об этом надо выдать сообщение (сообщение об ошибке).
2.3. Типом коллекции должен стать тип elemType, т.е. тип свойства Current у объекта который возвращается методом GetEnumerator. Обращаю особое внимание, что типизация других вариантов при этом не должна проводиться. То есть, если найден GetEnumerator, то далее типизатор должен добиваться от программиста наличия корректно оформленного паттерна "перечеслитель" и игнорировать другие варианты даже если тип реализует интерфейс IEnumerable.

Что такое ":: out" тоже не ясно. Это тоже надо пояснять.

WH>//Конкретный предикат.

WH>pred GenericIEnumirableItemType(collectionType, itemType) extends CollectionItemType
WH>{
WH> ConvertibleTo(collectionType, type);//Перебираем типы
WH> IEnumerable[itemType] = type;//Проверяем есть ли среди них IEnumerable[_] и связываем itemType
WH>}
WH>//Как вариант можно написать так:
WH>//ConvertibleTo(collectionType, IEnumerable[itemType]);

А где должны располагаться эти "pred"?

WH>pred IEnumirableItemType(collectionType, itemType) extends CollectionItemType

WH>{//Тут все тоже самое
WH> ConvertibleTo(collectionType, type);
WH> IEnumerable = type;

Что такое "type"? Это переменная типа? Откуда она взялась? Какова ее область видимости? Мы вводим переменные без объявления? Это противоречит духу немерла. Плюс как отличать введение переменной и использование ранее определенных? Хочется нахватать граблей Руби?

Почему object?

WH> itemType = object;//Только возвращаем всегда object.

WH>}

В C# для foreach по IEnumerable используется явное приведение типов. В немерле для тех же целей используется ПМ. Где и как это учитывается?

WH>//Задаем порядок.

WH>//Если GenericIEnumirableItemType нашол ответ то IEnumirableItemType проверяться не будет
WH>order IEnumirableItemType < GenericIEnumirableItemType;

WH>//При желании можно воткнуть что-то между ними

WH>order IEnumirableItemType < MyCollectionItemType < GenericIEnumirableItemType;

Опять внешние объявления? Где они будут располагаться? Как увидеть связь с макросами?

WH>Теперь при помощи расширяемого предиката CollectionItemType можно получить тип коллекции.

WH>Далее типизируем паттерн
Автор: WolfHound
Дата: 02.06.11
.

WH>ast ForEach : Expression
WH>{
WH> syntax "foreach" "(" pattern "in" collection ")" body;
WH> pattern : Pattern;
WH> collection : Expression;
WH> body : Expression;
WH>}
WH>typing
WH>{
WH> CollectionItemType(collection.Type, pattern.InType);

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

1. В Немерле паттерн может иметь разный вид.
Так допустим паттерн вида "var is SomeType". В терминах переписывания — это выглядит так:
match (x)
{
  | var is SomeType => $body
  | _ => ()
}

Кроме того это может быть имя переменной, но body, при этом, содержит вхождения match-а, так что в терминах переписывания уже выходит следующая картина:
def var = ...

match (var)
{
  ..$body
}

Так же может быть случай когда паттерн — это просто имя переменной. Тогда в терминах переписывания мы получаем:
{
def var = ...
..$body
}
[/Nemerle]
Другими словами, параметр "pattern" может иметь разный тип в зависимости от контекста. На тип pattern-а влияет как содержимое pattern, так и содержимое body.

Вот фрагмент кода из реализации этого макроса в Н1:
    // build the body of loop (may contain additional matching)
    def build_definition(val)
    {
      match (body)
      {
        | <[ match ($(null)) { ..$cases } ]> =>
          match (iter)
          {
            | <[ $(x : name) ]> when char.IsLower(x.Id[0]) | <[ (..$_) ]> => ()
            | _ => Message.FatalError("only simple names available in pattern of foreach with direct matching")
          }

          <[ def $iter = $val;
             match ($iter) { ..$cases } ]>

        | _ =>
          def mat =
            match (iter)
            {
              | <[ $pat :> $ty ]> => <[ match ($val :> $ty) { | $pat  => $body; () | _ => () } ]>
              | _                 => <[ match ($val)        { | $iter => $body; () | _ => () } ]>
            };
          mat.cases.Iter (fun (x : PT.MatchCase) { x.disable_warnings = true });
          mat
      }
    }


Как видишь тут анализируется содержимое body, и если — это тело match-а то проверяется, что паттерн (который имеет в этой реализации имя iter) содержит простое имя (хотя по уму можно допускать и "_", но это ладно).

Как ты собираешься решать эту проблему?

WH> newscope body add VarsFromPatternType(pattern.Type);

WH> ConvertibleTo(body.Type, #void);
WH> Type = #void;
WH>}


WH>newscope создает пространство имен, вложенное в текущее и типизирует с его помощью указанные выражения. В данном случае body.


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

Ну, и опять же что ты будешь делать в случае который в Н1 называется "direct matching", т.е. когда body содержит cese-ы match-а?

WH>VarsFromPatternType превращает тип паттерна в список переменных.


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

Далее очень интересным вопросом является — как переменные созданный в этом коде будут найдены кодом который будет генерировать тот самый паттерн-матчинг? Другими словами как эти переменные будут связаны с кодом ПМ-а в который в итоге должно все раскрыться?

По сему еще интереснее становится взглянуть на код переписывания. Тут у тебя явно будут несостыковки.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[3]: Размышления о типизаторе для Н2
От: WolfHound  
Дата: 07.06.11 22:02
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Отсылать к изучении Меркури не стоит. Никто не будет его учить чтобы писать макросы.

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

VD>Потом что это за птичий язык? Что за невнятные сокращения — "semidet", "multi", "mode"? Я так понимаю этот стиль почерпнут из Меркури? Не надо сдирать у него плохоие черты. Имена должны быть внятными и поясняться перед использованием.

Мне просто сейчас лень выдумывать свой синтаксис.

WH>>При помощи бектрекинга перебирает все типы к которым можно привести данный.

VD>Зачем? Почему нельзя просто возвратить список? В общем, ничего не понятно.
И перебирать его руками. Ага, конечно.

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

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

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

Пока не закончу с поиском имен я это делать не буду.

VD>Что такое ":: out" тоже не ясно. Это тоже надо пояснять.

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

VD>А где должны располагаться эти "pred"?

В пространстве имен.

VD>Что такое "type"? Это переменная типа? Откуда она взялась? Какова ее область видимости? Мы вводим переменные без объявления? Это противоречит духу немерла. Плюс как отличать введение переменной и использование ранее определенных? Хочется нахватать граблей Руби?

require: collection as x && !x.IsPrimitive // "x" новая переменная типа равная типу collection
require: x has method GetEnumerator() : e // проверяем соответствие паттерну "перечислитель"

Что такое "x" и "e"? Это переменные типов? Откуда они взялась? Какова их область видимости? Мы вводим переменные без объявления? Это противоречит духу немерла. Плюс как отличать введение переменной и использование ранее определенных? Хочется нахватать граблей Руби?


VD>Почему object?

По тому, что IEnumerable возвращает object'ы.

VD>В C# для foreach по IEnumerable используется явное приведение типов. В немерле для тех же целей используется ПМ. Где и как это учитывается?

В ПМ попадает object, а дальше с ним уже ПМ разбирается.

VD>Опять внешние объявления?

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

VD>Где они будут располагаться? Как увидеть связь с макросами?

Рядом с макросами.

VD>1. В Немерле паттерн может иметь разный вид.

Эти два варианта на типизацию вообще никак не повлияют.
Они будут различаться только на этапе кодогенерации.

VD>Кроме того это может быть имя переменной, но body, при этом, содержит вхождения match-а, так что в терминах переписывания уже выходит следующая картина:

Это вариант я просто не рассматривал.
Для этого придется чуток усложнить.
ast ForEach : Expression
{
    syntax "foreach" "(" pattern "in" collection ")" body;
    pattern    : Pattern;
    collection : Expression;
    body       : Expression | MatchBody;
}
typing
{
    CollectionItemType(collection.Type, ItemType);
    pattern.InType = ItemType;
    scope body add VarsFromPatternType(pattern.Type);
    Type = #void;
    {
        body is Expression;
        ConvertibleTo(body.Type, #void);
    |
        body is MatchBody;
        body.InType = ItemType;
        ConvertibleTo(body.Type, #void);
    }
}


VD>Стоп, стоп, стоп! Какое на фиг текущее пространство имен? Ты не забыл, что твой язык ленивый (если вообще носит вычислительную семантику)?

Я все помню.

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

Ну почему же?
У нас есть дерево созданное парсером.
С его помощью можно задать четкую иерархию контекстов.

WH>>VarsFromPatternType превращает тип паттерна в список переменных.

VD>Ее реализация тоже интересна! Это же тоже часть процесса типизации. Убрав его в отдельную функцию ты всего лишь скрыл его с глаз, но не устранил необходимость его писать.
Я ее пока не придумал.
Она очень завязана на поиск имен.

VD>Далее очень интересным вопросом является — как переменные созданный в этом коде будут найдены кодом который будет генерировать тот самый паттерн-матчинг? Другими словами как эти переменные будут связаны с кодом ПМ-а в который в итоге должно все раскрыться?

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

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

RewriteForeachBody(fe : ForEach) : Expression
{
    def body = match (fe.Body)
    {
        | body is Expression => body
        | body is MatchBody  => <[ match (item) $body ]>
    }
    match (fe.pattern)
    {
        | pattern is VarPattern =>
            <[
                def $(pattern.Name) = item;
                $body
            ]>

        | pattern =>
            <[
                match (item)
                {
                    | $(pattern) => $body
                    | _          => ()
                }
            ]>
    }
}

rewriter GenericIEnumirableForEach for ForEach
when ConvertibleTo(collection.Type, IEnumerable[_]);
{
    <[
        using (enum = ($collection).GetEnumerator())
        {
            while (enum.MoveNext())
            {
                def item = enum.Current;
                $(RewriteForeachBody(this));
            }
        }
    ]>
}

RewriteForeachBody один на всех. VarPattern см тут
Автор: WolfHound
Дата: 02.06.11
.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[4]: Размышления о типизаторе для Н2
От: VladD2 Российская Империя www.nemerle.org
Дата: 09.06.11 15:04
Оценка:
Здравствуйте, WolfHound, Вы писали:

WH>Это вариант я просто не рассматривал.

WH>Для этого придется чуток усложнить.
WH>
WH>ast ForEach : Expression
WH>{
WH>    syntax "foreach" "(" pattern "in" collection ")" body;
WH>    pattern    : Pattern;
WH>    collection : Expression;
WH>    body       : Expression | MatchBody;
WH>}
WH>typing
WH>{
WH>    CollectionItemType(collection.Type, ItemType);
WH>    pattern.InType = ItemType;
WH>    scope body add VarsFromPatternType(pattern.Type);
WH>    Type = #void;
WH>    {
WH>        body is Expression;
WH>        ConvertibleTo(body.Type, #void);
WH>    |
WH>        body is MatchBody;
WH>        body.InType = ItemType;
WH>        ConvertibleTo(body.Type, #void);
WH>    }
WH>}
WH>


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

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

WH>
WH>RewriteForeachBody(fe : ForEach) : Expression
WH>{
WH>    def body = match (fe.Body)
WH>    {
WH>        | body is Expression => body
WH>        | body is MatchBody  => <[ match (item) $body ]>
WH>    }
WH>    match (fe.pattern)
WH>    {
WH>        | pattern is VarPattern =>
WH>            <[
WH>                def $(pattern.Name) = item;
WH>                $body
WH>            ]>

WH>        | pattern =>
WH>            <[
WH>                match (item)
WH>                {
WH>                    | $(pattern) => $body
WH>                    | _          => ()
WH>                }
WH>            ]>
WH>    }
WH>}

WH>rewriter GenericIEnumirableForEach for ForEach
WH>when ConvertibleTo(collection.Type, IEnumerable[_]);
WH>{
WH>    <[
WH>        using (enum = ($collection).GetEnumerator())
WH>        {
WH>            while (enum.MoveNext())
WH>            {
WH>                def item = enum.Current;
WH>                $(RewriteForeachBody(this));
WH>            }
WH>        }
WH>    ]>
WH>}
WH>


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

Получается, что мы сделали ряд никому не нужных действий.

Плюс остается вопрос — как генерируется TAST (конечный код)? Ведь именно он нужен в конечном итоге.

WH>RewriteForeachBody один на всех.


Это и сейчас так.

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

WH> VarPattern см тут
Автор: WolfHound
Дата: 02.06.11
.


Там вообще какая-то каша.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[5]: Размышления о типизаторе для Н2
От: WolfHound  
Дата: 09.06.11 15:58
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>То что ты демонстрируешь — это банальное очковтирательство. Погляди внимательно на мой вариант, а еще лучше на "тот ужасный код" что есть в Н1. Там ест куча сообщений об ошибках. Без них все это совершенно не интересно.

Ну давай разбираться.
Может я плохо смотрел, но я нашёл ровно 3 сообщения, которые генерирует foreach.

Message.FatalError($<#the syntax is ' "foreach" "(" name "in" collection (with indexName)? ")" body ', got $e#>);
Это не нужно, ибо у нас нормальный парсер.

Message.FatalError("only simple names available in pattern of foreach with direct matching")
Это не нужно, ибо я сделал, так что матчить можно и там и там.
Поведение ровно такое же, как с функциями.
За одно у меня автоматом получилась возможность писать _ вместо имени переменной в foreach.

Осталось:
Message.Error($"collection in foreach must be an array or type implementing enumerator pattern, $guess");
Message.Hint("try specifing the type directly using 'expr : SomeType'");

Это можно переписать 1 в 1.
    CollectionItemType(collection.Type, ItemType) else
        error "collection in foreach must be an array or type implementing enumerator pattern"
        hint "try specifing the type directly using 'expr : SomeType'";

Итого +2 строки.
Как добавить guess я еще подумаю. Но ИМХО не очень-то он и нужен.

VD>Тоже самое относится к типизации паттернов. Там вообще какие-то игрушечные потягужки не имеющие ничего общего с реальностью.

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

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

Никуда ничего не будет выкинуто.
Основная типизация была внутри body.
Он вся сохраниться.
Типизация pattern'а тоже сохранится.
Типизировать будут только сгенерированные конструкции.

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

VD>Получается, что мы сделали ряд никому не нужных действий.

Это твои фантазии.

VD>Плюс остается вопрос — как генерируется TAST (конечный код)? Ведь именно он нужен в конечном итоге.

1)Даже без переписывания это уже TAST. Ибо у меня все типизаронанно.
2)Переписывание будет происходить пока не останется TAST понятный текущему бекенду.

И главное в моем подходе TAST в том виде как понимаешь, его ты нет.
Это просто лишняя сущность.
Ты хочешь сделать немерле++. Я хочу действительно универсальное решение.

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

Но при этом люди смогут его выкинуть и жить без него, если оно им не нужно.

WH>> VarPattern см тут
Автор: WolfHound
Дата: 02.06.11
.

VD>Там вообще какая-то каша.
А может ты, наконец, сформулируешь внятный вопрос?
Там все просто.
InType это тип выражения которое матчит паттерн.
Type это набор имен переменных и их типов которые связываются внутри паттерна.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[6]: Размышления о типизаторе для Н2
От: VladD2 Российская Империя www.nemerle.org
Дата: 10.06.11 13:47
Оценка:
Здравствуйте, WolfHound, Вы писали:

WH>>> VarPattern см тут
Автор: WolfHound
Дата: 02.06.11
.

VD>>Там вообще какая-то каша.
WH>А может ты, наконец, сформулируешь внятный вопрос?

ОК. Начать надо с того чтобы ты внимально прочитал вот это
Автор(ы): Михаил Купаев (Kupaev)
Дата: 14.03.2005
Поиск в Google по словам "как писать статьи" выдает 664 страницы. Статьи с таким названием писали столь уважаемые люди, как Г.А. Шенгели, А.А.Шалыто и др. Но в целом, 664 страницы — это, конечно, перебор. Понятно, что большая часть этого моря писанины сочинена людьми, писать статьи не умеющими. Если бы они умели писать статьи, они их писали бы, а не учили других. Признаюсь честно – я не знаю, как надо писать статьи. Зато за время своего редакторства я насмотрелся на такое количество уродцев, которого хватило бы на пару питерских Кунсткамер, и еще осталось бы на несколько курортных выставок. Поэтому я достаточно хорошо представляю себе, чего при этом делать не нужно. Вот об этом-то я и попытаюсь рассказать...
. Особенно раздел Телепатия на марше, или сага об утюгах
Автор(ы): Михаил Купаев (Kupaev)
Дата: 14.03.2005
Поиск в Google по словам "как писать статьи" выдает 664 страницы. Статьи с таким названием писали столь уважаемые люди, как Г.А. Шенгели, А.А.Шалыто и др. Но в целом, 664 страницы — это, конечно, перебор. Понятно, что большая часть этого моря писанины сочинена людьми, писать статьи не умеющими. Если бы они умели писать статьи, они их писали бы, а не учили других. Признаюсь честно – я не знаю, как надо писать статьи. Зато за время своего редакторства я насмотрелся на такое количество уродцев, которого хватило бы на пару питерских Кунсткамер, и еще осталось бы на несколько курортных выставок. Поэтому я достаточно хорошо представляю себе, чего при этом делать не нужно. Вот об этом-то я и попытаюсь рассказать...
.
Потом нужно внимательно изучить вот это. После этого надо сделать еще один подход и описать реальную реализацию типизации паттернов в которой будут все (или хотя бы большая часть) сообщения об ошибках что есть в последней ссылке и преобразование вот в этот вариант (как результат процесса типизации):
  public variant Pattern : Located
  {
    | Wildcard
    | As          { pat : Pattern; decl : LocalValue; }
    | HasType     { typ : FixedType; }
    | Tuple       { args : list [Pattern]; }
    | Record      { args : list [IMember * Pattern]; }
    | Application { name : TypeInfo; arg : Pattern; }
    | Enum        { fld : IField; val : Nemerle.Compiler.Literal; }
    | Literal     { lit : Nemerle.Compiler.Literal; }
    | Error

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

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

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

Отдельная претензия к синтаксису. Прологовские правила (они же паттерн-матчинг в обе стороны) основаны на том факте, что переменные имеют отличия в синтаксисе от атомов и термов. По сему в твоих примерах постоянный конфликт меду именами вводимыми в паттернах и внешними именами. Этот конфликт надо разрешать. То что показывал я такого конфликта не имеет, так как мои паттерны не могут ссылаться на внешние переменные. У меня в коде "collection as x" — x — это всегда новая переменная. У тебя же явного синтаксиса введения переменных нет, а значит на лицо конфликт.

Теперь про in/out. Это не понятно, да и не красиво. out-тип может быть только один. По сему описывать явно out-тип бессмысленно. Само применение in/out выглядит дико, непривычно и многословно. По сему имеет смысл всегда иметь один out-тип и использовать для его идентификации стандартный синтаксис. Идентифицировать out-типы правил можно по их именам (как в моих примерах). in-типы надо как-то описывать. Но это уже больше похоже на описание параметров.

WH>Там все просто.

WH>InType это тип выражения которое матчит паттерн.
WH>Type это набор имен переменных и их типов которые связываются внутри паттерна.

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

Типизация паттерна должна связывать все выражение в единое дерево. Скажем, если у нас есть:
match (x)
{
  | pattern1 => e1
  | pattern2 => e2
}

то pattern1 и pattern2 должны иметь свои типы. И тип "x" должен быть связан с типами этих паттернов весьма не тривиальным образом. Нетривиальность проистекает из-за того, что паттерны могут up-cast-ить выражения. Причем up-cast-иться могут не только сами паттерны, но и их части. Возможность такого up-cast-та нужно проверять во время типизации.

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

Ну, а то что ты продемонстрировал никак не тянет на реальную типизацию паттернов. Так что внимательно изучи то как типизация паттернов делается сейчас и попробуй создать более детальный пример в котором будет генерация TAST, выдача всех возможных сообщений об ошибках, проверка возможности up-cast-ов и т.п.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[6]: Размышления о типизаторе для Н2
От: VladD2 Российская Империя www.nemerle.org
Дата: 10.06.11 14:56
Оценка:
Здравствуйте, WolfHound, Вы писали:

WH>Ну давай разбираться.

WH>Может я плохо смотрел, но я нашёл ровно 3 сообщения, которые генерирует foreach.

А ты смотри спецификацию C#. Там прямо описаны сообщения об ошибках которые надо выдавать и когда их надо выдавать.

The compile-time processing of a foreach statement first determines the collection type, enumerator type and element type of the expression. This determination proceeds as follows:
• If the type X of expression is an array type then there is an implicit reference conversion from X to the System.Collections.IEnumerable interface (since System.Array implements this interface). The collection type is the System.Collections.IEnumerable interface, the enumerator type is the System.Collections.IEnumerator interface and the element type is the element type of the array type X.
• Otherwise, determine whether the type X has an appropriate GetEnumerator method:
o Perform member lookup on the type X with identifier GetEnumerator and no type arguments. If the member lookup does not produce a match, or it produces an ambiguity, or produces a match that is not a method group, check for an enumerable interface as described below. It is recommended that a warning be issued if member lookup produces anything except a method group or no match.
o Perform overload resolution using the resulting method group and an empty argument list. If overload resolution results in no applicable methods, results in an ambiguity, or results in a single best method but that method is either static or not public, check for an enumerable interface as described below. It is recommended that a warning be issued if overload resolution produces anything except an unambiguous public instance method or no applicable methods.
o If the return type E of the GetEnumerator method is not a class, struct or interface type, an error is produced and no further steps are taken.
o Member lookup is performed on E with the identifier Current and no type arguments. If the member lookup produces no match, the result is an error, or the result is anything except a public instance property that permits reading, an error is produced and no further steps are taken.
o Member lookup is performed on E with the identifier MoveNext and no type arguments. If the member lookup produces no match, the result is an error, or the result is anything except a method group, an error is produced and no further steps are taken.
o Overload resolution is performed on the method group with an empty argument list. If overload resolution results in no applicable methods, results in an ambiguity, or results in a single best method but that method is either static or not public, or its return type is not bool, an error is produced and no further steps are taken.
o The collection type is X, the enumerator type is E, and the element type is the type of the Current property.
• Otherwise, check for an enumerable interface:
o If there is exactly one type T such that there is an implicit conversion from X to the interface System.Collections.Generic.IEnumerable<T>, then the collection type is this interface, the enumerator type is the interface System.Collections.Generic.IEnumerator<T>, and the element type is T.
o Otherwise, if there is more than one such type T, then an error is produced and no further steps are taken.
o Otherwise, if there is an implicit conversion from X to the System.Collections.IEnumerable interface, then the collection type is this interface, the enumerator type is the interface System.Collections.IEnumerator, and the element type is object.
o Otherwise, an error is produced and no further steps are taken.


WH>Message.FatalError($<#the syntax is ' "foreach" "(" name "in" collection (with indexName)? ")" body ', got $e#>);

WH>Это не нужно, ибо у нас нормальный парсер.

+1

WH>Message.FatalError("only simple names available in pattern of foreach with direct matching")

WH>Это не нужно, ибо я сделал, так что матчить можно и там и там.

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

WH>Осталось:

WH>Message.Error($"collection in foreach must be an array or type implementing enumerator pattern, $guess");
WH>Message.Hint("try specifing the type directly using 'expr : SomeType'");

WH>Это можно переписать 1 в 1.

WH>
WH>    CollectionItemType(collection.Type, ItemType) else
WH>        error "collection in foreach must be an array or type implementing enumerator pattern"
WH>        hint "try specifing the type directly using 'expr : SomeType'";
WH>


Я так и не увидел полноценного анализа реализации паттерна перечислитель. Только в нем будет штуки 3 сообщения об ошибке.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[7]: Размышления о типизаторе для Н2
От: WolfHound  
Дата: 10.06.11 16:12
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>ОК. Начать надо с того чтобы ты внимально прочитал вот это
Автор(ы): Михаил Купаев (Kupaev)
Дата: 14.03.2005
Поиск в Google по словам "как писать статьи" выдает 664 страницы. Статьи с таким названием писали столь уважаемые люди, как Г.А. Шенгели, А.А.Шалыто и др. Но в целом, 664 страницы — это, конечно, перебор. Понятно, что большая часть этого моря писанины сочинена людьми, писать статьи не умеющими. Если бы они умели писать статьи, они их писали бы, а не учили других. Признаюсь честно – я не знаю, как надо писать статьи. Зато за время своего редакторства я насмотрелся на такое количество уродцев, которого хватило бы на пару питерских Кунсткамер, и еще осталось бы на несколько курортных выставок. Поэтому я достаточно хорошо представляю себе, чего при этом делать не нужно. Вот об этом-то я и попытаюсь рассказать...
. Особенно раздел Телепатия на марше, или сага об утюгах
Автор(ы): Михаил Купаев (Kupaev)
Дата: 14.03.2005
Поиск в Google по словам "как писать статьи" выдает 664 страницы. Статьи с таким названием писали столь уважаемые люди, как Г.А. Шенгели, А.А.Шалыто и др. Но в целом, 664 страницы — это, конечно, перебор. Понятно, что большая часть этого моря писанины сочинена людьми, писать статьи не умеющими. Если бы они умели писать статьи, они их писали бы, а не учили других. Признаюсь честно – я не знаю, как надо писать статьи. Зато за время своего редакторства я насмотрелся на такое количество уродцев, которого хватило бы на пару питерских Кунсткамер, и еще осталось бы на несколько курортных выставок. Поэтому я достаточно хорошо представляю себе, чего при этом делать не нужно. Вот об этом-то я и попытаюсь рассказать...
.

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

Например: У тебя в голове полная каша на тему того где заканчивается синтаксис и начинается семантика.
Для тебя и вывод типов и кодогенерация это семантический анализ.
Но это не верное представление.
Вывод типов это часть синтаксического анализа.
Ибо именно синтаксический анализ занимается тем, что отвечает на вопросы: Принадлежит ли текст языку? и На основе каких именно правил языка получился данный текст?
А семантический анализ уже думает, что с этой кучей ответов (на второй вопрос) делать.

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

VD>Потом нужно внимательно изучить вот это.

И что я должен увидеть в этой куче деревьев? Леса за ними не видно.

VD> После этого надо сделать еще один подход и описать реальную реализацию типизации паттернов в которой будут все (или хотя бы большая часть) сообщения об ошибках что есть в последней ссылке и

Там есть все ошибки, которые можно сообщить для тех паттернов, которые там есть.
Остальным паттернам нужен поиск имен.
Кстати OrPattern и AndPattern в немерле просто отсутствуют.

VD>преобразование вот в этот вариант (как результат процесса типизации):

1)Это настолько тривиально, что даже скучно.
2)Как результат процесса переписывания в более низкоуровневый язык.

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

VD>Именно описанный выше вариант должен появиться в конце процесса типизации,

Он кстати очень убог.

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

Не должна.
Ты не видишь за деревьями леса и не понимаешь суть вещей.
Прочитай Type Safe Pattern Combinators, by Morten Rhiger.
Там последовательно и очень доходчиво объясняется, откуда берется тип паттерна.
Я просто пошёл чуть дальше и довел это до логического конца, плюс избавился от плясок вокруг системы типов хаскеля.
Если посмотреть, то наверняка можно найти много чего, что по-хорошему должно иметь свои типы.

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

Ну, вставит их очередной проход трансформации.
Делов то.
Я вообще не понимаю, что тут обсуждать.

VD>Отдельная претензия к синтаксису.

Повторяю сотый раз: Синтаксис меня на донном этапе не волнует. Совсем.

VD>Теперь про in/out. Это не понятно, да и не красиво. out-тип может быть только один.

Это не правда.
Выходных параметров у предиката может быть больше одного.

VD>То что ты называешь типом паттерна — это не тип, а нечто вроде вариантного типа Pattern описанного мной выше. Вот его ты и должен получить. Причем со всеми деталями. А их там не мало.

Ничего ты не понял. И что самое печально даже не попытался.
Тип паттерна это одно. Твой вариантный тип другое.
Разница такая же, как между int и деревом выражения 1 + 2 * 3.

VD>А то что паттерн порождает еще и список переменных — это уже к типу отношения не имеет. Это имеет отношение к списку переменных, разрешению имен и т.п., но не к типизации.

1)Это и есть тип паттерна.
Или более точно
Тип -> Словарь[Имя, Тип]

Те паттрен [a, b] имеет свой самостоятельный тип list[T] -> { a : T; b : T; }
Ни с каким выражением его унифицировать нельзя. Это всё равно что унифицировать яблоки с жирафами.

2)Разрешение имен это неотъемлемая часть типизации.

VD>Типизация паттерна должна связывать все выражение в единое дерево. Скажем, если у нас есть:

Не путай типизацию паттерна и типизацию match'а. Это разные вещи.

VD>то pattern1 и pattern2 должны иметь свои типы. И тип "x" должен быть связан с типами этих паттернов весьма не тривиальным образом. Нетривиальность проистекает из-за того, что паттерны могут up-cast-ить выражения. Причем up-cast-иться могут не только сами паттерны, но и их части. Возможность такого up-cast-та нужно проверять во время типизации.

Искаропки.
Просто вместо
lPattern.InType = InType;
Нужно писать
ConvertibleTo(InType, lPattern.InType);

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

Нет. Тип паттерна это тип паттерна.

VD>Ну, а то что ты продемонстрировал никак не тянет на реальную типизацию паттернов.

Просто ты не понял что это.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[8]: Размышления о типизаторе для Н2
От: VladD2 Российская Империя www.nemerle.org
Дата: 10.06.11 16:20
Оценка:
Здравствуйте, WolfHound, Вы писали:

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


VD>>ОК. Начать надо с того чтобы ты внимально прочитал вот это
Автор(ы): Михаил Купаев (Kupaev)
Дата: 14.03.2005
Поиск в Google по словам "как писать статьи" выдает 664 страницы. Статьи с таким названием писали столь уважаемые люди, как Г.А. Шенгели, А.А.Шалыто и др. Но в целом, 664 страницы — это, конечно, перебор. Понятно, что большая часть этого моря писанины сочинена людьми, писать статьи не умеющими. Если бы они умели писать статьи, они их писали бы, а не учили других. Признаюсь честно – я не знаю, как надо писать статьи. Зато за время своего редакторства я насмотрелся на такое количество уродцев, которого хватило бы на пару питерских Кунсткамер, и еще осталось бы на несколько курортных выставок. Поэтому я достаточно хорошо представляю себе, чего при этом делать не нужно. Вот об этом-то я и попытаюсь рассказать...
. Особенно раздел Телепатия на марше, или сага об утюгах
Автор(ы): Михаил Купаев (Kupaev)
Дата: 14.03.2005
Поиск в Google по словам "как писать статьи" выдает 664 страницы. Статьи с таким названием писали столь уважаемые люди, как Г.А. Шенгели, А.А.Шалыто и др. Но в целом, 664 страницы — это, конечно, перебор. Понятно, что большая часть этого моря писанины сочинена людьми, писать статьи не умеющими. Если бы они умели писать статьи, они их писали бы, а не учили других. Признаюсь честно – я не знаю, как надо писать статьи. Зато за время своего редакторства я насмотрелся на такое количество уродцев, которого хватило бы на пару питерских Кунсткамер, и еще осталось бы на несколько курортных выставок. Поэтому я достаточно хорошо представляю себе, чего при этом делать не нужно. Вот об этом-то я и попытаюсь рассказать...
.

WH>Ты тоже иди что-нибудь прочитай на тему того как не считать других идиотами.

Я что вижу то и говорю. Вижу несвязанное изложение с кучей утюгов и говорю об этом.

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


Ты тоже иди что-нибудь прочитай на тему того как не считать других идиотами. (с)

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


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

Так что, в моем лице, видишь как раз видишь единственного читателя кто тебя пытается понять. И вместо того чтобы все время переходить на обсуждение моей личности тебе бы стоило бы поискать бревно в своем глазу.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[8]: Размышления о типизаторе для Н2
От: VladD2 Российская Империя www.nemerle.org
Дата: 10.06.11 16:24
Оценка:
Здравствуйте, WolfHound, Вы писали:

VD>>Потом нужно внимательно изучить вот это.

WH>И что я должен увидеть в этой куче деревьев? Леса за ними не видно.

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