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

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

misha

Moderators


Статус

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

#6860   2012-12-31 03:01 GMT+3 часа(ов)      
Цитата
Я хочу сделать язык "поверх" CL, т.к. мне нужно подключать к моему проекту
других людей. Признаться, и мне с моим опытом иногда бывает нелегко работать
на лиспе. Это касается многословности, трудности отладки кода с макросами,
вообще трудности диагностики ошибок.
Ну, с разработкой интерпретатора вы скорее наживете себе еще большую головную боль, чем избавитесь от проблем. Т.е. проблема не в лиспе, а скорее в отсутствии методологии разработки на лиспе. Да и разнообразие диалектов вносит еще большую неразбериху. Причем большинство лисперов вместо того, чтобы делиться опытом, устраивают срач - чей диалект круче. А до методологии никому нет дела.

Kergan

Members


Статус

300 сообщений

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

#6861   2013-01-02 02:30 GMT+3 часа(ов)      
Цитата
Генерация же SQL из SEXP-based DSL - это просто ад

А в чем, собственно, разница, кроме того, что в случае ридера приходится в дополнение ко всему тому, что надо сделать в s-exp based DSL, еще лексер писать?

Kergan

Members


Статус

300 сообщений

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

#6862   2013-01-02 02:32 GMT+3 часа(ов)      
Цитата
Т.е. проблема не в лиспе, а скорее в отсутствии методологии разработки на лиспе.

"методологии разработки на лиспе" нет и быть не может. может быть методология разработки на конкретном диалекет.

den73

Members


Статус

12 сообщений

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

#6865   2013-01-03 04:47 GMT+3 часа(ов)      
>А в чем, собственно, разница, кроме того, что в случае ридера приходится в дополнение ко всему тому, что надо сделать в s-exp based >DSL, еще лексер писать?
Лексер я написал года два назад, не сказать, что надорвался. С тех пор его трогаю раз в полгода, когда всплывает какая-то проблема. В остальном я разницу описал достаточно подробно. Повторю коротко и другими словами. SQL не является sexp-based языком, в этом и загвоздка. Sexp-образный синтаксис сначала казался многообещающим, но потом оказался неоптимальным, т.к. выгода от него оказалась меньше, чем постоянные затраты на него.
> Т.е. проблема не в лиспе, а скорее в отсутствии методологии разработки на лиспе
Как ни странно, у меня лично проблема в избытке способов реализовать ту или иную вещь на лиспе. Из которых ни одна не является полноценной при близком рассмотрении. Например, цикл. loop мне давно не нравился. Я долго пользовался iterate, он вообще-то прекрасен, но теперь я обнаружил, что iterate плохо взаимодействует с дебаггером: отладчик не может показать точное место внутри iterate, а это важно. Пытаюсь пользоваться простыми циклами типа dolist, dotimes, но с ними возникают уже другие проблемы (сложно сделать break/continue, нет collecting и appending, нельзя сделать for i from 1 to N и т.п.). Таким образом, вместо решения прикладных задач приходится всё время латать дыры в языке. При работе с "мейнстримовыми" языками, я за собой не наблюдал большой вовлечённости в подобную деятельность.

То же можно сказать и про инкапсуляцию. Вроде логично инкапсулировать данные процесса в локальных функциях, но на практике это неудобно: нарушается принцип "разделяй и властвуй", т.к. весь алгоритм норовит превратиться в одну гигантскую функцию со множеством локальных подфункций. IDE плохо поддерживает это, и с точки зрения отладки, и из-за невозможности перекомпилировать отдельную локальную подфункцию.

Оказывается, начиная с определённого объёма алгоритма, данные лучше инкапсулировть в структурах, как это делается в ООП языках, но тут выясняется, что те же Delphi/C++ имеют лаконичный синтаксис для доступа к полям объекта, а в лиспе такого синтаксиса нет и как его сделать - опять же неясно. Снова вместо решения прикладной задачи приходится заниматься филологией.

Kergan

Members


Статус

300 сообщений

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

#6866   2013-01-03 13:42 GMT+3 часа(ов)      
Цитата
SQL не является sexp-based языком

ну и что? кроме того - вас же никто не заставляет делать его именно скобочным. Можно же сделать макрос вида: (fse (dsl ...)) и в (dsl) plain-запрос, который будем парсить уже в макросе fse, а ридер используем стандартный лисповский.

Цитата
чем постоянные затраты на него

мне как раз и интересно какие у вас в вашем конкретном случае были затраты. в этом и состоял мой вопрос.

То есть если смотреть на приведенные в вашем посте примеры, то при замене в них ридера на экспандер все станет только лучше, а затраты как минимум не возраустут. то есть в итоге получим более оптимальное решение меньшими затратами. у вас почему-то было не так, мне и интересно - почему.

metadeus

Members


Статус

89 сообщений

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

#6867   2013-01-03 16:46 GMT+3 часа(ов)      
Ой-вей, я думал что это только у меня такие проблемы, грешил на то, что не осилил CL во всей красе.

den73

Members


Статус

12 сообщений

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

#6868   2013-01-03 17:57 GMT+3 часа(ов)      
> в (dsl) plain-запрос
Тогда это уже не подпадает под случай, к-рый я охарактеризовал как "ад".
> а ридер используем стандартный лисповский
plain-запрос предлагается в виде строки? Эскейпить кавычки - это тоже труд. Компьютер ведь дан нам для облегчения труда, а не наоборот?

Kergan

Members


Статус

300 сообщений

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

#6869   2013-01-04 00:53 GMT+3 часа(ов)      
Цитата
plain-запрос предлагается в виде строки?

зачем в виде строки? обычная лиспоформа, просто без скобок.

Цитата
Тогда это уже не подпадает под случай, к-рый я охарактеризовал как "ад".

почему "ад"-то, если работы меньше, а качество решения - выше?

den73

Members


Статус

12 сообщений

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

#6870   2013-01-04 01:04 GMT+3 часа(ов)      
>зачем в виде строки?
select distinct 'a' as a,b,c from "Таблица"
> это - не лиспоформа.

> почему "ад"-то, если работы меньше, а качество решения - выше?
Приведите пример уменьшения количества работы для запроса, приведённого выше.

Kergan

Members


Статус

300 сообщений

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

#6871   2013-01-04 01:31 GMT+3 часа(ов)      
Цитата
select distinct 'a' as a,b,c from "Таблица"

ну и пусть будет (select disctinct 'a as (a b c) from "Таблица").

Цитата
Приведите пример уменьшения количества работы для запроса, приведённого выше.

Соответствующий макрос пишется в несколько строк. Ваш самописный ридер, могу предположить, будет несколько больше. Порядка на два. Десятичных.

Я и прошу вас объяснить, почему макрос-двустрочник - "ад", а поддержка полноценного лексера - не "ад".

отредактировал(а) Kergan: 2013-01-04 01:43 GMT+3 часа(ов)

den73

Members


Статус

12 сообщений

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

#6872   2013-01-04 01:50 GMT+3 часа(ов)      
> ну и пусть будет...
контрпример:

select distinct 'a ' as a,b,c from "Таблица"
неотличимо в Вашем синтаксисе от
select distinct 'a' as a,b,c from "Таблица"

Видите, Вы с лёгкостью предложили неверное решение, сразу наступив на грабли. И это произошло на первом же примере,
совсем не заковыристом. У меня есть SQL-запросы объёмом исходника более 1 КБ. Уверяю, там найдётся ещё пяток грабель.

> Я и прошу вас объяснить, почему макрос-двустрочник - "ад"
Потому что он затрудняет работу: для работы с SQL нужно знать не только SQL (изрядный объём знаний), а ещё и оболочку
для него. Далее. Пусть компилятор SQL говорит: строка 1,колонка 25. Поле b не существует.
Опишите процесс поиска этой ошибки в Вашей форме (select disctinct 'a' (as a b c) from "Таблица").
Обычно IDE для разработки на SQL просто ставят курсор на место ошибки. Способен ли двухстрочный макрос сделать это?
Нет.

den73

Members


Статус

12 сообщений

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

#6873   2013-01-04 01:52 GMT+3 часа(ов)      
Забавно, что Вы поправили свой код, пока я писал свой ответ, но мой контрпример всё равно остался действительным.
Могу сразу ещё одну задачку для Вашего синтаксиса (на Firebird)
BUDDEN 63 > fse '''' from rdb$database;
(("'"))
#("CONSTANT")

den73

Members


Статус

12 сообщений

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

#6874   2013-01-04 01:53 GMT+3 часа(ов)      
здесь budden 63 > - это подсказка интерпретатора, '''' - четыре одинарных, "'" - это строка из одной одинарной.

Kergan

Members


Статус

300 сообщений

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

#6875   2013-01-04 02:06 GMT+3 часа(ов)      
Цитата
контрпример:

ну это же не принципиально. у нас есть спека на SQL, можно сразу покрыть все варианты подобных форм, благо их мало. Можно для кавычек, например, сделать (! ...) вместо одинарных и (!! ...) вместо двойных, третья форма для запятой ну и так далее. В любом случае проще ридера. И макросы, которые вы делали отдельным костылем, в данном случае будут доступны искаробки.

Цитата
Видите, Вы с лёгкостью предложили неверное решение, сразу наступив на грабли. И это произошло на первом же примере,

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

Цитата
Далее. Пусть компилятор SQL говорит: строка 1,колонка 25. Поле b не существует.

А, ну тут да, проблема есть. Стандарт CL, к сожалению, не предполагает такой возможности. В более современных диалектах, однако, подобные вещи могут быть предусмотрены и доступны искаробки, практически бесплатно с точки зрения оверхеда в сложности реализации. Можно только узнать как конкретно работает позиционирование вместе с def-sql-macro?

Kergan

Members


Статус

300 сообщений

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

#6876   2013-01-04 02:21 GMT+3 часа(ов)      
наличие ; и парные скобки в (("'")) существенны? и еще, что можно делать внутри fse кроме вызова спец. макросов определенных для него, это отличается чем-нибудь семантически от интерполяции строк?

то есть вообще говоря в какой код будет раскрыт ваш вызов fse в последнем примере?

misha

Moderators


Статус

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

#6877   2013-01-04 02:52 GMT+3 часа(ов)      
Цитата
"методологии разработки на лиспе" нет и быть не может. может быть методология разработки на конкретном диалекет.
Речь шла о CL. Остальные диалекты еще довольно сырые, хотя некоторым уже несколько десятков лет, возможно, потому что используются в основном в академической среде.

misha

Moderators


Статус

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

#6878   2013-01-04 03:09 GMT+3 часа(ов)      
Цитата
Пытаюсь пользоваться простыми циклами типа dolist, dotimes, но с ними возникают уже другие проблемы
А чем loop не угодил?
Цитата
То же можно сказать и про инкапсуляцию. Вроде логично инкапсулировать данные процесса в локальных функциях, но на практике это неудобно: нарушается принцип "разделяй и властвуй", т.к. весь алгоритм норовит превратиться в одну гигантскую функцию со множеством локальных подфункций.
Ну, тут главное не перестараться. Лучше разбейте гигантскую функцию на несколько функций. Когда функция слишком большая, то труднее произвести последующий рефакторинг, да и возникают трудности при чтении кода.
Цитата
Оказывается, начиная с определённого объёма алгоритма, данные лучше инкапсулировть в структурах, как это делается в ООП языках, но тут выясняется, что те же Delphi/C++ имеют лаконичный синтаксис для доступа к полям объекта, а в лиспе такого синтаксиса нет и как его сделать - опять же неясно. Снова вместо решения прикладной задачи приходится заниматься филологией.
Можно перегрузить квадратную скобку. Если используем emacs (в качестве IDE), то достаточно лишь добавить поддержку нашего синтаксиса.

den73

Members


Статус

12 сообщений

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

#6879   2013-01-04 23:56 GMT+3 часа(ов)      
> А, ну тут да, проблема есть
И её одной вполне достаточно.

> Можно только узнать как конкретно работает позиционирование вместе с def-sql-macro?
На выбор предлагается два места - место определения макроса и место его использования.
Реализация состоит в том, что к лексеме привязывается информация о расположении, которая выводится
и на печать, и в fasl. Однако, это работает только для непосредственно вызываемого из лиспа кода.
Если мы создали из лиспа хранимую процедуру, то по ней мы уже не сможем найти исходник лиспа.
Можно было бы решить эту проблему, вставляя в исходный текст SQL комментарии, указывающие место исходника, но
я этого не сделал.

> И макросы, которые вы делали отдельным костылем
Я не так уж перенапрягся, реализация костыля занимает около 15 строчек, хотя определённые трудности
в разработке действительно были.

> и еще, что можно делать внутри fse кроме вызова спец. макросов определенных для него
подставлять параметры, двумя способами. В первом способе предполагается, что мы хотим подставить кусок
текста запроса, во втором - что хотим подставить параметр для передачи в запрос. Соответственно,
по-разному происходит превращение объекта в строку.

> парные скобки в (("'"))
Это - уже результат вычисления. Сам запрос заканчивается после #\;
> Но ведь вы в ридере наступаете на точно те же грабли - то есть вам этот кейз надо предусмотреть.
Мне надо предусмотреть их один раз, когда я пишу лексер sql. Мне не нужно разрабывать спецификацию,
мне нужно лишь ей следовать. Ридер делает всего лишь одну вещь:
встречая символ fse, запускает лексер sql над своим потоком и возвращает то, что вернул этот лексер.
Т.е., работа не сложнее, чем просто написать лексер SQL. Это несложно.
Вы предлагаете:
1. разработать новый непротиворечивый синтаксис поверх SQL, что уже не совсем тривиально.
2. помнить не только синтаксис SQL, но и новый синтаксис SQL.
В природе есть книги, форумы, трассировка SQL-сервера, IDE с автогенерацией SQL-кода. Например, если
мне надо поменять тип поля, а я не помню наизусть, как это делать, а беру код SQL, к-рый генерит мне IBExpert
из того, что я натыкал мышью.
Если я правильно понимаю, Вы предлагаете
3. встретив код SQL где-то во внешнем источнике, переводить его на разработанный новый синтаксис. Можно, конечно,
завести альтернативную форму, в которой запрос представлен строкой, но в любом случае, придётся мыслить и
в терминах Вашего синтаксиса, и в терминах SQL, избавиться от двуязычности не выйдет. Двуязычность стоит определённых
ресурсов разума.

Т.е., трудности в работе возникают абсолютно на каждом шагу, в то время как воспользоваться какими-то возможностями
генерации кода нужно примерно в одном случае из 10.

И тут возникает простой вопрос: а зачем всё это?

> то есть вообще говоря в какой код будет раскрыт ваш вызов fse в последнем примере?
fse '''' as русскоеСлово from rdb$database;
будет раскрыт в
select '''' as "русскоеСлово" from rdb$database;

т.к. известно, что Firebird не понимает идентификаторов с кириллиицей,
и после лексера они автоматически квотятся. Таким образом, мой синтаксис
получается даже чуть короче, чем родной SQL, даже без макросов.

> А чем loop не угодил?
Нерасширяемостью, неудобством применения составных операторов и условных конструкций.

> Можно перегрузить квадратную скобку.
Всё равно, a.b - это лаконичнее, чем [a b]
Особенно, a.b.c.d(12) - намного лаконичнее, чем [d [c [b a]] 12]

С другой стороны, перекрывать квадратную скобку хотят все. Очень быстро возникнет конфликт.

У меня на данный этап существует порядка 20-30 readmacro, из которых 5-7 я использую часто. Поскольку readmacro
связан с символом, можно удобно конструировать контекст чтения, включая тот или иной readmacro в пакет.
Это - действительно масштабируемое и управляемое решения, которое, к тому же, красиво смотрится и которое
удобно набирать на клавиатуре, в отличие от (dispatch-)macro-characters.

Основная проблема, как я уже говорил выше - это поддержка со стороны IDE. В случае с SQL, в общем-то, повезло,
но так повезёт не в любом случае. В общем-то, macro-characters тоже от неё страдают, т.к. они тоже
позволяют встраивать произвольный текст в код на лиспе.

Kergan

Members


Статус

300 сообщений

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

#6880   2013-01-05 08:38 GMT+3 часа(ов)      
2den73
Я вначале несколько неверно понял предназначение дсл. Если все сводится к интерполяции строк - то и делать это надо как интерполяцию строк, да.

Цитата
На выбор предлагается два места - место определения макроса и место его использования.

меня больше интересует что происходит с оставшейся частью запроса. ну то есть у нас написано fse macro blah-blah. macro - некоторый макрос, blah-blah - какой-то кусок запроса, который следует за макросом. Как расчитывается позиция blah-blah? то есть в sql она будет расчитана уже после раскрытия макроса, а в коде лиспа то макрос не раскрыт.

den73

Members


Статус

12 сообщений

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

#6883   2013-01-06 05:20 GMT+3 часа(ов)      
> Если все сводится к интерполяции строк
В SQL только подстановка параметров в запрос не сводится к интерполяции строк. Моя библиотека работы с SQL не поддерживает параметры, или поддерживает криво, или у меня руки не дошли. Поэтому передачу параметров я имитирую, подставляя значения в текст. Всё остальное, что можно делать в SQL, "по определению" сводится к интерполяции строк, поскольку SQL-запрос - это строка.
Назначение DSL:
1. работать с SQL из лисп.
2. делать это, по возможности, не хуже, а в идеале - лучше, чем в других средах.
Если сравнивать мою среду и IBExpert, то в целом IBExpert лучше, но некоторые возможности моей среды в нём отсутствуют.

> то есть в sql она будет расчитана уже после раскрытия макроса, а в коде лиспа то макрос не раскрыт.
Местоположение лексемы определяется в момент считывания её из лиспового файла, т.к. удалось достать эту информацию из потока. В момент составления окончательного текста SQL запроса все макросы раскрываются и строится для данного SQL-запроса отображение смещениеБуквыЗапроса->позицияВФайлеИсходникаНаЛиспе.

Kergan

Members


Статус

300 сообщений

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

#6884   2013-01-06 06:42 GMT+3 часа(ов)      
Цитата
Местоположение лексемы

ну так о чем речь - в файле лиспа этой лексемы нет, а в sql-запросе - есть.

den73

Members


Статус

12 сообщений

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

#6885   2013-01-06 16:34 GMT+3 часа(ов)      
А, вот о чём Вы. Если идёт просто подстановка лисповой строки, то тогда этот исходник не найти. Но, как правило, макросы для SQL сами включают в себя (fbody ... ^),
т.е., они тоже состоят из лексем, знающих своё место в файле. Но не все. Например,

fse ~~my_table_sql_rec^LIST from my_table;
развернётся в
select поле1,поле2,...полеN from mytable

Из любого места фрагмента поле1,поле2,...,полеN исходник не найдётся.
В этом случае, я ищу место, которое возникло из лексемы и уже на нём нажимаю "перейти к исходнику".

Можно было бы сделать так, чтобы в таком месте бралось ближайшее известное место из остальной части
запроса, но я не сделал.

den73

Members


Статус

12 сообщений

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

#6886   2013-01-06 17:05 GMT+3 часа(ов)      
(на самом деле, сделал, просто забыл)

snv

Members


Статус

25 сообщений
http://sym.at.ua/load
Где: Russia Серпухов
Род занятий: Безработный
Возраст: 31

#7037   2013-05-29 21:57 GMT+3 часа(ов)      
Цитата
metadeus :

>В основу … должна войти LLVM
Fail. Хороший язык должен быть self hosting, а LLVM - это лишняя зависимость на C/C++, которая затруднит например реализацию LispOS.

>Часть семантики CL планируется оставить практически без изменений
Fail. Семантика CL ущербна, ибо теже пакеты путаются под ногами, глобальные пространные имён ммодульности, а eval-when усложняет компиляцию.

>first-class continuations, да оптимизацию хвостовой рекурсии запилить прям в стандарт языка как в Scheme
Fail. Неограниченные континуации мешаю безопасности и unwind-protect/RAII

>Система типов планируется в следующем виде: в core lang: статическая типизация с базовыми типами близкими к языку C + какое-то приближение лямбда-исчисления (Хиндли-Милнер);
Fail.
1. Сложная система типов делает язык недоступным для 95% людей
2. Инференция типов - затрудняет понимание работы кода, а генерики генерируют лишний код у тебя за спиной

>ООП с динамической диспетчеризацией по обобщенным функциям как в CLOS
Fail.
CLOS - вещь в себе, слишком сложная для 95% людей и по размеру чуть ли не больше самого компилятора Common Lisp.

> использовании макросов Racket больших изменений не потребуется.
Fail. Макросистема Scheme/Racket слишком сложна для 95% людей.

>41) С макросами пока нет определенности, после дополнительного изучения будет определено какой тип макросов оставить (CL или Racket). Скорее всего Racket, т.к. судя по обсуждению ниже мы ничего не теряем и в то же время простые вещи упрощаются.
Fail. Система пакетов и макросистема - основополагающие части Lisp. Все остальное реализуется через них.

>50) Работу с файловой системой тоже планируется перепроектировать, т.к. в CL это суко говно мамонта какое-то.
Fail. Файловая система ненужна вообще. Это аппендикс доставшийся нам от Unix. Более того, многие программы (вроде эмуляторов OS и браузерных скриптов) просто не должны иметь произвольный доступ к файлам пользователя.

>60) Необходимо четко разделить рантайм и стандартную библиотеку, которую планируется распихать по пакетам.
Fail. Многие задачи требуют полной замены или переопределения стандартной библиотеки. Более того, системный язык требует учитывать on-fly замену сборщика мусора и компилятора. Например, раний этап загрузки LispOS работает вообще без сборщика мусора и компилятора.

>70) Планируется так же реализация поставки библиотек в виде скомпилированного кроссплатформенного байткода
Fail. Common Lisp уже использует FASL, который можно и как DLL применять

>80) Поддержка юникода искаропки, внутренняя кодировка только UTF-8, только хардкор.
UTF-8 - аппендикс от Unix. Лиспу он нужен не больше чем ASCII или EBCDIC.

>90) Избавление от не-Лисп-style макросов типа loop, замена их чем-то более дружественным Лиспу (iterate там).
Fail. Макросов сложней `while` вообще быть не должно в стандартной библиотеке. Если пользователю они нужны - определит сам.

>100) Case-sensitive конечно же.
Fail. Надо либо принудить все символы к lowercase, либо к Prolog стилю, где все переменные должны начинать с заглавной буквы, а lowercase символы работают как keyword-ы

>110) Возможность сохранить систему в исполняемый бинарник.
Fail. "исполняемый бинарник" - аппендикс от Unix. Lisp уже имеет eval и lambda функции.

>130) Предполагается возможность отключения сборщика мусора и управления памятью вручную (по типу реализации в D2), а так же возможность переопределения операций выделения/освобождения памяти для реализации своих аллокаторов.
Fail. Сборщик мусора необходим для тех же bignums. Проще и надёней ограничить размер heap, ибо кучу размером в 512 килобайт можно уместить в кэш и гарантированно очистить за микросекунду, не теряя в безопасности.

>140) Возможности работы с LLVM напрямую -- все необходимые привязки в ядре языка: генерирование функций, блоков и SSA-инструкций в рантайме и их подключение. (Поверх FFI)
Fail. Ещё больше внешних зависимостей.
The hour will come in which all the peoples of the earth will awake, and the Jews will be the victims. -- Joseph Goebbels, 21 January 1945


Онлайн :

1 пользователь(ей), 18 гость(ей) :
skelter



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