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

[migmit.livejournal.com]

Умгум. Парочка ссылок:

уно) http://yz.mit.edu/wp/true-scala-complexity/
дос) http://www.reddit.com/r/haskell/comments/zxcks/haskell_vs_f_vs_scala_a_highlevel_language/c68ybn1

[xeno-by.livejournal.com]

Спасибо за примеры. Они неплохо подчеркивают то, что я хотел сказать, но не знал в каком контексте это представить.

Есть куча высказываний на тему "я попытался сделать в Скале как в Хаскелле и получилась какая-то фигня". Эти высказывания многими считаются критикой Скалы. Но в обратную сторону это почему-то не работает. "Я попытался сделать в Хаскелле трейты как в Скале и получилась какая-то фигня" - такого в интернетах не видел ни разу.

[migmit.livejournal.com]

Ну, собственно, и "я попытался сделать в C++ как в Хаскелле и получилась какая-то фигня" тоже предостаточно, а вот наоборот - не видел.

[xeno-by.livejournal.com]

И какой следует вывод?

[thesz.livejournal.com]

Видимо, что у Хаскеля с типами получше будет?

[xeno-by.livejournal.com]

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

[xeno-by.livejournal.com]

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

От тайп инференса пришлось отказаться (см. отличные примеры с обоснованием вот тут: http://groups.google.com/group/scala-language/msg/c26eb3bd7aa58817) ради смешивания ООП и ФП. В результате можно делать вот такие вещи: https://www.precog.com/blog-precog-2/entry/existential-types-ftw. Для меня неочевидно, что этот трейдофф проигрышный.

[thesz.livejournal.com]

Я внимательно прочитал ваши ссылки.

Честное слово, после чтения я пришёл к выводу, что я стал очень далёк от OO. Я даже не понимаю формулировки проблемы, которые могут привести к таким решениям, что уж говорить про сами решения.

Во второй (которая FTW) есть хотя бы список успехов. Но таким списком я бы гордился году в 2008, примерно. Сейчас это обычное дело в проекте на Хаскеле.

[isorecursive.livejournal.com]

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

[thesz.livejournal.com]

Что такое programming in large?

Могут ли модули быть заменены записями? (подсказка: Cayenne)

[isorecursive.livejournal.com]

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

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

[thesz.livejournal.com]

Да, ещё вот, что надо заметить. Вот в этой статье https://www.precog.com/blog-precog-2/entry/existential-types-ftw есть список успехов: "Limited-to-no "classical" OO", "Most-Specific type at the "end of the world"" и т.д.

Я про эти успехи говорил.

[migmit.livejournal.com]

Что Scala находится примерно на уровне C++.

[xeno-by.livejournal.com]

Ок

[isorecursive.livejournal.com]

А я видел. Человек пытался воспроизвести на тайпклассах какие-то темплейт-трюки с перегрузками по аргументам и результату, и проверкой размерностей, для какой-то хитрой обобщённой матрично-векторной арифметики. Чем закончилось, не знаю, но товарищ был недоволен.
Мне в хаскеле от скалы хотелось бы хотя-бы имплициты (ни в коем случае не динамический скоупинг по имени, с которым их путают, как в уже присутствующем расширении implicit parameters!), но без конверсий - а только в качестве управляемого type-directed скоупинга, для того, чтобы не протаскивать постоянно конфигурации в монадах, для замены тайпклассов, и для удобного proof-carrying, если захочется что-нибудь такое в духе агды писать.

[udpn.livejournal.com]

Ну в Haskell нет расширяемых ADT, а в С++ есть наследование, например. Об этом ребе M E@G+ частенько напоминает. А на С++ с Haskell всё переводится отлично, особенно теперь, с С++11.

[migmit.livejournal.com]

> Ну в Haskell нет расширяемых ADT, а в С++ есть наследование, например.

Легко эмулируется через классы и RankNTypes.

> А на С++ с Haskell всё переводится отлично, особенно теперь, с С++11.

Что, C++11 наконец-то научился не ограничивать при компиляции количество типов в рантайме?

[udpn.livejournal.com]

>> Легко эмулируется через классы и RankNTypes.
Расширьте мне data Bool = True | False на ещё один конструктор Uncertain. Библиотечный код не должен пострадать.
Или расширьте data Point a = Point { x : a, y : a } на z : a.
Или определите два trait'а с абстрактными типами a la Scala.

>> не ограничивать при компиляции количество типов в рантайме
Каких типов в рантайме? WTF?

[migmit.livejournal.com]

> Расширьте мне data Bool = True | False на ещё один конструктор Uncertain. Библиотечный код не должен пострадать.

Я правильно понял, вы научились в C++ наследоваться от bool?

> Или расширьте data Point a = Point { x : a, y : a } на z : a.

Я что, обещал расширять типы, на расширение не рассчитанные?

> Каких типов в рантайме? WTF?

Ну блин, вы же видели мой пост в ЖЖ. http://migmit.livejournal.com/32688.html

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

[udpn.livejournal.com]

>> Я правильно понял, вы научились в C++ наследоваться от bool?
ADT Bool в С++: http://ideone.com/00TLJc
Сast-constructor и implicit cast для Bool <-> bool добавить для пущей убедительности?
>> нет расширяемых ADT
>> Легко эмулируется через классы и RankNTypes.
>> data Point a = Point { x : a, y : a } на z : a.
>> Я что, обещал расширять типы, на расширение не рассчитанные?
[когнитивный диссонанс]
Подразумевается, что я сейчас побегу заменять ADT на композируемую систему классов типов с геттерами и сеттерами, сдабривать это Template Haskell поверх для преобразования ADT<>TC и создания инстансов, и всё это ради того, чтобы в Haskell у меня появилась вещь, которая есть в С++, O'Caml и Scala by design и никаких сложностей не вызывает?
>> Ну блин, вы же видели мой пост в ЖЖ. http://migmit.livejournal.com/32688.html
Ну таки там у вас ошибка, полиморфная рекурсия. Она накладывается на ошибку языка: дженерики, которые не подлежат type erasure.

UPD Единственная известная мне система, где полиморфная рекурсия тайпчекается, это исчисление Милнера-Майкрофта, для которого, походу, ещё даже нет доказательства разрешимости тайпчека.

[migmit.livejournal.com]

> ADT Bool в С++

То есть, нет. Ясно.

> Подразумевается, что я сейчас побегу заменять ADT на композируемую систему классов типов с геттерами и сеттерами, сдабривать это Template Haskell поверх для преобразования ADT<>TC и создания инстансов, и всё это ради того, чтобы в Haskell у меня появилась вещь, которая есть в С++, O'Caml и Scala by design и никаких сложностей не вызывает?

Конечно, нет. Это вещь редко нужная, и вам, скорее всего не понадобится.

А Template Haskell - бяка.

> Ну таки там у вас ошибка, полиморфная рекурсия.

> Единственная известная мне система, где полиморфная рекурсия тайпчекается, это исчисление Милнера-Майкрофта, для которого, походу, ещё даже нет доказательства разрешимости тайпчека.

Странно, в Java пример тайпчекается, в C# тайпчекается, в Haskell тайпчекается. А вот во всяких сишечках, с плюсами и без - ну никак.

> ошибку языка: дженерики, которые не подлежат type erasure.

Ну, вот в C# нет type erasure, а пример в шарпе работает.

[sum-erman.livejournal.com]

Я, как человек не слишком искушённый, совершено не понимаю когда использовать object, когда class, когда abstract class, когда trait, когда наследоваться, когда расширять прямо в new %) Что характерно скала-курс перед подобным выбором не ставит :)

[udpn.livejournal.com]

object нужен для объявлений переменных.
object с таким же именем, как и trait, нужен для static.
abstract class + case classes нужны для расширяемых ADT (которых в Х-е нет) aka Composite pattern по GoF.
class+traits это основной способ сборки программ на Scala, посредством cake pattern. Суть простая: создаём много trait в качестве строительных единиц класса. В С++ trait известны как "стратегии Александреску". Наследование классом A трейта B в С++ выглядит как class A : B (да, CRTP).

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

[xeno-by.livejournal.com]

объекты еще нужны для имплиситов - они могут как сами выступать в роли инстансов тайп классов, так и быть контейнерами для имплиситов

[udpn.livejournal.com]

Чёртов ЖЖ, сожрал тег и не могу отредактировать.

Там A : B<A>