> рантайм обновление нафик не нужно

Вы просто не в курсе, насколько это удобно.

>Можно начать с того, что эта недоподелка до сих пор не поддерживает бурно развивающуюся ARM.

Добавлю, что это показательная черта всех сектантов - приносить в жертву объективные факторы взамен мнимых киллерфич вроде рантайм обновления кода.

>Вы просто не в курсе, насколько это удобно.

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

> Можно начать с того, что эта недоподелка до сих пор не

поддерживает бурно развивающуюся ARM.

Зато ARM поддерживает Clozure CL, а нормально написанный код должен работать на обоих реализациях. Так что здесь нет проблемы.

Хм, надеюсь вы не претендуете на адекватность?

>Например REPL

Штука хорошая, но не уникальная... Взять тот же ерланг... Но там виртуальная машина.

Для GHC это означает что нужно тащить в рантайм сам GHC. Это просто нереально. Есть только GHCi, но опять тот же байткод.

А ещё динамика

Ну началось... Не «универсальный» тип T, а стирание типов у всего чего можно. Плюс специальные конструкции, типа «а вот тут у нас будут происходить фейлы типизации». Только все-равно, фейлы будут происходить при вычислении конкретного S-выражения. Но в строго определенных местах. Достижение, мля!

Data.Dynamic просто не работает

Просто работает. И еще работает Data.Generics. А то что приходится gfoldl определять, так это издержки.

чтобы не приходилось обмазывать лифтингом

Считай это элементом дизайна.

И вообще, в любой реализации системы типов можно сколько угодно найти способов отстрелить себе ногу. Дальше что? Зато в динамических языках полностью отсутствует требование чтобы все типы были к моменту рантайма худо-бедно опеределены. Тоже, аффигительное достижение!

>Зато ARM поддерживает Clozure CL, а нормально написанный код должен >работать на обоих реализациях. Так что здесь нет проблемы.

Ты как-то неправильно цитируешь, прям как Суворов-Резун про Сталина. Всё самое главное вырезал. Вопрос был про SBCL, я про него и ответил.
А Clozure - это отдельная песня.

> Вопрос был про SBCL, я про него и ответил.

Да не, вопрос в целом про проблемы CL. Ибо из свободных есть не только SBCL, но Clozure CL, а также ещё ECL и даже CLISP. Там где пасует одна реализация (например, поддержка ARM), оказывается что можно использовать другую. Иначе бы и смысла в существовании различных реализаций не было бы.

А Clozure - это отдельная песня.

Clozure CL, если быть точным, а то у некоторых возникаю неправильные ассоциации с Clojure. Кстати, что за песня?

>>Вопрос был про SBCL, я про него и ответил.

Да не, вопрос в целом про проблемы CL

Привожу точную цитату:

SBCL, у которого масса проблем.

Огласите тогда весь список проблем, пожалуста. Если что, то порт на Win32 считается экспериментальным. Какие ещё есть проблемы?

И кто из нас после этого неадекват?

Иначе бы и смысла в существовании различных реализаций не было бы.

В том то и суть, что всё что есть лиспового где-то да пасует. А реально юзабельного ничего нет.

Кстати, что за песня?

Можно начать с его тормознутости даже на фоне тормознутого SBCL. И все ваши песни про «CL быстрый почти как C» становятся детским лепетом. Особенно когда речь идёт про ARM, где производительность всегда в цене.

> И кто из нас после этого неадекват?

Не после этого. И без сомнения вы. В том числе потому, что указываете на отсутствие поддержки SBCL-ом ARM. Macil то просто не знает, что CL это не только SBCL. SBCL не поддерживает ARM и Windows потому что это не нужно разработчикам SBCL, да и пихать SBCL на современные ARM может оказаться не самой лучшей затеей (ибо как настоящий сервер приложений он считает себя самым важным и не стесняется в потреблении системных ресурсов). Зато ARM и Windows поддерживает Clozure CL, очевидно его разработчикам это нужно. И в этом и заключается сила стандарта, что приложения обычно достаточно легко переносятся с одной реализации на другую.

Можно начать с его тормознутости даже на фоне тормознутого SBCL.

Он намного быстрей, чем Python и этого достаточно.

И все ваши песни про «CL быстрый почти как C» становятся детским

лепетом.

Опять неадекват. Чьи песни? Тут такое такое love5an любил рассказывать. Всем же остальным совершенно понятно, что смысла сравнивать С и CL по производительности нет никакого, ибо области применения у них совершенно разные. Да и используют CL не из-за скорости.

Там, где скорость не нужна, используют Python. Или PHP.

Список будет, или слив засчитываем?

> Там, где скорость не нужна, используют Python. Или PHP.

Там много что используют. Но CL удобней чем Python и уж тем более PHP. Потом, так вообще нельзя говорить «скорость не нужна».

>Там много что используют.

Не для флейма ради. Ты видел MetaLua?

> Не для флейма ради. Ты видел MetaLua?

Нет, а что?

Лисп не самый удобный ЯП, возьми Factor.

можно подробнее?

Некоторые объяснения есть в «Lazy Functional State Threads». Суть в том, что с формальной точки зрения система эффектов одна, но на уровне GHC она реализованна дважды - как ST и как IO (не так что IO - частный случай ST, а именно независимо).

Основная идея всей этой системы эффектов это такой тип данных (название условное):

> newtype Effect s a = Effect { effect :: s -> (a, s) }

Т.е. мы берём что-то (типа s), возвращаем новое что-то (типа s) + ассоциированное значение (типа a). При этом часть преобразования s -> a будет всегда чистой (ссылочно прозрачной и безопасной для системы типов), а вот преобразование s -> s может быть не чистым, т.е. тип s может быть примитивом типа данных который принадлежит нечистому миру, но это не важно, т.к. типовая верификация проводится только по первой части преобразования, вторая может реализовать собой побочный эффект (если так - то на уровне примитива, это никак не сказывается на системе типов, что-то вроде дополнения набора примитивов типом BlackHole или RealWorld).

Процесс выполнения осуществляется так:

> run :: (forall s. Effect s a) -> s -> (a, s)
> run s i = effect s i

> run' :: (forall s. Effect s a) -> s -> a
> run' s i = fst $ run s i

> run'internal :: (forall s. Effect s a) -> s -> s
> run'internal s i = snd $ run s i

Т.е. это что-то вроде «вилки» которая расшепляет вычисление на две части - одна остаётся в чистом мире (который проверяется чекером), а другая отправляется в примитив «ВесьОстальнойМир».

Ну и характеристики этого типа данных:

> instance Functor (Effect s) where
>   fmap f m = Effect $ \s -> case effect m s of (r, s') -> (f r, s')

> instance Applicative (Effect s) where
>   m <*> n  = Effect $ \s -> case effect m s of
>                               (f, s') -> case (effect n) s' of
>                                            (x, s'') -> (f x, s'')

> instance Monad (Effect s) where
>   return x = Effect $ \s -> (x, s)
>   m >>= n  = Effect $ \s -> case effect m s of (r, s') -> effect (n r) s'

Это всё что можно сказать с формальной точки зрения :)

А дальше есть такая картинка. И этот тип Effect воплощается на разных уровнях - на том уровне который покрывает (на данный момент) система типов FC и на том который она не покрывает.

Часть которая покрывается системой типов это state transformer:

> type ST s a = Effect (State s) a

(писать инстансы не нужно - они уже есть для Effect). Тут State (State#, то есть) это примитив по полиморфному типу:

  type State s

т.е. он параметризирует другие примитивы (s). Какие-то конкретные типы (State Foo, State Bar) могут давать чистые преобразования, а какие-то - нет (State RealWorld).

> data RealWorld

С точки зрения ST функция run' это runST (которая кошерна).

А вот если мы имеем дело с:

  ST RealWorld a == Effect (State RealWorld) a

то имеем:

> type IO a = ST RealWorld a

это часть которая на данный момент неполная - с точки зрения IO функция run' это как раз unsafePerformIO (некощерная), примитив RealWorld обладает такими свойствами, что эта функция портит ссылочную прозрачность и не даёт правильно работать системе типов, считается, что программист сам должен их обеспечить (если использует unsafe* функции), т.е. «нетипичный» (плохо типизированный) код пропускается и генерируется плохой STG код - он может как упасть так и отработать.

Т.е. с точки зрения типа run' :: (forall s. Effect s a) выполнять run' на IO (== Effect RealWorld a) не правильно, поэтому в мире Haskell правильно прятать конструкторы, но если реализовывать run' для IO в виде (exactly RealWorld s => Effect s a) (как-то так) т.е. [un]safePerformIO, то правильно принимать во внимание существование низлежащего мира. По крайней мере генерировать кривой STG неправильно - нужно хоть что-то предпринять.

Можно начать с того, что эта недоподелка до сих пор не поддерживает бурно развивающуюся ARM.

Надо сначало отделить мух от котлет - SBCL это embedded? Это как Java SE + SWING на ARM ;) Для ARM есть ECL.

недоподелка

разработчик доделанных компиляторов в треде детектед?

спасибо

> SBCL это embedded?
А ARM это embedded?

Но там виртуальная машина.

А в GHC нет её?

Для GHC это означает что нужно тащить в рантайм сам GHC.

Почему он не может быть сбоку обеспечивая RPC?

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

Нет, я имел ввиду вывод с обоих сторон.

Плюс специальные конструкции, типа «а вот тут у нас будут происходить фейлы типизации».

С точки зрения лиспа (как там сделано) - не фейлы типизации, а фейлы типа «ой, у нас сюда попало что-то совсем не того типа, давайте сделаем рестарт, пусть пользователь (языка) сам решает», а не «решим-ка за пользователя». Т.е. типы тоже можно использовать как данные (а не просто квантифицировать по ним в параллельном представлении), и делать выбор по typecase.

Просто работает. И еще работает Data.Generics. А то что приходится gfoldl определять, так это издержки.

Т.е. если я решил писать код в духе Data.Dynamic и использую ещё несколько библиотек в которых их авторы определили несколько типов данных, то мне нужно заниматься дописыванием инстансов к чужим библиотекам (при том что даже gfoldl неплохо деривайдится). Я просто как-то наткнулся на это «очевидное» поведение и понял, что я всё-таки не могу это использовать.

Считай это элементом дизайна.

Ну хорошо, я как раз думал - нет ли общепринятого способа это обойти. Видимо нет.

Дальше что? Зато в динамических языках полностью отсутствует требование чтобы все типы были к моменту рантайма худо-бедно опеределены.

Тоже верно, но это, ещё раз, на тему того что одни выводят типы снизу, другие распостраняют их сверху. В лиспе, например, нет проблем с тем чтобы добавить вывод снизу (есть проблемы в умельцах которые бы реализовали такую возможность правильно, и нет «покупателей» - кому нужны типы в лиспе? :))

Кстати, есть такое расширение как CLOS (+ MOP), там сделать унификацию времени компиляции не составляет особых проблем.

> Т.е. типы тоже можно использовать как данные (а не просто квантифицировать по ним в параллельном представлении), и делать выбор по typecase.

Если _компилятор_ не может дать гарантий, то вышесказанное - просто жалкое словоблудие^W^Wпопытка оправдания :)

Если _компилятор_ не может дать гарантий, то вышесказанное - просто жалкое словоблудие^W^Wпопытка оправдания :)

Ты поднимаешь социальный а не технический вопрос :) Надо спросить mv какие они гарантии дают в своём софте :) Компилятор-то легко расширяется - все over 30 примитивов в раз-макросенном CL не покроешь, но частичную унификацию можно делать.

Изначально (после вопроса «нафиг лисп?») речь пошла про «полезный REPL», типа если ты купил новый многоядерный процессор с новыми инструкциями, то в SBCL ты можешь научить компилятор работать с этими ядрами и инструкциями так же просто как определить в GHCi факториал :)

Теперь нужны гарантии от чего? От реализаций CL? Тогда приведи простой пример кода (точнее класс возможных кодов) относительно которогу нужны какие-то гарантии.

>> Если _компилятор_ не может дать гарантий, то вышесказанное - просто жалкое словоблудие^W^Wпопытка оправдания :)

Ты поднимаешь социальный а не технический вопрос :) Надо спросить mv какие они гарантии дают в своём софте :)

Вот как раз вопрос про софт mv - это социальный, а вопрос о гарантиях компилятора - технический.

Теперь нужны гарантии от чего? От реализаций CL?

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

take two

пример будет?

Пример чего тебе нужен?

>Почему он не может быть сбоку обеспечивая RPC?

Суть изменится мало, а проблемы безопасности возникнут. Нужен какой-то хитрый линкоровщик... Не обязательно же делать как в лиспе. Пусть хотя бы будет эрланговский подход: возможность замены модулей в рантайме. Но тогда придется использовать модули а-ля ML, как минимум, и хранить их сигнатуры в рантайме.

Нет, я имел ввиду вывод с обоих сторон.

Что ты имеешь в виду под «c обоих сторон»?

а не «решим-ка за пользователя»

Не совсем так. Скорее «я не могу доказать соответствующее высказывание». Но никто за пользователя ничего не решает.

в которых их авторы определили несколько типов данных

А если эти типы даннх — абстрактные? Придется делать обертку из своего типа, для него определять набор комбинаторов, чтобы можно было быстро преобразовывать из и в библиотечный тип. А уж для этого безобразия делать instance'ы.

Я конечно могу ошибаться, но Identity должно хватить.

В лиспе, например, нет проблем с тем чтобы добавить вывод снизу

Угу. Будет такой же «двумерный» подход: сначала описываем сам терм, затем описываем что этот терм делает, затем описываем что делает терм, который описывает... и т.д. пока не надоест. ИЧХ в лиспе это будет сделано _намного_ проще. Хотите тип как объект первого класса? Пожалуйста! Хотите генерить типы с помощью макросов? Вперед! Хотите генерить типы на основе статического анализа S-выражения? Кто ж мешает? Тип можно вытаскивать в рантайме по аналогии с документацией. Э-э-э-х. Только кому это нужно?

Пример чего тебе нужен?

Ну ты пишешь:

Если _компилятор_ не может дать гарантий, то вышесказанное - просто жалкое словоблудие^W^Wпопытка оправдания :)

Если -> То. Вот я и спрашиваю - какой компилятор не может дать гарантий (а то словоблудие получается) и каких (пример: «код - нужные гарантии»).

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

Вот чё за уроды опять тред потёрли?

Была интереснейшая дискуссия про продолжения в вебе. Что за мудень её снёс?

Наитупейшие высеры малолеток на главной интереснее читать?

>Надо сначало отделить мух от котлет - SBCL это embedded? Это как Java SE + SWING на ARM ;) Для ARM есть ECL.

Во-первых, последние cortex-ы это довольно мощная штука, я бы не назвал их embedded.

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

Embeddable Common Lisp (ECL) is a LGPL Common Lisp implementation aimed at producing a small-footprint Lisp system that can be embedded into existing C-based applications. It is able to create stand-alone ELF executables from Common Lisp code and runs on most platforms that support a C compiler. Because it compiles Common Lisp to C...

> Во-вторых, я не догоняю как этот ваш суперлисп будет делать

обновление кода в рантайме и прочие ненужные киллерфичи, если он

транслирует код в C:

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

Солидарен, брат. Налил чайку и приготовился почитать свежак, а тут облом. Development катится в СГ.

Запилили в толксах:

http://www.linux.org.ru/forum/talks/5956895/page3

Но без анонимуса уже не то.

>У ECL есть интерпретатор.

ЧТД

RusNekromant, кстати, глянь Racket. Там шикарнейшая документация с примерами, книги, куча батареек. Своя IDE, если кто с Емаксом не дружит. Даже есть исходники 3D игр. Для новичка, так вообще рай.

Спасибо, я почитал вскользь. Она схемо подобна и на unix, я на винде работаю. Не ну даже если на винде запустится то синтаксис чужд будет наверное, не хочу перескакивать с одного на другой. Да вот ща на работе завал разгребу и буду читать что такое сокеты и с чем их едят.

>Спасибо, я почитал вскользь. Она схемо подобна и на unix, я на винде работаю. Не ну даже если на винде запустится то синтаксис чужд будет наверное, не хочу перескакивать с одного на другой. Да вот ща на работе завал разгребу и буду читать что такое сокеты и с чем их едят.

Оно и есть бывшая схема. Да и под виндовс есть. В чем проблема? И что значит синтаксис другой? о_О

> Она схемо подобна и на unix, я на винде работаю.

Юзаю ее под винду, никаких проблем пока не было.

Вот как раз по сабжу: http://www.free-soft.org/FSM/english/issue01/sk.html Собственно, там практически вся сетевая логика для простенькой игры изложена (например допилить этого до чего-нибудь пошагового типа крестиков-ноликов как нефиг делать. еще и чатик туда прилепить в виде упражнения :)).

Ну я сам не пробовал, но схема это семество лиспа но всё же это не комон лисп... ну попробую как нибудь обязательно.

Спасибо, нада почитать внимательно. Кстати вот как раз на схеме написано, там например присутствуют квадратные скобки(я бегло глянул), а в Cl нет таких вещей.

Кстати вот как раз на схеме написано, там например присутствуют квадратные скобки(я бегло глянул), а в Cl нет таких вещей.

В CL такое тоже есть - в тех библиотеках в которых их авторы определили специальный синтаксис. В RDNZL, например. Ещё в cl-opengl есть декораторы (http://nklein.com/tags/opengl/)

У ECL есть интерпретатор.

ЧТД

У ECL есть байткод - с символом связывается место в памяти в которое был записан компилятором байткод. Вызов этого символа-функции это вызов сишной функции которая начинает выполнять этот байткод. Горячее обновление осуществляется тем, что компилятор генерирует новый байткод для другого кода и связывает с ним этот символ (в таблице символов), старый байткод собирается GC, т.к. при аллокации чего либо оно помещается в стек GC. Т.е. горячее обновление возможно в любом языке в котором есть объекты, таблица символов и GC. SBCL и CCL отличаются только тем, что их компиляторы размешают в памяти не байткод, а машинозависимой код. Если бы ECL умел сохранять свой байткод на диск (а он не умеет) - это было бы даже приимущество, как у Java. А так, как было сказано, CCL тоже работает на ARM-е, если нужен именно машинный код.

> «Сетевые игры на лиспе» и подобные запросы. Мне ничего не выдало кроме того как создать сайт на лиспе. С чего начать, может кто то статью знает с примерами или книгу?

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

Ну, например, крестики-нолики с компом.
* 1: отрисовка сцены
* ход игрока: интерфейс GUI
* ход компа: вычислить нужный ход
* проверка GAME_OVER
* player1 win или player2 win
* goto 1

Теперь 2 игрока локальных: всё то же самое, только не надо вычислять нужный ход. Вместо интерфейса GUI появляется клиент-сервер: сервер занимается обработкой ввода пользователя, клиент отрисовывает сцену.

Теперь, 2': 2 игрока по сети. Клиент и сервер исполняются на разных узлах. Ввод пользователя через GUI заменяется на чтение
пакета из удалённого протокола, который пришёл по сети.

То есть, вариант 2 и 2' отличается тем, что: нужно работать с событиями ввода пользователя по сети, и отправлять свои события тоже в сеть.

Как пример, допустим, делаем крестики-нолики через джаббер. Сетевой протокол XMPP, http://en.wikipedia.org/wiki/Extensible_Messaging_and_Presence_Protocol

Там внутри XML, то есть он довольно расширяемый. Библиотека под лисп называется http://common-lisp.net/project/cl-xmpp/
, другой пример: trivial xmpp http://gzip4ever.blogspot.com/2010/06/trivial-xmpp-01-release.html

А может на лиспе всё это дело слишком сложно и не стоит заморачиваться?

да нет, не сложнее чем на других языках.
В чём-то даже проще, из-за unwind-protect, sxml, метапрограммирования на sxml и т.п.

Сначала придумай, как бы ты писал несетевой алгоритм не на лиспе. Потом, как бы ты писал сетевой алгоритм на лиспе. Потом просто перепиши получившееся на лисп :)

на схеме под айфон тоже симпатично выглядит: http://jlongster.com/legacy/scheme-iphone-apps.html http://jlongster.com/legacy/remotely-debugging-iphone-scheme.html

* Потом, как бы ты писал сетевой алгоритм НЕ на лиспе. //fix

> Разве есть киллер-фича в лиспе для сабжевых целей? Невозбранный обмен S-выражениями? Дык, это раньше в далекие дремучие времена можно было их сувать eval'у напрямую... Теперь это наивность, граничащая с идиотизмом.

ну тащем-та, да, но прикинь, как упрощаются обновления клиент и сервер: сервер генерит S-выражения, клиент получает их при загрузке уровня и компилирует на клиенте. Готовое облако, фактически, типа Steam cloud :) а как ботов становится просто писать, и античитеров геморно, это просто сказка :))) а сборщик мусора как проснётся ВНЕЗАПНО :))

Реализации CL делятся на 2 неравные части: оголтелая проприетарщина и SBCL, у которого масса проблем.

ССL вполне рабочий, CMUCL с проблемами в среде сборки (под x86-64).

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

см. пример игрушки под айфон на Gambit scheme. Кстати, в Gambit с параллелилизмом всё хорошо, потому что собирались на нём моделировать Erlang через termite. Green threads в Gambit реализованы неплохо.

google://«Game in a Day» +lisp тоже довольно много поделок выдаёт.

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

правильность чего? сетевого протокола?

А сделать это можно только с помощью языков со статической типизацией и сделанной в соответствии с теорией типов системой типов.

мне нравится Maze of Monads, но сколько ещё таких монадоподобных игрушек на Хаскелле вообще в природе существует?

> Читал обзоры, где разработчики делились с восторгом опытом использования для этого Python.

1. берешь protocol buffers
2. ... Python/lisp/C++/whatever ... — генерируешь стабы
3. ???
4. PROFIT!

>Теперь про реализации... <...>

поэтому на выбор: Хаскель, Окамл, Скала, и F# (если не тошнит от .Net и M$).

я бы взял Mythryl
http://news.ycombinator.com/item?id=699146 — неплохой SML/NJ расширенный классами, объектами, исключениями. Прозрачный С FFI.

Но система сборки у него пока только под 32 бита :((

> Какой именно - я написал же, что sbcl под виндой

вот допишет Лавсан свои биндинги к DirectX, считай графику уже будет на чём писать