LINUX.ORG.RU

Вопрос про Dylan (из темы про D)


0

0

Анонимусу, который приводил ссылки на Dylan в теме про D:
что-то у меня Dylan выпал из внимания. По-моему, мне не понравились его макросы. Сейчас смотрю - на первый взгляд, подставы нет.
В общем, вопрос такой - насколько язык жизнеспособен сегодня?

★★★★★

А, по-моему мне не понравилось то, что они стали бороться с захватом переменных. Для меня, with-gensyms полностью решает проблему, а в некоторых случаях я специально хочу, чтобы переменные были захвачены. Мне показалось, что в Dylan это нельзя, после чего я отказался от дальнешего изучения. Так что второй вопрос - могу ли я захватить переменную в дилановском макросе или обратиться к символу с вычисленным именем?

den73 ★★★★★
() автор топика
Ответ на: комментарий от den73

Ну, в общем-то да. В конце этого текста
http://people.csail.mit.edu/jrb/Projects/dexprs.pdf
написано, что

Unlike a grand tradition in Lisp, replacement

phrases are constructed purely by template substitution
and not arbitrary computation.

И это значит, что нельзя, например, сделать препроцессор для встроенного SQL, который проверяет корректность текста запроса во время компиляции. Это плохо.

den73 ★★★★★
() автор топика

>В общем, вопрос такой - насколько язык жизнеспособен сегодня?

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

volh ★★
()
Ответ на: комментарий от den73

В общем, я думаю, план работ над языком мечты мог бы быть примерно такой:

1. Берём opencxx

2. Превращаем его просто в openc, удаляя всё, что относится к C++

3. Портируем на common lisp.

4. Используем opencxx для перехвата таких операций, как копирование указателя и взятие ссылки. Делим весь код на «опасный» и «безопасный». В безопасном коде вводятся некоторые ограничения (их вводим уже на следующем этапе).

5. Расширяем cpp: - возможность сохранять и восстанавливать состояние макропроцессора (а может быть, и компилятора, раз уж у нас будет openc) - удаление однострочности - макросы могут быть многострочными. Например

#def NAME(params)
  BODY
#endef 

- добавление &rest,&key,&body (вроде бы &body есть в gcc?)

- добавление macrolet и просто defmacro (макрос может расширяться в директивы макропроцессора)

- добавление вызовов CommonLisp, причём, параметры макроса передаются лисповой функции в виде списка лексем. Например

#def SORT(&rest lexems)
  LISP(list-to-comma-separated-list
   (sort (comma-separated-list-to-list lexems)
     :key 'lexem-test
     :test 'string<))
#enddef

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

den73 ★★★★★
() автор топика
Ответ на: комментарий от den73

>Unlike a grand tradition in Lisp, replacement phrases are constructed purely by template substitution and not arbitrary computation.

Правильно. В отличие от Lisp, захват переменных происходит только в тех случаях, когда это явно задано.

Dylan provides a much more natural mechanism for intro-

ducing hygiene escapes using an intuitive notation, ?=.

anonymous
()
Ответ на: комментарий от anonymous

> В отличие от Lisp, захват переменных происходит только в тех случаях, > когда это явно задано
Но основной недостаток - в том, что, как я понял, нет произвольных вычислений в макрорасширителях. Или я опять не прав?

den73 ★★★★★
() автор топика
Ответ на: комментарий от den73

>Но основной недостаток - в том, что, как я понял, нет произвольных вычислений в макрорасширителях. Или я опять не прав?
Да.

anonymous
()

>Но основной недостаток - в том, что, как я понял, нет произвольных вычислений в макрорасширителях.
Да.

anonymous
()
Ответ на: комментарий от anonymous

> Спасибо!
Да, удивительно, насколько часто прогресс оказывается губителен. Хотя, конечно, есть определённый смысл запретить произвольные вычисления. При этом можно ведь генерировать исходные тексты, как это обычно делается в других языках, когда нужны макросы. Но лично мне это не по вкусу.

den73 ★★★★★
() автор топика

Из википедической статьи.

Initially, Dylan used a Scheme-like prefix syntax, which is based on s-expressions:

(bind ((radius 5)
       (circumference (* 2 $pi radius)))
  (if (> circumference 42)
      (format-out "Hello big circle! c is %=" circumference)
      (format-out "Hello circle! c is %=" circumference)))
By the time the language design was completed, it was changed to an Algol-like syntax, designed by Michael Kahl, with the expectation that it would be more familiar to a wider audience of programmers:
begin
 let radius = 5;
 let circumference = 2 * $pi * radius;
 if (circumference > 42)
    format-out("Hello, big circle! c = %=", circumference);
 else
    format-out("Hello, circle! c is %=", circumference);
 end if
end

Переводя на русский: в угоду быдло-monkey-кодерам превратился из Лиспа в Бейсик. Дальше продолжать, или сам закопаешь?

anonymous
()

Из википедической статьи.

Initially, Dylan used a Scheme-like prefix syntax, which is based on s-expressions:

(bind ((radius 5)
       (circumference (* 2 $pi radius)))
  (if (> circumference 42)
      (format-out "Hello big circle! c is %=" circumference)
      (format-out "Hello circle! c is %=" circumference)))
By the time the language design was completed, it was changed to an Algol-like syntax, designed by Michael Kahl, with the expectation that it would be more familiar to a wider audience of programmers:
begin
 let radius = 5;
 let circumference = 2 * $pi * radius;
 if (circumference > 42)
    format-out("Hello, big circle! c = %=", circumference);
 else
    format-out("Hello, circle! c is %=", circumference);
 end if
end

Переводя на русский: в угоду быдло-monkey-кодерам превратился из Лиспа в Бейсик. Дальше продолжать, или сам закопаешь?

anonymous
()
Ответ на: комментарий от volh

> Ни активности в рассылках, ни новостей, ни обсуждений в интернете, несколько в разной степени сырых компиляторов, эге?

да, это удручает. Хотя если порыскать по SVN, обнаруживается, что кто-то пилит type inference и LLVM компилятор (биндинги к LLVM уже есть в SVN).

anonymous
()

> В общем, вопрос такой - насколько язык жизнеспособен сегодня?

сложно судить. С одной стороны, язык и пара компиляторов есть и работает. OpenDylan можно скачать, весит 90M — включает IDE с проектами, REPL запущенного приложения, компилятор, генерирующий нативный код. Правда, я не воспринимаю IDE без синтаксической раскраски, поэтому приходится пользоваться Emacs-ом (или есть надежда допилить deuce, родной текстовый редактор из IDE (он аналогичен емаксу portable hemlock, только фич маловато и расширяемости), чтобы он понимал синтаксическую раскраску) + использовать консольный компилятор. Компилятор сносно работает под Windows, Linux, компилирует довольно быстро. Компилятор написан сам на Dylan, но в конечном итоге собирается Си компилятором через Jam систему сборки. Можно выбирать gcc, msvc, pelles c. Код получается в виде кучи DLL c runtime языка ~20M в совокупности + 20К..1М само приложение. Собственно динамичность реализуется переключением всяких разных DLL на ходу (debug/release/и т.п.). Язык, система модулей, ООП сильно похожи на CL. Правда CLOS упрощён немного, но сделан упор на готовые библиотеки и «батарейки». Библиотек в среднем достаточно: есть GUI (DUIM=McCLIM), есть ODBC, для винды есть COM/CORBA/ActiveX обёртки лисповыми макросами :)) Внезапно программировать под COM становится не так страшно. Первый компилятор, OpenDylan в основном под винду + упор на IDE и генерацию нативного кода, оптимизацию Gwydion Dylan, второй компилятор в осном под юниксы + кодогенерация в си + сборка через gcc и мейкфайлы. Библиотек в среднем поменьше, но тоже портируют потихоньку, DUIM есть на GTK. Надо брать свежую версию из SVN, старый 2.4 у меня на Gentoo не собрался (но с небольшими пинками собрался под Haiku). В SVN что-то пилят на тему LLVM. FFI с Си встроенный, есть import, который понимает Си хедеры. Биндинги и обёртки в основном делаются чтобы придать функциям вид вроде CLOS/или макросов.

Язык в общем работоспособный. Есть библиотеки, системы сборки, примеры, какие-то приложения. Вполне годится для прототипирования GUI/CRUD интерфейсов к БД/каких-то компиляторов/парсеров. Правда, смущает та же «многословность» и местами не наглядность именования/синтаксиса.

Язык имеет смысл попробовать на предмет «как функциональность лиспового рантайма в образе засунуть в отдельные DLL-ки, и набрать из них минимальный рантайм». Хотя рантайм получается не таким уж минимальным: ~10..20M в OpenDylan, ~1M в Gwydion. На тему минимализма можно попробовать goo или Church/State — там нет алгольного синтаксиса, но общий дух «всё это CLOS объекты, прозрачная интеграция с Си» примерно тот же.

anonymous
()

Ещё в OpenDylan есть MPS http://wiki.opendylan.org/wiki/view.dsp?title=Memory+Pool+System http://www.ravenbrook.com/project/mps/doc/2002-01-30/ismm2002-paper/ismm2002....  — GC из разных пулов с делением на зоны, арены и т.п. Довольно эффективный аллокатор/сборщик мусора. Насколько я понимаю, он довольно гибкий — можно приспособить один пул не под GC, а под выделяемую твоим способом память.

anonymous
()

да, ещё касательно SLIME+Dylan. Надо брать из SVN и SLIME и dswank, но SLIME обновляется гораздо чаще, и есть вероятность что dswank сломается. Возможно, придётся повозиться чтобы найти работающую комбинацию SVN ревизий и того и того.

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.