Здравствуйте, MasterZiv, Вы писали:
MZ>dmz пишет:
>> А вот где бы посмотреть на *простые* (простые — это не окамл с >> хаскеллом, пожалуйста) скриптовые языки со >> статической типизацией? Т.е. что бы тип всех переменных выводится в
MZ>Гы, Java !
Где там тип переменных выводится? Там компилятор такой тупой, что ему два раза говорить тип надо — он с первого не понимает:
MySuperType mySuperObject = new MySuperType();
Re: А вот скриптовые языки со статической типизацией?
dmz>А вот где бы посмотреть на простые (простые — это не окамл с хаскеллом, пожалуйста) скриптовые языки со dmz>статической типизацией? Т.е. что бы тип всех переменных выводится в компайл-тайме. Нужен источник вдохновения.
EiC — C interpreter : http://www.linuxbox.com/tiki/node/149
Вывода типов конечно нет. Но я бы не сказал что динамическая типизация "оборачивается усложнением vm и разрастанием кода и memory footprint".
Re: А вот скриптовые языки со статической типизацией?
Здравствуйте, dmz, Вы писали:
dmz>что бы тип всех переменных выводится в компайл-тайме. dmz>Интересно, можно ли сделать легковесную (простую в реализации) статическую систему типов.
что такое "статическая система типов"?
V8 engine используемый в Chrome говорят делает вывод типов (когда может). При этом он может строить
оптимальную структуру кода. Например для инкремента i:
var i = 1; ++i;
может сгенерирвать BC_INC_INT вместо BC_INC_VAR. Но на всю глубину AST вывод типов построить достаточно сложно (сложная вычислительная задача). Т.е. где-то типы тебе таки нужно объявлять чтобы получить разумную скорость компиляции.
Например параметры функций наверное должны быть типизированы чтобы не анализировать все call paths.
Re[2]: А вот скриптовые языки со статической типизацией?
Здравствуйте, c-smile, Вы писали:
CS>Здравствуйте, dmz, Вы писали:
dmz>>что бы тип всех переменных выводится в компайл-тайме. dmz>>Интересно, можно ли сделать легковесную (простую в реализации) статическую систему типов.
CS>что такое "статическая система типов"?
def main()
{
local b = "PECHEN TRESKI";
local c;
c = b + 1;
}
||
\/
FFFF {3} {3} JMP 000F ; [0D 13 00]
0003 {2} {2} 0011: DATA 000D ; [0D 00] len: 13 'PECHEN TRESKI'
FFFF {2} {2} DATA 4550 ; [50 45]
FFFF {2} {2} DATA 4843 ; [43 48]
FFFF {2} {2} DATA 4E45 ; [45 4E]
FFFF {2} {2} DATA 5420 ; [20 54]
FFFF {2} {2} DATA 4552 ; [52 45]
FFFF {2} {2} DATA 4B53 ; [53 4B]
FFFF {2} {2} DATA 0049 ; [49 00]
0013 {3} {3} 000F: LIT 0000 ; [29 00 00] b#0 -- main
FFFF {3} {3} LIT 0000 ; [29 00 00] c#0
FFFF {3} {3} SF 0001 ; [07 01 00] main
FFFF {1} {1} NOP ; [00 ]
FFFF {3} {3} ADDROF 0011 ; [29 03 00]
FFFF {1} {1} STORE0 ; [34 ] -> b#0
FFFF {1} {1} LOAD0 ; [2C ] b#0
FFFF {1} {1} INC ; [13 ] <- (*1)
FFFF {1} {1} STORE1 ; [35 ] -> c#0
0024 {1} {1} 0010: DOWN ; [FF ]
(*1) - вот тут, вместо того, что бы сделать что-то полезное, если определена операция (+) (string, int)
или сгенерировать ошибку - мы прибавили к ссылке единицу. нехорошо вышло. но это только проверка типов.
а система типов всплывает, в частности тут. Вот надо мне описать интерфейс с нативными функциями — сейчас это выглядит как-то так:
(* BUILTINS *)
BUILTIN beepvm_do_something do_somethin : вот что мне тут написать, что бы компилятор понял, что возращаемое значение - список списков строк?
...
BUILTIN beepvm_put_char putc(1)
BUILTIN beepvm_put_int put_int(1)
BUILTIN beepvm_put_str puts(1)
BUILTIN beepvm_gc alloc(1) EMIT(ALLOC)
BUILTIN beepvm_gc gc(0) EMIT(GC)
BUILTIN beepvm_gc_cheap gc_cheap(0) EMIT(CGC)
BUILTIN beepvm_dump debug_dump(0) EMIT(DUMP)
CS>Например параметры функций наверное должны быть типизированы чтобы не анализировать все call paths.
не хотелось бы; запись
def function(a:int, b:string)
выглядит уже как-то не по скриптовому. но в крайнем случае могу на это пойти.
Re[10]: А вот скриптовые языки со статической типизацией?
D>(язык условный). Эта функция полиморфна истинным (параметрическим) полиморфизмом. Тип x — под квантором всеобщности, если хочется вывода типов, никуда не деться.
С одной стороны хочется написать, что мне лучше его не надо. С другой стороны, если подумать, то функции (или операции, whatever),
например, работы со списками и массивами неизбежно получаются полифорфными:
local a = [[[1,2],[1,2]],[[1,2],[1,2]]];
a[0] # <- Тип?
a[0][0] # <- Тип ?
собственно, из-за них то все и началось. правда, их можно сделать встроенными, и таким образом, полиморфны будут только те операции, которые встроены в язык.
Re[2]: А вот скриптовые языки со статической типизацией?
CS>EiC — C interpreter : http://www.linuxbox.com/tiki/node/149
CS>Вывода типов конечно нет. Но я бы не сказал что динамическая типизация "оборачивается усложнением vm и разрастанием кода и memory footprint".
Ну как же. Вот у меня стековая машина. 256 16-битных слов стека, 1024 слов кучи. Арифметика обязана быть 16-битной, ну пусть, в крайнем случае, 15-битной — это все равно не спасает.
Динамическая типизация означает, что для каждого значения (на стеке или на куче) мы храним признак его типа, и выполняем операции над ним в зависимости от этого признака. Ну то есть, самое простое — это считать все объектами, а к каждому значению приписать vptr. Допустим, у нас не более 256 разных типов объектов — тогда vptr можно урезать до 1 байта. Правда, боюсь, придется выровнять, так что два. Итого — мы урезали объем доступной скрипту памяти в одном случае на треть, во втором — в два раза.
Далее, сама VM. На TI MSP430F1612, который, допустим будет нижней планкой, на которой будет работать наша система, 55K program flash. Это я к тому, что хранить там таблицу методов на каждый объект — тоже особо не разгуляешься. А в случае генерации кода компилятором, если грамотно выбрать базис инструкций, например для работы с памятью, то добавление новых типов можно будет делать, не трогая код VM вообще, расширяя только компилятор.
Re: А вот скриптовые языки со статической типизацией?
dmz>А вот где бы посмотреть на простые (простые — это не окамл с хаскеллом, пожалуйста) скриптовые языки со dmz>статической типизацией? Т.е. что бы тип всех переменных выводится в компайл-тайме. Нужен источник вдохновения.
Есть простой функциональный (фвп, паттерн матчинг и т. п.) язык со статической типизацией, без вывода типов, но с возможностю полиморфного определения типов (типа шаблонов в C++) это Hope http://www.soi.city.ac.uk/~ross/Hope/ ну и плюс конечно классическое "Функциональное программирование" Филда и Харрисона в котором разжеваны многие детали реализации.
Re[11]: А вот скриптовые языки со статической типизацией?
Здравствуйте, dmz, Вы писали:
dmz>собственно, из-за них то все и началось. правда, их можно сделать встроенными, и таким образом, полиморфны будут
только те операции, которые встроены в язык.
D>>Правда это как раз и есть то, что используют и Хаскелл, и ML dmz>Боюсь, что так.
А чо там бояться?
Вот рекомендую: Luca Cardelli, Basic Polymorphic Type checking. Реализация для простенького языка, ~500 строк на Modula-2.
Re[7]: А вот скриптовые языки со статической типизацией?
M>>Так прикручивай. dmz>Есть мнение, что надо сначала подумать, потом делать. Хотя бы пару дней подумать. Я пока не понимаю, как работает вывод типов, который меня, в общем, устраивает для задачи, вероятно рано или поздно пойму.
Unfortunately, type information is very hard to represent and manipulate efficiently, especially when the underlying type system involves ML-like polymorphic types and module types. A naive implementation can easily add exponential overhead to the compilation and execution of a program.
...
We describe several different ways of representing type variables bound in the term languages and then compare their performance.
Re[3]: А вот скриптовые языки со статической типизацией?
deniok пишет:
> MySuperType mySuperObject = new MySuperType();
1) ну вот тут и вводится. Слева.
2) Это — РАЗНЫЕ типы, вообще-то. Слева — тип переменной-ссылки, справа — тип
значения переменной (объекта).
Но в контексте разговора это, конечно, безполезно — человеку надо как пирмер
посмотреть реализацию, а копаться в спецификациях Java-машины наверное не очень
интересно в этом смысле.
Posted via RSDN NNTP Server 2.1 beta
Re[3]: А вот скриптовые языки со статической типизацией?
Здравствуйте, dmz, Вы писали:
CS>>Например параметры функций наверное должны быть типизированы чтобы не анализировать все call paths.
dmz>не хотелось бы; запись
dmz>
dmz>def function(a:int, b:string)
dmz>
dmz>выглядит уже как-то не по скриптовому. но в крайнем случае могу на это пойти.
Да собственно другого способа и нет. Скажем есть:
def main()
{
local b = "PECHEN TRESKI";
local c = foo("GOLOVA MINTAYA", 1);
local d = foo(2, "KIL`KIN HVOST");
c = b + 1;
}
Что такое эта foo()? Или их две сгенерируется?
И какой тип будут иметь с и d?
Re[4]: А вот скриптовые языки со статической типизацией?
Unfortunately, type information is very hard to represent and manipulate efficiently, especially when the underlying type system involves ML-like polymorphic types and module types. A naive implementation can easily add exponential overhead to the compilation and execution of a program.
Ну, если реализовывать через унификацию, то это специальные программы нужны, чтобы получать экспоненциальное поведение. Если унификацию не использовать, то опять получится, что надо что-то придумывать.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[4]: А вот скриптовые языки со статической типизацией?
CS>Да собственно другого способа и нет. Скажем есть:
local b = "PECHEN TRESKI";
(1) b -> string
local c = foo("GOLOVA MINTAYA", 1);
(2) c -> typeof foo [string, int] -> что там foo возвращает — определяем из словаря, если уже на вызов напарывались, или прямо сейчас определям и кладем в словарь
CS>Что такое эта foo()? Или их две сгенерируется?
Тип foo определим по первому встреченному вызову. При вызове foo типы ее аргументов должны быть выводибельны, иначе type_error.
Очевидно, что придется сделать опциональное декларирование типов на всякие крайние случаи, и вообще надо прочитать
описание хиднли-милнера. Примеры его реализации для игрушечных языков выглядят не страшно.
CS>И какой тип будут иметь с и d?
никакой, так как ошибка типов.
Re[5]: А вот скриптовые языки со статической типизацией?
local d = foo(2, "KIL`KIN HVOST");
type_error: (fun(string,int), int) != (fun(int, string), int)
ну то есть не ошибка в смысле type(d) != type(fun(string,int),?), а в смысле что вызывается функция не с той сигнатурой, с которой определена (парой строк раньше). Не проснулся просто еще.
Re: А вот скриптовые языки со статической типизацией?
CS>>>Что такое эта foo()? Или их две сгенерируется? dmz>>Тип foo определим по первому встреченному вызову.
M>А если один раз встретился foo — то тип можно не проверять, наверняка правильный?
да, выводить foo по его вызову нет смысла, для определения сигнатуры достаточно определения самой foo.
продолжаем курить хиндли-милнера.
Re[7]: А вот скриптовые языки со статической типизацией?
dmz>да, выводить foo по его вызову нет смысла, для определения сигнатуры достаточно определения самой foo.
Не, на самом деле все вхождения идентификатора foo равноправны — цель же не определить тип, а проверить самосогласованность всей программы.
id :: forall a . a -> a
id x = x
foo :: String
foo = id "Вася"-- здесь id мономорфизируется и получает тип String -> String, благодаря вызову с "Васей"
