?

Log in

Почему LISP? - Жить не можем без проблем! [entries|archive|friends|userinfo]
Жить не можем без проблем!

[ userinfo | livejournal userinfo ]
[ archive | journal archive ]

Почему LISP? [Jan. 13th, 2011|02:05 pm]
Жить не можем без проблем!

ru_lisp

[aralex]

Как говорил Ворошилов, вопрос к Знатокам (к знатокам LISP-а в данном случае)! Почему таки LISP? Или, если конкретнее, вопроса три:

  1. Для каких именно задач LISP подходит больше, чем другие языки?
  2. За счёт чего для них он подходит больше?
  3. В чём именно выражается его преимущество?

Если не в лом, приведите, pls, коротенькие иллюстрации на LISP-е (или ссылочку на них). Заранее благодарен!

Исходно данный пост был размещён в сообществе ru_programming, но там Знатоков, способных ответить внятно и по сути, увы, не нашлось :(

linkReply

Comments:
[User Picture]From: thesz
2011-01-19 09:21 pm (UTC)
Но получится точно больше 50%. ;)
(Reply) (Parent) (Thread)
From: (Anonymous)
2011-01-20 03:35 am (UTC)
Неверно выразился. Как считать более менее понятно - смотрим в каких макросах это используется, а в каких нет. В CL будет использоваться почти везде, потому что по-другому в CL нельзя :)
Другое дело, что шерстить весь проект и смотреть каждый макрос - несколько лениво.
(Reply) (Parent) (Thread)
[User Picture]From: thesz
2011-01-20 09:06 am (UTC)
>В CL будет использоваться почти везде, потому что по-другому в CL нельзя :)

В CL нельзя писать код без побочных эффектов? Не поверю.

И меня больше интересовало отношение количества кода макросов с побочными эффектами к коду приложения вообще. Это даст примерное понимание результата отказа от таких макросов.
(Reply) (Parent) (Thread)
From: (Anonymous)
2011-01-20 03:42 pm (UTC)
> В CL нельзя писать код без побочных эффектов? Не поверю.

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

> И меня больше интересовало отношение количества кода макросов с побочными эффектами к коду приложения вообще.

А что может дать это отношение?

> Это даст примерное понимание результата отказа от таких макросов.

Нет, конечно. Эта величина вообще никакого смысла не имеет, смысл имеют следующие величины:
1. отношение макросов "с побочными эффектами" к количеству макросов вообще
2. отношение кода с такими макросами к эквивалентному коду, который реализован без таких макросов.
Второе измерить нельзя, первое - ну как-то, но никто этого делать не будет, потому что долго, нудно, разве что в рамках какого-то научного исследования. А вообще, ваш троллинг чересчур толст. Я уже популярно объяснил, что такие макросы используются в реализации стандарта языка (что уже гарантирует их "нужность"), кроме того, они позволяют делать то, что нельзя делать обычными макросами (без доступа к среде) либо существенно упрощают то, что сделать можно, но делается очень и очень криво. Вы, конечно, не в курсе вообще, какие макросистемы бывают, какие у них особенности, какие достоинства и недостатки, как они реализуются - по-этому и не понимаете, к каким глобальным последствием для макросистемы ведет такое вот "урезание". Советую разобраться с макросистемой r5rs, почитать papers на соответствующую тему - и вы увидите, какой анальной акробатикой приходится заниматься для реализации элементарных, в сущности, вещей. Кроме того, вы так и не объяснили, зачем вообще это надо, кроме незначительного упрощения общей семантики, которое само по себе ничего не дает.
(Reply) (Parent) (Thread)
[User Picture]From: thesz
2011-01-20 07:58 pm (UTC)
>Вы, конечно, не в курсе вообще, какие макросистемы бывают, какие у них особенности, какие достоинства и недостатки, как они реализуются - по-этому и не понимаете, к каким глобальным последствием для макросистемы ведет такое вот "урезание".

Я от "макросистем" отошёл в 27 лет. ;)

Сейчас мне 39, если что. ;)

В интересных для меня задачах они не дают достаточного результата.

>Кроме того, вы так и не объяснили, зачем вообще это надо, кроме незначительного упрощения общей семантики, которое само по себе ничего не дает.

Далее там интересное вылезает.

Появляется возможность задать типы для макросов, типы для исходных и конечных термов, и т.п.

Получается, что можно сделать хороший, годный Лисп. ;)
(Reply) (Parent) (Thread)
From: (Anonymous)
2011-01-21 01:59 am (UTC)
> Я от "макросистем" отошёл в 27 лет. ;)

Вы к ним не подходили.
Вот вам вопрос на засыпку - в негигиенической макросистеме макрос, который раскрывается в форму объявления (например в (define x 5)) - имеет сайд-эффекты или нет? Как "функция" он просто возвращает константный кусок АСТа (соответствующего коду "(define x 5)") - то есть полностью "чист".

> В интересных для меня задачах они не дают достаточного результата.

Нет, это значит, что вы предпочитаете другой стиль разработки.

> оявляется возможность задать типы для макросов, типы для исходных и конечных термов, и т.п.

Вы далеко не самый умный, все уже придумали до вас. Я же сказал - изучать макросистему для syntax-rules. Там как раз и есть макросы без сайдэффектов, сохраняющие лексическую структуру программы. Только у вас все на уровне интуитивного понимания - "хочется как-то так, не знаю как", а там - готовое, продуманное до мелочей, решение. И вы тут занимаетесь мокрыми фантазиями на тему - а люди использовали это на практике. Использовали, использовали, да и запилили syntax-case, который поддерживают все нормальные реализации схемы. А схемеров (в отличии от тех же общелисперов, кстати) уж никак не заподозрить в стремлении насовать в язык фич просто "чтобы было можно". Что до типизации - тут надо уточнить, какую именно типизацию вы имеете в виду. Если приписывать термам типы оригинального языка - во-первых, это не нужно, вообще, раскрываем мы все макросы в компайл-тайме, по-этому статически чекать их не надо - если установить рантайм контракт на входные/выходное значение, то он будет чекнут во время компиляции, и в том же Typed Racket вы можете, например, импортировать макрос, навесив на него типы - но это не надо никому. Если же вы под типизацией имели в виду синтаксические свойства термов - константы, те или иные выражения и т.п. - это тоже все есть, например, в dylan или в syntax/parse для Racket. Для такого рода типизации есть и работы, описывающие макросы со статической проверкой на базе syntax-rules. И, что самое главное, к вашим фантазиям о модели вычислений это не имеет ровным счетом никакого отношения.
(Reply) (Parent) (Thread)