Изучаю CL и вот наткнулся на них. Понял, что они последовательно по цепочки специфичности вызывают все аналогичные методы, но на кой черт это нужно и где может пригодиться не могу понять. Приведите пример пожалуйста.

«Изменяясь, оно остается неподвижным»

Гераклит.

На протяжении нескольких месяцев уже я пытаюсь понять ФП. И пока у меня 2 варианта. Либо я идиот, либо ФП имеет огромную концептуальную трещину в самом основании.

Древние говорили, что нельзя дважды войти в одну и ту же реку. Это значит, что река - это всегда река. Река постоянно меняется, но она остается все той же рекой, и о ней можно говорить как о реке. Что мы имеем в ФП:

(define river-state 1)
(define fu (let ((the-river-state river-state)) (lambda() the-river-state)))
(write (fu))
(define river-state 2)
(write (fu))
(define river-state 3)
(write (fu))
;111

Дело тут даже не во времени. Мы вообще лишены возможности рассуждать о вещах в общем смысле. ФП снижает абстракцию. Абстргирование стремиться к нулю. Только ради компиляции мы вынуждены мириться с тем, что наш язык не дает нам возможности расуждать о вещах наиболее естественным путем.

PS Как выяснилось, многие не поняли о чем я говорю. Я говорю здесь о фиксации состояния внутри ф-ции. То что код примера императивен я в курсе, это было сделано преднамеренно, для демонстрации идеи. Не надо капитанствовать по этому поводу.

Закралось подозрение, что эти 2 термина, которые, зачастую употребляются как синонимы, означают, все же, разные вещи.

Концепцию code-as-data, может быть, следует понимать, как то, что код является first-class сущностью, его можно брать в качестве аргумента и возвращать в качестве значения. Таким свойством обладает, например Pico-lisp:

(set 'fu (quote(x) (let (local 1) (+ (eval x) (eval x)))))

(fu 'local) # 2

Может быть следовало бы разделить эти понятия, чтобы не плодить коней в вакууме? И вообще, был бы очень благодарен, если бы кто-нибудь дал четкое и прозрачное объяснение сабжевых терминов.

В последнее время играюсь к clojure, на этой волне посмотрел, что такое сабж. Понравилось. Вопрос - что вы думаете об этом ЯП? Какие у него перспективы в плане использования для высокоуровневой разработки компилируемых в нативный код программ? Т.е. производительность, удобство разработки, инфраструктура, количество библиотек, графических тулкитов и т.д.? В какой области у него наибольшие преимущества?

Мужики, поясните за eval-when. В целом, эмпирически, я представляю как работает eval-when в разрезе compile-file, (load .lisp) и (load .fasl), но таблички в HyperSpec-е и CLtL2 вообще никак соотнести со своими представлениями не могу. В частности, не могу понять что из-себя compile-time-too и non-compile-time режимы представляют и когда они наступают. В описании какие-то мутные, если можно так сказать, определения.

Для удобства, приведу таблички здесь: http://www.lispworks.com/documentation/HyperSpec/Body/03_bca.htm

| CT  | LT  | E   | Mode | Action   | New Mode         |
|-----+-----+-----+------+----------+------------------|
| Yes | Yes | -   | -    | Process  | compile-time-too |
| No  | Yes | Yes | CTT  | Process  | compile-time-too |
| No  | Yes | Yes | NCT  | Process  | non-compile-time |
| No  | Yes | No  | -    | Process  | non-compile-time |
| Yes | No  | -   | -    | Evaluate | -                |
| No  | No  | Yes | CTT  | Evaluate | -                |
| No  | No  | Yes | NCT  | Discard  | -                |
| No  | No  | No  | -    | Discard  | -                |

https://www.cs.cmu.edu/Groups/AI/html/cltl/clm/node68.html#SECTION00933000000...

| LT  | CT  | EX  | CTTM | Action                                |
|-----+-----+-----+------+---------------------------------------|
| yes | yes | -   | -    | process body in compile-time-too mode |
| yes | no  | yes | yes  | process body in compile-time-too mode |
| yes | no  | -   | no   | process body in non-compile-time mode |
| yes | no  | no  | -    | process body in non-compile-time mode |
| no  | yes | -   | -    | evaluate body                         |
| no  | no  | yes | yes  | evaluate body                         |
| no  | no  | -   | no   | do nothing                            |
| no  | no  | no  | -    | do nothing                            |

Статью (на русском) Fare про eval-when знаю, но считаю её ещё более запутанной, чем описания в первоисточниках.

P.S. У меня вот такие таблички получились:

| :compile-toplevel | :load-toplevel | compile-file   | load .fasl |
|-------------------+----------------+----------------+------------|
| -                 | -              | -              | -          |
| +                 | -              | eval           | -          |
| -                 | +              | compile        | eval       |
| +                 | +              | eval & compile | eval       |

| :execute | load .lisp     |
|----------+----------------|
| -        | -              |
| +        | eval           |

Собственно меня интересуют батарейки и возможность компиляции в нативный код (последнее в меньшей степени). Как я понял, серьезно следует рассматривать только различные реализации CL и Scheme (Racket).

Если вы предлагаете Clojure, хотелось бы услышать обоснование (кококо-интероперабельность-с-жабой и кококо-ынтырпрайз - не аргументы).

По легенде, Lisp придуман для решения задач искусственного интеллекта. Зачем для этого надо было придумывать такой довольно необычный язык - язык обработки списков? Чем например Fortran не подошёл бы?

Заранее прошу прощения за то, что не в Talks, а сюда. Так получается, что теперь в Talks просто так постить нельзя, нужна некая карма и я должен «страдать» (Почему я не могу писать в раздел Talks? (комментарий)). Я в упор не помню данные своего старого аккаунта. Зарабатывать карму здесь и сейчас у меня нет ни времени, ни возможности, ни необходимости. Почему сюда, а не на другие форумы? Потому что считаю, что здесь обитают люди, которые смогут ответить на вопросы ниже и, возможно, даже, которые застали те самые времена (если конечно те самые люди ещё здесь).

Всем доброго времени суток! Не срача ради, а понимания для. Хочется понять историчность и почему так произошло. Понятно, что сейчас уже стали внедрять функциональные фичи много куда (в те же Java, C++, C# и т.д.). Стало появляться много функциональных языков (в том числе совсем новых). Но почему спустя столько времени? Почему спрашиваю:
- Functional programming has its origins in lambda calculus, a formal system developed in the 1930s (!!!) to investigate computability, the Entscheidungsproblem, function definition, function application, and recursion. Many functional programming languages can be viewed as elaborations on the lambda calculus (отсюда: https://en.m.wikipedia.org/wiki/Functional_programming);
- Lisp появился ажно в 1958 году;
- после лиспа ещё была целая куча функциональных языков (APL, IPL, ML, Miranda, Erlang, etc.);
- C++ в 1985;
- Haskell в 1990;
- Java в 1995;

Сама идея ООП (и то я так понял весьма размытая, каждый понимал (и, кстати, по-моему до сих пор понимает) по-своему) вроде как витала со времени создания самого лиспа, но до конкретных реализаций она добралась ближе к концу 80-х - начала 90-х годов.
(поправьте меня, если не прав)
И это ещё при всём при том, что ФП имеет под собой весьма конкретный математический базис (чего я, пожалуй, не могу сказать про ООП).
Я так понял, что благодаря таким крупным компаниям как Microsoft, Oracle...
Но почему они так сильно повлияли на развитие этих технологий и как именно они это сделали я, честно говоря, не совсем понимаю.
Ок, ладно, тогда железо было не такое как сейчас, памяти было маловато для нормального существования функциональных языков на x86 платформе.
Но ведь была же та же, например, Symbolics, которая вроде бы весьма активно продавала лисп-машины?
Ок, Symbolics развалилась благодаря неблагоприятному стечению обстоятельств и «эффективным» манагерам, но их наработки оказались никому не нужны что ли?
И опять-таки, когда нужное железо появилось почему выбор этих и других крупных компаний пал именно на эти языки?
Почему не на функциональные языки?
Потому что в то время функциональные языки в основном использовались сугубо в академической среде или как?
Или если перефразировать всё вышесказанное словами моего коллеги: «если всё так круто (про ФП), то почему оно ещё не захватило рынок?»

Ни для кого не секрет, что многие ЛОРовцы любят поговорить об этом замечательном языке, аргументированно обсудить сильные и слабые его стороны, то, какую роль он сыграл в успехах некоторых компаний, как именно обеспечил их конкурентное преимущество.

Когда-то я участвовал в переводе замечательной книги «Practical Common Lisp», в частности главы «Макросы: Создание собственных макросов». И вот сейчас вот осознал, что она содержит одну из лучших историй успеха Lisp из виденных мною, тем более успех сей был обеспечен самой важной, как знает каждый завсегдатай ЛОР, возможностью языка: макросами. Надеюсь она направит юных программистов на правильный путь и вдохновит их на свершения, а сомневающиеся смогут отбросить последние сомнения!

А вот и непосредственно сама история:

~~~~~

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

В отчаянии большой босс нанял младшего (junior) программиста, Мака, чьей работой стал поиск комментариев, написание требуемого кода и вставка его в программу на место комментариев. Мак никогда не запускал программы, ведь они не были завершены и поэтому он попросту не мог этого сделать. Но даже если бы они были завершены, Мак не знал, какие данные необходимо подать на их вход. Поэтому он просто писал свой код, основываясь на содержимом комментариев, и посылал его назад создавшему комментарий программисту.

С помощью Мака все программы вскоре были доделаны, и компания заработала уйму денег продавая их: так много денег, что смогла удвоить количество программистов. Но по какой-то причине никто не думал нанимать кого-то в помощь Маку; вскоре он один помогал нескольким дюжинам программистов. Чтобы не тратить все свое время на поиск комментариев в исходном коде, Мак внес небольшие изменения в используемый программистами компилятор. Теперь, если компилятор встречал комментарий, то отсылал его электронной почтой Маку, а затем ждал ответа с замещающим комментарий кодом. К сожалению, даже с этими изменениями Маку было тяжело удовлетворять запросам программистов. Он работал так тщательно, как только мог, но иногда, особенно когда записи не были ясны, он допускал ошибки.

Однако программисты обнаружили, что чем точнее они пишут свои комментарии, тем больше вероятность того, что Мак вернет правильный код. Однажды один из программистов, встретив затруднение с описанием в словах нужного кода, включил в один из комментариев программу на Lisp, которая генерировала нужный код. Такой комментарий был удобен Маку: он просто запустил программу и послал результат компилятору.

Следующее новшество появилось, когда программист вставил в самый верх одной из своих программ комментарий, содержащий определение функции и пояснение, гласившее: «Мак, не пиши здесь никакого кода, но сохрани эту функцию на будущее; я собираюсь использовать ее в некоторых своих комментариях.» Другие комментарии в этой программе гласили следующее: «Мак, замени этот комментарий на результат выполнения той функции с символами x и y как аргументами.»

Этот метод распространился так быстро, что в течение нескольких дней большинство программ стало содержать дюжины комментариев с описанием функций, которые использовались только кодом в других комментариях. Чтобы облегчить Маку различение комментариев, содержащих только определения и не требующих немедленного ответа, программисты отмечали их стандартным предисловием: «Definition for Mac, Read Only» (Определение для Мака, только для чтения). Это (как мы помним, программисты были очень ленивы) быстро сократилось до «DEF. MAC. R/O», а потом до «DEFMACRO».

Очень скоро в комментариях для Мака вообще не осталось английского. Целыми днями он читал и отвечал на электронные письма от компилятора, содержащие DEFMACRO комментарии и вызывал функции, описанные в DEFMACRO. Так как Lisp программы в комментариях осуществляли всю реальную работу, то работа с электронными письмами перестала быть проблемой. У Мака внезапно стало много свободного времени, и он сидел в своем кабинете и грезил о белых песчаных пляжах, чистой голубой океанской воде и напитках с маленькими бумажными зонтиками.

Несколько месяцев спустя программисты осознали что Мака уже довольно давно никто не видел. Придя в его кабинет, они обнаружили, что все покрыто тонким слоем пыли, стол усыпан брошюрами о различных тропических местах, а компьютер выключен. Но компилятор продолжал работать! Как ему это удавалось? Выяснилось, что Мак сделал заключительное изменение в компиляторе: вместо отправки электронного письма с комментарием Маку компилятор теперь сохранял функции, описанные с помощью DEFMACRO комментариев, и запускал при вызове их из других комментариев. Программисты решили, что нет оснований говорить большим боссам, что Мак больше не приходит на работу. Так происходит и по сей день: Мак получает зарплату и время от времени шлет программистам открытки то из одной тропической страны, то из другой.

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

Ну вот допустим будет некий язык с Си-подобным синтаксисом, пусть там пользователь вводит массив чисел с клавиатуры, ну как-то так

  uint32_t a[100];

  for (size_t i = 0; i < 100; i++)
  {
    if ( scanf("%" SCNu32 "\n", &a[i]) != 1)
    {
      exit(-1);
    }
  }

Вот после этого for цикла (если не произошло exit (-1)) в массиве a[100] образовались какие-то там данные, нам про них ничего в точности неизвестно, там пользователь что попало мог ввести.

Скажем, если мы после этого сделаем такое:

  for (size_t i = 0; i < 100; i++)
  {
    printf("%" PRIu32 "\n", 100500 / a[i]);
  }

А если например перед этим сделать нечто такое

  for (size_t i = 0; i < 100; i++)
  {
    if(a[i] == 0)
    {
      a[i] = 1;
    }
  }

Надо значит цеплять какие-то условия к данным (массивам, переменным) т.е. отслеживать их историю эволюции, выводить на основе этого некие свойства.

Ну и это еще можно использовать для оптимизации, скажем если мы отсортировали некий массив, то потом если мы пытаемся его отсортировать второй раз подряд, то во-первых можно вывести предупреждение от компилятора «этот массив и так сортирован, нечего его сортировать» а во-вторых можно просто вызов сортировки выкинуть т.к. он ничего не делает. Ну и кроме того, есть алгоритмы которым обязательно сортированные данные нужны, например это алгоритм двоичного поиска. Можно на каком-то языке описать, что алгоритм двоичного поиска, если ему на вход подать сортированный массив, он там сможет найти некий элемент если он там точно есть и не найти если его нет. А если ему несортированный массив подать (т.е. для которого нет свойства что a[n] <= a[n+1] для всех n от 0 до размермассива) то тогда это уже неверно, т.е. должна быть ошибка компиляции, если мы не проверенные на сортированность данные пускаем на вход к двоичному поиску

Вообще, есть такой GNU экстеншен __builtin_unreachable() и им можно например такую ерунду вытворять https://godbolt.org/z/dN6ozS

#define ALWAYS_FALSE(a) if(a) __builtin_unreachable()
#define ALWAYS_TRUE(a) ALWAYS_FALSE(!(a))

unsigned div_eq(unsigned a, unsigned b)
{
  ALWAYS_TRUE(a == b);
  ALWAYS_TRUE(a != 0);
  return a/b;
}

unsigned div(unsigned a, unsigned b)
{
  return a/b;
}

Ну и тут вариант div_eq оптимизируется до return 1; (шланг неосиливает) - но это все костыли. И язык аннотаций из Frama-C это тоже костыли - из них такую оптимзацию не сделать, это внешний костыль для проверки контрактов.

Почему нет нормального компилируемого в натив языка без жирного рантайма с GC, чтоб там можно было вот так специфицировать поведение функций, допустимые входные параметры, кванторы-шманторы там, чтоб это все проверялось и оптимизировалось на основе спецификации-контрактов? И чтоб с суперкомпиляцией!

Я занимаюсь разработкой нового диалекта Lisp, параллельно в вузе читаю спецкурс по семантике языков программирования. По ссылке можно прочитать о некоторых моих идеях:

https://drive.google.com/file/d/0B13ti3tFkQZlSkFPV3NuMHR4eGc/view?usp=sharing

Пока исходников нет в общем доступе, т.к. я активно работаю над ними и мне тяжело будет поддерживать к ним доступ в инете. Ищу соавтора для допиливания реализации и/или написания книги по семантике Лиспа. Желательно из Санкт-Петербурга. Обращайтесь вконтакте: http://vk.com/maliculo

Еще хочу прорекламировать свою публичную лекцию в cs club по Лиспу: http://compsciclub.ru/node/2767

Сегодня вышла новая версия одной из самых популярных и развивающихся реализаций языка Smalltalk — Pharo.

( читать дальше... )

>>> Официальный анонс

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

У этого подхода есть свои плюсы, которые позволяют строить на основе лексической области видимости интересные вещи.

Не знаю, как в Clojure, но вроде они пошли по пути Scheme в этом плане.

Но вот есть некоторые сторонники Common Lisp, которые утверждают, что это все таки зло и котлеты отдельно, мухи отдельно.

Был бы рад подробной аргументации этого подхода, желательно в сравнении с подходом с общим пространством имен.

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

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

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

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

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

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

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

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

Не совсем portable, но заметно расширяет возможности для SBCL и CCL и приводит их к общему знаменателю. Для остальных реализаций возможно не более одного «совета» на функцию и реализация не завязана на родные возможности реализаций, а просто перешибает defun.

https://bitbucket.org/budden/cl-advice

В CCL не просто можно вызвать предыдущую функцию (с помощью (:do-it)), но и подменить ей аргументы.

В SBCL можно найти определения самой функции и её «советов» с помощью SWANK.

Говоря холиварно, это позор, что в EMACS и в питоне декораторы есть, а в CL - нет. Уж лет 20, как пора было это исправить и вот я сделал к этому шаг наконец-то.

На самом деле код ещё довольно сырой - для CCL я написал его сегодня и не факт, что завтра что-то не всплывёт. Для SBCL уже несколько месяцев пользуюсь - вроде всё нормально.

В целом, мне нравится lisp - импонирует сама концепция lisp-a, я без особых проблем читаю s-выражения, нравиться его поддержка в emacs. И я использую emacs lisp как язык для всякой мелочевки.
С другой стороны простота концепции, когда первый аргумент s-выражения - функция, а остальные єлементы - параметры, имеет свой неприятный побочный эффект: огромное, неструктурированное пространство имен. Примерно за это я не люблю python - надо помнить кучу тонких особенностей и фич языка. А в lisp надо помнить кучу нужных функций. В книжке Грема их приблизительно 1000. В противопложность java - минимум ключевых слов, а вся функциональность вынесена в методы, которые выясняются по автодополнению и доктипу.
Второй нюанс, ХЗ, может зависит от конкретной реализации. Все функции из заргуженных пакетов валятся в одно пространство имен. Т.е. если Васян по глупости или злому умыслу перепишет стандартный car можно поиметь проблем, особенно если такой car подгружаю в составе какой-то библиотеки. Хотелось бы импорта a-la python import my-package as mp с последующим доступом типа (mp.foo).
Собственно, вопрос. Как борются с этими проблемами местные лисперы. Особенно с первой. Лично я запомнил около полусотни функций, примерно из списка снипеттов, к части прибавляю p и автоматом получаю знание новых. Может есть компактный список must know функций как перечень самых популярных коменд для emacs?
Вторая проблема больше для собственного кругозора, я сомневаюсь, что буду в большой команде использовать lisp, та и не годиться он для этого.

С пакетами вопрос решился. А с насышенным и неструктурированным пространством имен или с кратким справочником на манер такого - нет.

Прошу помощи емаксеров.

Сейчас размер шрифта задается в конфигурационном файле так:

(set-face-attribute 'default nil
                     :font "IBM Plex Mono"
                     :height 120
                     :width 'normal)

(set-face-attribute 'mode-line nil :height 110)	

(setq text-scale-mode-step 1.05)

При работе на мониторе с другим DPI можно быстро отрегулировать размер шрифта через C-x +/-. Но размер шрифта mode-line меняю через eval-buffer.

Как поменять размер шрифта в меню команд (под mode-line) я вообще не знаю.

Хотелось бы написать функцию, которая по C-x +/- будет масштабировать все три элемента с небольшим шагом. Либо, что еще лучше, будет работать так: M-x scale-interface 1.8.

P.S. Я не настоящий емаксер, так что разжуйте поподробнее, пожалуйста.

По следующей ссылке приведен список рекомендуемых библиотек и фреймворков в Common Lisp для различных применений:

http://eudoxia.me/article/common-lisp-sotu-2015/

"(к примеру, язык Lisp известен тем, что интерпретатор Лиспа, написанный на Лиспе, занимает 15 строк)" - из опуса о эзотерических языках:

http://www.rsdn.ru/article/philosophy/languages.xml

Где-нибудь можно посмотреть на эти 15 строк?