Выход mocl

И кто соснул? :)

Фантастика. Как же это у тебя формат документов не ломает рабочий код - рабочему коду вообще до лампочки что там лежит в докментах? Он у тебя наверное ничего не делает.

Нет, не до лампочки. У меня json-документы валидируются json-схемами. И если говорить о расширении документов, то в json-схемах возможные расширения заложены в определённых местах. Следовательно, расширять документы можно (и это не сломает работающую систему), но вот изменять строго заданные старые поля — нельзя. Валидация не пройдёт.

Шоб тебе зарплату по такой бухгалтерии платили.

А я сам себе зарплату плачу, сколько надо — столько и заплачу.

Хех. Были уже треды про это.

Зимой, емнип, был годный макросрач CL vs Racket

Следовательно, расширять документы можно (и это не сломает работающую систему

А с чего бы ему ломаться?

но вот изменять строго заданные старые поля — нельзя. Валидация не пройдёт.

Да ладно тебе! Меняешь схему — и все прекрасно работает. Исключение — очень специальные поля, которые: 1. есть в количестве не более 5 штук; 2. никогда не изменяются и необходимость такая не вожникает; 3. выполняют важную, но вспомогательную роль и 4.это всё задокументировано, все это прекрасно знают и ни один дурак не будет менять поле ID на что-либо другое.

Изменить схему — всяко проще, чем код

upd: в самом крайнем случае задействуем на полную катушку механизм наследования:

schem['di']=schem['id'];

А с чего бы ему ломаться?

Я об этом и говорю, что не с чего.

Да ладно тебе! Меняешь схему — и все прекрасно работает. Исключение — очень специальные поля, которые: 1. есть в количестве не более 5 штук; 2. никогда не изменяются и необходимость такая не вожникает; 3. выполняют важную, но вспомогательную роль и 4.это всё задокументировано, все это прекрасно знают и ни один дурак не будет менять поле ID на что-либо другое.

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

Изменить схему — всяко проще, чем код

Да.

А почему считаешь, что решение не удачное? Что с funcall'ом не так?

В lisp-2 с функолом все ok. Другой вопрос - все ли ok с lisp-2 :) Но мои аргументы против будут достаточно известны: неудобство работы с HOF и вообще писанины в функциональном стиле, кроме того - я вообще не вижу причин для раздельного пространства имен функций и переменных кроме как для обеспечения нормальной работы CL-стайл макросов.

неудобство работы с HOF

А в чём заключается неудобство? Как бы ты хотел?

А в чём заключается неудобство?

Синтаксическая перегруженность при передаче ф-ций как аргументов

Как бы ты хотел?

Lisp-1 на данный момент меня устраивает.

Я об этом и говорю

А я и не спорю, я искренне удивляюсь.

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

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

Предлагаю самому сделать выводы :) http://www.linux.org.ru/forum/development/8117976

тикль не проектировался для этого и не предназначен.

Щикарно, чо!

Теперь буду знать.

Гг. Ну я дальше по треду признал, частично, что неправ :)

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

Неверно.
dave Полноценные статически типизированные макросы еще ни у кого не получились, насколько мне известно.... Scala нет нетипизированных макросов, без которого сама идея макросистемы не особо жизнеспособна...
Lisp-style макросы и динамическая типизация - вещи взаимосвязанные.

tailgunnerТак звучит более правдоподобно (хотя всё равно неизвестно, правда ли).

aliencasterНе существует примеров подтверждающих обратное. Появятся - поговорим.

rscalamacros.org

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

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

dict-bind хорошо демонстрирует основы МП и кодогенерацию

Нет - он демонстрирует лиспорешение лиспопроблем.

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

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

Это конечно круто, но ни ADT, ни pattern matching не решают поставленной задачи о деструктуризации словаря.

Да ты наверное ослеп:
Выход mocl (комментарий)

Ты показал regexp'ы и ADT, а это совершенно не то что нужно.

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

Ты не показал, как pattern matching разбирает именно словарь.

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

Далее протечка продлжилась и ты заявил, что подобная деструктуризация вообще не нужна, ибо решает некие частные случаи.

Именно. Потому что все представленные деструктуризации a) результат исходных хреновых решений передавать словарем то что словарем передавать не надо (и заметил что здесь пахнет объектным перлом на хэшах), и б в общем случае не решается потому что ключи в хешах в общем случае отфонарны, и соответствие их переменным в скоупе - это частный случай частного случая. На что ты предложил посмотреть как в кложуре используется :as. Но в тоже время то что переменные не имеют отношения к ключам в моем решении тебе не нравится.

Когда мы увидим разбор _словаря_ c неявным связванием идентификаторов механизмами Scala?

Когда ты объяснишь что именно ты хочешь показать?

И она с этой задачей справляется. А сраловский pm — нет.

Ты что - слепой?

scala> val List(a,b,c) = List(1,2,3)
a: Int = 1
b: Int = 2
c: Int = 3

Снова фантазии? Когда ты покажешь как деструктурировать словарь в Scala?

Ну е мое сколько можно ты что ослеп?
Выход mocl (комментарий)

И уже на протяжении нескольких дней пытаюсь выбить из тебя реализацию подобной функциональности на Scala.

Ослеп?

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

Ты же только вертишь задком и протекаешь, вместо того чтобы показать как это сделать.

Я тебе на первой же странице показал. У тебя с глазами как?

Понимаешь ли ты, что ADT в понимании ФЯП'ов в CoffeeScript вообще нет. CoffeeScript — вообще не ФЯП.

ADT к функциональщине имеет просто никакое отношение.

Чё, плохо что-ли?

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

позно пришел домой

Если «писать работающие программы» — это долбиться с типами и невменяемым дизайном Scala, вместо того чтобы непосредственно решать задачу, то у меня для тебя плохие новости.

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

Лучше покажи, как же это у тебя формат документов ломает рабочий код?

Хотя нет, лучше просто расскажи, не показывай, а то я все равно со страху глаза зажмурю.

Деструктуризация не более чем демонстрирующий пример.

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

Итак, начнём сначала.

Что - опять трудности с чтением?

«На вход прилетает JSON». Кто будет укладывать json в твои классы? Одерски?

lift-json например (https://github.com/lift/lift/tree/master/framework/lift-base/lift-json/).

На вход прилетсяет XML в CoffeeScript. Кто будет вкладывать его в кофейные объекты?

И если говорить о расширении документов,

Ты просто кладесь частных случаев.

«а пускай у нас только такие ихменения которые ничего не поломают».

Ну так ничего и не поломается в скале.

Так звучит более правдоподобно (хотя всё равно неизвестно, правда ли).

Звучит что именно - «Lisp-style макросы и динамическая типизация - вещи взаимосвязанные»? Я немного подумал и решил, что типизация макросов не очень важна, если сгененрированный код проверяется тайпчекером. В конце концов, худшее, что может случиться - невнятные сообщения об ошибках.

Лучше покажи, как же это у тебя формат документов ломает рабочий код?

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

Кстати на счет макросов в Scala, раз уж меня помянул :)

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

Вообще говоря, нужны не просто продолжения, а их обобщение в виде вычислительных выражений как в F#. Но сдается мне, что Scala имеет ряд (фатальных??) недостатков в дизайне, которые будут мешать такой реализации. Один из них - возможность поставить return (в смысле java) в любом месте внутри метода. Из той же песни - break. Еще for comprehension сильно не стыкуется. По иронии судьбы этот comprehension призван решать похожую задачу, но здесь он будет здорово мешать.

В общем, это основные причины, по которым я забил на Scala. Боюсь, что исправить Scala будет уже поздно. Она теперь будет такой, какая она есть сейчас.

Ты что - слепой?

scala> val List(a,b,c) = List(1,2,3)
a: Int = 1
b: Int = 2
c: Int = 3

Лалка :) Это ж list, а не словарь. Кто-то из нас двоих действительно ослеп и это не я.

«а пускай у нас только такие ихменения которые ничего не поломают»

Очаровательно! ib4: echo $TXT | md5sum f6a1bbdbc65312c1d3bcb070a7ab103d -

Лучше покажи как это у тебя формат входных данных не имеет значения

Я смотрю, ты неравнодушен к базвордам. Вот тебе еще один: data driving

upd: кстати, методика описана у финнов.

В конце концов, худшее, что может случиться - невнятные сообщения об ошибках.

Как в CPP. Угу.

lift-json например

Кодом, пожалуйста, кодом. А не ссылками. Мне интересно, что нужно написать, чтобы эта штука сложила определённый выше json в определённые тобой объекты.

На вход прилетсяет XML в CoffeeScript. Кто будет вкладывать его в кофейные объекты?

xml2json сложит сам.

Лалка :) Это ж list, а не словарь. Кто-то из нас двоих действительно ослеп и это не я.

Лапка ты сам не читаешь что пишешь?

Хотел показать, что её задача декларативно разбирать словари и списки. И она с этой задачей справляется. А сраловский pm — нет.

словари и списки
списки

Со словарем ссылку выше дал раз пять.

В конце концов, худшее, что может случиться - невнятные сообщения об ошибках.

Как в CPP

В Си++ не макросы, а примитивная текстовая подстановка.

Один из них - возможность поставить return (в смысле java) в любом месте внутри метода.

В макру приходит AST. Можно ругнуться на стадии компиляции.

В общем, это основные причины, по которым я забил на Scala.

То что там работают продолжения и реализованы они не макрой?

Да ты наверное ослеп: Выход mocl (комментарий)

Как я понял BooBoo хочет малость не это. Что-то вроде:

val Dict(('a, av1), ('b, bv2)) = Map('a -> 1, 'b -> 2)

val Dict(('b, bv1), ('a, av2)) = Map('a -> 1, 'b -> 2)

val Dict(('a, av1), ('b, bv2), _ ...) = Map('a -> 1, 'b -> 2, 'c -> 3, 'd -> 4)

Кодом, пожалуйста, кодом. А не ссылками.

По ссылке код.

Мне интересно, что нужно написать, чтобы эта штука сложила определённый выше json в определённые тобой объекты.

По ссылке _именно это_ и показано.

xml2json сложит сам.

Кодом сестра кодом.

И все же, ты откроешь секрет, что нужно сделать, чтоб изменения формата данных сломали код?

Как я понял BooBoo хочет малость не это.

scala> val map = Map('a -> 1, 'b -> 2, 'c -> 3)
scala> implicit class RichMap[K,V](map: Map[K,V])  {  def byKeys(ks: K*) = ks.map(k => map.getOrElse(k, null.asInstanceOf[V])).toList }

scala> val a :: c :: Nil =  map.byKeys('a,'c)
a: Int = 1
c: Int = 3

scala> val a :: rest =  map.byKeys('a,'c)
a: Int = 1
rest: List[Int] = List(3)

Нет. Не нравится то, что в Scala, скорее всего, не получится добавить нормальный аналог вычислительных выражений по типу F#, а они мне нужны именно в Scala. Если бы был такой синтаксический сахар (по типу нотации do из Haskell), то тогда бы на фиг в Scala не нужны были бы ни текущие корявые продолжения, ни какой-то неполноценный for comprehension. Это та вещь, где Дон Сайм явно переиграл Мартина Одерского.

Я думаю, что в статически типизированных языках будущего обязательно будет аналог вычислительных выражений. К тому же, они много проще, чем нотация do из Haskell.

В общем, я жду появления нового языка. Существующие меня не устраивают. Даю поблажку только для Common Lisp.

И все же, ты откроешь секрет, что нужно сделать, чтоб изменения формата данных сломали код?

Как только ты пояснишь что такое «сломали код». В слова я играться не буду.

что нужно сделать, чтоб изменения формата данных сломали код?

Изменить тип поля, скажем, с int на string. Что, так никто никогда не поступает, а тот, кто поступает - ССЗБ? «Я знал, что ты скажешь это» (ц)

Изменил. УМВР. ЧЯДНТ?

Ослеп? www.linux.org.ru/news/commercial/9298028?cid=9326673 (комментарий)

Какашка твоё решение. Это вообще не решение. Интересует неявное связывание путём генерации кода (ну а коль уж есть крутой pm, то сделай при помощи него). Но только словарей (hash table в Scala) и без всяких toList, лалка. А так как ты пукнул, так любой может сделать:

(defun yoba (ht)
  (iter (for (k v) in-hashtable ht) (nconcing (list k v))))

(destructuring-bind (k1 v1 k2 v2) (yoba (plist-hash-table '(:a 1 :b 2)))
  (list k1 v1 k2 v2))
; (:A 1 :B 2)

Изменил. УМВР. ЧЯДНТ?

ТННПИЛМ.

передаешь в строках цифры на пыхе, правильно?

Как только ты пояснишь что такое «сломали код»

Действительно. Был не прав. Но я, кажется, знаю как все исправить! Давай зададим вопрос непосредственно автору этого термина: Выход mocl (комментарий)

Какашка твоё решение. Это вообще не решение.

Это звездец какие аргументы.

Интересует неявное связывание путём генерации кода

Кого - тебя? Меня не интересует.

ну а коль уж есть крутой pm, то сделай при помощи него).

Плять, а я с помощью чего по твоему сделал?

А так как ты пукнул, так любой может сделать:

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

Давай зададим вопрос непосредственно автору этого термина:

Автор этого термина - втор поста на который отетом ыл пост по твоей ссылке.

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

В смысле, ссылку на первое использование термина я привел.