Здравствуйте, AndrewVK, Вы писали:

AVK>А вообще, как то по детски там у них все, имхо — ковыряются с мелочами, а на серьезные проблемы ответов не видно.

А вот интересно, на что ты обратил бы внимание, если бы сейчас проектировал высокоуровневый язык общего назначения.

Здравствуйте, VladD2, Вы писали:

VD>Три вопроса:
VD>1. Нельзя ли выразить этот тип верхнего уровня через ограничение (констрэйн)?
Не совсем понял вопрос, но скажу, что более простыми средствами эта проблема не решается, если мы хотим иметь безопасность типов во время компиляции (то есть отсутствие явных приведений типа).

VD>2. Насколько это нужно на практике? Не является ли это наукой ради науки?
Конечно, нужно. Сейчас вся стандартная библиотека коллекций в Scala переделана, чтобы использовать эту возможность. В общем-то, это очень естественная вещь: мы можем абстрагироваться от типа элементов коллекции, и можем абстрагироваться от типа контейнера. Можно привести кучу примеров, где это нужно. Например, мы уже имеем методы Map и Filter, и хотим написать MapFilter[S] : (T -> Option[S]) -> List[S], который бы применял данную функцию ко всем элементам, и те элементы, для которых она возвращает None, выбрасывал, а те, для которых возвращается Some(obj) — извлекал оттуда obj и помещал его в результирующую коллекцию. В Scala мы можем написать этот код один раз и он будет работать для любых коллекций, причем возвращать не базовый тип наподобие IEnumerable[S], а ту коллекцию, которую нужно.

VD>3. Как эта штука уживается с наличием типов-значений?
Нормально. В Scalа примитивные типы являются типами-значениями, и в отличие от Java, их можно использовать как типы-аргументы.

Здравствуйте, nikov, Вы писали:

N>А вот интересно, на что ты обратил бы внимание, если бы сейчас проектировал высокоуровневый язык общего назначения.

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

Вот как выглядит настоящая Scala, а не псевдо-код:

trait Collection[TContainer[_], T] {
    def Convert[S](f : T => S) : TContainer[S]
    def Filter(p : T => Boolean) : TContainer[T]
}

class List[T] extends Collection[List, T] {
    def Convert[S](f : T => S) : List[S] = { /* ... */ }
    def Filter(p : T => Boolean) : List[T] = { /* ... */ }
}

class LinkedList[T] extends Collection[LinkedList, T] {
    def Convert[S](f : T => S) : LinkedList[S] = { /* ... */ }
    def Filter(p : T => Boolean) : LinkedList[T] = { /* ... */ }
}

object Program {
    def ConvertAndFilter[TContainer[X] <: Collection[TContainer, X], T](coll : TContainer[T], f : T => Int) : TContainer[Int] = { 
        coll.Convert(f).Filter(_ > 0) 
    }
    
    def Foo() : List[Int] = {
       val list = new List[String]
       ConvertAndFilter[List,String](list, _ => 2) // здесь почему-то не выводятся типы-аргументы
    }
}

Здравствуйте, nikov, Вы писали:

VD>>3. Как эта штука уживается с наличием типов-значений?
N>Нормально. В Scalа примитивные типы являются типами-значениями, и в отличие от Java, их можно использовать как типы-аргументы.

Насколько я знаю это не так. Вэлью-типы тупо оборачиваются (боксятся).

Здравствуйте, AndrewVK, Вы писали:

AVK>Здравствуйте, nikov, Вы писали:

N>>А вот интересно, на что ты обратил бы внимание, если бы сейчас проектировал высокоуровневый язык общего назначения.

AVK>Это очень сложный вопрос. Во-первых требований очень много, во-вторых у каждого свои задачи, и свои приоритеты. Но если говорить о том, о чем здесь мало спорят — наверное обратил бы внимание на технологичность процесса разработки на этом языке.
Тут одного языка мало — нужно разрабатывать сразу среду с языком.
Оригинальный подход к среде с языком сделали Виртовские ученики — разработка BlackBox очень не стандартна.

Здравствуйте, LaptevVV, Вы писали:

LVV>Тут одного языка мало — нужно разрабатывать сразу среду с языком.

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

Здравствуйте, LaptevVV, Вы писали:

LVV>Оригинальный подход к среде с языком сделали Виртовские ученики — разработка BlackBox очень не стандартна.
Интересно, чего в ней вообще есть нестандартного?

Здравствуйте, LaptevVV, Вы писали:

LVV>Тут одного языка мало — нужно разрабатывать сразу среду с языком.
LVV>Оригинальный подход к среде с языком сделали Виртовские ученики — разработка BlackBox очень не стандартна.

Это что же там нового появилось?

Здравствуйте, AndrewVK, Вы писали:

AVK>наверное обратил бы внимание на технологичность процесса разработки на этом языке.

Это очень расплывчато.

Здравствуйте, VladD2, Вы писали:

VD>Это очень расплывчато.

Для раскрытия нужна масса времени.

Здравствуйте, nikov, Вы писали:

N>Пусть меня поправят специалисты, если я не прав, но по-моему, в Haskell нет никаких аналогов для подобных констрейнтов.

Потому что в Haskell нет наследования?

Здравствуйте, lomeo, Вы писали:

N>>Пусть меня поправят специалисты, если я не прав, но по-моему, в Haskell нет никаких аналогов для подобных констрейнтов.

L>Потому что в Haskell нет наследования?

Ну, определенная форма наследования — для классов типов, всё таки есть.
Кроме того, некое подобие приведения к базовому типу предоставляют экзистенциальные типы (но это уже нестандартный Haskell).

Здравствуйте, LaPerouse, Вы писали:

LP>Здравствуйте, 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

LP>Боюсь, получится еще один хаскель. Тотальная иммутабельность до добра не доводит.

У полумер это получается чаще.

LP>По-моему, Scala — самый разумный на сегодняшний день выбор. Она поддерживает ФП в той же степени, что и Хаскель

Три раза "ХА!".

LP>при этом оставляя место и другим парадигмам. По-большому счету, для большинства задач и явы хватало, скала — просто более хорошая, новая ява, а больше ничего и не нужно.

Явы не хватает ни для какой задачи, вообще. Если, конечно, имеешь представление о тех же ОКамле с Хаскелем.

Я тут имею возможность сравнивать производительность одного и того же программиста на хорошо ему знакомой Яве и на малознакомом Хаскеле.

Сравнение явно не в пользу Явы.

Здравствуйте, nikov, Вы писали:

N>Здравствуйте, LaPerouse, Вы писали:

LP>>По-моему, Scala — самый разумный на сегодняшний день выбор. Она поддерживает ФП в той же степени, что и Хаскель, при этом оставляя место и другим парадигмам. По-большому счету, для большинства задач и явы хватало, скала — просто более хорошая, новая ява, а больше ничего и не нужно.

N>В общем-то я согласен. После того как усилиями Adriaan Moors в Scala были добавлены higher-kinded types, в ней стало возможно эмулировать почти все возможности стандартных Haskell type classes. Не хватает только возможности условной реализации классов (например, список является Ordered, если элементы являются Ordered).

Иными словами, higher-kinded types не позволяют эмулировать даже базовые возможности классов типов Хаскеля.

Тем временем Хаскель ушёл ещё дальше.

N>Ну и еще не хватает поддержки rank-N polymorphism на уровне языка (хотя его можно эмулировать).

И GADT.

Здравствуйте, nikov, Вы писали:

N>Здравствуйте, nikov, Вы писали:

N>>Здесь-то как раз и нужны higher-kinded types, то есть дженерики, у которых типы-параметры могут в свою очередь свои типы параметры.
N>Здесь-то как раз и нужны higher-kinded types, то есть дженерики, у которых типы-параметры могут в свою очередь иметь свои типы параметры.

N>Надо добавить, что в Scala, кроме того, что обычные типы параметры могуть иметь upper и lower констрейнты (последние нужны в некоторых сценариях с контравариантностью), типы-параметры высших порядков тоже могут иметь констрейнты, и их собственные типы-параметры (которые, кстати, тоже могут быть высшего порядка!) тоже могут иметь констрейнты. Причем любой из этих типов параметров может быть как инвариантным, так и ко- или контравариантным, причем не только в трейтах(интерфейсах), но и в конкретных классах, а типы-параметры у типов-параметров высшего порядка — даже в методах.

N>Констрейнты в Scala называются bounds.

N>Пусть меня поправят специалисты, если я не прав, но по-моему, в Haskell нет никаких аналогов для подобных констрейнтов.

Классы типов.

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

Эти границы нужны при наличии наследования (отношения < (вложенность, или подстановочность, или как там оно называется) между типами). Если наследования типов нет, то и границы не нужны.

Хотя, с другой стороны, мы можем обеспечить работу в пересечении ограничений, (Lower a, Upper a) => ...

В общем и целом, система типов Хаскеля Тьюринг-полна и там можно выразить всё, что угодно.

Здравствуйте, nikov, Вы писали:

L>>Потому что в Haskell нет наследования?
N>Ну, определенная форма наследования — для классов типов, всё таки есть.

Я так понял, что речь шла о наследовании типов всё же.

Ладно, тогда другой вопрос — чего ты хочешь добиться в рамках Хаскельных типов? Т.е. что будут означать констрейнты?
Пример из scala

trait Function1[-T1, +R]

Что будет означать в рамках Хаскеля, где нет наследования типов, эти — и +?

N>Кроме того, некое подобие приведения к базовому типу предоставляют экзистенциальные типы (но это уже нестандартный Haskell).

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

Здравствуйте, Cyberax, Вы писали:

C>Здравствуйте, LaptevVV, Вы писали:

LVV>>Оригинальный подход к среде с языком сделали Виртовские ученики — разработка BlackBox очень не стандартна.
C>Интересно, чего в ней вообще есть нестандартного?
Среда — замкнутая. Для инженеров, вынужденных программировать, самое оно.
Любой модуль созданный в рамках среды, включается в среду. Вплоть до возможности прописывания данного модуля в меню. Таким образом, можно полностью сделать среду под свои задачи — на том же языке, на котором сами задачи пишутся.
Например, мне нужно специализированный редактор сделать, я реализую отдельный модуль, и он у меня лежит в системе и работает, когда я его вызываю. Модуль играет роль и компонента и DLL одновременно.
Окно с текстом — это не элементарный текст программы как в Блокноте.
Мне, например, очень импонирует, что я в одном и том же окне пишу текст лекции и тут же в этом же тексте пишу программу, которую могу оттранслировать и тут же запустить. Исходные данные для этой проги я могу тут же в этом же окне прописать — и прога их возьмет как входной файл (или как параметры командной строки — в данном случае неважно).

И кроме всего прочего, у меня, естественно, имеется возможность выйти из среды в том смысле, что либо подключить стороннюю DLL, либо создать свою собственную DLL для работы без среды в Windows. Можно и exe-модуль создать и работать независимо от среды.
В общем, мне как преподу она очень импонирует.

Здравствуйте, LaptevVV, Вы писали:

LVV>>>Оригинальный подход к среде с языком сделали Виртовские ученики — разработка BlackBox очень не стандартна.
C>>Интересно, чего в ней вообще есть нестандартного?
LVV>Среда — замкнутая. Для инженеров, вынужденных программировать, самое оно.
Не ново. См.: "Smalltalk", "Lisp" (в Симболиксах, к примеру).

LVV>Любой модуль созданный в рамках среды, включается в среду. Вплоть до возможности прописывания данного модуля в меню. Таким образом, можно полностью сделать среду под свои задачи — на том же языке, на котором сами задачи пишутся.
См.: "Smalltalk".

LVV>Мне, например, очень импонирует, что я в одном и том же окне пишу текст лекции и тут же в этом же тексте пишу программу, которую могу оттранслировать и тут же запустить. Исходные данные для этой проги я могу тут же в этом же окне прописать — и прога их возьмет как входной файл (или как параметры командной строки — в данном случае неважно).
См.: "Smalltalk".

Эти подходы были известны задооооооооолго до Оберона. В частности, есть до сих пор удобные обучающие среды типа Squeak с теми же принципами.

Здравствуйте, VladD2, Вы писали:

VD>Здравствуйте, LaptevVV, Вы писали:

LVV>>Тут одного языка мало — нужно разрабатывать сразу среду с языком.
LVV>>Оригинальный подход к среде с языком сделали Виртовские ученики — разработка BlackBox очень не стандартна.

VD>Это что же там нового появилось?
Насчет нового не знаю, я только в этом годе стал пользовать 1.5. Но народ ваяет 1.6 и переносит ее под Linux.