Данный текст приводится с целью проверки идеи на вшивость. Если кто-то до завтрашнего дня (примерно до 16:00 по Москве) найдет в моих рассуждениях ошибки, то просьба о них сообщить.

Ниже приводится алгоритм в вольном изложении:

Для успешной типизации match нужно чтобы были известны типы всех вхождений match и ожидаемый тип.

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

1. Если унификация проходит успешно, то эти действия (унификация ветвей и ожидаемого значения) повторяются за пределами транзакции, а затем, формируется и возвращается match. Это позволит обрабатывать имеющийся код Nemerle 1.х, со скоростью близкой к скорости прошлой версии.
   
2. Если унификация не проходит, то по завершении транзакции происходит формирование объекта отложенной типизации, в котором ожидается конкретизация не конкретизированных типов (как типов ветвей, так и ожидаемого типа).

2. В объекте отложенной типизации производится проверка конкретизированности не конкретизированных типов (ветвей и ожидаемого).

1. Если все проверяемые типы оказываются конкретизированы какими-то значениями, то для ожидаемого типа и типов ветвей match-а производится подбор оператора неявного приведения типов (вызывается функция AddCastTo()). Это приводит к добавлению неявных приведений типов, или к выдаче сообщений об ошибках. Причем, сообщения должны быть такими как хочет FDSC, так как они будут формироваться под влиянием унификации с выведенным ожидаемым типом.
   
2. Если некоторые из типов так и не конкретизируются до окончания типизации (т.е. когда параметр lastTry фукнции отложенной типизации не станет равнен true), то выдается сообщение об ошибке гласящее, что для оператор match имеет ветви с несовместимыми типами. При этом сообщение указывает на заголовок оператора match (или макроса if). Так же выдаются хинты для каждой из таких ветвей, чтобы было проще понять какие из ветвей несовместимы и какие типы в них вывелись.

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

VD>Если все проверяемые типы оказываются конкретизированы какими-то значениями, то для ожидаемого типа и типов ветвей match-а производится подбор оператора неявного приведения типов (вызывается функция AddCastTo()). Это приводит к добавлению неявных приведений типов, или к выдаче сообщений об ошибках. Причем, сообщения должны быть такими как хочет FDSC, так как они будут формироваться под влиянием унификации с выведенным ожидаемым типом.

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

Кроме этого, не очень понятно, как узнать, что match ещё не типизирован, если у него есть ожидаемый тип? (или этот тип обозначен верхней границей, но не зафиксирован?)


Если в пункте 2 тип match вывести не удалось, но унификация с приведением типов веток закончится успешно, разве стоит уходить на пункт 2.2? Ведь нам, в общем-то, ведь не нужно знать ожидаемый тип match.

Вот это точно глупый вопрос:

FDS>Если в пункте 2 тип match вывести не удалось, но унификация с приведением типов веток закончится успешно, разве стоит уходить на пункт 2.2? Ведь нам, в общем-то, ведь не нужно знать ожидаемый тип match.