Re[9]: Ещё более высокоуровневое(?) пр-ние на JVM чем в Scal
От: Lazy Cjow Rhrr Россия lj://_lcr_
Дата: 14.02.07 10:59
Оценка:
lomeo,

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


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


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


Я даже слов таких не знаю, как я могу знать, что я это хотю

Если серьёзно, пока писал это сообщение, немножко прозрел. Сначала я действовал по аналогиии: функция f имеет тип :: a -> m b, где в каждом конкретном случае мы имеем
Если f :: a -> Maybe b => m b = Maybe b
Если f :: a -> [ b ] => m b = [ b ]
Если f :: a -> s -> (b, s) => m b = s -> (b, s)
Если f :: (a, s) -> (b, s) => m b =

Сейчас я понял, что не могу просто написать m b = (_, s) -> (b, s), поэтому нужен какой-то тип State1 b s, такой что я смогу записать m b = State1 b.

Таким образом, мне нужно определение State1 b s. Вот определение этого типа я и называл "обходным манёвром".

И ты, и Кодт привели определения этого типа, но почему-то у Кодта получилось компактнее, вот я и смотрю, в чём отличия твоего решения от решения Кодта.
quicksort =: (($:@(<#[),(=#[),$:@(>#[)) ({~ ?@#)) ^: (1<#)
Re[10]: Ещё более высокоуровневое(?) пр-ние на JVM чем в Sca
От: lomeo Россия http://lomeo.livejournal.com/
Дата: 14.02.07 11:16
Оценка:
Здравствуйте, Lazy Cjow Rhrr, Вы писали:

LCR>Если серьёзно, пока писал это сообщение, немножко прозрел. Сначала я действовал по аналогиии: функция f имеет тип :: a -> m b, где в каждом конкретном случае мы имеем

LCR>Если f :: a -> Maybe b => m b = Maybe b
LCR>Если f :: a -> [ b ] => m b = [ b ]
LCR>Если f :: a -> s -> (b, s) => m b = s -> (b, s)
LCR>Если f :: (a, s) -> (b, s) => m b =

Это именно то, что я имел в виду, когда говорил об унификации. Насколько я понимаю этот термин — унификация — это нахождение наиболее общего типа для данного выражения при выводе типов. Т.е. наша унификация для общей функции (a -> m b) при конкретной монаде (которую мы ищем!) m, должна вывести тип ((a,s) -> (b,s))

LCR>Сейчас я понял, что не могу просто написать m b = (_, s) -> (b, s), поэтому нужен какой-то тип State1 b s, такой что я смогу записать m b = State1 b.


Верно, кроме последнего — m == State1 b, m a = State1 b a. Сейчас попробую объяснить. Наш State1 должен работать над двумя полиморфными типами — типом состояния и типом результата, которые одновременно является типом результата монады. Это естественно, т.к. тип состояния при вычислениях не должен меняться (представь обычную императивную программу, у нас меняются объекты, но не их типы), а тип результата меняться может, т.к. он представляет собой прохождение вычисления. Сначала мы посчитали obj, потом obj.getProp() и т.д. Т.к. в монадических вычислениях тип над которым монада обёрнута является изменяющимся (bind :: m a -> (a -> m b) -> m b — переход монады с одного типа на другой). То в конструкторе типа нашего состояния этот тип должен стоять последним — State1 s a, чтобы мы могли выделить m = State1 s. Или в терминах хаскеля:

data State1 s a = ...

instance Monad (State1 s) where ...


Таким образом состояние идеально ложится на монаду — State1 s будет постоянным, а последний тип — a — будет меняться при вычислениях.

LCR>Таким образом, мне нужно определение State1 b s. Вот определение этого типа я и называл "обходным манёвром".


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

LCR>И ты, и Кодт привели определения этого типа, но почему-то у Кодта получилось компактнее, вот я и смотрю, в чём отличия твоего решения от решения Кодта.


Отличие в том, что у Кодта, к сожалению, не работает. В ответе ему я это объяснил.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[2]: Ещё более высокоуровневое(?) пр-ние на JVM чем в Scal
От: Gajdalager Украина  
Дата: 15.02.07 16:46
Оценка: 7 (1)
Здравствуйте, BulatZiganshin, Вы писали:

BZ> жаль только, что они не сделали совместимость с хаскелом по синтаксису


Сегодня нашел на кодехаусе линку: здесь. Сам не хаскелист, но может, тебя и других хаскелистов заинтересует
Re[3]: Ещё более высокоуровневое(?) пр-ние на JVM чем в Scal
От: lomeo Россия http://lomeo.livejournal.com/
Дата: 15.02.07 19:02
Оценка:
Здравствуйте, Gajdalager, Вы писали:

G>Сегодня нашел на кодехаусе линку: здесь. Сам не хаскелист, но может, тебя и других хаскелистов заинтересует


Когда я смотрел этот проект, он был мёртвый. Есть еще jhaskell.sf.net, если я верно написал.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[4]: Ещё более высокоуровневое(?) пр-ние на JVM чем в Scal
От: Курилка Россия http://kirya.narod.ru/
Дата: 16.02.07 07:48
Оценка:
Здравствуйте, lomeo, Вы писали:

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


G>>Сегодня нашел на кодехаусе линку: здесь. Сам не хаскелист, но может, тебя и других хаскелистов заинтересует


L>Когда я смотрел этот проект, он был мёртвый. Есть еще jhaskell.sf.net, если я верно написал.


Правда? И правда — 1.0 за весну прошлого года
А сайт у них странный, новости только через RSS
Re[5]: Ещё более высокоуровневое(?) пр-ние на JVM чем в Scal
От: lomeo Россия http://lomeo.livejournal.com/
Дата: 16.02.07 09:01
Оценка:
Здравствуйте, Курилка, Вы писали:

К>Правда? И правда — 1.0 за весну прошлого года

К>А сайт у них странный, новости только через RSS

Я вот этот смотрел http://www.scdi.org/~avernet/projects/jaskell/
Может разные?
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[6]: Ещё более высокоуровневое(?) пр-ние на JVM чем в Scal
От: BulatZiganshin  
Дата: 16.02.07 09:05
Оценка: :)
L>Я вот этот смотрел http://www.scdi.org/~avernet/projects/jaskell/
L>Может разные?

"Page last modified on September 03, 2000."

я про jaskell тоже слышал только в контексте "давно мёртв"
Люди, я люблю вас! Будьте бдительны!!!
Re[6]: Ещё более высокоуровневое(?) пр-ние на JVM чем в Scal
От: Курилка Россия http://kirya.narod.ru/
Дата: 16.02.07 09:07
Оценка: 1 (1)
Здравствуйте, lomeo, Вы писали:

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


К>>Правда? И правда — 1.0 за весну прошлого года

К>>А сайт у них странный, новости только через RSS

L>Я вот этот смотрел http://www.scdi.org/~avernet/projects/jaskell/

L>Может разные?

Я про тот, что Gajdalager на кодхаусе привёл, наверное разные
Re[7]: Ещё более высокоуровневое(?) пр-ние на JVM чем в Scal
От: Alexey Romanov  
Дата: 16.02.07 23:18
Оценка: 9 (1)
Здравствуйте, Курилка, Вы писали:

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


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


К>>>Правда? И правда — 1.0 за весну прошлого года

К>>>А сайт у них странный, новости только через RSS

L>>Я вот этот смотрел http://www.scdi.org/~avernet/projects/jaskell/

L>>Может разные?

К>Я про тот, что Gajdalager на кодхаусе привёл, наверное разные


А вот LambdaVM -- живая.
http://www.cs.rit.edu/~bja8464/lambdavm/ и
здесь
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.