Я не знаю, что такое MINA, но я посмотрел, что такое Netty: "an asynchronous event-driven network application framework" (http://www.jboss.org/netty/)
Прошу прощения, но это натурально не имеет смысла в случае ghc. В GHC RTS весь ввод-вывод асинхронный, на событиях. В этом смысле сеть ничем не отличается от других действий по вводу-выводу.
>Хотя бы на уровне эрланговских инструменты для распарсивания протоколов, буферизации, комбинаторы для построения сообщений?
Пожалуйста, ознакомьтесь с текущим положением дел в мире Хаскеля. Там всё не так плохо, как вы себе представляете. И коль уж зашла речь про понимание, то по-моему мнению, вы не представляете себе, насколько в мире Scala плохо.
Простой пример. Хочу попросить вас посмотреть вот на этот тип: http://hackage.haskell.org/packages/archive/containers/0.5.0.0/doc/html/src/Data-IntMap-Base.html#IntMap
Вот он, чтобы далеко не ходить:
-- See Note: Order of constructors
data IntMap a = Bin {-# UNPACK #-} !Prefix {-# UNPACK #-} !Mask !(IntMap a) !(IntMap a)
| Tip {-# UNPACK #-} !Key a
| Nil
type Prefix = Int
type Mask = Int
type Key = Int
Какой размер будет у значения конструктора Tip в случае реализации этого типа на Scala? Моя прикидка - 5 слов (3 слова на VMT, ключ и указатель на данные + два слова на заголовок объекта). В случае Хаскеля - три слова: тэг, ключ и указатель на значение.
Для IntSet, построенного по той же схеме, но без значений (два слова на конструктор Tip), лишних данных будет ещё больше, вроде, 100% лишнего.
Это я к тому, что большими объёмами символьных вычислений на Scala пользоваться.менее выгодно, чем практически возможно, а мой опыт говорит, что символьные вычисления чрезвычайно практичны в самых разных областях.
(no subject)
9/7/12 10:53 (UTC)Прошу прощения, но это натурально не имеет смысла в случае ghc. В GHC RTS весь ввод-вывод асинхронный, на событиях. В этом смысле сеть ничем не отличается от других действий по вводу-выводу.
>Хотя бы на уровне эрланговских инструменты для распарсивания протоколов, буферизации, комбинаторы для построения сообщений?
binary package: http://hackage.haskell.org/package/binary-0.5.0.1
Пожалуйста, ознакомьтесь с текущим положением дел в мире Хаскеля. Там всё не так плохо, как вы себе представляете. И коль уж зашла речь про понимание, то по-моему мнению, вы не представляете себе, насколько в мире Scala плохо.
Простой пример. Хочу попросить вас посмотреть вот на этот тип: http://hackage.haskell.org/packages/archive/containers/0.5.0.0/doc/html/src/Data-IntMap-Base.html#IntMap
Вот он, чтобы далеко не ходить: Какой размер будет у значения конструктора Tip в случае реализации этого типа на Scala? Моя прикидка - 5 слов (3 слова на VMT, ключ и указатель на данные + два слова на заголовок объекта). В случае Хаскеля - три слова: тэг, ключ и указатель на значение.
Для IntSet, построенного по той же схеме, но без значений (два слова на конструктор Tip), лишних данных будет ещё больше, вроде, 100% лишнего.
Это я к тому, что большими объёмами символьных вычислений на Scala пользоваться.менее выгодно, чем практически возможно, а мой опыт говорит, что символьные вычисления чрезвычайно практичны в самых разных областях.