Выход mocl

Для этого не нужна статическая типизация. Анализируется внешним чекером, в рантайме перед jit-ированием.

У тебя jit будет реализацию выбирать если она принципиально другой либой делается?

Ты погрешность от php не учёл.

Тем не менее. Там в десятке 4 близких группы. Раньше перл был во второй. Сейчас в четвертой. Он не треть секунды проиграл на финише лидеру в десятикилометровой гонке, он как раз спустился и з проигрыша в «треть секунды» в «приползший за восьмикратное время».

Что-то я потерял твою мысль.

Что базовый лисп - это такой примитивный ассемблер. И от того что там можно намакросить DSL проистекает что его надо макросить очень сильно а иначе юзабельность неахти. Берем сабжевый код:

(declaim (call-in draw-contact-item))
(defun draw-contact-item ()
  (let* ((height 640)
(file (merge-pathnames *temp-dir* "contact@2x.png")))
    (with-canvas (:width *width* :height height :close-font-loaders nil)
      (set-font *font* 40)
      (set-fill-color *white*)
      (clear-canvas)
      (set-stroke-color *light-gray*)
      (set-line-width 2)
      (rounded-rectangle (box 25 (- height 525) (- *width* 25) (- height 25)) 10 10)
      (stroke)
      (set-fill-color *dark-gray*)
      (vecto:draw-string-fast 50 (- height 80) (contact-name *current-contact*))
      (set-fill-color *blue*)
      (vecto:draw-string-fast 50 (- height 140) (contact-mobile *current-contact*))
      (vecto:draw-string-fast 50 (- height 200) (contact-email *current-contact*))
      (save-png file))
    (namestring file)))

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

Если не противоречит, то почему ты не можешь сложить объекты одного типа?

Почему нет? Сложишь в коде что угодно с чем угодно этого самого «одного типа», закинешь в образ, запустишь, словишь исключение, которое тоже значение этого же единственного типа (который в CL называется T и реализуется как тегированный указатель lispobj у SBCL — эти lispobj обычно и летают у него между функциями).

А вообще man Дана Скотт и теория доменов.

scalamacros.org

Давай на примерах проверим скаламакросы. Напиши, пожалуйста, деструктуризацию хеш-таблицы, аля в Clojure или в CoffeeScript. Начнём с простой деструктуризации.

(dict-bind (a b c) (plist-hash-table '(:a 1 :b 2 :c 3))
  (list a b c)) ; * (1 2 3)

Убери из лиспа скобки

Добавь типизацию, вывод типов и прочее и прочее...

В случае xml не совсем удачные.

xml вот имено такой баланс между автообработкой и читаемосью человеками. Нужен чтобы тулы работать умели а человеки читали если нужно. Вот лисп структурно - там же.

При постоянно меняющихся требованиях, а с ними и архитектуре - приложение всегда остается «прототипом».

Єто не отменяет факта что ему надо быть рабочим прототипом.

Исключать довольно-таки примитивный класс ошибок (практически все подобные ошибки будут и так выявлены на начальных стадиях разработки, особенно если имеется

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

Нового в крестах 0.

А с каких это пор фраза «статическая типизация развивается» стала обозначать кресты?

Короче, это все бессмысленный спор «статика vs динамика», свое мнение я озвучил, а на счет скаломакросов то это даже не смешно.

А с каких это пор фраза «статическая типизация развивается» стала обозначать кресты?

Я говорил про мейнстрим. Если говорить о развитии статической типизации в целом, то конечно развитие есть. И развивать направление определённо полезно. Нынче говорят о dependency types и о таких вещах, как Haskell, Agda, ATS, OCaml GADT. Но не о Scala уж точно :) Scala вообще не учитывает весьма богатый опыт ФЯП'ов и ничего не развивает. Ну да и на сегодняшний момент успехов в этом плане маловато. Всё что есть очень уж кроваво и не практично.

почему ты не можешь сложить объекты одного типа?

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

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

Для этого нужна не статическая типизация, а внешний статический чекер

Между статической типизацией и статическим чекером нет никакой практической разницы.

Операции на них определены таким образом. Кто вообще сказал, что объекты одного типа обязательно должны складываться?

Сложить это условно. Произвести операцию определенную для этого типа и определенного же количества операндов.

Между статической типизацией и статическим чекером нет никакой практической разницы.

Есть - чекер можно выбросить, написать новый, вообще не использовать, допилить под свои нужды. Варнинги чекера - не ошибки. Нет борьбизма со статической системой. Нет самой жестко зашитой статической системы. Можно чекать выборочно что-то. Короче, преимуществ много.

Даже какую-то глупую отмазку придумали, что мол, если нужны вам макросы, то вы что-то делаете не так. Право смешно читать их :)

А можно линк?

Линка нет. По-моему такое мнение распространено среди хаскелистов. Завидуют :)

Короче, нужна такая статическая типизация, которая позволяет запускаться с «ошибками», с настраиаемым уровнем ошибочности классов ошибки.

Произвести операцию определенную для этого типа и определенного же количества операндов.

Операция имеет полное право зафейлиться при ненадлежащих входных данных.

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

Для этого нужна не статическая типизация, а внешний статический чекер

Между статической типизацией и статическим чекером нет никакой практической разницы.

Есть - чекер можно выбросить, написать новый, вообще не использовать

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

Варнинги чекера - не ошибки.

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

Ты дебил. Во всех перечисленных языках макросистемы аналогичны по возможностям говнолиспу.

В скале для такого макры не нужны. Можно конечно выпендриться - но декларировать идентификаторы символами в скале - это мрак как мрачно будет. Скльное решение для такого что-то вроде:

object MapBind {
  def unapplySeq[A, B](t: (Map[A, B], List[A])): Option[List[B]] =
    Some(t._2.map(k => t._1.getOrElse(k, null.asInstanceOf[B])))


  def main(args: Array[String]) {
    val map: Map[Symbol, Int] = Map('a -> 1, 'b -> 2, 'c -> 3)
    val MapBind(a, c) = (map, 'a :: 'c :: Nil)
    println(a :: c :: Nil)
  }
}

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

а на счет скаломакросов то это даже не смешно.

И что именно тебе не смешно?

Хотите честно? Так вот: в чём смысл CAS?

А по сабжу: CL крут, да, а вот что такое iOS и вендроид я не знаю

http://stackoverflow.com/questions/7432146/what-is-scalas-powerful-type-syste...

Так вот: в чём смысл CAS?

А ты диаграммы Фейнмана ручонками считать предпочитаешь? Интегралы по теории вычетов на бумажке считаешь?

Так симпатичнее (давно не писал на скале):

import scala.collection._

object bind {
  def unapplySeq[A](list: Traversable[A]): Option[List[A]] = Some(list.toList)

  implicit class RichMap[K,V](map: Map[K,V])  {
        def byKeys(ks: K*) = ks.map(k => map.getOrElse(k, null.asInstanceOf[V]))
  }

  def main(args: Array[String]) {
    val map = Map('a -> 1, 'b -> 2, 'c -> 3)
    val bind(a, c) = map.byKeys('a,'c)
    println(a, c)
    map.byKeys('a, 'b) match {
        case bind(a, b) => println(a, b)
    }
  }
}

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

Ну уговорил, ладно.

В scala (пока??) нет нетипизированных макросов, а это значит, что запилить аналог cl-cont или вычислительных выражений не получится (ужасно мне не нравится стандартный плагин scala для продолжений).

Расскажи мне, что сделал Грэм для развития Лиспа.

Написал On Lisp и ANSI Common Lisp

По каким конкретно возможностям?

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

А с каких пор Стауструп в авторитете? Он даже для развития C++ мало чего сделал.

Бида-огорчение. Расскажи мне, что сделал Грэм для развития Лиспа.

Написал On Lisp и ANSI Common Lisp

И это хотя бы сравнимо с тем, что сделал Страуструп для Си++?

По стилю разработки.

Позволяет звать дождь в жаркий день?

Сравнимо. On Lisp самое полное руководство к использованию Common Lisp-овых макросов и повлияло на их использование до сего дня.

Сравнимо.

Вклад в развитие Си++ Страуструпа, _автора_ языка, первого его компилятора и лучших учебников по его использованию, в развитие Си++, сравним с вкладом в развитие CL Грэма, написавшего полное руководство по использованию макросов? Okay %)

Если бЫ Грэм бы вот этим всем, я бы назвал его вклад равным, а так я не могу его назвать несравнимым.

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

Производительность? Тут и так томми убился, а ещё и через lisp...

Операция имеет полное право зафейлиться при ненадлежащих входных данных.

Нормальный тип должен ограничивать поступление «неправильных» данных.

Есть - чекер можно выбросить, написать новый, вообще не использовать

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

*Часть* работы, компилятора статически типизированного языка. Да.

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

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

Ты дебил. Во всех перечисленных языках макросистемы аналогичны по возможностям говнолиспу.

Нет, дебил именно ты. Потому что приводишь пример статически типизированных НЕ лисп-макросов, на вопрос о лисп-макросах. И потому что не понимаешь, как избыточный синтаксис мешает созданию другого синтаксиса.

Операция имеет полное право зафейлиться при ненадлежащих входных данных.

Нормальный тип должен ограничивать поступление «неправильных» данных.

*пожимая плечами* Он и ограничивает.

*Часть* работы, компилятора статически типизированного языка

Нет. Просто нет.

а на счет скаломакросов то это даже не смешно.

И что именно тебе не смешно?

Выход mocl (комментарий)

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

*Часть* работы, компилятора статически типизированного языка

Нет. Просто нет.

Как нет, если нужно только чекать, но не компилировать и линковать? Подсказки вместо жестких ограничений - тоже нет?

tailgunner> можно же считать, что динамика - это статика, но у всех объектов один и тот же тип.
alienclaster> Не, нельзя.

Так вот, если типы ограничивают входные данные, то «не, нельзя».

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

Нет, чекер не должен заниматься генерацией кода и не занимается ей.

Так да, согласен. Т.е. он должен будет «делать ту же работу».

Из «контекста непонятно было», что я говорю о том, что и ты? :)

Кстати, интересно другое, обоснование - можно ли динамически типизированный язык *весь* привести к статически типизированному аналогу. Вот почему RPython только подмножество, например?

Можно. Я даже выше сказал, как именно.

Дай линк.

http://existentialtype.wordpress.com/2011/03/19/dynamic-languages-are-static-...

Щаз прочту. По rpython - почему это подмножество питона, а не весь питон?

Думаю, сколько смогли - столько и сделали.

Т.е. попросту «ниасилели»? Слабо верится насчет осиливших pypy и psycho.