Scala

[metaclass]

Читаю книжку Одерского, до основной шизы еще не добрался, но такое ощущение, что в скале чрезмерно много синтаксического сахара. Типа "тут вы можете скобки опустить, а тут вместо скобок использовать фигурные скобки, а тут мы прямо в параметрах класса сделаем их полями, а в multiline string literal вы можете сделать отступ и stripMargin" и прочая и прочая в том же духе.
Основное из этого, видимо - function literals и вызов методов в стиле a methodName b, без точек и скобок, что делает код более лаконичным, одновременно позволяя при желании превратить код в нечитабельный ад.

Заодно по наводке jdevelop глянул на http://spray.io/ https://github.com/spray/spray/wiki
Примеры там, конечно, знатный abuse возможностей языка и вычислений на типах, типа extraction-директив с HList в качестве параметра типа.

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

PS: Вот, к примеру:
https://github.com/spray/spray/blob/master/docs/documentation/spray-routing/code/docs/HttpServiceExamplesSpec.scala

В SimpleService HttpResponse реализован как html-код написанный прямо внутри скала-кода. Сижу уже 30 минут ищу, где это преобразование реализовано и как. Т.е. не видя отдельных литералов и их типов (которые без загрузки всего оного кода с зависимостями в IDE/интерпретатор еще и не увидишь), с ходу догадаться, что происходит, достаточно сложно. XML literals, встроенные в язык и где-то implicit для конверсии.

PPS: implicit evidence:
http://jim-mcbeath.blogspot.com/2008/11/scala-type-infix-operators.html
http://stackoverflow.com/questions/3427345/what-do-and-mean-in-scala-2-8-and-where-are-they-documented

По-моему, это уже достаточно сложно, чтобы увлечь психов и стать новыми крестиками. Вот xeno_by еще приделает макросы - и совсем хорошо станет.

Comments

[xeno-by.livejournal.com]

Я скорее хотел узнать в чем проявляется лучшее разделение обязанностей.

[thesz.livejournal.com]

В ленивости?

Как я понимаю, short circuit оператор && наверняка встроен в Scala.

[xeno-by.livejournal.com]

Понятно.

Оператор пока еще да, встроен.

[thesz.livejournal.com]

Вот-вот. И сейчас вы накрутите ещё всякого. ;)

[isorecursive.livejournal.com]

Наверное, встроен, для эффективности, но можно сделать и средствами языка:
http://www.scalakata.com/509a323ce4b093f3524f38fa
Но, конечно, это by-name, а не by-need.

[thesz.livejournal.com]

Вы определение && на Хаскеле видели?

И как я понимаю, булевский тип тоже встроен.

[isorecursive.livejournal.com]

Что-нибудь такое ?:

True && True = True
_    && _    = False

Дело в том, что паттерн-матчинг в хаскеле дешугарится в case, а это такой же встроенный примитив, как и if.

@ И как я понимаю, булевский тип тоже встроен.
Ну это всё мелочи, по-моему. Можно вот так:
http://www.scalakata.com/509a3b5ce4b093f3524f38fd
и так:
http://www.scalakata.com/509a3bb3e4b093f3524f38ff

[thesz.livejournal.com]

Нет, не такое. Ваш оператор не будет short circuit. В частности, для False && error "Badam!" будет вычислен error "Badam!"

True && x = x
False && _ = False

Видите ли, в чём дело. Я могу 1) сделать свой собственный if и 2) воспользоваться кодированием конструкторов и деструкторов (сравнение с образцом) через функции. Это так называемое кодирование Чёрча.

Если вы не знали, то вот вам пример (я уж задолбался его приводить):
*Main> let true = \a b -> a
*Main> let false = \a b -> b
*Main> let a &&& b = a b false
*Main> let ifThenElse c a b = c a b
*Main> ifThenElse (true &&& false) 10 12
12
*Main> ifThenElse (true &&& true) 10 12
10
*Main> ifThenElse (true &&& true) 10 (error "Badam!")
10
*Main> ifThenElse (false &&& error "Badam!") 10 12
12

Попробуйте сделать такое на Scala.

На таком кодировании основана AwesomePrelude - как можно взять практически обычный Хаскель (пара расширений) и скомпилировать его в JS библиотекой. Без макросов. Без трансляции, как у меня в HHDL. Простой библиотекой.

Short-circuit операторы я могу также сделать и для других значений. Например, для Q Bool, если сочту это нужным. Поэтому я и обратил ваше внимание на встроенность bool.

[xeno-by.livejournal.com]

Касательно AwesomePrelude предлагаю посмотреть в сторону http://infoscience.epfl.ch/record/179888/files/js-scala-ecoop.pdf. Тоже делается Скалой с парой расширений.

[thesz.livejournal.com]

Интересно.

Получение AST из выражений я и сам хотел.

[xeno-by.livejournal.com]

> для False &&& error "Badam!" будет вычислен error "Badam!"
Не будет, т.к. соответствующий параметр call-by-name.

[isorecursive.livejournal.com]

@ Нет, не такое. Ваш оператор не будет short circuit. В частности, для False && error "Badam!" будет вычислен error "Badam!"
Не будет: http://ideone.com/1Tcr6D

@ Попробуйте сделать такое на Scala.
Не проблема: http://www.scalakata.com/509a5a9fe4b093f3524f3994

В скале нотация "(=> T)" в аргументах обозначает by-name.

[thesz.livejournal.com]

Согласен, прикольно. Чем-то Алгол-68 напоминает.

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

[metaclass.livejournal.com]

Да, он не мемоизируется, да и мутабельность там везде, много не намемоизируешь.

[isorecursive.livejournal.com]

@ Алгол-68
Почему-то рассмешило.

@ Как я понимаю, call-by-name аргумент будет вычислен столько раз, сколько мы его будем использовать?
Ну да, потому и by-name.
Кстати, только что придумал как на implicit-конверсиях сделать by-need!
Конечно, оверхед по производительности побольше чем в хаскеле, но по выразительности - нулевой!

[valentin budaev (from livejournal.com)]

> Если вы не знали, то вот вам пример (я уж задолбался его приводить):

Такой if в любом языке пишется, достаточно будет обернуть аргументы в delay. С другой стороны, в хаскеле нельзя реализовать свой begin - он в хаскеле встроен (и называется case). То есть в хаскеле приходится руками оборачивать выражения в force. Это известная эквивалентность ленивого и энергичного порядка. На языке теорката она выражается в том, что в категории соответствующей ленивому порядку нету сумм, а в категории, соответствующей энергичному порядку - произведений, т.о. полученные категории дуальны.

[thesz.livejournal.com]

В принципе, вы подтвердили мою мысль, но не до конца. Важно количество обёрток.

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

[valentin budaev (from livejournal.com)]

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

[metaclass.livejournal.com]

А что будет, если есть два импортированных класса с операторами &&& и implicit-конверсией - какой из них используется в этом случае?

[isorecursive.livejournal.com]

Если подходит первый (по типами и сигнатуре), то он, если нет - будет попытка использовать конверсию.
И это, наверное, самый сложный и хитрый момент в имплицитных конверсиях. По мне, лучше воздерживаться от них, и использовать только обогащения (новые implicit class, но их пока нет на scalakata), и только такие, которые не создают конфликтов имён.
И самое плохое в имплицитных конверсиях, что люди думают, будто имплицитные значения (type-directed скоупинг) - что-то близкое по духу, и тоже стрёмное.

[xeno-by.livejournal.com]

+1 про implicit vals

[xeno-by.livejournal.com]

Если подходят оба, будет ошибка компиляции.

[thesz.livejournal.com]

Язык Ада, в прямом и переносном смысле этого слова. В Аде точно такие же правила.

[xeno-by.livejournal.com]

В переносном смысле вы имеете ввиду, что это что-то плохое?

[thesz.livejournal.com]

Да.

Я писал разбор VHDL и писал на нем самом. VHDL это суперсет первой Ады.