Разработчики из Google начали делать Noop — новый язык для JVM. Часть компилятора написана на Scala.
Noop says Yes to
* Dependency injection in the language
* Testability — a seam between every pair of classes
* Immutability
* Readable code is more important than any syntax feature
* Executable documentation that's never out-of-date
* Properties, strong typing, and sensible modern stdlib
Здравствуйте, LaptevVV, Вы писали:
N>>Разработчики из Google начали делать Noop — новый язык для JVM. Часть компилятора написана на Scala.
LVV>Пока нет документа с описанием языка — сложно что-то сказать.
Здравствуйте, jenyavb, Вы писали:
J>Здравствуйте, nikov, Вы писали:
N>>Разработчики из Google начали делать Noop — новый язык для JVM. Часть компилятора написана на Scala.
J>Гораздо интереснее то, чему Noop говорит "нет": J>
J>
Implementation inheritance (subclassing)
вместо наследования будет поддержка композиции (агрегации) ProposalForComposition
с претензией на оригинальность
Здравствуйте, nikov, Вы писали:
N>Разработчики из Google начали делать Noop — новый язык для JVM. Часть компилятора написана на Scala.
N>[q] N>Noop says Yes to
N>* Dependency injection in the language N>* Testability — a seam between every pair of classes N>* Immutability
Боюсь, получится еще один хаскель. Тотальная иммутабельность до добра не доводит.
По-моему, Scala — самый разумный на сегодняшний день выбор. Она поддерживает ФП в той же степени, что и Хаскель, при этом оставляя место и другим парадигмам. По-большому счету, для большинства задач и явы хватало, скала — просто более хорошая, новая ява, а больше ничего и не нужно.
Социализм — это власть трудящихся и централизованная плановая экономика.
Здравствуйте, LaPerouse, Вы писали:
LP>По-моему, Scala — самый разумный на сегодняшний день выбор. Она поддерживает ФП в той же степени, что и Хаскель, при этом оставляя место и другим парадигмам. По-большому счету, для большинства задач и явы хватало, скала — просто более хорошая, новая ява, а больше ничего и не нужно.
В общем-то я согласен. После того как усилиями Adriaan Moors в Scala были добавлены higher-kinded types, в ней стало возможно эмулировать почти все возможности стандартных Haskell type classes. Не хватает только возможности условной реализации классов (например, список является Ordered, если элементы являются Ordered).
Ну и еще не хватает поддержки rank-N polymorphism на уровне языка (хотя его можно эмулировать).
Здравствуйте, nikov, Вы писали:
N>Здравствуйте, LaPerouse, Вы писали:
LP>>По-моему, Scala — самый разумный на сегодняшний день выбор. Она поддерживает ФП в той же степени, что и Хаскель, при этом оставляя место и другим парадигмам. По-большому счету, для большинства задач и явы хватало, скала — просто более хорошая, новая ява, а больше ничего и не нужно.
N>Не хватает только возможности условной реализации классов (например, список является Ordered, если элементы являются Ordered).
Не можешь объяснить, как такое возможно? Поддерживает ли данный элемент интерфейс Ordered или нет — это же информация времени выполенения. Наверное, это какой-то навороченный instanceof с диспетчеризацией внутри класса?
N>Ну и еще не хватает поддержки rank-N polymorphism на уровне языка (хотя его можно эмулировать).
Боюсь справшивать что это такое, ну да ладно, вроде жили без него, проживем и далее
Социализм — это власть трудящихся и централизованная плановая экономика.
Здравствуйте, LaPerouse, Вы писали:
N>>Не хватает только возможности условной реализации классов (например, список является Ordered, если элементы являются Ordered).
LP>Не можешь объяснить, как такое возможно? Поддерживает ли данный элемент интерфейс Ordered или нет — это же информация времени выполенения. Наверное, это какой-то навороченный instanceof с диспетчеризацией внутри класса?
Ну как в хаскеле:
instance (Ord a) => Ord (Tree a) where
(Leaf _) <= (Branch _) = True
(Leaf x) <= (Leaf y) = x <= y
(Branch _) <= (Leaf _) = False
(Branch l r) <= (Branch l' r') = l == l' && r <= r' || l <= l'
Можно создавать Tree, для элементов которых не определен инстанс класса Ord, тогда и для деревьев он не будет определен. А если создадим Tree, элементы которого поддерживают Ord, то сразу получаем возможность упорядочивать и сами деревья. ИМХО, в Scala такое не возможно.
N>>Ну и еще не хватает поддержки rank-N polymorphism на уровне языка (хотя его можно эмулировать). LP>Боюсь справшивать что это такое, ну да ладно, вроде жили без него, проживем и далее
Ну, проще говоря, это возможность передать куда-то функциональное значение, представляющее generic метод, и уже там, куда мы его передали, вызвать этот метод с разными типами-аргументами. Сейчас в Scala для этого нужно создавать специальный класс-обертку для такого функционального значения (здесь). А существующие расширения хаскеля поддерживают это на уровне языка.
Общее ощущение от прочитанного — товарищи нашли фатальный недостаток в Яве... ну, вы поняли какой...
Мое мнение — бредовая затея. Цели мутные. Полное ощущение, что люди живут в мире Явы и поняли что в ней что-то в ней не так, но что так и не поняли, так что пытаются прилепить к ней разные "нужные" вещи вроде ослиного хвоста и ластов.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, nikov, Вы писали:
N>В общем-то я согласен. После того как усилиями Adriaan Moors в Scala были добавлены higher-kinded types, в ней стало возможно эмулировать почти все возможности стандартных Haskell type classes.
А можно на пальцах объяснить — что это такое и с чем едят?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
N>>В общем-то я согласен. После того как усилиями Adriaan Moors в Scala были добавлены higher-kinded types, в ней стало возможно эмулировать почти все возможности стандартных Haskell type classes.
VD>А можно на пальцах объяснить — что это такое и с чем едят?
Представь, что у тебя есть такая задача:
Есть много generic коллекций: List, LinkedList, Tree и т.д.
У всех этих коллекций есть generic метод Map[S], принимающий функцию, применяющий ее ко всем элементам коллекции и возвращающий коллекцию, имеющую тот же тип контейнера, но другой тип элементов.
Например, у типа List[T] этот метод будет иметь сигнатуру (T -> S) -> List[S], у LinkedList — сигнатуру (T -> S) -> LinkedList[S] и т.д. (пишу на псевдо-коде).
Теперь, тебе надо написать функцию Map0, которая будет абстрагироваться от конкретного типа коллекции, и вызывать у нее метод Map, передав ей функцию (_ -> 0), которая устанавливает все элементы коллекции в 0. Для этого все коллекции должны реализовывать общий интерфейс с методом Map. Но вот беда: в рамках обычных дженериков C#, Nemerle или Java такого не сделать — у методов Map совершенно разные сигнатуры. Здесь-то как раз и нужны higher-kinded types, то есть дженерики, у которых типы-параметры могут в свою очередь свои типы параметры. Тогда сигнатура метода Map будет такая (опять псевдо-код):
Тип-параметр TCollection — высшего порядка, потому что он декларирует наличие у него собственных типов-параметров (их имена обычно не важны, поэтому пишется _). При инстанциации типа IMapableCollection вместо TCollection должен быть передан generic тип, имеющий один обычный тип-праметр, без типа-аргумента.
Более подробно читать диссертацию Adriaan Moors, его статьи, или Scala Language Specification.
В Haskell аналогичная задача решается классом типов Functor с функцией fmap.
Здравствуйте, nikov, Вы писали:
N>Здесь-то как раз и нужны higher-kinded types, то есть дженерики, у которых типы-параметры могут в свою очередь свои типы параметры.
Здесь-то как раз и нужны higher-kinded types, то есть дженерики, у которых типы-параметры могут в свою очередь иметь свои типы параметры.
Надо добавить, что в Scala, кроме того, что обычные типы параметры могуть иметь upper и lower констрейнты (последние нужны в некоторых сценариях с контравариантностью), типы-параметры высших порядков тоже могут иметь констрейнты, и их собственные типы-параметры (которые, кстати, тоже могут быть высшего порядка!) тоже могут иметь констрейнты. Причем любой из этих типов параметров может быть как инвариантным, так и ко- или контравариантным, причем не только в трейтах(интерфейсах), но и в конкретных классах, а типы-параметры у типов-параметров высшего порядка — даже в методах.
Констрейнты в Scala называются bounds.
Пусть меня поправят специалисты, если я не прав, но по-моему, в Haskell нет никаких аналогов для подобных констрейнтов.
Здравствуйте, nikov, Вы писали:
N>Тип-параметр TCollection — высшего порядка, потому что он декларирует наличие у него собственных типов-параметров (их имена обычно не важны, поэтому пишется _). При инстанциации типа IMapableCollection вместо TCollection должен быть передан generic тип, имеющий один обычный тип-праметр, без типа-аргумента.
Три вопроса:
1. Нельзя ли выразить этот тип верхнего уровня через ограничение (констрэйн)?
2. Насколько это нужно на практике? Не является ли это наукой ради науки?
3. Как эта штука уживается с наличием типов-значений?
N>Более подробно читать диссертацию Adriaan Moors, его статьи, или Scala Language Specification. N>В Haskell аналогичная задача решается классом типов Functor с функцией fmap.
Аналог fmap можно получить средствами метапрограммирования.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, nikov, Вы писали:
N>...так и ко- или контравариантным, причем не только в трейтах(интерфейсах), но и в конкретных классах, а типы-параметры у типов-параметров высшего порядка — даже в методах.
Ну, дык у них все типы ссылочные по этому это реализуемо для всех типов. Плата за это — производительность при работе с влэль-типами и отсутствие составных влэлью-типов.
N>Констрейнты в Scala называются bounds.
N>Пусть меня поправят специалисты, если я не прав, но по-моему, в Haskell нет никаких аналогов для подобных констрейнтов.
Остается вопрос — зачем оно все нужно?
Хаскель мне не нравится в первую очередь своей перенавороченностью. Даже простые вещи в нем имеют ужасающее описание.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, nikov, Вы писали:
N>Я думаю, и поля и методы.
Ну поля — понятно, хотя уж больно фееричная перестраховка, а методы то чем помешали?
N> Наверное, будут делать, как в Scala — встроенные в язык singleton objects.
Не вникал подробно, но sigleton objects от проблем статических полей не избавляют
А вообще, как то по детски там у них все, имхо — ковыряются с мелочами, а на серьезные проблемы ответов не видно. Так языки лет 15-20 назад проектировали.
... << RSDN@Home 1.2.0 alpha 4 rev. 1237 on Windows 7 6.1.7100.0>>