[Kernfach-devel]Re[2]: Kernfach
Status: Planning
Brought to you by:
dilmah
From: Denis L. <dl...@ma...> - 2005-02-03 12:16:04
|
> Нет, не чушь! Статистический контроль типов можно сделать только для > аннотированных списков, в которых будут указываться типы параметров функций > и возвращаемых значений или придумав что-нибудь еще. > > Как, например узнать, что получится в результате (.PK (.RD pos) (1 (2 3)))? > Результат работы этого фрагмента зависит от того какое значение лежит в > переменной pos и это может быть либо список, либо целое число. Какая же > здесь возможна статистическая проверка, если значение pos может меняться как > угодно в результате работы программы, а тогда тип результирующего выражения > на этапе компиляции не определен. Наверное, это можно как-нибудь обойти. это вопрос того что компилятор должен знать что может возвратить (.RD pos) Это решается либо теми же аннотациями, либо в большинстве случаев (например локальные переменные) компилятор это может вывести самостоятельно. Я не вижу как списки мешают этому. Списки и динамическая типизация перпендикулярны. Еще раз -- gcc компилирует в промежуточный язык. Я не называю его лисп-подобным, но он построен на списках: http://olympus.het.brown.edu/cgi-bin/info2www?(gcc-295)RTL > Например, надо сделать, чтобы результатом .PK был всегда список, т.е. > (.PK 1 (1 (2 3))) вернет список (1) > (.PK 2 (1 (2 3))) вернет список ((2 3)) > для списков последнего вида можно ввести операцию .UL так, что > (.UL ((2 3))) вернет (2 3) > Правда, тогда непонятно, что делать с (.PK), который будет возвращен в > результате работы (.PK 1 (.QU(.PR .PR)))? Можно выйти из положения введя > операцию .UP, которая будет для списка (.PR) возвращать .PR и выполнять его. > Тогда надо писать так: > (.UP (.PK 1 (.QU (.PR .PR))) 1), что будет эквивалентно (.PR 1) > > Я думаю, что все это вполне логично. То что приходиться вводить несколько > операций для извлечения из одноэлементного списка объясняется так: > На самом деле мы определяем одну операцию .U*, перегруженную для возвращения > различных результатов. Можно обойти это если мы введем дополнительные > ключевые слова, которые будут обозначать тип возвращаемого значения > (.U EP (.PR)) - извлечет элемент типа EP - примитива выполнения, > (.U IV (1)) - извлечет целое число, > (.U FPV (0.75)) - извлечет вещественное число. > Кстати, упаковку в список можно разрешить выполнять автоматически, т.е. это > будет неявное приведение типа. Данные при этом не теряются. > > >FL все равно нужен чтобы превратить целое в float. > > Зачем он нужен? Множество целых чисел является подмножеством вещественных > поэтому преобразование целых в вещественные должно выполняться > автоматически, если это требуется для вычисления выражения. > > >Я против вещественных литералов. > > Не понятно : почему? > > >Со строковыми сложнее, учитывая действительно необходимость > >поддержки Unicode. > > В чем сложность? Стандартные символы ASCII пусть представляются как > печатаются, а расширенные указываются например так \FEA0, при этом для > русских символов такое преобразование из "привет" в двухбайтовый аналог > преобразовывать автоматически или с указанием кодировки. я потом углубленно это прочту, подумаю. > > чтобы сделать код читаемым нужно будет пользоваться библиотеками > > макроопределений. > > Зачем нужны макроопределения? Если они будут работать только как > подстановки, то это может вызвать трудно отлавливаемые ошибки. Лучше > реализовать все что нужно сразу. > >на Си будет писаться только транслятор kernfach->C. > >Все остальное на kernfach. В процессе написания нужно создать > >библиотеки макроопределений, которые сделают программирование > >на kernfach удобным. > > Вообще не понятен смысл макроопределений. Все равно все это будет > преобразовываться на этапе компиляции, а писать на kernfach без таких > библиотек ты не станешь, зачем тогда все усложнять? в языке есть core сущности, а есть синтаксический сахар. Они должны быть четко отделены. Кстати примеры: С--: http://www.cminusminus.org/ CIL: http://manju.cs.berkeley.edu/cil/ |