Выход mocl

По сравнению с жабой их ноль.

По сравнению с жабой лисп не существует в принципе.

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

Истинная правда. Есть лисперы которые покажут статс вроде того что я приводил в том треде по скале?

просто ищут сообразительных и учат. Добро пожаловать в 2013-й год.

И факты лиспа в этой теме я надеюсь пойдут уже буквально следующим постом?

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

То есть то что в склале их достаточно - уже не вызывает возражений?

funcall - это костыль lisp-2, зачем, спрашивается, его делать макрой,

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

Это какое-то новое слово в ООП.

Изменяемые объекты? Да неужели.

Нет - ты просил язык - тебе дали язык.

Ты несешь хню, не обижайся, серьезно, «ты спросил мне дали» - это вообще не очень вежливый пассаж, отметь.

А теперь у тебя претензии к чему к платформе?

И к платформе и к отсутствию макросов - третий ли пятый раз уже пишут о них.

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

Полноценные нормальные макросы. Про фазу луны это ты опять пытаешься невежливо то ли троллить, то ли сливать.

Это просто пример.

Неудачный. Потому что синтаксиса в питоне меньше, чем в ocaml и прочем статикоговне.

В окамле тебя почему-то отсутсвие поддержки SMP беспокоит, а питоновский GIL не жмет когда ты его в пример приводишь или рубиевый global VM lock?

Питоновский gil тоже жмет, естественно. Руби я не использую и не планирую.

Питон который ты привел в пример полон макросами?

Относительно нормальными макросами полон, например, racket.

По сравнению с жабой лисп не существует в принципе.

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

Есть лисперы которые покажут статс вроде того что я приводил в том треде по скале?

Это не имеет значения.

И факты лиспа в этой теме я надеюсь пойдут уже буквально следующим постом?

Я привел примеры контор с лиспом даже в таких банановых странах как наши, в штатах подобной работы - завились.

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

То есть то что в склале их достаточно - уже не вызывает возражений?

Вызывает.

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

Да. Потому что у вас макросы это неюзабельный костыль а-ля «шоб було».

Компиляция vs. интерпретация, чмо ничтожное.

Изменяемые объекты? Да неужели.

Таки да.

И к платформе и к отсутствию макросов - третий ли пятый раз уже пишут о них.

В питоне который ты приводишь постоянно макросы есть?

Потому что синтаксиса в питоне меньше, чем в ocaml и прочем статикоговне.

Где «полноценные нормальные макросы»?

Питоновский gil тоже жмет, естественно.

Тогда чем же плох окамл?

Руби я не использую и не планирую.

Ты ж только что дифирамбы пел ему и рору в смысле фейсбуков и прочего?

Относительно нормальными макросами полон, например, racket.

То есть питон хорош тем что макросы есть в схеме. Лисп хорош тем что рор в руби и стартапы. ocaml плох тем что решетка вместо точки в руби собаки разные не жмут, и хуже питона и руби тем же самым чем они с ним одинаковые. А F# хуже динамического питона отсутствием макр которые есть в схеме.

Замечательно.

Он существует на достаточном уровне, чтобы найти на нем работу и вообще эффективно программить

То есть списка предложений не будет.

Это не имеет значения.

Классно! Ни что так не подкрепляет аргумент как нежелание его подкреплять.

Я привел примеры контор с лиспом даже в таких банановых странах как наши

Ну то есть отсыл к моему аргументу был мимо кассы.

Да. Потому что у вас макросы это неюзабельный костыль а-ля «шоб було».

По причине того что макрой не делается то что в скаще макрой делать не нужно? Железно.

Компиляция vs. интерпретация,

«интерпретация макр в скале»? Проходи мальчик...

Ты решил шланговать, смысла дальше общаться не вижу.

Чем удобно? Разве что имена для переменных проще выдумывать ;)

Ну да. Как минимум. Ведь в Lisp вызов функции и обращение к переменной синтаксически чётко определены. Так чем же плохо, когда один идентификатор можно использовать в двух смыслах...

о что в руби так сделано - ну как бы не особо показатель

А что является показателем? На кого равняться? Вот Perl и Ruby на Lisp равнялись — не плохо получилось. Да и что не так с Ruby?

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

Окей. Давай попробуем ещё раз. Ты просишь меня показать ADT «какой-то там глубины». Но у тебя же нет никакой «глубины». На входе у тебя плоская структура типа «List of Optional String». У меня на входе — список из строк и nil'ов. В чём принципиальная разница? Списки-то у меня гетерогенные, т.е. в optional'е в моём решении смысла нет. Задача-то у нас какая? Деструктурировать и матчить структуры данных (желательно не тривиальные). Ты показал лохню, я написал реализацию этой лохни на Lisp — всё прекрасно разбирается. Что тебя не устраивает?

и полиморфным flatten.

Ещё раз. Твой flatten убирает None'ы. В моём случае, nil'ы убирает mapcon. Что не так?

Я понимаю паттерн матчинг с глубокой деконструкцией изобрел тот пацан что написал оптиму. Все остальные хаскели содрали у него.

Нет, не тот пацан. Пацан показал, что pattern matching на Lisp написать — пустячное дело. Я плохо знаю историю, но не удивлюсь, если Милнер ML прототипировал на Lisp.

Респект за советы, мужик ;)

Юзай F#.

Ты предлагаешь чуваку знающем CL соскочить на F#. Офигеть. Это равносильно предложению о самокастрации.

Никаких. Подключай. Где решение?

Та привёл задачу. Указал вход и выход. Я привёл решение этой задачи, с аналогичным входом и выходом. PM присутствует — преобразование описывается декларативно. Есть ещё какие-то критерии решённости? Расскажи, а не виляй задком. Я не Ванга. Не видишь список с вариантным типом optional — гетерогенный список из строк и nil'ов. Не видишь flatten — mapcan. Не видешь exhaustive check — и не увидишь, ибо CL по природе своей динамичен и, соответственно, в нём отсутствуют вариантные типы с конструкторами в compile time. Но не велика беда, ибо PM по ADT в статических ФЯП'ах только и делают что чекают элементарщину, навроде, «все ли конструкторы ADT перечислены в PM конструкции» и совершенно никак не помагают «глубинно» деструктурировать, а только мешают. Это капля в море. Вот скажи, прочекает-ли статически сралка сопоставляемость входных строк с заданными рац. выражениями? Нет? Ну да и кури бамбук тогда.

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

Очередная глупость сралка-фанбоя, котрую в угол не вопрёшь? Фанбой продолжает гипнотизировать себя и повторять, как мантру, — ADT, ADT, ADT...? http://www.scala-lang.org/api/current/index.html#scala.collection.mutable.HashTable, http://caml.inria.fr/pub/docs/manual-ocaml/libref/Hashtbl.html, http://msdn.microsoft.com/en-us/library/ee353686.aspx. Покажи, пожалуйста, где ты тут узрел ADT? Максимум, что даёт статика для подобных структур — типы для ключа и значения. Количество и какие ключи/значения в compile time не известо. А как разберёшься наконец таки с тем, что словарь — не ADT, напиши в конце-то концов как в сралке будет выглядеть «глубинная» деструктуризация словаря. Но только если снова решение будет, навроде:

val (ka, va) :: (kb, vb) :: (kc, vc) :: Nil = Map('a -> 1,'b -> 2, 'c -> 3).toList;

то фиг знает там в топе чего, может там на сишке всё писано, а собрано плюсовым компилятором :)

http://www.spoj.com/ranks/HOMO/

лично добавился на первое место, что иметь право сказать - нет :) в моем решении кастомный аллокатор + unordered_set, был бы у них компилятор поновее - было бы еще быстрее

Круто, чё. А iostream заюзал?

нет

Ну так сишечное всё же есть? :)

это плюсовое ;) если надо С++ без низкоуровневых операций - это уже будет Java

это плюсовое ;) если надо С++ без низкоуровневых операций - это уже будет Java

Ну так-то можно всё на Сишке написать и сказать что это плюсовое.

Ну так-то можно всё на Сишке написать и сказать что это плюсовое

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

Ты решил шланговать,

То есть я свел в один обзац твои перемешанные аргументы - и это я шлангую.

Ты просишь меня показать ADT «какой-то там глубины».

Нет ADT -это всего лишь один из продемонстрированных четырех аспектов.

Но у тебя же нет никакой «глубины».

Есть. Посмотри на деконструкцию.

В чём принципиальная разница?

В чем принципиальная разница в наличии и отсутствии Maybe? Собственно наличие и отсутствие.

Списки-то у меня гетерогенные, т.е. в optional'е в моём решении смысла нет.

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

Что тебя не устраивает?

Как ты думаешь почему там у меня показано несколько разных матчей и несколько результатов? Покажи мне последний на лиспе.

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

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

Хочешь посмотреть что умеют скальныё макры в релизной версии - вот: https://github.com/retronym/macrocosm/blob/master/src/main/scala/com/github/r...

А в бете сейчас вот: http://docs.scala-lang.org/overviews/macros/paradise.html

Твой flatten убирает None'ы. В моём случае, nil'ы убирает mapcon. Что не так?

То что flatten в данном случае демонстрация плиморфизма по типу (ака перегрузки) - что является одним из практических свойств для чего полезна типизация. Как по твоему он работает?

Пацан показал, что pattern matching на Lisp написать — пустячное дело.

Ты понимаешь чем «потенциальные возможности» отличаются от «распространенной практики»? Потенциально дистр линукса может собрать любой жела.щий - все открыто. На практике это делает ограниченное количество лиц. Потенциально для лиспа можно сделть глубокие ADT - оптима тому пример. На практике стандартная библиотека этого _не_ делает. То есть стандартная библиотека полностью не в курсе об их существовании.

Возвращаясь к примеру который я привел - ты понимаешь что тому коду абсолютно пофигу откуда приходят данные? Что я абсолютно одинаково могу обрабатывать что огромный файл (ага - lazyness) что бесконечный сетевой поток, что список из трех символов - код _не поменяется_. В этом и была суть демонстрации. И это в рамках _стандартного_ дизайна либы. Что-то мне подсказывает что в лиспе тебе придется для аналогичной вещи написать _все_ самому.

Та привёл задачу. Указал вход и выход.

Я сделал не это. Что я сделал - указанно выше.

Вот скажи, прочекает-ли статически сралка сопоставляемость входных строк с заданными рац. выражениями?

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

Ты понимаешь чем «потенциальные возможности» отличаются от «распространенной практики»?

Да, понимаю. Но optima — это не потенциальная возможность. Это реализованная возможность. Чувствуешь разницу?

На практике стандартная библиотека этого _не_ делает.

Ризницы никакой. Optima существует и широко используется, макросы и стандартная библиотека позволили её реализовать. Ты предлагаешь с выходом любой библиотеки тащить её в стандарт? Зачем это нужно?

Что я абсолютно одинаково могу обрабатывать что огромный файл (ага - lazyness) что бесконечный сетевой поток, что список из трех символов - код _не поменяется_. В этом и была суть демонстрации. И это в рамках _стандартного_ дизайна либы. Что-то мне подсказывает что в лиспе тебе придется для аналогичной вещи написать _все_ самому.

Моща невероятной силы. Не знаю кто тебе и что «подсказывает», но, напрмер, Clojure это может «искаропки».

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

Вот именно что не ожидаю. Я же не фанбой. Я знаю что может дать статическая типизация; и в этом случае она даёт очень мало. И, кстати, не только даёт, но и берёт.

То что flatten в данном случае демонстрация плиморфизма по типу (ака перегрузки) - что является одним из практических свойств для чего полезна типизация.

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

В чем принципиальная разница в наличии и отсутствии Maybe? Собственно наличие и отсутствие.

Ну просто в динамике Maybe by default.

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

Покажи мне гетерогенный список в Scala, пожалуйста.

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

Покажи мне «нормальное» решение для деструктуризации словаря в Scala. Сколько ещё раз попросить?

Хочешь посмотреть что умеют скальныё макры в релизной версии

Нет, не хочу. Хочу видеть от тебя примеры. Таким же образом я могу тебя отослать Art of Metaobject Protocol читать. Хотелось бы видеть как на Scala можно определить связания по ключам, на основании которых можно модифицировать значения словаря (мой пример с макролитами).

Покажи, пожалуйста, где ты тут узрел ADT?

Там их нет. Покажи где optima хоть где нибудь присутствует в стандартной либе лиспа.

Максимум, что даёт статика для подобных структур — типы для ключа и значения.

Да правда! Я тебе немного статической магии подкину:

trait TraversableOnce[A] {
   ...
   def toMap[T, U](implicit ev: <:<[A, (T, U)]): Map[T, U] 
   ...
}

перевести или сам догадаешься что именно здесь происходит и где оно чекается?

Вот еще (этот трейт реализуют всякие структуры) - расшифровать?

trait FilterMonadic[+A, +Repr] {
    ...
    def map[B, That](f: (A) ⇒ B)(implicit bf: CanBuildFrom[Repr, B, That]): That 
    ...
}

Или вот примерчик:

> def m[A, B](x:A, f:PartialFunction[A,B]):Either[Symbol, B] = if (f.isDefinedAt(x)) Right(f(x)) else Left('Not_Applicable)

> val pf:PartialFunction[Int, Symbol] = {case 1 => 'ok}

> m(1, pf);
res10: Either[Symbol,Symbol] = Right('ok)

> m(2, pf);
res11: Either[Symbol,Symbol] = Left('Not_Applicable)

частично определенные функции - тоже не нужны? И на этом тоже стандартная либа построена. Вся. И что бы тут могло статически чекаться а?

вот еще пример HKT Вышел Ceylon M5 «Nesa Pong» (комментарий)

тоже нечему статически чекаться да?

А как разберёшься наконец таки с тем, что словарь — не ADT,

Я задал вопрос какие принципиальные ограничения у словаря с точки зрения его семантики что он не может быть ADT? А то что реализация на хешах не адт всем очевидно.

перевести или сам догадаешься что именно здесь происходит и где оно чекается?

Переводи.

Вот еще (этот трейт реализуют всякие структуры) - расшифровать?

Да. Пожалуйста.

Да, понимаю. Но optima — это не потенциальная возможность. Это реализованная возможность. Чувствуешь разницу?

Покажи мне оптиму в стандартной либе.

Ризницы никакой.

Если нет разницы есть оптима или нет - зачем она «существует и широко используется»?

Ты предлагаешь с выходом любой библиотеки тащить её в стандарт? Зачем это нужно?

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

но, напрмер, Clojure это может «искаропки».

Clojure это такой лисп под которым статическая стандартная жабалиба?

Это искаропки кложуры я видел - это оень уныло. Я такую унылость и на эрланге делал. Давай пппробуй применить ее к отличной от списков структуре данных - например в дереве - и ты увидишь что будет. Ага first rest. Ага а как заставить их отличать с чем они работают. Ага ввести runtime дискриминацию - типы времени исполнения для бедных. Правда - и зачем нужна статика.

Я же не фанбой.

Ты именно что фанбой. Что ты что aliencaster уже скатились до личных фу и фи вроде «очень мало» и «нахрен нужно».

Только неспосредственно flatten это хреново демонстрирует.

Вот опять «хреново». Он это либо демонстрирует либо нет. Он єто демонстрирует.

scala> List(Some(1), None, Some(3)).flatten
res0: List[Int] = List(1, 3)

Ты именно что фанбой. Что ты что aliencaster уже скатились до личных фу и фи вроде «очень мало» и «нахрен нужно».

Ты покажешь таки, как деструктурировать словарь? Покажешь как Scala зарулит на spoj'е по производительности sbcl? Тут уже 2 реализации привели, осталось только перенести это на Scala. Или продолжешь пустую демагогию?

Но профитов-то не видно. У меня гетерогенный список. В качестве отсутствия значения у меня nil. И его спокойно фильтрую - без optional, без статики и без сраного flatten. А ты нафгарил список с вариантным типом optional и заюзал flatten — результат тот же. Я не понимаю твоего детского восхищения.

«нахрен нужно»

Ну а разве не «нахер нужно», если принципиально подойти к суте? Зачем в CL optional в том виде в котором ты его привёл? Если задача-то решается. Если списки-то гетерогенны.

Покажи мне оптиму в стандартной либе.

Блин, я фигею. Тебя что, кто-то по почкам бьёт, когда ты берёшь распространённую либу и решаешь задачу при помощи неё? Не надо забывать, что стандарту CL уже много лет, но это не мешает CL быть современным языком, в первую очередь, ввиду МП.

Clojure это такой лисп под которым статическая стандартная жабалиба?

Да. И что? От этого Clojure перестаёт быть Lisp'ом? Какие-то пряги?

От этого Clojure перестаёт быть Lisp'ом?

У кложуры от лиспа только скобки. Но для жаба-кодеров сойдет и так.

Ну просто в динамике Maybe by default.

Он там такой же как и null в статике.

Покажи мне гетерогенный список в Scala, пожалуйста.

> List(1,'c, 3.4);
res1: List[Any] = List(1, 'c, 3.4)

Покажи мне «нормальное» решение для деструктуризации словаря в Scala.

Я тебе показал. То что лично тебе оно не нравится - лично твои проблемы. Принципиальность соответствия названий переменных - ключам - это твой личный загиб. А если там будут ключи числами или строками с пробелами - как твой dict-bind работатать будет? Никак? Это вообще странный частный случай. И связан он скорее всего с тем что в виде словаря передается то что на самом деле должно передаваться нормальной структурой.

Хочу видеть от тебя примеры.

Там примеры. Ты хочешь не примеры ты хочешь решение на скале частной лиспопроблемы, к тому же весьма частный случай. Решение которое показал тебе я работает на любых ключах. dict-bind на числах работает?

Принципиальность соответствия названий переменных - ключам - это твой личный загиб.

Нет, не личный. Везде где есть деструктуризация словаря так сделано.

А если там будут ключи числами или строками с пробелами - как твой dict-bind работатать будет? Никак?

Приведенный макрос никак не будет. Но ведь я не конечное промышленное решение привёл, а набросок — для того, что бы показать макросы. Посмотри как это реализовали в CoffeeScript и Clojure.

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

Нет.

Ты хочешь не примеры ты хочешь решение на скале частной лиспопроблемы, к тому же весьма частный случай.

Нет. Посмотри как это реализовали в CoffeeScript и Clojure.

dict-bind на числах работает?

Нет, не работает. Но может работать. Посмотри как это реализовали в CoffeeScript и Clojure.

Я тебе показал.

Ты не решил задачу. Твоё «решение» — ручное низкоуровневое извлечение значений по ключам. Я так и на Сишке могу.

Переводи.

Метод toMap

def toMap[T, U](implicit ev: A <:< (T, U))

будет разрешен к вызову компилятором только в том случае если компилятор сможет доказать что любая структура (например список) инстанциирована с типом элемента который является подтипом пары A <:< (K,V), а иначе будет ошибка типов на стадии компиляции. То есть для List('a -> 1, 'b -> 2) (к стати -> это библиотечная функция, а не язык - стрелочный синтаксис - просто юзердефайнед удобство для пар) toMap вызвать можно, а для List(1,2,3) нельзя - и проверит это компилятор.

Второй бобщает метод map из гомоморфного до параметризированного соответствующей целевой структурой - компилятор согласно типизации ищет в скоупе соответствующее преобразование - билдер CanBuildFrom в целевую структуру - все это делается именно анализом типов.

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

А то как в случае HKT компилятор проверяет что в случае с list.map результатом будет именно статический list со всем набором методов, а в случае в set.map будет set (в отличии от сишарппов и жаб) - и он в состоянии это доказать во время компиляции - тоже «неважно»?