А вот где бы посмотреть на простые (простые — это не окамл с хаскеллом, пожалуйста) скриптовые языки со
статической типизацией? Т.е. что бы тип всех переменных выводится в компайл-тайме. Нужен источник вдохновения.
Что-то все, какие (из простых) знаю навскидку — с динамической типизацией: tcl, js, lua, ...
Интересно, можно ли сделать легковесную (простую в реализации) статическую систему типов.
Делать динамическую типизацию очень сильно не хочется, т.к. крайняя простота компилятора
оборачивается усложнением vm и разрастанием кода и memory footprint — так как информация
о типах и рантайм полиморфизм, в общем, обходятся дороговато.
Здравствуйте, dmz, Вы писали:
dmz>А вот где бы посмотреть на простые (простые — это не окамл с хаскеллом, пожалуйста) скриптовые языки со dmz>статической типизацией? Т.е. что бы тип всех переменных выводится в компайл-тайме. Нужен источник вдохновения.
См.: Boo (http://boo.codehaus.org/).
Sapienti sat!
Re: А вот скриптовые языки со статической типизацией?
dmz>А вот где бы посмотреть на простые (простые — это не окамл с хаскеллом, пожалуйста) скриптовые языки со dmz>статической типизацией? Т.е. что бы тип всех переменных выводится в компайл-тайме. Нужен источник вдохновения.
Здравствуйте, dmz, Вы писали:
dmz>А вот где бы посмотреть на простые (простые — это не окамл с хаскеллом, пожалуйста) скриптовые языки со dmz>статической типизацией? Т.е. что бы тип всех переменных выводится в компайл-тайме. Нужен источник вдохновения.
Basic.
dmz>Что-то все, какие (из простых) знаю навскидку — с динамической типизацией: tcl, js, lua, ...
Это, простите, интерпретаторы. А тебе компилятор нужен.
dmz>>А вот где бы посмотреть на простые (простые — это не окамл с хаскеллом, пожалуйста) скриптовые языки со dmz>>статической типизацией? Т.е. что бы тип всех переменных выводится в компайл-тайме. Нужен источник вдохновения.
M>Basic.
Я так думаю, для изучения его исходники малопригодны.
dmz>>Что-то все, какие (из простых) знаю навскидку — с динамической типизацией: tcl, js, lua, ...
M>Это, простите, интерпретаторы. А тебе компилятор нужен.
lua компилируется.
Re[2]: А вот скриптовые языки со статической типизацией?
Попробую пофтыкать, но что-то мне казалось, что это вообще интерпретатор.
Z>Можно заодно(с Haxe) NekoML посмотреть — но он не сильно проще Caml light. Или http://www.ccs.neu.edu/home/samth/typed-scheme/
Кстати, у меня оно даже валяется, но что-то казалось, что там динамическая типизация. Посмотрел в исходники — и правда статическая.
Re[3]: А вот скриптовые языки со статической типизацией?
Здравствуйте, dmz, Вы писали:
Z>>TAPL! Z>>http://www.cis.upenn.edu/~bcpierce/tapl/
dmz>Заказал, но систему типов придется реализовать до того, как она приедет с амазона
Здравствуйте, dmz, Вы писали:
dmz>>>Что-то все, какие (из простых) знаю навскидку — с динамической типизацией: tcl, js, lua, ...
M>>Это, простите, интерпретаторы. А тебе компилятор нужен.
dmz>lua компилируется.
Разница между современным компилятором и интерпретатором не очень велика. Как правило в интерпретатор встроено некое подобие виртуальной машины. Программа предварительно компилируется в байт-код, а потом исполняется на виртуальной машине. Единственное -- пожалуй только не оптимизируется так подробно как при компиляции. Ибо долго это, а для интерпретатора время запуска программы бывает критичным.
А с какой целью вообще возникла такая потребность, дизайн языка разрабатываете или хотите отдельные вопросы реализации прояснить ?
Re[4]: А вот скриптовые языки со статической типизацией?
J>А с какой целью вообще возникла такая потребность, дизайн языка разрабатываете или хотите отдельные вопросы реализации прояснить ?
Язык есть, надо типизацию прикрутить. Статическую, к сожалению.
Re[5]: А вот скриптовые языки со статической типизацией?
Здравствуйте, dmz, Вы писали:
J>>А с какой целью вообще возникла такая потребность, дизайн языка разрабатываете или хотите отдельные вопросы реализации прояснить ? dmz>Язык есть, надо типизацию прикрутить. Статическую, к сожалению.
Так прикручивай.
Не бывает типизации "вообще".
Она зависит от твоего языка. Если в нём нет структур, наследования, полиморфизма, параметризации типов и пр. — только фиксированный набор типов — это один случай. Если есть структуры — другой. Если есть наследование — третий. Если функции как first class объекты — четвёртый. И так далее.
И в зависимости от твоего языка — тебе и надо искать примеры реализации.
M>Так прикручивай.
Есть мнение, что надо сначала подумать, потом делать. Хотя бы пару дней подумать. Я пока не понимаю, как работает вывод типов, который меня, в общем, устраивает для задачи, вероятно рано или поздно пойму.
M>И в зависимости от твоего языка — тебе и надо искать примеры реализации.
Вот именно этим я и занимаюсь.
Re[7]: А вот скриптовые языки со статической типизацией?
Здравствуйте, dmz, Вы писали:
M>>Так прикручивай. dmz>Есть мнение, что надо сначала подумать, потом делать. Хотя бы пару дней подумать. Я пока не понимаю, как работает вывод типов, который меня, в общем, устраивает для задачи, вероятно рано или поздно пойму.
То есть ты ещё не знаешь, какая тебе нужна типизация.
M>>И в зависимости от твоего языка — тебе и надо искать примеры реализации. dmz>Вот именно этим я и занимаюсь.
M>То есть ты ещё не знаешь, какая тебе нужна типизация.
Боюсь, что знаю. Вообще, тут линк на умный книжка публиковали, если что.
И короче, этот топик не обсуждение моей скромной персоны. Линки, которых сюда бросили — очень помогли, тот же Neko.
Я к тому, что места для флейма тут нет.
Re[7]: А вот скриптовые языки со статической типизацией?
M>>Так прикручивай. dmz>Есть мнение, что надо сначала подумать, потом делать. Хотя бы пару дней подумать. Я пока не понимаю, как работает вывод типов, который меня, в общем, устраивает для задачи, вероятно рано или поздно пойму.
Полный вывод типов работает для довольно узких классов систем типов (и языков). Выше дали ссылку на Пирса, 22 глава, Type Reconstruction, как раз описывает самый знаменитый алгоритм вывода типов, Хиндли-Милнера. Правда это как раз и есть то, что используют и Хаскелл, и ML
Re[8]: А вот скриптовые языки со статической типизацией?
D>>Правда это как раз и есть то, что используют и Хаскелл, и ML dmz>Боюсь, что так.
Беда (или счастье, это как посмотреть) в том, что полиморфизм — абсолютно естественная вещь:
function id ( x )
{
return x;
}
(язык условный). Эта функция полиморфна истинным (параметрическим) полиморфизмом. Тип x — под квантором всеобщности, если хочется вывода типов, никуда не деться.
Re: А вот скриптовые языки со статической типизацией?
dmz пишет:
> А вот где бы посмотреть на *простые* (простые — это не окамл с > хаскеллом, пожалуйста) скриптовые языки со > статической типизацией? Т.е. что бы тип всех переменных выводится в
Гы, Java !
Posted via RSDN NNTP Server 2.1 beta
Re[2]: А вот скриптовые языки со статической типизацией?
Здравствуйте, 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, благодаря вызову с "Васей"
Re[8]: А вот скриптовые языки со статической типизацией?
D>Не, на самом деле все вхождения идентификатора foo равноправны — цель же не определить тип, а проверить самосогласованность всей программы.
Ну это зависит от размера контекста, который мы можем используем при выводе типа. В принципе же, можно ведь потребовать, что
бы тип выводился из одного определения — тогда если тип чего-либо не выводится из операций, то можно потребовать его явно специфицировать.
Просто я как-то опасаюсь, что если вывод типов каждого узла это
let type_of ast_node ast = ...
то, например, поиск всех вызовов функции при ее определении может дороговато обходиться. Хотя...
Re[9]: А вот скриптовые языки со статической типизацией?
Здравствуйте, dmz, Вы писали:
dmz>А вот где бы посмотреть на простые (простые — это не окамл с хаскеллом, пожалуйста) скриптовые языки со dmz>статической типизацией? Т.е. что бы тип всех переменных выводится в компайл-тайме. Нужен источник вдохновения.
source forge, поиск среди проектов по "type inference". навскидку — kaya
Люди, я люблю вас! Будьте бдительны!!!
Re: А вот скриптовые языки со статической типизацией?
dmz>А вот где бы посмотреть на простые (простые — это не окамл с хаскеллом, пожалуйста) скриптовые языки со dmz>статической типизацией? Т.е. что бы тип всех переменных выводится в компайл-тайме. Нужен источник вдохновения.
dmz>>А вот где бы посмотреть на простые (простые — это не окамл с хаскеллом, пожалуйста) скриптовые языки со dmz>>статической типизацией? Т.е. что бы тип всех переменных выводится в компайл-тайме. Нужен источник вдохновения.
FR>http://min-caml.sourceforge.net/index-e.html
Cкоро наверное, можно будет смело повесить сюда ссылку и на бип. Типы выводятся, в т.ч. и полиморфных функций.
Re[2]: А вот скриптовые языки со статической типизацией?
dmz>>А вот где бы посмотреть на простые (простые — это не окамл с хаскеллом, пожалуйста) скриптовые языки со dmz>>статической типизацией? Т.е. что бы тип всех переменных выводится в компайл-тайме. Нужен источник вдохновения.
FR>http://min-caml.sourceforge.net/index-e.html
Очень крутые товарищи. В учебных целях разработать компилятор ML с нативной кодогенерацией, код которого работает быстрее ocamltop
и часто — быстрее gcc — это, конечно, мощно.
Re[3]: А вот скриптовые языки со статической типизацией?
Здравствуйте, dmz, Вы писали:
dmz>Очень крутые товарищи. В учебных целях разработать компилятор ML с нативной кодогенерацией, код которого работает быстрее ocamltop dmz>и часто — быстрее gcc — это, конечно, мощно.
реклама — двигатель прогресса
Люди, я люблю вас! Будьте бдительны!!!
Re[3]: А вот скриптовые языки со статической типизацией?
Здравствуйте, dmz, Вы писали:
dmz>Очень крутые товарищи. В учебных целях разработать компилятор ML с нативной кодогенерацией, код которого работает быстрее ocamltop dmz>и часто — быстрее gcc — это, конечно, мощно.
Они еще круче, программы запускают на собственноручно спроектированном процессоре
Re[4]: А вот скриптовые языки со статической типизацией?
Здравствуйте, BulatZiganshin, Вы писали:
dmz>>Очень крутые товарищи. В учебных целях разработать компилятор ML с нативной кодогенерацией, код которого работает быстрее ocamltop dmz>>и часто — быстрее gcc — это, конечно, мощно.
BZ>реклама — двигатель прогресса
Для простого языка и оптимизатор сделать проще. Например для того же оберона есть http://www.excelsior.ru/products/xds.html написанный лет десять назад и делающий compile time оптимизации не хуже а может даже и получше современных C++ компиляторов. Другой пример Stalin Scheme.
Re[4]: А вот скриптовые языки со статической типизацией?
Ну под один конкретный процессор и для несложного языка почему бы и не сделать? Тем более, если это учебный курс,
который оттачивается годы. Документы и исходники, кстати, интересные, мне бы их полгода назад
Re[5]: А вот скриптовые языки со статической типизацией?
Здравствуйте, dmz, Вы писали:
dmz>Ну под один конкретный процессор и для несложного языка почему бы и не сделать? Тем более, если это учебный курс, dmz>который оттачивается годы. Документы и исходники, кстати, интересные, мне бы их полгода назад
Не совсем по теме насчет конкретного процессора, оказывается у llvm есть биндинг к окамлу, и вот тут http://groups.google.com/group/fa.caml/msg/5aee553df34548e2 показано как в 200 строчек кода сделать компилятор очень ограниченного подмножества окамла на llvm, в общем тоже интересное направления для DSL строения.