Действительно ли ECMAScript диалект Lisp?

Ответ 1

Брендан Эйх хотел сделать язык, подобный схеме, для Netscape, но реальность вмешалась, и ему пришлось заняться чем-то, что выглядело смутно как C и Java для "нормальных" людей, но работало как функциональный язык.

Лично я считаю ненужным растягивать вызов ECMAScript "Lisp", но каждому свой. Ключевая вещь о реальном Lisp кажется характеристикой того, что обозначение структуры данных и нотация кода одинаковы, и это неверно в отношении ECMAScript (или Ruby или Python или любого другого динамического функционального языка, а не Lisp).

Предостережение: у меня нет учетных данных Lisp: -)

Ответ 2

Это не так. Он получил множество функциональных корней, но в настоящее время, как вы указали, так много других языков не lisp.

Lisps имеют одну оставшуюся характеристику, которая делает их lisps, что означает, что код lisp написан в терминах структур данных lisp (гомоконичность). Это то, что позволяет использовать мощную макросистему lisps и почему она выглядит так, как будто она не используется для чтения. Вызов функции - это просто список, в котором первым элементом в списке является имя функции.

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

Ответ 3

Даже если бы я не назвал JavaScript Lisp, он, по моему скромному мнению, больше похож на способ Lisp делать что-то, чем большинство основных языков (даже функциональных).

Для одного, точно так же, как Lisp, это, по сути, простой, императивный язык, основанный на нетипизированном лямбда-исчислении, который подгоняется REPL.

Во-вторых, легко вставлять литеральные данные (включая код в форме лямбда-выражений) в JavaScript, поскольку его подмножество эквивалентно JSON. Это общий шаблон Lisp.

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

На самом деле, есть несколько (более или менее) последних событий в мире JavaScript, которые заставляют язык чувствовать себя довольно lispy время от времени. Возьмите jQuery, например. На мой взгляд, вложение CSS-селекторов в подъязык - это симпатичный подход Lisp. Или рассмотрите протокол метаобъекта ECMAScript Harmony: он действительно выглядит как прямой порт Common Lisp (гораздо больше, чем системы метаобъектов Python или Ruby!). Список продолжается.

В JavaScript не хватает макросов и разумной реализации REPL с интеграцией редактора, что является неудачным. Разумеется, влияние других языков также очень заметно (и не обязательно плохо). Тем не менее, существует значительная культурная совместимость между лагерями Lisp и JavaScript. Некоторые из них могут быть случайными (например, недавнее появление JIT-компиляции JavaScript), некоторые систематические, но это определенно есть.

Ответ 4

Нет, нет.

Для того, чтобы считаться a Lisp, нужно быть гомоиконическим, что ECMAscript не является.

Ответ 5

Я думаю, что ECMAScript является диалектом LISP в том же смысле, что английский - это диалект французского языка. Есть общие черты, но у вас будут проблемы с присвоениями в одном вооружении только с учетом другого:)

Мне интересно, что только один из трех основных презентаций, выделенных для 4-го европейского симпозиума LISP, напрямую касается LISP (остальные два относятся к x86/JVM/Python и Scala).

Ответ 6

"диалект" определенно растягивает его слишком далеко. Тем не менее, как и тот, кто изучил и использовал Python, Javascript и Scheme, Javascript явно обладает гораздо более ощутимым (и Coffeescript, возможно, даже более), чем Python.

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

Ответ 7

Не диалект. Я узнал LISP в 70 году и не использовал его с тех пор, но когда я недавно узнал об JavaScript, я обнаружил, что он был LISP -like. Я думаю, что из-за 2-х факторов: (1) JSON - это список-подобная ассоциативная структура, и (2) кажется, что объекты JS являются, по существу, JSON. Поэтому, даже если вы не пишете JS-программы в JSON, так как вы пишете LISP в списках, вы почти ничего не делаете.

Таким образом, мой ответ заключается в том, что есть достаточное сходство, которое программистам, знакомым с LISP, напомнят об этом, когда они используют JavaScript. Такие выражения, как JS = LISP в Java-костюме, только выражают это чувство. Я верю, что все есть.

Ответ 8

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

Lisp должен правильно ссылаться на язык с определенными атрибутами.

Язык Lisp, если:

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

• Древовидные данные являются основной структурой данных в самом языке, что делает программы восприимчивыми к манипуляциям с программами.

• Язык имеет тип данных символа. Символы имеют напечатанное представление интернированное: когда в нотации появляются два или более экземпляра одной и той же печатной нотации для символа, все они обозначают один и тот же объект.

  • Основной принцип достоинства символьного объекта заключается в том, что он отличается от всех других символов. Символы сопряжены с различными другими объектами по-разному в семантике программ Lisp и тем самым служат в качестве имен для этих объектов.
  • Например, диалект Lisp обычно имеет переменные, как и другие языки. В Lisp переменные обозначаются символами (объектами в памяти), а не текстовыми именами. Когда часть программы Lisp определяет некоторую переменную a, синтаксис для этого a является символьным объектом, а не символьной строкой "a", которая является именно этим именем символа для целей печати. Ссылка на переменную, выражение, написанное как a в другом месте программы, также является объектом on. Из-за того, как работают символы, это один и тот же объект; этот объект идентичности затем связывает ссылку с определением. Идентичность объекта может быть реализована как равенство указателя на уровне машины. Мы знаем, что два символьных значения одинаковы, поскольку они являются указателями на одно и то же место памяти в куче (объект типа символа).
  • Дело в том, что диалект NewLisp с нетрадиционным управлением памятью для большинства типов данных, включая вложенные списки, делает исключение для символы, заставляя их вести себя выше. Без этого не будет Lisp. Цитата: "Объекты newLISP ( исключая символы и контексты) передаются путем копирования значений другим пользовательским функциям. В результате каждый объект newLISP требует только одной ссылки". [акцент мой]. Передача символов также, как по копированию значения, приведет к уничтожению их идентичности: функция, получающая символ, не будет получать исходную и, следовательно, неправильно получает ее идентификатор.
• Составные выражения в языке Lisp - те, которые не являются простыми праймериями, такими как числа или строки;— состоят из простого списка, первый элемент которого является символом, обозначающим операцию. Остальные элементы, если они есть, являются выражениями аргументов. Диалог Lisp применяет какую-то стратегию оценки, чтобы уменьшить выражение до значения и вызвать любые побочные эффекты, которые могут иметь.
• Я бы предположил , что списки, состоящие из двоичных ячеек, содержащих пары значений, заканчивающиеся специальным пустым объектом списка, вероятно, должны рассматриваться как часть определения Lisp: целое бизнес, способный сделать новый список из существующего, "заимствуя" новый элемент на фронте и легкую рекурсию в "первом" и "остальном" списка и т.д.

И тогда я бы остановился прямо здесь. Некоторые люди считают, что системы Lisp должны быть интерактивными: обеспечить среду слушателем, в которой все изменено и может быть переопределено в любое время и так далее. Некоторые считают, что Lisps должны иметь первоклассные функции: должен быть оператор lambda и т.д. Стареющие традиционалисты могут даже настаивать на том, что должны быть функции car и cdr, точечная двоичная нотация, поддерживающая неправильные списки, и что списки должны состоять из ячеек и заканчиваться конкретным символом nil, обозначающим пустое список, а также логическое значение false. Настаивание на car и cdr позволяет Scheme быть Lisp, но nil является терминатором списка и ложными правилами

Чем больше мы переходим к определению диалекта "Lisp", тем больше он становится политическим; люди расстраиваются из-за того, что их любимый диалект (возможно, который они создали сами) исключается по некоторым техническим причинам. Настаивание на car и cdr позволяет Scheme быть Lisp, но nil является терминатором списка и ложными правилами. Что, схема не Lisp?

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

Ответ 9

Да, это так. Цитата Крокфорда:

"JavaScript имеет много общего с Scheme: динамический язык, он имеет гибкий тип данных (массивы), который может легко имитировать s-выражения. И самое главное, функции - лямбды.

Из-за этого глубокого сходства все функции в [рекурсивном программном праймере] "The Little Schemer" могут быть написаны на JavaScript ".
http://www.crockford.com/javascript/little.html

Что касается гомоконичности, я бы рекомендовал искать это слово вместе с JavaScript. Говорить, что это "не гомоиконический", это правда, но не конец истории.