Чем заменить CL и Scheme?

Lua

SICP нынче вроде на Python преподают?

OCaml

Elixir.

Javascript. Тем более, что SICP есть на нём. К остальному пятку, я думаю, обратишься уже через годик-другой, если филонить не будешь.

Clojure. Ну, накрайняк, ClojureScript.

на каком-нибудь другом ЯП для большей пользы

Haskell, например

А в чём «большая польза»? Шило на мыло.

ещё с пяток книг, использующих Lisp

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

Вопрос всплывает почти каждый год, видимо «судьба такой». И ответ прилетает всегда (почти всегда) один и тот же - Racket/Scheme. Haskell и прочие Idris’ы лучше оставь альтернативно одарённым людям.

Технически, можно любым языком, где есть списки и первоклассные функции (в том числе Haskell). Практически, тебе надо знать лисп и целевой язык достаточно, чтобы понять, какую функцию какой заменить.

проще всего erlang. Хаскель ленивый и сильно сложный.

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

Какой смысл менять шило на мыло? Лучше что нибудь плохо подходящее для таких задач - Си, например, или Rust.

Планирую выполнять их на каком-нибудь другом ЯП для большей пользы.

На каком-нибудь другом — это на каком-нибудь более-менее похожем, чтобы меньше сложностей адаптации, или наоборот?

На каком-нибудь популярно-практичном, или пофиг?

Энивей, попробуй Oz (wikipedia.org).

Чем угодно тьюринг-полным. А так еще можно прогулками на свежем воздухе.

Плюсую прогулки.

Лисп - это такая вещь в себе. Поэтому остаются из популярных clojure и Racket.

У haskell свои книги вместо SICP. Например, Вил Курт «Программируй на Haskell». А если ты американец, то там у вас есть оригинал.

А цель какая?

Энивей, попробуй Oz.

По нему я Concepts, Techniques, and Models of Computer Programming планировал прочитать, но пока не поборол свой страх мертвечины.

RE: Ускорение НТР

@Irma, Oz и Mercury. Последний активно пилят больше 30 лет, есть неплохая стандартная библиотека; используется ровно в 1 проекте (в каком-то маленьком австралийском ООО для парсинга HTML, о чём известно только с их слов).

А цель какая?

Цели нет, только путь.

ISLISP (более вменяемый стандарт, чем CL) eisl или openlisp (реализации ISLISP), LFE (lisp flavoured erlang – есть книжка SICP на нём), clojure (есть книжка SICP на нём) , 3lisp, SINK John Schutt kernel vau-expressions, elisp, форт, фактор, APL, J, K из Kxdb, Q

Какой-нибудь Haskell

SML, Myrrdin и прочий ML, тот же F# например.

можно кашей:

https://www.gnu.org/software/kawa/

скушай кашки :-)

(ссылка почти только ради убойного логотипа)

Если только путь, то CL / Racket и Haskell / Ocaml. Там больше интересных книг.

Вот вы читали Питера Норвига «Paradimgs of Artificial Intelligence»? В свое время как-то много лет назад прочитал с удовольствием. Мне понравилось.

Из хаскеля мне нравится Пол Хьюдак «The Haskell School of Expression». Правда, там есть главы про музыку, в которой я ничего не понимаю, но я их так бегло просмотрел.

Если ближе к практике, то есть интересные книги по Scala. Есть хорошая книга «Expert F#» от коллектива авторов с самим Доном Саймом, автором языка. Так глядите, станете потом энтерпрайзным квалифицированным разработчиком Java и .NET. Особенно, если преодолеете нелюбовь к Spring и чего там есть еще такое энтерпрайзное для .NET.

Или вон котлин вам потом понравится. Упрощенная scala как никак. Станете вон разработчиком андроида или бэкенд-разработчиком, если опять преодолеете энтерпрайзность спринга и недоверие к авторам котлина.

Энтерпрайзность, она такая. После ФП ее как-то хочется обходить стороной! Но деньги-то нужны!

Дерзайте только в путь! Что-то по душе можно найти.

Собираюсь перечитать SICP и ещё с пяток книг,

ПОНТЫ!!!

Планирую выполнять их на каком-нибудь другом ЯП для большей пользы.

Это случится не скоро!

Scala 2.

Питоном

Если питоном, то надо осознавать, что то, что в питоне называется списками, не является списками в смысле лиспа. И рекурсия там ограниченная.

Если

(define (length items)
  (define (length-iter a count)
    (if (null? a)
        count
        (length-iter (cdr a) (+ 1 count))))
  (length-iter items 0))

является эффективным решением, то эквивалент на питоне:

def length(items):
  def length_iter(a, count):
    if a == []:
      return count
    else:
      return length_iter(a[1:], 1+count)
  return length_iter(items, 0)

является примером того, как никогда не надо писать на питоне.

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

Уважаемый monk намекнул вам, что в питоне нет оптимизации хвостового вызова (TCO), а в схеме она полноценная (в отличие, от той же Scala, например). А без TCO рекурсивные функции из высоко-эффективных превращаются в жручие и падучие.

Можно также вручную раскручивать хвостовую рекурсию в цикл.

Но, в целом, да. Придётся написать лисп на питоне и программы писать уже на нём.

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

Если выкинуть макросы, то бери любой где можно взять лямбду и положить её в переменную. Хоть Javascript.

как ты в хаскеле изобретешь синтаксическую абстракцию?

Не любую рекурсию можно записать вручную. В этом может помочь только среда исполнения, чтобы было полноценно на 100%! Речь о косвенной рекурсии. Нужно специальное соглашение о вызове функций по примеру описанного в упомянутом PAIP Питера Норвига.

Собственно, из-за того, что в JVM нет оптимизации хвостового вызова (TCO), в Scala в итоге забросили плагин продолжений, где, например, бесконечный «while (true) {}» просто выжирал всю память. Похоже, что в команде Scala пытались реализовать TCO через трамплин, но результаты их, мягко говоря, разочаровали. Ну, а в JVM наотрез отказались добавлять TCO, хотя во многих реализациях .NET он есть - доступно из F#.

А без TCO нет полноценной хвостовой рекурсии и быть не может, только обрезки как в той же Scala, хотя скалистам это не особо-то и мешает.

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

А вот, схема умеет TCO, как умеют и хаскель с F# и, может быть, окамл. Возможно, что это весь список… Хотя, вот некоторые реализации CL умеют, а может, что только одна - SBCL. LispWorks точно не умеет. Вот, такие пироги

LispWorks точно не умеет. Вот, такие пироги

Умеет. Даже в документации про это написано.

https://www.lispworks.com/documentation/lw80/lw/lw-compiler-ug-7.htm

9.7.5 Tail call optimization

Да читал я это, правда это было давно. Подобное и в учебниках по Scala пишут без конкретизации, что обыватели потом думают, что там тоже есть полноценная хвостовая рекурсия… Есть, но урезанная, не полноценная. Сам Одерский, конечно, в теме разбирается, что видно по его статьям на тему плагина продолжений.

Короче, возьмите cl-cont и внутри макроса запустите бесконечный loop. Если он выжрет всю память компьютера, то TCO нет. Если память будет на одном уровне, а программа будет исполняться вечно, то TCO есть. Это самый простой тест из известных мне.

Проверять мне лень сейчас. Когда много лет назад проверял, то была труба.

Поправка. Выжрет не память, а выжрет стек вызовов.

Ничем. SICP заточен под Схему в том числе из-за простоты реализации самой схемы. Хачкель ты сам писать жопу себе порвёшь, даже минимальное его подмножество.

Пиши на Схеме и не выдрючивайся.

как ты в хаскеле изобретешь синтаксическую абстракцию?

ваще легко

никак

не совсем именно про хачикель, но про ML: была статья абстрактные машины и почему они эффективнее виртуальных машин.

машина Кривина, zam-kazam05.pdf

«From Krivine’s to the Caml implementations», Xavier Leroy

1. A retrospective on the ZAM, a call-by-value variant of Krivine’s machine.

2. From abstract machine to efficient P.L. implementations: the example of Caml Light and Objective Caml.

3. Beyond abstract machines: push-enter models vs. eval-apply models.

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

про лисп – такого нетути. есть про LispKit, SECD машину ту же, «механическая реализация лямбда исчисления» (кажется, Лэндин про SECD), про 3-lisp тот же. хорошая ссылка была про всё это лисповое у сотни зайцев которые на яхте с девятым планом. LiskKit вон вообще есть паскалевская реализация, ещё BASE на паскале SECD. 3-lisp тоже занятный. ещё на BCPL есть какой-то лисп.

ну и чтобы два раза не вставать:

по конпеляторам презентация CompilerTalk-2019.pdf LtU (lambda-the-ultimate.org)

«Graydon Hoare: 21 compilers and 3 orders of magnitude in 60 minutes»

21 compilers and 3 orders of magnitude in 60 minutes a wander through a weird landscape to the heart of compilation

там приводится 21 особь (specimen) начиная с анекдотично громозких конпеляторов С++ :

слайд 8. Шланг Clang: 2M строк (800k сам + 1.2M LLVM)

слайд 10. растишка от данон: 360k сам + 1.2М LLVM

слайд 12. особь № 4, Gcc (который на g++) – 2.2M строк.

Enjoy your C++!!

и т.д и т.п. через ML, лиспы и форты.

вплоть до особи № 21. JonesForth 1490 строк, 692 строк VM.

сюда можно в принципе и варвару добавить и uxn от сотни зайцев.

и тот же ретрофорт или ngaro vm например.

и ту же схему ribbit.

где всё это ещё компактнее.

или например Myrrdin который ML подобное под Plan9, да тот же QBE аналог LLVM с SSA, например.

но в целом, достаточно для понимания:

1. почему часть конпеляторов пишут на лиспах, часть на ML.

2. и почему 2.2М строк на С++ – это театр абсурда какой-то.

лисп на лиспе компактный это например sectorlisp от justine.lol, 3-lisp, kernel klisp, shen, да тот же LispLit или BASE SECD на паскале например (очень наглядные).

у сотни зайцев про лиспы неплохо.

про метациклическую схему на схеме тоже где-то в местах от SICP не столь отдалённых было.

а так да, вот наглядная демонстрация.

хочешь написать конпелятор в 2 милиона строк – добро пожаловать в С++, лолъ.

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

а что в итоге? теперь в CLFS циклические ссылки в процессе сборки и в результате пересобирают кроссконпелятор по три раза.

вот он, театр абсурда. Enjoy your C++ everywhere.

;;;; Krivine's Machine in Scheme ;;;;
;;; 2012 Minori Yamashita <ympbyc@gmail.com> ;;add your name here

пыщь

через Template Haskell, например.

но да, тут уже что-то типа ocaml-овского парсера на CTMP нужно городить.

что-то типа converge pl питоноподобного, где вместо макросов с quote/unquote/splice/выборочный eval – типизированные AST и CTMP, compile-time metaprogramming как более продвинутые, модульные и типизированные макросы.

парсер в основном вручную городить придётся, или на вход ему что-то ADT-подобное подавать.

хотя можно например tree meta или meta ii взять на самом себе и ту же META на эдаком CTMP изобразить.

то есть по сути для синтаксических макросов нужно что-то типа этих более продвинутых макросов с CTMP и нормальный интерфейс между интерпретатором и конпелятором (в converge pl lift FEI и т.п.)

или можно как в том же D pegged PEG парсер на CTFE реализован.

там правда есть string mixin, template mixin, нормальные а не всратые шаблоны не как в С++, нормальная рефлексия и CTFE по ней.

так что даже такое не так просто и наглядно как в D получится.

Не любую рекурсию можно записать вручную. В этом может помочь только среда исполнения, чтобы было полноценно на 100%! Речь о косвенной рекурсии. Нужно специальное соглашение о вызове функций по примеру описанного в упомянутом PAIP Питера Норвига.

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

Кстати, пользуясь случаем, хотел спросить, как поживает Racket?

Уж больно меня их call/cc интригует. А вот ООП как-то не понравилось, когда я смотрел много лет тому назад.

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

Ну, мы все были когда-то студентами… И оглядываясь на свое прошлое, я все же считаю, что развивать продукт лучше 30-летним и 40-летним - как по мне, так самый плодовитый возраст.

// прежний аноним с PAIP

Кстати, пользуясь случаем, хотел спросить, как поживает Racket?

Отлично живёт, развивается. https://blog.racket-lang.org/2024/05/racket-v8-13.html

А вот ООП как-то не понравилось, когда я смотрел много лет тому назад.

Там ООП исключительно для графического интерфейса. Эту функцию он выполняет достаточно хорошо.

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

С учётом того, что они успешно перетащили ядро Racket на Chez Scheme, а сейчас пилят Rhombus (https://docs.racket-lang.org/rhombus/index.html), ресурсов на разработку хватает.

Если так смотреть, то разработчик TeX тоже был преподавателем.

Lua

(хотя наверноеное не всех фич лиспов будет хватать, но наверное в том и смысл, когда близко к лиспу по ряду моментов, но не в лоб как кложура какая и типа того)

Спасибо!

Про SICP на Clojure вот эта, ананасик?

https://www.sicpdistilled.com/

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

P.S. Затея «хочу SICP, но не SICP» изначально очень сомнительная. Теряюсь в догадках почему эта тема время от времени поднимается.