Предыдущая страница Следующая страница [1] [2] > 3 < [4]

Автор Сообщение

Kergan

Members


Статус

300 сообщений

Где: ---
Род занятий:
Возраст:

#6718   2012-11-01 09:15 GMT+3 часа(ов)      
> Ну, если неправильно это значит "не так как у нас принято", то да. Ладно, не суть, я просто не знал, что Racket wanna be pure functional.

Ну derived form scheme же. То есть мутабельности и императивности по умолчанию желательно избегать, но если вдруг оно в каком-то конкретном случае сильно упростит жизнь - следует использовать.

И как я выше сказал, опять же, классический return/break для схем просто _не работает_, т.к. при выходе из цикла это нелокальный переход (т.к. это выход из глубокой рекурсии).

Kergan

Members


Статус

300 сообщений

Где: ---
Род занятий:
Возраст:

#6731   2012-11-06 09:26 GMT+3 часа(ов)      
2metadeus
Как дело то движется? Кстати, может сделаете проект на гитхабе?


ЗЫ: к слову о производительности в racket в сравнении с SBCL - во многих случаях просадки объясняются вот примерно так:
http://www.mail-archive.com/users@racket-lang.org/msg14712.html

metadeus

Members


Статус

89 сообщений

Где: Russia
Род занятий:
Возраст:

#6732   2012-11-07 04:08 GMT+3 часа(ов)      
Цитата
Kergan :
2metadeus
Как дело то движется? Кстати, может сделаете проект на гитхабе?



Пока никак почти не движется. TAPL не освоил ещё, т.к. с наскока он в башку не лезет. Попробую найти в ближайшее время возможности выделять свободное время под дело реализации хоть минимального прототипа. Проект оформлю на битбакете, наверное, т.к. сейчас больше меркуриалом пользуюсь, ссылку скину сюда, когда будет хоть что-то.

metadeus

Members


Статус

89 сообщений

Где: Russia
Род занятий:
Возраст:

#6735   2012-11-08 02:37 GMT+3 часа(ов)      
А можно в #lang typed/racket загружать и использовать библиотеки #lang racket? И, вообще, насколько стабилен и юзабелен typed/racket?

Kergan

Members


Статус

300 сообщений

Где: ---
Род занятий:
Возраст:

#6736   2012-11-08 11:02 GMT+3 часа(ов)      
Цитата
И, вообще, насколько стабилен и юзабелен typed/racket?

В принципе - вполне достаточно. Уже есть некоторые написанные на нем библиотеки, как на planet так и в стандартной поставке racket. Естественно, не любой racket-код можно типизировать (всякие евалы, классы, некоторые фишки со структурами - в общем сильно динамичные вещи типизировать не получится).

Цитата
А можно в #lang typed/racket загружать и использовать библиотеки #lang racket?

Да, можно, надо использовать require/typed.

metadeus

Members


Статус

89 сообщений

Где: Russia
Род занятий:
Возраст:

#6745   2012-11-12 04:50 GMT+3 часа(ов)      
Сделал репозиторий публичный https://bitbucket.org/metadeus/aerylisp , но пока там смотреть нечего, надеюсь перекрошить своё время, чтобы заняться разработкой, пока этого не получается =\.

Пытался найти толкового студента-программиста за вменяемые деньги (то есть не из Москвы/Питера) под это дело, но видимо проблема даже не в деньгах, а в том, что редкому студенту вообще знакомы все эти Лиспы, LLVM, компиляторы и пр. Может быть попробовать поискать спеца на удаленку из сопредельных государств...

divanov

Members


Статус

19 сообщений
http://lisp.ystok.ru
Где: Russia Москва
Род занятий:
Возраст:

#6747   2012-11-14 12:04 GMT+3 часа(ов)      
Добрый день!

Цену вопроса можно обсудить.
Связь через Контакты на http://lisp.ystok.ru/

metadeus

Members


Статус

89 сообщений

Где: Russia
Род занятий:
Возраст:

#6768   2012-11-22 02:29 GMT+3 часа(ов)      
Вопрос по поводу типизации: правильно ли я понимаю первый этап типизации. На примере:
Дано:
- результат парсинга входной строки -- '(+ (to_str 10) abc)
- лисп-система содержащая символы:
- + имеет тип (generic-function a b) со следующими реализациями (+ a:int b:int):int и (+ a:string b:string):string к примеру
- to_str имеет тип (generic-function a) со следующими реализациями (to_str a:int):string и (to_str a:uint):string
- abc имеет тип string

Нужно: проставить типы всему выражению и всем подвыражениям

Алгоритм решения:
1) Нужно составить систему уравнений для всех ограничений типов выводимых из использования выражений
1.1) Каждому выражению присваиваем уникальное имя: + = A, 10 = B, abc = C, to_str = D, (to_str 10) = E, (+ (to_str 10) abc) = F
1.2) Добавляем все ограничения типов последовательно
1.2.1) Список F типизируем по первому элементу, подтипам в нем тоже присваиваем уникальные имена (G H I):
F = G
(and H:int I:int) = G:int
(and H:string I:string) = G:string
H = (or string int)
I = (or string int)
E = H
C = I

1.2.2) Далее список E (J K):
E = J
J = string
K = (or int uint)
B = K

1.2.3) Типизируем B по значению, выбираем наиболее узкий тип (в реальном применении тут может быть правило -- наиболее узкий, но не уже машинно-специфичного, то есть не ubyte, а uint например, для эффективности)
B = (or ubyte byte)

1.2.3) Второй параметр в F -- С:
C = string

1.3) Полученная система уравнений:

F = G
(and H:int I:int) = G:int
(and H:string I:string) = G:string
H = (or string int)
I = (or string int)
E = H
C = I
E = J
J = string
K = (or int uint)
B = K
B = (or ubyte byte)
C = string


2) Нужно эту систему уравнений решить, решать её можно по идее хоть в лоб прямым перебором в ширину или глубину, это уже вопрос скорости процесса компиляции, здесь же решим её аналитически:

F = string
G = string
H = string
I = string
E = string
J = string
K = (or int uint)
B = (or int uint)
C = string


3) Здесь по идее мы получили ошибку вывода типа, т.к. 10 может быть как int, так и uint и требуется дополнительная декларация типа. Если такую декларацию добавить:

(+ (to_str (: 10 uint)) abc)


То выражение будет типизироваться корректно.

--

1) Правильный ли это подход к задаче, хотя бы для начала для таких простых выражений?
2) Стоит ли множественную компайл-тайм диспетчеризацию по типам параметров функций -- generic-функции делать в kernel language или лучше сосредоточиться на макросах, а дженерики пытаться реализовать через макросы? Здесь я не очень ещё разобрался как вообще макросы должны взаимодействовать с системой типов?

divanov

Members


Статус

19 сообщений
http://lisp.ystok.ru
Где: Russia Москва
Род занятий:
Возраст:

#6775   2012-11-29 13:36 GMT+3 часа(ов)      
Простите, metadeus.

Не нанялись ли Вы на вакансию
http://lisp.ru/forums.php?m=posts&q=1043
"Программист Lisp без опыта"?

Если так, попытка привлечь помощников на добровольной основе выглядит не очень корректно.

metadeus

Members


Статус

89 сообщений

Где: Russia
Род занятий:
Возраст:

#6776   2012-11-29 15:50 GMT+3 часа(ов)      
Цитата
divanov :
Простите, metadeus.

Не нанялись ли Вы на вакансию
http://lisp.ru/forums.php?m=posts&q=1043
"Программист Lisp без опыта"?

Если так, попытка привлечь помощников на добровольной основе выглядит не очень корректно.



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

UPD: Кстати это же я к вам обращался по поводу этого проекта. Вы что посчитали, что я устроился лиспером без опыта и свою работу пытался отдать на аутсорс, который вышел бы существенно дороже зарплаты этого лиспера без опыта? Лол)))

отредактировал(а) metadeus: 2012-11-29 16:08 GMT+3 часа(ов)

divanov

Members


Статус

19 сообщений
http://lisp.ystok.ru
Где: Russia Москва
Род занятий:
Возраст:

#6807   2012-11-30 12:31 GMT+3 часа(ов)      
Простите.

Я переговаривался с ними - всё что удалось узнать: нужен незнамо-какой Лисп под неуказаннюу виртуальную машину. Ваша задумка весьма близка. Так что рекомендую предложить им свои услуги :-)

Ещё пара советов.
Был такой ANSI Lisp со строгой типизацией. Bruno Heible, aвтор CLISP, бросил свой проект и ушёл в компаннию Lilog, если не ошбабюсь, чтобы разрабатывать реализацию ANSI Lisp. Правда, последние лет двенадцать о них не слышал.

Вообще, CLISP компилирует в байткод. Взглянуть на его исходники не помешало бы.

Kergan

Members


Статус

300 сообщений

Где: ---
Род занятий:
Возраст:

#6808   2012-11-30 18:47 GMT+3 часа(ов)      
Цитата
1) Правильный ли это подход к задаче, хотя бы для начала для таких простых выражений?

естественно если ограничиться простыми случаями - то имеет смысл ограничиться и простыми решениями.

Цитата
2) Стоит ли множественную компайл-тайм диспетчеризацию по типам параметров функций -- generic-функции делать в kernel language или лучше сосредоточиться на макросах, а дженерики пытаться реализовать через макросы?

Это неоднозначный вопрос. С одной стороны, добавление этого в ядро позволяет работать с ad-hoc полиморфными ф-ями как с объектами первого порядка на уровне рантайма (то есть полиморфная ф-я сама по себе, не инстанс, может быть представлена конкретным объектом). С другой стороны - выкидывания этого во внешнюю библиотеку _значительно_ упрощает семантику целевого языка.


Цитата
Здесь я не очень ещё разобрался как вообще макросы должны взаимодействовать с системой типов?

Я полагаю, надо с одной стороны типизировать код после экспанда, но с другой стороны уметь оставлять в макросе какие-то хинты для чекера, т.о. вмешиваясь (отложенно) в процесс вывода типов и типизации при помощи выделенного апи. Возможно, здесь даже следует ввести какой-то специальный после-экспанда-до-тайпчекера проход компилятора, тут все непросто. Макросы для типизированного ЯП - это открытая и актуальная исследовательская проблема, см. template haskell, макросы скалы, Nemerle. Здесь нету наработанной практики и проверенных временем решений. Я бы сказал - вообще нету решений. Скорее, ряд способов, которые позволяют с той или иной степенью удобства замести те или иные проблемы под ковер

Быть может, лучше даже остановиться на самом простом способе - тайпчек после макроэкспанда, никакого взаимодействия нет. А потом, когда остальное уже будет в значительной степени готово, думать о йоба-фичах.

metadeus

Members


Статус

89 сообщений

Где: Russia
Род занятий:
Возраст:

#6809   2012-11-30 19:05 GMT+3 часа(ов)      
Цитата
divanov :
Простите.

Я переговаривался с ними - всё что удалось узнать: нужен незнамо-какой Лисп под неуказаннюу виртуальную машину. Ваша задумка весьма близка. Так что рекомендую предложить им свои услуги :-)



Они ищут лиспера без опыта, чтобы он им Лисп написал? Даже боюсь предположить что они ожидают получить.

Цитата
divanov :
Ещё пара советов.
Был такой ANSI Lisp со строгой типизацией. Bruno Heible, aвтор CLISP, бросил свой проект и ушёл в компаннию Lilog, если не ошбабюсь, чтобы разрабатывать реализацию ANSI Lisp. Правда, последние лет двенадцать о них не слышал.

Вообще, CLISP компилирует в байткод. Взглянуть на его исходники не помешало бы.



Я смотрел байт-код CLISP -- на мой взгляд адская каша, да и толку мне с его исходников если динамически типизированный Лисп пишется достаточно просто и непринужденно -- вся засада (для меня конкретно) это стыковка его со статической типизацией и выводом типов. А так есть исходники и SBCL, но там все эти особенности с компиляцией под целевую платформу и оптимизации, которые отвлекают от собственно целевой нагрузки системы.

metadeus

Members


Статус

89 сообщений

Где: Russia
Род занятий:
Возраст:

#6810   2012-11-30 19:23 GMT+3 часа(ов)      
Цитата
Kergan :
Это неоднозначный вопрос. С одной стороны, добавление этого в ядро позволяет работать с ad-hoc полиморфными ф-ями как с объектами первого порядка на уровне рантайма (то есть полиморфная ф-я сама по себе, не инстанс, может быть представлена конкретным объектом). С другой стороны - выкидывания этого во внешнюю библиотеку _значительно_ упрощает семантику целевого языка.



Удастся ли добиться подобного поведения проектированием и разработкой доступа к системе типов? Иными словами запилить возможности объявлять не просто новые типы, а новые виды типов (type kind) со своими правилами вывода и пр., которые бы позволили реализовать полиморфные функции в виде библиотеки, но в то же время давали возможность обращаться с ними как с объектами первого рода.

Цитата
Kergan :
Быть может, лучше даже остановиться на самом простом способе - тайпчек после макроэкспанда, никакого взаимодействия нет. А потом, когда остальное уже будет в значительной степени готово, думать о йоба-фичах.



Разумно.

--

Из новостей: во-первых, что-то не срослось у меня с LLVM в Racket, поэтому переключился таки на C++. И вроде как нашел толкового разработчика, которого хочу подключить к реализации проекта, т.к. своего времени не хватает, тем более, что тут планировать нужно достаточно много. Репозиторий перенес на github: https://github.com/metadeus/aerylisp

Сейчас главный вопрос это вид уравнений типизации и алгоритм их решения, пытаюсь освоить его по статье из 4 номера fprog.ru и нашел реализацию Хиндли-Милнера на C++: https://github.com/jaredhoberock/hindley_milner Так что надеюсь удастся разобраться.

Kergan, если есть желание посмотреть/помочь с созданием стандарта языка, то скинь мне свой email, я тебе документ из google docs открою.

отредактировал(а) metadeus: 2012-11-30 23:04 GMT+3 часа(ов)

misha

Moderators


Статус

1273 сообщений
http://racket-lang.org/
Где: Yemen
Род занятий:
Возраст:

#6813   2012-12-01 19:48 GMT+3 часа(ов)      
Цитата
Репозиторий перенес на github: https://github.com/metadeus/aerylisp
Посмотрел я на ваши исходники, и у меня сложилось мнение, что вы не знаете как правильно реализовать ридер. Вам стоит посмотреть как он реализован в других реализациях лиспа.
Цитата
если есть желание посмотреть/помочь с созданием стандарта языка
Я думаю, это стоит вынести на публичное обсуждение.

metadeus

Members


Статус

89 сообщений

Где: Russia
Род занятий:
Возраст:

#6815   2012-12-02 03:24 GMT+3 часа(ов)      
Цитата
misha :
Посмотрел я на ваши исходники, и у меня сложилось мнение, что вы не знаете как правильно реализовать ридер. Вам стоит посмотреть как он реализован в других реализациях лиспа.


Ну это вероятно потому, что там нет ридера как такового, а есть пока тупой и примитивный парсер. Устройство ридера ещё находится в проектировании, пока планирую сделать расширяемый набор PEG-парсеров с приоритетами. Ридер не первоочередная задача, т.к. особо на юзабельность языка не влияет, т.к. если реально нужно расширение ридера, то это ясный сигнал, что нехватает синтаксиса, а значит язык не достаточно выразительный получился.

Цитата
misha :Я думаю, это стоит вынести на публичное обсуждение.


Ну, собственно, для этого эта тема и существует, здесь обсуждение вести и будем. Просто я склонен разделять обсуждение в плане потрепать языком о том как лучше и как правильнее и работу по воплощению принятых базовых принципов в стандарт конкретного языка. А выставлять на всеобщее обозрение незаконченный документ это вводить в заблуждение читателей, что, собственно, и произошло в случае с ридером и исходниками в репозитории.

misha

Moderators


Статус

1273 сообщений
http://racket-lang.org/
Где: Yemen
Род занятий:
Возраст:

#6816   2012-12-03 03:59 GMT+3 часа(ов)      
Цитата
Ну это вероятно потому, что там нет ридера как такового, а есть пока тупой и примитивный парсер.
Дело в том, что классический ридер реализуется довольно просто, т.е. вы там намудрили. Поэтому я советую вам посмотреть исходники других "простых" лиспов.
Цитата
пока планирую сделать расширяемый набор PEG-парсеров с приоритетами.
А это лучше вынести в отдельную библиотеку, т.к. я не думаю, что простые пользователи будут ими регулярно пользоваться.

metadeus

Members


Статус

89 сообщений

Где: Russia
Род занятий:
Возраст:

#6817   2012-12-03 17:07 GMT+3 часа(ов)      
Цитата
misha :
Дело в том, что классический ридер реализуется довольно просто, т.е. вы там намудрили. Поэтому я советую вам посмотреть исходники других "простых" лиспов.


Что может быть проще примитивного леворекурсивного парсера? =) Ну ладно, посмотрю.

UPD: Нашел первый попавшийся лисп и увидел:
lval lread(lval * g) {
int c = getnws();
if (c == EOF)
return 8;
if (c == '(')
return read_list(g);
if (c == '\"')
return stringify(g, read_string_list(g));
if (c == '\'')
return list2(g, 12);
if (c == '#') {
c = getnws();
if (c == '\'')
return list2(g, 20);
return 0;
} if (c == '`')
return list2(g, 38);
if (c == ',') {
c = getnws();
if (c == '@')
return list2(g, 40);
ungetc(c, ins);
return list2(g, 39);
} ungetc(c, ins);
if (isdigit(c)) {
double d;
fscanf(ins, "
%lf", &d);
return d2o(g, d);
} if (c == ':')
getnws();
return is(g, c == ':' ? kwp : pkg, stringify(g, read_symbol(g)));
}
 
lval read_list(lval * f) {
int c;
NF(1) T = 0;
c = getnws();
if (c == ')')
return 0;
if (c == '.') {
lval r = lread(g);
getnws();
return r;
}
ungetc(c, ins);
T = lread(g);
return cons(g, T, read_list(g));
}
 
lval read_symbol(lval * g) {
int c = getc(ins);
if (isspace(c) || c == ')' || c == EOF) {
if (c != EOF)
ungetc(c, ins);
return 0;
} if (c > 96 && c < 123)
c -= 32;
return cons(g, (c << 5) | 24, read_symbol(g));
}


Скажете чем отличается от того, что сделано у меня? Ну кроме того, что мой код ещё корректно работает с UTF-8.

отредактировал(а) metadeus: 2012-12-03 17:36 GMT+3 часа(ов)

misha

Moderators


Статус

1273 сообщений
http://racket-lang.org/
Где: Yemen
Род занятий:
Возраст:

#6818   2012-12-03 20:28 GMT+3 часа(ов)      
Ну, это тоже не то. Почитайте как устроен лисп ридер.

Kergan

Members


Статус

300 сообщений

Где: ---
Род занятий:
Возраст:

#6819   2012-12-04 18:50 GMT+3 часа(ов)      
misha
Если ты про readtable, то на сишке и без лямбд оно именно как лр-парсер и будет выглядеть

misha

Moderators


Статус

1273 сообщений
http://racket-lang.org/
Где: Yemen
Род занятий:
Возраст:

#6822   2012-12-05 02:18 GMT+3 часа(ов)      
Ну, для простоты в качестве readtable можно временно использовать контейнер map, хотя лучше сразу создать свой собственный тип данных. А вместо лямбд можно использовать указатели на функции.

Кстати, чтобы избежать неоднозначности, лучше писать не "лр-парсер", а лл-парсер. Ведь оба ридера использовали лл-анализ (LL(1) грамматика).

metadeus

Members


Статус

89 сообщений

Где: Russia
Род занятий:
Возраст:

#6825   2012-12-06 21:54 GMT+3 часа(ов)      
Цитата
misha :
Ну, это тоже не то. Почитайте как устроен лисп ридер.



Вы об этом? http://www.lispworks.com/documentation/HyperSpec/Body/02_b.htm
По мне так не самое удачное решение для расширяемого ридера. Мне все таки набор PEG-парсеров нравится больше, т.к. такое решение, вообще говоря, будет более гибким. Если я правильно понимаю CL reader не сможет принципиально преобразовать входной поток вида (чисто из носа пример):
(set answer $ok-box$)
в
(with (%1% (ok-box-result (make-ok-box)))
(if (!= FAIL ok-box-result)
(set answer %1%)))
, а PEG сможет (? вообще говоря не очевидно -- сможет ли).

С другой стороны поддержку такого ридера не сможет обеспечить ни одна IDE. Нужен нам вообще расширяемый ридер или простота поддержки языка в ИДЕ важнее? Если расширение ридера действительно необходимая вещь, то нужно эту возможность привести в декларативный вид, с которым любая среда могла бы работать.

отредактировал(а) metadeus: 2012-12-07 17:28 GMT+3 часа(ов)

Kergan

Members


Статус

300 сообщений

Где: ---
Род занятий:
Возраст:

#6826   2012-12-10 17:58 GMT+3 часа(ов)      
Цитата
С другой стороны поддержку такого ридера не сможет обеспечить ни одна IDE.

Если иде крутится внутри лиспо-рантайма - сможет.

metadeus

Members


Статус

89 сообщений

Где: Russia
Род занятий:
Возраст:

#6828   2012-12-11 16:47 GMT+3 часа(ов)      
Цитата
Kergan :
Цитата
С другой стороны поддержку такого ридера не сможет обеспечить ни одна IDE.

Если иде крутится внутри лиспо-рантайма - сможет.



Насколько правильно полагаться на такое решение? Получится, то без вкорячивания рантайма в редактор, он даже синтаксис правильно подсветить не сможет? Может лучше формализовать правила введения нового синтаксиса каким-то образом? Да и главный вопрос нужно ли это в принципе? Мощи макросов и нескольких спец-форм недостаточно? А если дать возможность вводить простейшие спец-формы из одного символа и атома или списка за ними, и этим ограничиться? Иначе получается, что мы вроде как лисп проектируем, но нам синтаксиса не хватает.

Kergan

Members


Статус

300 сообщений

Где: ---
Род занятий:
Возраст:

#6829   2012-12-11 17:16 GMT+3 часа(ов)      
Как раз лексический парсинг - это никакая не проблема, нормальной иде придется на ходу раскрывать макросы. Вот это уже сложнее значительно.

Цитата
Насколько правильно полагаться на такое решение? Получится, то без вкорячивания рантайма в редактор, он даже синтаксис правильно подсветить не сможет?

Ну и пусть. В чем, собственно, проблема такого подхода?

metadeus

Members


Статус

89 сообщений

Где: Russia
Род занятий:
Возраст:

#6832   2012-12-12 18:16 GMT+3 часа(ов)      
Цитата
Kergan :
Как раз лексический парсинг - это никакая не проблема, нормальной иде придется на ходу раскрывать макросы. Вот это уже сложнее значительно.



Ну раскрытие макросов понадобится ИДЕ и это нормально, т.к. это функции ИДЕ.

Цитата
Kergan :
Цитата
Насколько правильно полагаться на такое решение? Получится, то без вкорячивания рантайма в редактор, он даже синтаксис правильно подсветить не сможет?

Ну и пусть. В чем, собственно, проблема такого подхода?



Ну хотя бы тем, что исходники на этом языке ничем кроме его ИДЕ подсвечиваться не будут, а значит разработчик без полноценной ИДЕ работать не сможет в принципе, что существенно сужает область применения такого языка.

Kergan

Members


Статус

300 сообщений

Где: ---
Род занятий:
Возраст:

#6834   2012-12-13 12:47 GMT+3 часа(ов)      
если вы написали расширение ридера, иде в любом случае не сможет определить как что подсвечивать. подсвечиваются кейворды языка (которые в спеке языка), а если хотите подсветку какого-то дсл - ну так это надо менять подсвечивающий код (или сделать подсветку настраиваемой, например). Как показывает практика - это вполне нормальное решение.

metadeus

Members


Статус

89 сообщений

Где: Russia
Род занятий:
Возраст:

#6843   2012-12-21 02:53 GMT+3 часа(ов)      
Цитата
Kergan :
если вы написали расширение ридера, иде в любом случае не сможет определить как что подсвечивать. подсвечиваются кейворды языка (которые в спеке языка), а если хотите подсветку какого-то дсл - ну так это надо менять подсвечивающий код (или сделать подсветку настраиваемой, например). Как показывает практика - это вполне нормальное решение.



Пока оставим расширение ридера в стороне, т.к. мне кажется можно отыскать более формальный путь к расширяемому ридеру, но его вид я пока не придумал. Тем более, я считаю, что возможности определять собственные спец-формы в kernel language должно "хватить всем", а расширять ридер это из области извращений имхо (затрудняет чтение и т.п.). Нужен eDSL -- используй S-exp'ы, ты же Лисп-программист, а если нужен полноценный DSL, так вот целый набор PEG-парсеров с блекджеком.

Я тут вычитал такую интересную вещь -- ребята жалуются, что "LLVM compilation is too slow for a Just-In-Time Compiler". Все пропало или они сгущают краски?

Kergan

Members


Статус

300 сообщений

Где: ---
Род занятий:
Возраст:

#6844   2012-12-21 15:35 GMT+3 часа(ов)      
Цитата
Все пропало или они сгущают краски?

Не знаю, если честно, это надо самому тестировтаь. Но в любом случае можно тогда вместо ллвм взять тот же libjit, быть может, это даже лучше будет (libjit сильнее "отвязан" от семантики языка).

den73

Members


Статус

12 сообщений

Где: Russia
Род занятий:
Возраст:

#6859   2012-12-31 00:57 GMT+3 часа(ов)      
Доброго времени суток и с наступающим.

Тут упомянули ридер, могу рассказать ещё раз о своём опыте.
Для SQL в Лиспворкс я использую такую команду:
fse * from mytable;

За словом fse и до ; работает лексер firebird, к-рый я написал.
Подсветка при этом действительно ломается, но других проблем нет.
Если она совсем ломается, размещаю балансирующие строки в комментариях, например,
fse '"' from mytable -- "
;
здесь вторая кавычка находится в SQL под комментарием и нужна для правильной работы
IDE. На практике такое бывает нужно в одном запросе из 500.

Для определения хранимой процедуры использую что-то вроде
(def-stored-proc имя :args параметры :returns '((myvar int))
(fbody
for select id from mytable into :myvar do
suspend;
^))

Здесь от слова fbody до ^ идёт текст SQL.

У меня есть спец. расширения лексера SQL, к-рые позволяют мне
подставлять результат вычисления лисп-выражений в код SQL. Например,
(def-sql-macro M_Macro1 (fbody field1, field2, field3 ^))

fbody select M_Macro1 from foo ^
=>
field1, field2, field3 from foo;

Я пробовал разные подходы, но только этот оказался приемлемым (я пишу
много кода на SQL). Главное: когда
компилятор SQL возвращает мне ошибку со строчкой и колонкой,
я умею найти автоматически место в исходнике лиспа, которое соответствует этой
строчке и колонке, поскольку каждая лексема хранит своё место.

Генерация же SQL из SEXP-based DSL - это просто ад, особенно, когда речь идёт
о десятках и сотнях КБ SQL и о полноценном использовании тонкостей конкретного
сервера SQL, без чего практически нереально писать эффективные двухзвенные
программы. С трёхзвезными, конечно, проще.

На практике это выливается в то, что приходится под каждую фичу SQL (а их полно)
писать альтернативный SEXP-синтаксис, поддерживать его, помнить его и при каждой
ошибке компиляции SQL становиться на время Шерлоком Холмсом, чтобы понять, что
именно оказалось неверным.

Подсветку я, в принципе, понимаю, как делать, но пока что руки не дошли. Жить
без неё можно, хотя с ней было бы лучше.

Я хочу сделать язык "поверх" CL, т.к. мне нужно подключать к моему проекту
других людей. Признаться, и мне с моим опытом иногда бывает нелегко работать
на лиспе. Это касается многословности, трудности отладки кода с макросами,
вообще трудности диагностики ошибок.

Что уж говорить о новичках? Они легко могут освоить какой-нибудь Питон
и разбить голову об CL.

Я вижу, что тут обсуждается нечто совсем другое, но вот, на всякий случай, тема о моих
задумках и достижениях, может, кому-то будет интересно: http://lisper.ru/forum/thread/878


Онлайн :

0 пользователь(ей), 11 гость(ей) :




Реклама на сайте: