Re: Ликбез по ComputationExpressions - Nemerle

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

D>Зато можно построить монаду Cont. Этого достаточно для многих практических задач. Тогда с помощью вычислительных выражений становится очень легко и просто создавать эти самые продолжения. Async из F# в своей основе есть продолжение, но которое еще умеет распространять исключения между потоками исполнения.

Как я понимаю, монады по своей сути — это CPS-продолжения. В бинд ведь как раз и передается функция которую нужно вызвать вслед за вычислением. Вот только это никак не способствует серилизации состояния вычисления.

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

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

VD>>Я говорю о том как будет сериализоваться информация о глубине рекурсии и значених параметров?

D>Наверное как граф объектов. Но для этого надо уметь сериализовывать функции и замыкания.

А как это вообще можно сделать? Да и вообще, что под этим понимаетя?

D>Меньше

Но время от времени еще увлекаюсь Common Lisp. Так что, к макросам привыкший.

А, да! Лисповская практика очень полезна. За исключением манипуляций с типами выражений идеология очень похожа.
В прочем она похоже полезна всегда

.

D>Нет, здесь свое. На мой взгляд основная фишка в том, что код, написанный в вычислительных выражениях, почти ничем не отличается от обычного кода на F# или Немерле.

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

D>Это просто гениальная вещь! В одном ряду с linq, где по забавному совпадению тоже монады

Я в linq монады ну ни как не могу узреть. С натяжкой SelectMeny, но ведь он а) редко используется, и б) имеет (по крайней мере для меня) не монадический смысл.

Я скорее рассматриваю linq как качественно портированый предюд из Хаскеля.

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

D>>Наверное как граф объектов. Но для этого надо уметь сериализовывать функции и замыкания.

VD>А как это вообще можно сделать? Да и вообще, что под этим понимаетя?

Я понимаю так, что функции и замыкания представлены как ООП-объекты в IL. Вот их и надо бы сериализовать вместе со всеми связями и состояниями. Только реально ли? Думаю, тупиковая идея.

VD>Я в linq монады ну ни как не могу узреть. С натяжкой SelectMeny, но ведь он а) редко используется, и б) имеет (по крайней мере для меня) не монадический смысл.

VD>Я скорее рассматриваю linq как качественно портированый предюд из Хаскеля.

С linq не работал и почти ничего не знаю о нем, не читал. Но мне кажется, что под from может скрываться defcomp (bind), под select — return, а под selectMany — returncomp. Where — альтернатива if при условии существования zero (пустая коллекция). Если бы были if и zero, то тогда можно было where определить через все другое:

def where (coll, pred)
{
  comp builder
  {
    defcomp x = coll;
    if pred (x) 
      return x
    else
      returncomp zero
  }
}

У меня есть вопрос ко всем. Правильно ли я понимаю следующую вещь? Есть тип TryCase, который задает один обработчик из блока try-catch. Вот его конструкторы:

match (c : TryCase)
{
  | Catch (exn, exn_ty, handler) => ...
  | Filter (exn, exn_ty, filter, handler) => ...
  | Ellipsis (handler) => ...
}

Меня интересуют переменные handler. Действительно ли это та часть конструкций, которая следует после символа => в части catch? Особенно смущает filter. Что он значит?

Если я правильно понимаю, что за => отвечают только переменные handler, то могу сказать, что реализован try-catch для вычислительных выражений. Я там сделал немного не так как в F#. Пошел на хитрость. Исключение перевозбуждается. Так стало намного проще. В F# же заменяют блок catch на паттерн матчинг, что напряжно делать, да и смысла большого не вижу.

Итог такой. Уже есть try-finally и try-catch (если я прав на счет handler). Для полноценной поддержки осталось добавить using/usingcomp.

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

D>У меня есть вопрос ко всем. Правильно ли я понимаю следующую вещь? Есть тип TryCase, который задает один обработчик из блока try-catch. Вот его конструкторы:

D>

D>match (c : TryCase)
D>{
D>  | Catch (exn, exn_ty, handler) => ...
D>  | Filter (exn, exn_ty, filter, handler) => ...
D>  | Ellipsis (handler) => ...
D>}
D>

D>Меня интересуют переменные handler. Действительно ли это та часть конструкций, которая следует после символа => в части catch? Особенно смущает filter. Что он значит?

Если не ошибаюсь то вот интерпретация:

Catch:

try {
} catch {
   | e is ArgumentNullException => 
}

Filter:

try {
} catch {
   | e is ArgumentNullException when e.Message.Contains("x") => 
}

Ellipsis:

try {
} catch {
   | _ => 
}

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

D>Интересная идея. Наверное, можно как-то связать с написанием своих собственных DSL. Следующий уровень после вычислительных выражений.
Упрощение создания собственных DSL это вообще отдельная история.
Причем для следующей версии языка.
Ибо для этого придется переделать все. От парсера до вывода типов.

D>Сейчас предлагаю завершить текущую схему. Я добавил более полную реализацию foreach (с матчингом и приведением :>) и блок try-finally. Из основных остались try-catch и using/usingcomp.
Делай как знаешь.
Я просто опытом делюсь.
Мне при работе над ПЕГом модель очень сильно помогла.

... << RSDN@Home 1.2.0 alpha 4 rev. 1305>>

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

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

D>>Меня интересуют переменные handler. Действительно ли это та часть конструкций, которая следует после символа => в части catch? Особенно смущает filter. Что он значит?

А хендлер, да это то, что следует после =>.

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

H>А хендлер, да это то, что следует после =>.

Спасибо! Тогда тестируйте! По-моему enumerable comprehension получается довольно аппетитным

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

D>Я понимаю так, что функции и замыкания представлены как ООП-объекты в IL. Вот их и надо бы сериализовать вместе со всеми связями и состояниями. Только реально ли? Думаю, тупиковая идея.

Объекты-замыкания сериализовать по любому придется.

D>С linq не работал и почти ничего не знаю о нем, не читал. Но мне кажется, что под from может скрываться defcomp (bind), под select — return, а под selectMany — returncomp. Where — альтернатива if при условии существования zero (пустая коллекция).

Ага. Астрономы тоже в звездах видят тельцов и дев

.
Реальности жизни несколько банальнее. select — это map, where — filter и т.д.

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

D>Меня интересуют переменные handler. Действительно ли это та часть конструкций, которая следует после символа => в части catch?

Да.
В немерле обработчики искючений аналогичны вхождениям оператора match (описывающиеся конструкцией MatchCase).

D>Особенно смущает filter. Что он значит?

Скажем если мы имеем следующий код:

try
{
  ...
}
catch
{
  | e is SomeException when e.SomeProperty == 123
}

то такое вхождение catch-а записывается как TryCase.Filter.
Собственно это легко понять если сделать поиск по TryCase.Filter в файле ncc\parsing\MainParser.n.

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

H>Ellipsis:

H>

H>try {
H>} catch {
H>   | _ => 
H>}
H>

Здесь ошибаешься. Ellipsis — это $-выражение в квази-цитате.

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

VD>Ага. Астрономы тоже в звездах видят тельцов и дев

.

Астрономы или астрологи?

VD>Реальности жизни несколько банальнее. select — это map, where — filter и т.д.

IEnumerable + Linq, в особенности с методом SelectMany являются реализацией монады списка. Докладнее можно почитать, например тут: http://codebetter.com/blogs/matthew.podwysocki/archive/2008/10/13/functional-c-linq-as-a-monad.aspx

Или посмотреть тут: http://www.infoq.com/interviews/LINQ-Erik-Meijer

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

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

VD>>Ага. Астрономы тоже в звездах видят тельцов и дев

.

А>Астрономы или астрологи?

Астрономы. Астрологи идут дальше и видят связь между тем чего нет и тем чего не может быть.

А>IEnumerable + Linq, в особенности с методом SelectMany являются реализацией монады списка.

А если скажем без IEnumerable? Или без SelectMany?

А>Докладнее можно почитать, например тут: http://codebetter.com/blogs/matthew.podwysocki/archive/2008/10/13/functional-c-linq-as-a-monad.aspx

А>Или посмотреть тут: http://www.infoq.com/interviews/LINQ-Erik-Meijer

Ну, да. Ну, да. Это все я видел. Я же говорю... В прочем не буду повторяться (см. выше).

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

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

H>>Ellipsis:

H>>

H>>try {
H>>} catch {
H>>   | _ => 
H>>}
H>>

VD>Здесь ошибаешься. Ellipsis — это $-выражение в квази-цитате.

А можно подробнее? Ellipsis имеет один параметр body. Сейчас этот body у меня преобразовывается в поисках монады. Мне интересно знать, насколько это корректно. Можно этот Ellipsis создать в коде?

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

VD>Реальности жизни несколько банальнее. select — это map и т.д.

Ну, да. Функция fmap для монады:

def fmap (coll, f)
{
  comp builder
  {
    defcomp x = coll;
    return (f (x))
  }
}

Вот тут, кстати, было бы хорошо отойти от канонов F# и генерировать общий код для fmap как в хаскеле. Над этим надо будет озадачиться.

Тут ко мне пришла гениальная идея! (как-то запоздало...) Можно не изобретать свой аналог async аля F#. Можно его просто использовать в Немерле, но со своим синтаксисом вычислительных выражений! Со своими foreach, паттерн-матчингом, repeat и do-while. Для этого нужны две вещи:

1) либо написать прослойку, которая давала бы немерлевский билдер (методы практически также называются), либо генерировать нужный код напрямую через ComputationBuilder (предпочтительнее);

2) установленный run-time для F# (идет вместе с .NET v4).

Тогда можно будет писать на Немерле в стиле:

def get_html_async (url : string)
{
  comp async 
  {
    def request = WebRequest.Create(url);
    defcomp response = request.AsyncGetResponse();
    def stream = response.GetResponseStream();
    def reader = StreamReader(stream);
    defcomp text = reader.AsyncReadToEnd();  
    return text  
  }  
}

В общем, считайте, что async из F# уже почти есть в Немерле

Знаю, что в Немерле уже есть свой async, но он какой-то другой.

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

D>А можно подробнее? Ellipsis имеет один параметр body. Сейчас этот body у меня преобразовывается в поисках монады. Мне интересно знать, насколько это корректно. Можно этот Ellipsis создать в коде?

Куда же подробнее? Это заглушка для квази-цитирования. Может появляться только внутри цитат. Нужно для генерации кода вхождения путем подстановки спласа.

Самому еще не разу не приходилось генерировать обработчики catch-ей, но это должно выгдядеть как-то так:

<[
try
{
}
catch 
{
  ..$(GenerateExcetpionHandlers())
}
]>

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

VD>>Реальности жизни несколько банальнее. select — это map и т.д.

D>Ну, да. Функция fmap для монады:

D>

D>def fmap (coll, f)
D>{
D>  comp builder
D>  {
D>    defcomp x = coll;
D>    return (f (x))
D>  }
D>}
D>

Какие монды? Вот определение Select-а:

public static IEnumerable<TResult> Select<TSource, TResult>(this IEnumerable<TSource> source, Func<TSource, TResult> selector)

Чем это отличается от MapLazy из стандартной библиотеки немерла:

public MapLazy[From, To](this source : SCG.IEnumerable[From], convert : From -> To) : SCG.IEnumerable[To]

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

VD>Какие монды? Вот определение Select-а:

В основе лежит монада списка (сюрприз!). Но как я понял, можно определять в linq и свои монады. Только непонятно, насколько эквивалентно получается тем же вычислительным выражениям.

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

VD>Куда же подробнее? Это заглушка для квази-цитирования. Может появляться только внутри цитат. Нужно для генерации кода вхождения путем подстановки спласа.

VD>Самому еще не разу не приходилось генерировать обработчики catch-ей, но это должно выгдядеть как-то так:
VD>

VD><[
VD>try
VD>{
VD>}
VD>catch 
VD>{
VD>  ..$(GenerateExcetpionHandlers())
VD>}
VD>]>
VD>

Я не понял, что с этим делать. Поэтому добавил вывод ошибки компиляции для этого TryCase.Ellipsis. Мне нужно больше информации, чтобы понять.

Сегодня добавил using. Он такой же. Только в нем нельзя использовать mutable. Зато можно использовать defcomp:

  comp builder
  {
    using (defcomp x = resource_in_monad)
    {
      ...
    }
  }

В общем, я сделал все, что хотел. Можно назвать готовой бетой. Теперь исправления ошибок, если таковые будут. Остается только неясность с FakeVoid (в F# для инстанцирования генериков по как бы void используется класс Unit, поддерживаемый на уровне компилятора). Плюс нужно написать документацию. Но теперь темп будет уже не таким.

От:	VladD2	www.nemerle.org
Дата:	24.04.10 13:55
Оценка:

От:	VladD2	www.nemerle.org
Дата:	24.04.10 14:07
Оценка:

	От:	dsorokin
	Дата:	24.04.10 14:23
	Оценка:

	От:	dsorokin
	Дата:	24.04.10 15:59
	Оценка:

От:	hardcase	http://nemerle.org
Дата:	24.04.10 16:12
Оценка: