LINUX.ORG.RU

Макросы в Scala против макросов в Common Lisp

 , ,


2

8

Я почитал туториал от 2016 года и написал очень краткую выжимку из него.

Что можно сказать? Во-первых, CL как язык для МП устаревает и теряет привлекательность буквально у нас на глазах. В scala, конечно, МП менее удобно из-за более сложного синтаксиса, зато в Scala появилась концепция семантической БД - это результат семантического анализа текста со всеми типами данных и декларациями. В CL такой семантической БД нет. Притом что Scala - это даже не первый такой язык. Если я правильно понял, clang тоже такое умеет.

Среди не афишируемых целей проекта Яр есть цель сделать именно такую семантическую БД. Теперь нет смысла это скрывать.

Поимимо этого, кто не в курсе - Common Lisp _не является_ гомоиконным языком, потому что есть #. , квазицитаты частично обрабатываются, а комментарии теряются. Другие побочные эффекты чтения - это создание символов в пакетах. macro character-ы назначенные пользователем, могут делать что угодно, вплоть до запуска ракеты. Т.е. нельзя зачитать файл лиспа и проанализировать его средством без последствий для среды. Вообще нельзя. Для Java и C это сделать можно, а для лиспа - нет. Фига себе, да? Ещё одной целью проекта Яр является создание истинно гомоиконного языка. Причём это не моя прихоть, а обязательное условие для создания полноценной IDE, а не набора костылей, каковым является SLIME.

Если ещё остались энтузиасты лиспа, можно попробовать сделать семантическую БД для CL. Есть augment-environment, к-рая поддерживается в CCL. В ней есть кое-какая информация о типах. Хотя на самом деле скорее всего придётся патчить компиляторы.

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

И ещё одно странное наблюдение - похоже, что макросы в Scala никому особо не нужны.

★★★★★

Ответ на: комментарий от feofan

fix formatting

den73>

Давайте вернёмся к теме: кто-нибудь хочет сделать библиотеку, содержащую слой переносимости для извлечения инфы о типах и декларациях для разных реализаций CL? Или может быть кто-нибудь знает о такой?

ctags разве умеет в references?

в literate programming среде, типа noweb автоматически генерируется типа такого:

.... Identifiers

Knuth prints his index of identifiers in a two-column format. I could force this automatically by emitting the \twocolumn command; but this has the side effect of forcing a new page. Therefore, it seems better to leave it this up to the user.

already_warned: U1, U2, D3, U4, U5 ...

.... <variables of the program>: U1, D2, D3, D4, D5, D6, D7, D8

Identifiers

j_prime: U1, D2, U3, U4 mult: D1, U2, U3 ....

... <Write statistics for file>: U1, D2

Indentifiers

argc: D1, U2, U3 argv: D1, U2, U3, U4 ...

то есть, с палками и верёвками, на древнем noweb — задача уже решена.

если

  • а) исходники переписать в literate programming виде
  • б) IDE должна делать что-то подобное, «за кадром»

    например, если взять skribilo на Guile как literate programming tool, или какое-то litprog средство на Common Lisp (например, обзор, также интересная публикация про L), или тот же Emacs org-mode

  • в) то есть, основная идея: Litprog средство должно работать с исходниками не в виде plain text как тот же noweb, а со структурированными S-выражениями — как в skribilo, racket scribe, org-mode

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

то есть, тащем-та как offline tool — это уже вполне себе есть в literate programming tools, том же noweb. есть некоторые, которые работают с S-выражениями.

как там с инкрементальностью — самому интересно, конечно же.

то есть, чтобы было не offline, а online и использовало не файлы, а какие-то inmemory DB на S-выражениях.

ЕМНИП, ничего готового такого вот нету, но можно допилить в этом направлении.

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

Слушай, ты какой-то кощей безсмертный - я вроде сегодня заигнорил анонимуса, а ты как-то выжил. Я не сторонник litprog (просто потому что уже старый, тупой а тут целая отрасль осваивать).

Суть проблемы - нужно извлечь данные из реализаций Common Lisp. Данные там есть, но они существуют только во время компиляции и их формат зависит от реализации CL. Извлечь - это первое дело. Есть GPL библиотека под это, но я и GPL - это две большие разницы, поэтому я даже забыл её название. Вроде ещё коде волкер от hu.dwim может. Но если ты хочешь это обсуждать, то пиши на почту. Я в обозримом будущем анонимусов разигноривать не собираются и ЛОР больше для тебя не является надёжным способом доставить мне сообщение.

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

В SBCL все массивы с fill-pointer - adjustable

И вообще, можно сказать, в SBCL есть два типа массивов, simple и hairy. У последних есть fill-pointer, они adjustable и прочее.

Layout в памяти примерно такой:

simple-array:
[TAG | LENGTH | ...elements...]

hairy:
[TAG | DIMENSIONS | FILL-POINTER | ...ETC... | DATA-POINTER ]
                                                  |
                                                  V
                   (simple-array)[ TAG | LENGTH | ...elements...]

Все операции доступа к simple-array - моментальные и константные, типа как в Си почти. В случае с hairy-массивами идут GENERIC-операции, типа как обобщенная арифметика, медленно. Плюс локальность памяти играет роль.

Но, при этом, если заливать массив чанками, типа через стандартные функции(REPLACE/FILL/etc), а не поэлементно, то вполне может быть быстрее, чем через поэлементный доступ к simple-array в некоторых случаях.

Ну как пример:


(defun strconc (&rest args)
  (let ((buf (make-array 0 :element-type 'character
                           :adjustable t
                           :fill-pointer t)))
    (dolist (x args buf)
      (unless (null x)
        (let* ((string (string x))
               (string-length (length string))
               (length (fill-pointer buf))
               (new-length (+ length string-length)))
          (when (> string-length 0)
            (when (> new-length (array-total-size buf))
              (adjust-array buf (1+ (* new-length 2))))
            (setf (fill-pointer buf) new-length)
            (replace buf string :start1 length
                                :end1 new-length
                                :start2 0
                                :end2 string-length)))))))

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

Поздравляю, анонимус которого ты так долго искал - anonimous. Вы должны были найти друг друга.

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

то пиши на почту. Я в обозримом будущем анонимусов

разигноривать не собираются и ЛОР больше для тебя не является надёжным способом доставить мне сообщение.

Блядь слезы наворачиваются. Два долбоеба нашли друг друга. Это любовь.

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

Literate Programming in Common Lisp

cast den73Erudite описание гитхаб — дальнейшее развитие LP/Lisp скачать

LitProg средство на Common Lisp, новое и старое. в старом генерация только LaTeX и конвертация в Emacs org-mode, в новом — org-mode/markdown/sphinx html/rst/pdf/...

в Erudite есть индексатор переменных и функций.

можно посмотреть код оттуда.

anonymous
()
Ответ на: Literate Programming in Common Lisp от anonymous

чем отличается от других LitProg средств типа noweb:

грамотная разметка идёт в комментариях, типа как в doxygen.

то есть «грамотный исходник» заодно является и кодом на лиспе.

из него генерируется документация через weave и код через tangle.

лисп лиспом генерирует лисп.

«small web of concept networks» из LP/Lisp pdf =>

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

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