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

[thesz.livejournal.com]

Да. Separation of concerns. Не переводить же эту фразу, как "разделение беспокойств" или "разделение интересов".

[xeno-by.livejournal.com]

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

[isorecursive.livejournal.com]

@ Что такое programming in large?
Что-то такое, но я подразумевал только systems-design/architecture-часть, безотносительно менеджмента.

@ Могут ли модули быть заменены записями?
Иногда могут, иногда нет - в зависимости от того, о каких модулях и каких записях речь.
На фундаментальном уровне все эти концепции крутятся вокруг типов-произведений, экзистенциальных типов, и сабтайпинга.
Для первого приближения я себе выработал такие соответствия:
непараметризуемые модули - это приблизительно то же самое (~), что и неймспейсы;
параметризуемые модули ~ записи, умеющие содержать те же виды деклараций, что и нечто, соответствующее обычным модулям в данном языке (где сами эти записи декларируются, например);
параметризуемые модули с сабтайпингом ~ классы в ООП.
Такие аналогии классов и записей с модулями лучше чувствуются в языках, где можно импортировать начинку экземпляров записей (Agda, Cayenne) и классов (Scala) в текущий скоуп.

[thesz.livejournal.com]

В ленивости?

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

[xeno-by.livejournal.com]

Понятно.

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

[thesz.livejournal.com]

>programming in the large

А. Разбиение на компоненты и архитектура.

Архитектура (на высоком уровне) не зависит от языка программирования. Название и назначение блоков без их детализации не меняются при смене ЯП.

Организация взаимодействия между компонентами от языка зависит и здесь Хаскель выигрывает. Ибо подключение компонент к архитектуре является (!) programming in the small. Это просто очередная библиотека.

>Записи

Добавьте к записи один параметр типа и одно поле, и получите всё, что угодно, вплоть до перегрузки и подтипизации.

[thesz.livejournal.com]

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

[isorecursive.livejournal.com]

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

[thesz.livejournal.com]

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

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

[metaclass.livejournal.com]

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

[isorecursive.livejournal.com]

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

@ Организация взаимодействия между компонентами от языка зависит и здесь Хаскель выигрывает.
А мне кажется, существенно проигрывает, причём даже всяким Java. И проблема как-раз в том, что в хаскеле самый большой вещественный компонент - запись, но они неудобные, неоткрываемые, не могут содержать внутри объявления типов и т.д. А в java самый большой вещественный компонент - параметризуемый модуль (класс) с операцией обратно-совместимого расширения (наследование). Вот взаимодействие между маленькими компонентами - это (по-моему) самая сильная сторона хаскеля, для таких вещей в нём поддерживается огромное количество клея (от обычной функциональной композиции до стрелочной, от функций высшего порядка до категорных паттернов структурно-констекстуального взаимодействия). Но эти маленькие компоненты - это внутренности подсистем, а большие компоненты - сами подсистемы, и их взаимодействия, в хаскеле напрочь неовеществлены.

@ Добавьте к записи один параметр типа и одно поле
Можно и без записей обойтись - одними туплами. Вместо имён компонент - функции-селекторы.
Если не хочется структурного сабтайпинга - ньютайп-врапперы для номинативности.

[isorecursive.livejournal.com]

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

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

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

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

[isorecursive.livejournal.com]

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

[thesz.livejournal.com]

>А мне кажется, существенно проигрывает, причём даже всяким Java.

Expression problem, идеализированная проблема расширения программы. Сравните решения на Хаскеле и других ЯП.

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

Неправда ваша. От MRef/IORef до каналов и (теперь уже) до Cloud Haskell.

[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]

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

[xeno-by.livejournal.com]

+1 про implicit vals

[xeno-by.livejournal.com]

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

[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 аргумент будет вычислен столько раз, сколько мы его будем использовать?

[thesz.livejournal.com]

Интересно.

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

[metaclass.livejournal.com]

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

[thesz.livejournal.com]

Тогда я останусь при моём Хаскеле без макросов.

[isorecursive.livejournal.com]

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

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