Здравствуйте, Аноним, Вы писали:
А>macro ttt (b) А>{ А>match type(b) А>| int => write('int'); А>| sring => write('string'); А>}
А>def b='1111'; А>ttt(b); А>или А>ттоже самое, но с функцией... или с более сложным типом...
Этот пример имеет мало общего с рабочим кодом. В этом примере даже строковые литералы указаны не верно. А уж о типах вообще говорить не приходится. То что передается в "match type" вообще не имеет типов на этапе раскрытия.
Работа с типами внутри макросов — это отдельная и очень не простая тема. Конечно, многое можно сделать проще. Но чтобы говорить предметно нужно, все же, разобраться в сути обсуждаемого вопроса.
Например, важно понимать, что типы вычисляются после раскрытия макросов, и то что, макрос может оперировать с типами которые еще не существуют в момент его компиляции. Так же следует понимать, что эквивалентность типов (которая, похоже, подразумевается в данном примере) имеет смысл только к узкому набору типов. Например, она не имеет смысла для дженерик-типов. При работе с типами используется механизм унификации. Причем даже более сложный нежели в Прологе, так как кроме просто унификации есть еще унификация с учетом подтипов/супертипов (в немерле функции для этого называются Require/Provide).
Возможно для них и можно придумать некий синтаксис, но тут есть много нюансов. Например, Require, Provide и Unify меняют состояние графа типов (т.е. имеют побочный эффект). Так что просто так их вызвать нельзя. Есть аналоги с префиксом Try которые выполняют эти операции в рамках транзакции. Но это влияет на эффективность. В общем, много нюансов.
Ну, и самое важное — чтобы работать с типами нужно сначала типизировать выражение. Получить типы из параметров макросов невозможно. Выражения, которые находятся внутри параметров — это нетипизированное AST. Его можно анализировать паттерн-матчингом, то только на предмет структуры.
В общем, чтобы получить реальный ответ на данный вопрос нужно сначала разобраться с имеющейся моделью (и реализацией). Иначе мои слова будут выглядеть непонятным набором терминов.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Аноним, Вы писали:
H>>Вы понимаете как выводятся типы в Nemerle?
А>Да.
А>Строится система логических(ограничений) уравнений и решается.
Эта система потенциально неполная — ввиду того, что изначально код содержит нераскрытые макросы уровня выражений. По мере раскрытия макросов эта система дополняется все новыми ограничениями и переменными типов. Добавьте сюда тот факт, что макросы могут использовать информацию о типах (как, например, это делает foreach) при трансформации кода. В таких условиях сделать не-итерационный процесс вывода типов — невозможно.
И, кстати, не нужно сюда мешать "стадии макросов" — эти стадии имеют отношение лишь к макроатрибутам, и связаны с процессом компиляции AST верхнего уровня (построение иерархии наследования классов, поиск частей классов, и т.п.).
/* иЗвиНите зА неРовнЫй поЧерК */
еще раз о типизации.
От:
Аноним
Дата:
09.04.11 20:39
Оценка:
почему нельзя заменить всю переусложненую на мой взгляд конструкцию с типизацией на match type. В качестве плюса.простое расширение механизма вывода типов до операций и и или. Кроме того уйдут стадии макросов
А>почему нельзя заменить всю переусложненую на мой взгляд конструкцию с типизацией на match type. В качестве плюса.простое расширение механизма вывода типов до операций и и или. Кроме того уйдут стадии макросов
Что за match type ??
Весь плюс Типизации в немерлах -- то что можно не указывать типы там где компилятор сам может определить!
Re[2]: еще раз о типизации.
От:
Аноним
Дата:
09.04.11 20:57
Оценка:
пример.
match type(a)
type(int) write('int')
type(string) write('string')
при раскрытии макроса образуется конструкция эквивалентная точки с занятой в прологе таким образом всегда можно сделать только одну типизацию
Здравствуйте, Аноним, Вы писали:
А>почему нельзя заменить всю переусложненую на мой взгляд конструкцию с типизацией на match type. В качестве плюса.простое расширение механизма вывода типов до операций и и или. Кроме того уйдут стадии макросов
Ничего не понял. Что за конструкция переусложнена? Можно примеры кода?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Аноним, Вы писали:
А>при раскрытии макроса образуется конструкция эквивалентная точки с занятой в прологе таким образом всегда можно сделать только одну типизацию
Вы имеете в виду проблему типизации выражений в контексте макроса, когда еще неизвестен тип выражения?
Предложенный подход, конечно, красивый, но требует отложенных вычислений, ведь на момент работы макроса типизация не окончена (да и не может быть окончена, ведь тело метода еще не сгенерировано до конца). Также он не поддерживает все сценарии работы. Допустим, я хочу просто вывести ворнингом имя типа: тогда матч никак не поможет.
Вообще, ваш подход — специальный случай использования DelayMacro: если тип сейчас неизвестен, мы ждем, пока компилятор его выведет, и матчим тип-результат.
Type match может быть использован как модель API для работы с типами в Немерле 2, в принципе.
Re[2]: еще раз о типизации.
От:
Аноним
Дата:
11.04.11 06:02
Оценка:
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Аноним, Вы писали:
А>>почему нельзя заменить всю переусложненую на мой взгляд конструкцию с типизацией на match type. В качестве плюса.простое расширение механизма вывода типов до операций и и или. Кроме того уйдут стадии макросов
VD>Ничего не понял. Что за конструкция переусложнена? Можно примеры кода?
macro ttt (b)
{
match type(b)
| int => write('int');
| sring => write('string');
}
def b='1111';
ttt(b);
или
ттоже самое, но с функцией... или с более сложным типом...
А>ттоже самое, но с функцией... или с более сложным типом...
Сейчас аналогичный матч можно написать с FixedType в обработчике функции TransformWhenAllTypesWouldBeInfered (в Typer-е).
/* иЗвиНите зА неРовнЫй поЧерК */
Re[4]: еще раз о типизации.
От:
Аноним
Дата:
11.04.11 07:16
Оценка:
Здравствуйте, hardcase, Вы писали:
H>Здравствуйте, Аноним, Вы писали:
А>>ттоже самое, но с функцией... или с более сложным типом...
H>Сейчас аналогичный матч можно написать с FixedType в обработчике функции TransformWhenAllTypesWouldBeInfered (в Typer-е).
вот это я и называю переусложнение.
есть ли случаи когда можно написать не так?
Здравствуйте, Аноним, Вы писали:
А>вот это я и называю переусложнение. А>есть ли случаи когда можно написать не так?
Вы понимаете как выводятся типы в Nemerle?
/* иЗвиНите зА неРовнЫй поЧерК */
Re[6]: еще раз о типизации.
От:
Аноним
Дата:
11.04.11 09:06
Оценка:
Здравствуйте, hardcase, Вы писали:
H>Здравствуйте, Аноним, Вы писали:
А>>вот это я и называю переусложнение. А>>есть ли случаи когда можно написать не так?
H>Вы понимаете как выводятся типы в Nemerle?
Да.
Строится система логических(ограничений) уравнений и решается.
Re[8]: еще раз о типизации.
От:
Аноним
Дата:
11.04.11 10:44
Оценка:
Здравствуйте, hardcase, Вы писали:
H>Здравствуйте, Аноним, Вы писали:
H>>>Вы понимаете как выводятся типы в Nemerle?
А>>Да.
А>>Строится система логических(ограничений) уравнений и решается.
H>Эта система потенциально неполная — ввиду того, что изначально код содержит нераскрытые макросы уровня выражений. По мере раскрытия макросов эта система дополняется все новыми ограничениями и переменными типов. Добавьте сюда тот факт, что макросы могут использовать информацию о типах (как, например, это делает foreach) при трансформации кода. В таких условиях сделать не-итерационный процесс вывода типов — невозможно.
Я это все учитываю. Понимаю. Кстати, это не проблема.
вот решение.
match type(a)
|int => .....
H>И, кстати, не нужно сюда мешать "стадии макросов" — эти стадии имеют отношение лишь к макроатрибутам, и связаны с процессом компиляции AST верхнего уровня (построение иерархии наследования классов, поиск частей классов, и т.п.).
не знал. Интересно.
Здравствуйте, Аноним, Вы писали:
А>Я это все учитываю. Понимаю. Кстати, это не проблема. А>вот решение. А>match type(a) А> |int => .....
Такой синтаксис можно сделать несложным макросом (а возможно даже с помощью ActivePattern-ов), правда ничего принципиально нового он не даст.
/* иЗвиНите зА неРовнЫй поЧерК */
Re[10]: еще раз о типизации.
От:
Аноним
Дата:
11.04.11 12:14
Оценка:
Здравствуйте, BogdanMart, Вы писали:
BM>Здравствуйте, Аноним, Вы писали:
А>>Я это все учитываю. Понимаю. Кстати, это не проблема. А>>вот решение. А>>match type(a) А>> |int => .....
BM>По идеи человек просто хочет синтаксического сахара.
как раз на оборот
Re[10]: еще раз о типизации.
От:
Аноним
Дата:
11.04.11 12:21
Оценка:
Здравствуйте, hardcase, Вы писали:
H>Здравствуйте, Аноним, Вы писали:
А>>Я это все учитываю. Понимаю. Кстати, это не проблема. А>>вот решение. А>>match type(a) А>> |int => .....
H>Такой синтаксис можно сделать несложным макросом (а возможно даже с помощью ActivePattern-ов), правда ничего принципиально нового он не даст.
я как раз говорю что нынешний синтаксис является частью этого.
Здравствуйте, Аноним, Вы писали:
А>я как раз говорю что нынешний синтаксис является частью этого.
Ваше решение неполное. Если мне неизвестен тип на момент компиляции, что мне матчить?
Re[12]: еще раз о типизации.
От:
Аноним
Дата:
11.04.11 13:05
Оценка:
Здравствуйте, catbert, Вы писали:
C>Здравствуйте, Аноним, Вы писали:
А>>я как раз говорю что нынешний синтаксис является частью этого.
C>Ваше решение неполное. Если мне неизвестен тип на момент компиляции, что мне матчить?
просто
<[ match type(a)
| type(int) .....
| type(string) .....
]>
Здравствуйте, Аноним, Вы писали:
C>>Ваше решение неполное. Если мне неизвестен тип на момент компиляции, что мне матчить?
А>просто А><[ match type(a) А>| type(int) ..... А>| type(string) ..... А>]>
Киса, вы говорите загадками.. (простите, не удержался).
Может всетаки расскажете что конкретно предлагаете? Дело в том, что код, аналогичный показанному можно писать:
match(ty : TyVar)
{
| x when x.Equals(<[ttype: System.Int32 ]>) => Message.Hint("int")
| x when x.Equals(<[ttype: System.String ]>) => Message.Hint("string")
| _ => Message.Hint("other")
}
/* иЗвиНите зА неРовнЫй поЧерК */
Re[14]: еще раз о типизации.
От:
Аноним
Дата:
11.04.11 14:13
Оценка:
Здравствуйте, hardcase, Вы писали:
H>Здравствуйте, Аноним, Вы писали:
C>>>Ваше решение неполное. Если мне неизвестен тип на момент компиляции, что мне матчить?
А>>просто А>><[ match type(a) А>>| type(int) ..... А>>| type(string) ..... А>>]>
H>Киса, вы говорите загадками.. (простите, не удержался). H>Может всетаки расскажете что конкретно предлагаете? Дело в том, что код, аналогичный показанному можно писать: H>
H>match(ty : TyVar)
H>{
H> | x when x.Equals(<[ttype: System.Int32 ]>) => Message.Hint("int")
H> | x when x.Equals(<[ttype: System.String ]>) => Message.Hint("string")
H> | _ => Message.Hint("other")
H>}
H>
не спорю, вот только раскрытие проверки типа переменной когда произойдет?
Учтите, что это может быть не только переменная, а например еще и функция с переданными параметрами...
Здравствуйте, Аноним, Вы писали:
А>не спорю, вот только раскрытие проверки типа переменной когда произойдет? А>Учтите, что это может быть не только переменная, а например еще и функция с переданными параметрами...
Ничего не понял.
/* иЗвиНите зА неРовнЫй поЧерК */
Re[16]: еще раз о типизации.
От:
Аноним
Дата:
11.04.11 15:28
Оценка:
Здравствуйте, hardcase, Вы писали:
H>Здравствуйте, Аноним, Вы писали:
А>>не спорю, вот только раскрытие проверки типа переменной когда произойдет? А>>Учтите, что это может быть не только переменная, а например еще и функция с переданными параметрами...
H>Ничего не понял.
наверно если покажу как реализовать станет понятнее
match type(a)
|type(int)=>write('int');
|type(string)=>write('string');
надо транслировать не так как вы сейчас, а следующем образом (компилятор вообще не затрагивается)
function ffr1111(a11111:int)
{
write('int');
}
function ffr1111(a11111:string)
{
write('string');
}
ffr1111(a);
теперь даже если a будет результатом функции, то код все равно оттранслируется.
Как я писал ранее это решит много проблем и достаточно вероятно серьезно ускорит компиляцию, так как большенство макросов могут быть оттранслированы изначально (если они чистые)