Наткнулся тут на статейку на реддит.ком. Речь идёт о том, что вот есть Скала для JVM, которая позволяет оперировать более высокими абстракциями, чем сама Java (к примеру кейс-классы с паттерн-матчингом, иммутабельность и пр.). Но есть и ещё перспективная вещь под названием CAL от BusinessObjects, компилирующаяся в Java-байткод, являющаяся ленивым чистым функциональным языком, с фичами haskell, где есть монады и функторы.
Серьёзно ещё не разбирался, но выглядит очень "вкусно".

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

К>Наткнулся тут на статейку на реддит.ком. Речь идёт о том, что вот есть Скала для JVM, которая позволяет оперировать более высокими абстракциями, чем сама Java (к примеру кейс-классы с паттерн-матчингом, иммутабельность и пр.). Но есть и ещё перспективная вещь под названием CAL от BusinessObjects, компилирующаяся в Java-байткод, являющаяся ленивым чистым функциональным языком, с фичами haskell, где есть монады и функторы.
К>Серьёзно ещё не разбирался, но выглядит очень "вкусно".

Это не потомок INTERCAL?

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

К>Наткнулся тут на статейку на реддит.ком. Речь идёт о том, что вот есть Скала для JVM, которая позволяет оперировать более высокими абстракциями, чем сама Java (к примеру кейс-классы с паттерн-матчингом, иммутабельность и пр.). Но есть и ещё перспективная вещь под названием CAL от BusinessObjects, компилирующаяся в Java-байткод, являющаяся ленивым чистым функциональным языком, с фичами haskell, где есть монады и функторы.
К>Серьёзно ещё не разбирался, но выглядит очень "вкусно"


у них буквально сегодня был анонс в haskell list. если коротко — это аналог хаскела без части syntax sugar. главное достоинство — это хороший уроень интеропа в явой. предполагается, что на этом языке будет писаться та самая бизнес-логика приложения, требующая сложных алгоритмов, а на яве можно делать GUI и тому подобное. на мой взгляд — очень полезный проект. жаль только, что они не сделали совместимость с хаскелом по синтаксису

Further to the seeding of the binary framework and SDK as announced on this
list last year, Business Objects is pleased to announce that the Open Quark
Framework for Java has now been released as open source under a BSD-style
license.

The Open Quark Framework for Java includes a language, CAL, similar in many
respects to Haskell, which is compiled to efficient byte code on the Java
platform. The purpose of Open Quark began, and remains, the ability to
conveniently mix logic expressed in a natural functional style with
'regular' Java code. Business Objects' interest in the functional paradigm
is that much of the logic to model complex data semantics and to express
data transformation is elegantly and reusably represented as pure functions.
This contrasts with the corpus of application logic that represents
workflow, UI, communications and storage, which is predominantly coded
directly in OO languages such as Java but with which the data logic must
interoperate. Despite the original motivations for the Quark Framework, CAL
is a completely general purpose non-strict functional language and suitable
for a broad range of applications.

We have made available a suite of documentation, included in the software
packages and separately downloadable. These documents should inform those
with both a casual interest in the project (and its similarities/differences
to Haskell) as well as those who wish to explore the language, SDK and tools
in more detail.

Open Quark can be downloaded, with or without sources from:
http://labs.businessobjects.com/cal
Unlike the previous 'seeding' regime, no registration is required to obtain
Open Quark.

Business Objects remains very active on the project and intends to set up
the necessary mechanisms to allow the community to contribute easily to the
project. While these arrangements will take a little longer, we are already
very happy to receive any/all comments, suggestions and contributions. A
discussion forum is already available for such activity (see the main web
page). A major priority for the immediate future is to deepen the Eclipse
integration in order to improve the convenience for developers using CAL.

Luke Evans
Chief Scientist, VP Research, Business Objects
_______________________________________________
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell

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

К>Наткнулся тут на статейку на реддит.ком. Речь идёт о том, что вот есть Скала для JVM, которая позволяет оперировать более высокими абстракциями, чем сама Java (к примеру кейс-классы с паттерн-матчингом, иммутабельность и пр.). Но есть и ещё перспективная вещь под названием CAL от BusinessObjects, компилирующаяся в Java-байткод, являющаяся ленивым чистым функциональным языком, с фичами haskell, где есть монады и функторы.
К>Серьёзно ещё не разбирался, но выглядит очень "вкусно".

Про ленивость и монады...
Вчера перечитывал новую версию ScalaByExample.
Так вот в Scala-е есть ленивость при передаче параметров:

Scala uses call-by-value by default,but it switches to call-by-name evaluation if the parameter type is preceded by =>

def loop: int = loop
def first(x: int, y: int) = x
first(1, loop) // Зацыклится
def constOne(x: int, y: => int) = 1
constOne(1, loop) // Все нормально
constOne(loop, 2) // Зацыклится

Насчет монад:

Есть Implicite передача параметров

Implicit parameters and conversions are powerful tools for custimizing existing li-
braries and for creating high-level abstractions.
Theprincipalideabehindimplicitparametersisthatargumentsforthemcanbeleft
out from a method call. If the arguments corresponding to an implicit parameter
sectionaremissing,theyareinferredbytheScalacompiler.

def sum[a](xs: List[a])(implicit m: Monoid[a]): a =
  if (xs.isEmpty) m.unit
  else m.add(xs.head, sum(xs.tail))

implicit object stringMonoid extends Monoid[String] {
  def add(x: String, y: String): String = x.concat(y)
  def unit: String = ""
}

implicit object intMonoid extends Monoid[int] {
  def add(x: int, y: int): int = x + y
  def unit: int = 0
}

sum(List(1, 2, 3))

Мне кажеться это что-то очень смахивает на монады...

M>Есть Implicite передача параметров
M>Мне кажеться это что-то очень смахивает на монады...

на одно из их применений. в целом монады — это способ определить >>=, т.е. механизм передачи управления. размножение общего параметра через цепочку вызовов — это лишь одна из монад. попробуй например через implicit параметры организовать парсинг с бэктрикингом или хотя бы монду List

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

BZ>на одно из их применений. в целом монады — это способ определить >>=, т.е. механизм передачи управления. размножение общего параметра через цепочку вызовов — это лишь одна из монад. попробуй например через implicit параметры организовать парсинг с бэктрикингом или хотя бы монду List

Если мы опять-таки обратимся к ScalaByExample — то буквально уже следующей после implicite параметров мы увидим главу Combinator Parsing, где в сокращенном виде приведено каким образом можно организовать этот парсинг...
Да... я еще подробно до этого места не дошел... так что не знаю есть ли там парсинг с бэктрикингом...

И во вторых, в чем преимущество реализации List-а через монады...

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

M>И во вторых, в чем преимущество реализации List-а через монады...

Преимущество то, что list comprehension естественным способом реализуется.

---

Но кстати, интересно. Представить монаду "одно неявное значение" — рядовому уму довольно просто. Вне зависимости от характера такого значения:
— уникальный мир IO*
— состояние State
— облако переменных окружения Reader, Writer
— опциональное значение Just, Either
Потому что принцип "one shot one body" — это естественно для ООП (this, self, и т.п.).

Но вот уже для List (и его аналогов: множество, мультимножество...) приходится головушку-то перенастраивать. Монада как набор элементов.
Вот задался вопросом: а какие ещё бывают разновидности монад? И не смог с разгону сообразить.

*) Сейчас перечитываю Пратчетта. Там один из богов — Слепой ИО. Символично, однако...

Кодт,

К>Вот задался вопросом: а какие ещё бывают разновидности монад? И не смог с разгону сообразить.

А у меня в процессе обдумывания твоего вопроса родился ещё один вопрос.

Предположим, у нас есть чистая функция f :: a -> b. Если мы хотим превратить её в stateful, то мы пользуемся подходом монады State и превращаем её в
f1 :: a -> s -> (b, s). Ну дальше можно определить тип State s b, bind и т.п.

Внимание вопрос: а что если мы попытаемся выписать stateful функцию в виде
f2 :: (a, s) -> (b, s). Как тогда будет выглядеть монада, bind и return?

К>*) Сейчас перечитываю Пратчетта. Там один из богов — Слепой ИО. Символично, однако...
Раз он бох, что ж он себе глаза не сделает?

Lazy Cjow Rhrr wrote:
>
> Предположим, у нас есть чистая функция f :: a -> b. Если мы хотим
> превратить её в stateful, то мы пользуемся подходом монады State и
> превращаем её в
> f1 :: a -> s -> (b, s). Ну дальше можно определить тип State s b, bind и
> т.п.
>
> Внимание вопрос: а что если мы попытаемся выписать stateful функцию в виде
> f2 :: (a, s) -> (b, s). Как тогда будет выглядеть монада, bind и return?
>
Мне спросонья кажется, что f2 = uncurry f1, нет?
Дальше, как говорится, выливаем воду из чайника и сводим к известной задаче.

Кодт wrote:
>
> Вот задался вопросом: а какие ещё бывают разновидности монад? И не смог
> с разгону сообразить.
>
Насколько я понял, ожидаемый ответ — некоторая высокоуровневая
классификация монад, такого у меня нет.

Вот какие монады народ понаписывал (помимо стандартных):

http://haskell.org/haskellwiki/NewMonads
http://okmij.org/ftp/Computation/monads.html

Интересное обобщение State-монады (не являющееся, строго говоря,
монадой) — у состояния меняется не только значение, но и тип. Это
позволяет ловить в compile-time такиеошибки, например, как обращение к
хэндлу закрытого файла.
http://www.mail-archive.com/haskell@haskell.org/msg19644.html

palm mute,

>> Внимание вопрос: а что если мы попытаемся выписать stateful функцию в виде
>> f2 :: (a, s) -> (b, s). Как тогда будет выглядеть монада, bind и return?

PM>Мне спросонья кажется, что f2 = uncurry f1, нет?
+100!

PM>Дальше, как говорится, выливаем воду из чайника и сводим к известной задаче.

Я тип монады не могу сконструировать

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

PM>>Дальше, как говорится, выливаем воду из чайника и сводим к известной задаче.

LCR>Я тип монады не могу сконструировать

Семантику бы. Например

newtype State2 x s a = S { runState2 :: (x,s) -> (a,s) }


instance Functor (State2 x s) where
    fmap f (S r) = S $ \initial -> let (a,s) = r initial in (f a, s)
                                                                        

instance Monad (State2 x s) where
    return a = S $ (_,s) -> (a,s)
    (S r) >>= f  = S $ \initial@(x,_) -> let (a, s) = r initial in runState2 (f a) (x,s)

Думаю, fmap тут интуитивно понятен, и записать его легко, а bind сейчас объясню. Его проще вывести через join. join всего лишь последовательно переводит состояния внешней монады к внутренней. Для выведения его определения воспользуемся его типом.

join :: (State2 x s (State2 x s a)) -> (State2 x s a)
join (S r) = ...

Очевидно, что r :: (x,s) -> (a,s) можно применить только к (x,s). (x,s) же мы можем использовать как аргумент параметра возвращаемой монады:

join (S r) = S $ \initial -> ... r initial ...

r initial :: (State2 x s a, s), а нам надо получить значение типа (a,s). Чтобы из значений типа (State2 x s a) и s получить значение типа (a,s) нам необходимо ещё и значение типа x, а его мы можем взять из initial (больше неоткуда). Итого получаем:

join (S r) = S $ \initial@(x,_) -> let (s,next) = r initial in runState2 s (x,next)

Вроде других вариантов нет. Тогда

  bind (S r) f
= join (fmap f (S r)) 
= (\(S r) -> S $ \initial@(x,_) -> let (s,next) = r initial in runState2 s (x,next)) (S $ \initial -> let (a,s) = r initial in (f a, s))
= S $ \initial@(x,_) -> let (s,next) = (\initial -> let (a,s) = r initial in (f a, s)) initial in runState2 s (x,next)
= S $ \initial@(x,_) -> let (s,next) = (let (a,s') = r initial in (f a, s')) in runState2 s (x,next)
= S $ \initial@(x,_) -> let (a,s') = r initial in runState2 (f a) (x,s')

ч.т.д.

Ну и дальше совсем просто (калька с State):

instance MonadState s (State2 x s) where
    get   = S $ \(x,s) -> (s, s)
    put s = S $ \_ -> ((), s)

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

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

К>Вот задался вопросом: а какие ещё бывают разновидности монад? И не смог с разгону сообразить.

Вот тут с Lazy Cjow Rhrr мы разродились:
Re[2]: Монады

Автор: lomeo
Дата: 08.02.07

lomeo,

...
L>Ну и дальше совсем просто (калька с State):
...

Ущёл разбираться

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

LCR>Внимание вопрос: а что если мы попытаемся выписать stateful функцию в виде
LCR>f2 :: (a, s) -> (b, s). Как тогда будет выглядеть монада, bind и return?

Как уже сказали, достаточно uncurry f2, чтобы привести к виду State.
Или считать, что эта функция имеет дело с монадой Id.

Mонадные операции имеют тип (a -> m b). То есть, либо аргумент не обёрнут, либо формат обёртки совпадает с форматом необёрнутого аргумента.
Кстати говоря, в Хаскелле нельзя объявить воплощением класса любой производный тип (в данном случае кортеж). Придётся его обозвать.

newtype MyState s a = MyState (a,s)

instance Monad (MyState s) where
    (MyState (x,s)) >>= action = action (x,s)
    return x = \(_,s) -> MyState (x,s)

К>>*) Сейчас перечитываю Пратчетта. Там один из богов — Слепой ИО. Символично, однако...
LCR>Раз он бох, что ж он себе глаза не сделает?
А ему они не нужны. Или, по крайней мере, для жрецов эти глаза недоступны.

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

К>

К>newtype MyState s a = MyState (a,s)

К>instance Monad (MyState s) where
К>    (MyState (x,s)) >>= action = action (x,s)
К>    return x = \(_,s) -> MyState (x,s)
К>

Ну... Как то всё не так. Во первых action :: a -> MyState s b, поэтому

(MyState (x,s)) >>= action = action x

Во вторых return :: MyState s a, а лябда после знака равно :: \(a,s) -> MyState (b,s)

По моему для этого типа вообще нельзя нарисовать return (если s не имеет конкретного контекста, разумеется).

К>А ему они не нужны. Или, по крайней мере, для жрецов эти глаза недоступны.

Пратчетт да, рулит

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


К>Но вот уже для List (и его аналогов: множество, мультимножество...) приходится головушку-то перенастраивать. Монада как набор элементов.

Кстати что интересно — List это была первая монада которую я реально ГРОК.
И после того как уидел в монадах интерфейс могу представить все что угодно. Ну мало ли что может иметь нужный интейфейс.. Хоть космиечкий корабль с интрефейсом питания 220V, хоть амеба с интейфейсом USB

А вот еще мысль.
А что если монады это не монады, а вычисления ?

ICalculation<T>
{
returnResult aka return
applyFunction aka bind
fail 
}

Где-то так. Но вычисление типа List звучит конечно дико..

Кодт,

К>Mонадные операции имеют тип (a -> m b).

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

К>>>*) Сейчас перечитываю Пратчетта. Там один из богов — Слепой ИО. Символично, однако...
LCR>>Раз он бох, что ж он себе глаза не сделает?
К>А ему они не нужны. Или, по крайней мере, для жрецов эти глаза недоступны.
Тогда почему он Слепой, а не Всёвидящий?

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

M>А вот еще мысль.
M>А что если монады это не монады, а вычисления ?

Сейчас на haskellwiki страничка Monads_as_computation отсутствует, но раньше на hawiki она была, правда, кусками. Что то вроде MonadAsComputations. Кажется, её тоже Cale Gibbard писал.

M>Где-то так. Но вычисление типа List звучит конечно дико..

Вовсе нет — List — это вычисление, возвращаюшее несколько результатов.

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

К>>Mонадные операции имеют тип (a -> m b).

LCR>Да, да, вот меня и заинтересовало, какой вид будет иметь m в данном случае. А вы мне с lomeo какие-то обходные манёвры предлагаете...

Тогда я просто изначально тебя не понял. Ты хочешь сунифицировать (a -> m b) на ((a,s) -> (b,s)), где m — монада? Чтобы просто была такая функция, которую ты мог передать в bind для некой State монады?