Лисперы, приведите пример превосходства Лиспа

(< 0 x 1)

P.S. Да даже на плюсах это красивее можно сделать:

for(auto& i: l) i*=2;

Да даже на плюсах

А мультиметоды в плюсах есть? Нет - проходите мимо.

средствами самого лиспа

4.2 же, нестандартными средствами одной из его реализаций, в чем как раз и беда лиспа - множество слабосовместимых и переносимых реализаций

А мультиметоды в плюсах есть?

множественная диспетчеризация - удел ЯП с жирным рантаймом, коим плюсы не являются

имеется ввиду конечно наличие данной функциональности в самом ЯП, а не самостоятельная реализация поверх него

и оба хаскеллисты, как назло.

Шо, опять?!

множественная диспетчеризация - удел ЯП с жирным рантаймом

Возьмешься доказать не статистическим методом?

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

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

Озвучь тогда уж определение

сам найди

после сикп не нужно искать причины любви

любви

But what can you do with it?
                — ubiquitous cry from Linux-user partner

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

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

после сикп не нужно искать причины любви

Я, когда читал SICP, после каждой их программы представлял, с каким шумом ЭТО навернётся на неверных входных данных.

Я, когда читал SICP, после каждой их программы представлял, с каким шумом ЭТО навернётся на неверных входных данных.

Когда наворачивается лисповая система в одном французском банке, она шлёт мыло единственному её девелоперу со всей нужной информацией внутри. Он фиксит проблему, шлёт ответ с fasl'ом, система применяет изменения и фурычет дальше.

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

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

Как-как ты авторов SICP-а обозвал?

Как-как ты авторов SICP-а обозвал?

Авторы SICP концепции программирования раскрывают, а не валидирующие парсеры входных данных на каждый пример клепают.

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

Авторы SICP концепции программирования раскрывают, а не валидирующие парсеры входных данных на каждый пример клепают.

Тогда к чему ты вообще об этом вспомнил?

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

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

сам найди

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

\> Вопрос в том, падает ли программа по-тихому в момент ввода, или с шумом и грохотом посреди вычисления, когда уже фиг дознаешься, где и кто наглючил.

Кто-то собрался складывать котов с гвоздями? В любом случае, внешние цифробуковки придется проверять на корректность *формата* и полноту данных... или (молиться и) надеяться на лучшее %) Как здесь поможет статическая типизация?

Тогда к чему ты вообще об этом вспомнил?

Я? Это ты SICP к дуракоустойчивости программ попытался привязать.

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

У лисперов ничего не падает. Как там у хаскеллотеоретиков - не знаю...

Имхо, ненужно

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

Как сейчас с Лиспом дела обстоят, жив? Какая самая развивающаяся реализация на данный момент?

Как здесь поможет статическая типизация?

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

Это ты SICP к дуракоустойчивости программ попытался привязать.

Я поделился своим впечатлением от этой книги. На мой взгляд, программы, приведённые в ней, являются катастрофически хрупкими. Настолько, что это уже невозможно списать на «учебность» примера. Это уже порочная практика.

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

Когда наворачивается лисповая система в одном французском банке

Взаимоисключающие параграфы, однако.

Как сейчас с Лиспом дела обстоят, жив?

Нет, но лисперы не считают это существенным недостатком.

Взаимоисключающие параграфы, однако.

Там применяется рантаймная кодогенерация, управляемая юзером, поэтому ошибки возникают. Впрочем, хаос получился managed.

Какая богатая фантазия. То, что я называл list comprehensions сахаром, не значит, что я ими недоволен.

банальный паттерн-матчинг

за этой «банальностью» скрывается необходимость хранить дополнительные данные, разбирать иерархию типов для параметров и собс-но искать нужный метод при каждом вызове

http://en.wikipedia.org/wiki/Multiple_dispatch

вдруг не найдешь

вдруг не найдешь

Про «жирный рантайм заданный в определении множественной диспетчеризации» показывай давай

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

Шо, опять?!

Эта музыка будет вечной.

double = +:

double =: *&2

после сикп не нужно искать причины любви

Ваа, какая лор-хайку...

чтобы банальный паттерн-матчинг под него не подходил.

Паттерн-матчинг диспетчеризирует по конструкторам одного типа. Мультидиспатч - по разным типам, аналогом мультиметодов в статике будут классы типов хаскеля, implicits скалы и instance arguments агды.

Паттерн-матчинг диспетчеризирует по конструкторам одного типа.

Мдя?

abstract class List
case class Nil extends List
case class Cons(head : Int, tail : List) extends List
def scalarProduct(xs : List, ys : List) {
  xs match {
    case Nil => 0
    case Cons(x,xt) =>
      ys match {
        case Nil => 0
        case Cons(y,yt) => x*y + scalarProduct(xt,yt)
      }
  }
}

http://lisp-univ-etc.blogspot.com/2010/07/common-lisp.html

Какие kindы у List, Nil и Cons? List : Type, Nil : List и Cons : List? Тогда ЧТД.

Мультиметоды можно считать формой паттерн-матчинга, но не на термах, а на типах. И это не вполне паттерн-матчинг так как он не задаётся одной специальной формой (match / case), а задаётся независимыми определениями в разных пакетах, модулях, исходных файлах, библиотеках.

Даже если List : Type, Nil : Type и Cons : Type, то всё равно проблема в том, что scalarProduct, выраженный через match, задаётся единожды, тогда как смысл методов и мультиметодов именно в том, что реализации интерфейсов могут добавляться постепенно, без изменения уже написанного кода.

Например, методы CL:

(defgeneric interface-method (object))

;; реализация в другом месте:

(defmethod interface-method ((object some-class))
  ;; implementation
)

;; вообще в другой библиотеке:

(defmethod interface-method ((object another-class))
  ;; implementation
)

аналогично, классы типов хаскеля:

class Interface t where
  interfaceMethod :: {- specification -}

-- далее, в том же модуле, реализация:

instance Interface SomeType where
  interfaceMethod = {- implementation -}

-- вообще в другом модуле (orphan instance):

instance Interface AnotherType where
  interfaceMethod = {- implementation -}

Implicits скалы:

trait Interface [T] {
  def interfaceMethod /* domens */ : /* codomen */
}

def interfaceMethod /* domens */ (implicit interface : Interface [T]) =
  interface.interfaceMethod /* arguments */

// и далее, реализации, по мере надобности:

implicit object someTypeInterface extends Interface [SomeType] {
  def interfaceMethod /* domens */ : /*codomen */ = /* implementation */ 
}

implicit object anotherTypeInterface extends Interface [AnotherType] {
  def interfaceMethod /* domens */ : /*codomen */ = /* implementation */ 
}

Instance arguments агды:

record Interface (a : Set) : Set where
  constructor interface
  field interface-method : {- specification -}

interface-method : {T : Set} → ⦃ _ : Interface T ⦄ → {- specification -}
interface-method ⦃ instance ⦄ = Interface.interface-method instance

-- в том же модуле:

instance-for-some-type : Interface SomeType
instance-for-some-type = interface {- implementation -}

-- в другом модуле:

opem import InterfaceModule

instance-for-another-type : Interface AnotherType
instance-for-another-type = interface {- implementation -}

вот paper на эту тему.

Мультиметоды можно считать формой паттерн-матчинга, но не на термах, а на типах.

Короче, «банальный паттерн-матчинг» это выбор в рамках одного типа, который финитен, в смысле конечного количества конструкторов, и поэтому для паттерн-матчинга можно гарантировать покрытие всех clauses и компилировать его в switch/if/let подобные конструкции c использованием примитивных аккессоров. Что-то вроде instance arguments, с другой стороны, работает в универсуме (*, Type, Set), гарантировать покрытие тоже можно, но только для раннего связывания, не для позднего. В агде интересно то, что instance arguments могут работать не только в Set, но и в Set₁, Set₂, ... (и вообще в (i : Level) (Set i)).

Какие kindы у List, Nil и Cons?

У всех трёх - Type. Это типы.

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

Мы всё ещё не слышали определение.

Что касается конечного автомата в несколько команд, то, представляю, на Lua, например, это тоже не так много заняло бы (Python, к сожалению, не знаю). Я бы даже сам написал, если бы точно понял, о каком автомате идет речь (я примерно представляю себе, что такое в лиспе CAR, CDDR и проч., но сомнениями отягощен разум мой).

Что касается второго примера с базой данных, то тут как раз использование Prolog не впечатляет. Вот какой возникает вопрос: не проще ли было бы держать БД (пусть даже и в памяти) отдельно, а логику отдельно? А если проще, то нужен ли здесь именно Лисп?

Что до третьего примера, то он конечно, впечатляет, но ведь организовать распределенную БД можно и другими способами...

У всех трёх - Type. Это типы.

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

Мы всё ещё не слышали определение.

Мультиметодов? Это как методы, только мульти :) Не вижу проблем в том чтобы иметь мультиметоды в языке с нежирным рантаймом, но только если остановится на раннем связывании (просто инстанцировать нужны спецификации методов во время компиляции), в CL обычно используется рантайм-машинерия с хэш-табличками для мультиметодов, которые, by design, работают с поздним связыванием.

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

если я правильно понял - это перегрузка методов, а не мультиметоды

если я правильно понял - это перегрузка методов, а не мультиметоды

В случае раннего связывания для метода c n аргументами и для m типов нужно произвести, в худшем случае, mⁿ специализаций (подстановок конкретных методов). Нулевой оверхед с точки зрения времени, памяти и кода.

Касательного позднего связывания - вот тут пришли к выводу, что

Indeed, it is almost as efficient as single dispatch. Because the dispatch is constant time and does not rely on exceptions to signal ambiguities, it is applicable in embedded and hard real-time systems.

У вас 3 символа :) Хотя, конечно, правильно.

ага - значит неправильно понял, спасибо за ссылку, в принципе, что было очевидно, - будут om-tables и dispatch-tables, правда с читерством в том плане, что компилятор и линковщик будут тебя бить по рукам, чтоб ты им все показал, и в том, что работа с библиотеками будет происходить хз каким способом