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

D>Проблема в том, что YieldComp/ReturnComp — получают уже значения в монаде, а Yield/Return только создают монаду по заданному аргументу.
Это не проблема. Это решение.
Ибо значение и монада имеют разные типы и как следствее работает перегрузка.
Мы просто определяем два метода Yield но один принимает значение, а второй монаду. Тоже для остальных методов.
Дальше механизм разрешения перегрузки разберется.

D>К тому же, так сделано в F#
А ты уверен что это не произошло из-за ограничений самого F#?

D>Должен сказать, что Дон Сайм очень хорошо все придумал и обдумал детали. Удивительно просто.
Просто для кого? Лично я не хочу видеть кучу ключевых слов которых может и не быть.

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

D>>Проблема в том, что YieldComp/ReturnComp — получают уже значения в монаде, а Yield/Return только создают монаду по заданному аргументу.
WH>Это не проблема. Это решение.
WH>Ибо значение и монада имеют разные типы и как следствее работает перегрузка.
WH>Мы просто определяем два метода Yield но один принимает значение, а второй монаду. Тоже для остальных методов.
WH>Дальше механизм разрешения перегрузки разберется.

Не-не, так нельзя. Это очень разные функции. Этому меня еще хаскель научил.

WH>А ты уверен что это не произошло из-за ограничений самого F#?

Не вижу здесь ограничений. У них трудно определить монадный трансформер. Это действительно ограничение. А в остальном, все очень логично.

WH>Просто для кого? Лично я не хочу видеть кучу ключевых слов которых может и не быть.

Можно просто не определять и не использовать ReturnComp и YieldComp в случае чего. Это факультативно.

А необходимость их следует хотя бы из array comprehension, для которого

yield $x      =>  $(acc : Name).Add ($x)
yieldcomp $x  =>  $(acc : Name).AddRange ($x)

И я не представляю как одно можно было бы выразить через другое в общем случае... И то, и другое — must have однозначно.

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

D>Не-не, так нельзя. Это очень разные функции. Этому меня еще хаскель научил.
А что в хаскеле уже появилась перегрузка функций?

D>Не вижу здесь ограничений. У них трудно определить монадный трансформер. Это действительно ограничение. А в остальном, все очень логично.
Я имел в виду ограничения компилятора из-за которых приходится заниматься всякой фигней типа введения новых ключевых слов.

D>И я не представляю как одно можно было бы выразить через другое в общем случае... И то, и другое — must have однозначно.
Уффф....

module ListHelper
{
  public Yield[A](l : List[A], value : A) : void
  {
    l.Add(value);
  }

  public Yield[A](l : List[A], values : IEnumerable[A]) : void
  {
    l.AddRange(values);
  }
}

yield $x      =>  <[ ListHelper.Yield($(acc : Name), ($x)) ]>

.NET такие функции спокойно инлайнит.

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

D>Послал тебе вчера со своего гуглового аккаунта.

Что-то я его не получил. Слал на vc@rsdn.ru?

D>Поучаствовать не против. Например, я мог бы заменить то, что есть сейчас в каталоге snippets/ComputationExpressions. Там сейчас лежит только набросок.

Да, давай. Когда дойдет до приличного состояния можно будет в стандартную библиотеку макросов переместить.

D>Да, видел. Похоже на хаскелевский list comprehension.

Так с него и драли, как я понимаю.

D>Кстати, у них нотация do есть обобщение list comprehension.

Разве? По-моему там мало общего. Разве что оператор "<-".

D>Сейчас есть зависимость от самой сборки ComputationExpressions.dll. Это из-за вспомогательного класса EnumerableHelper. Потом его вынесу в отдельную dll. Будет маленький и независимый ComputationExpression.Runtime.dll.

Лучше ComputationExpression.dll и ComputationExpression.Macro.dll.
А в дальнейшем можно будет это дело перенести в Nemerle.dll и Nemerle.Macro.dll соответственно.

D>>>Можно использовать и yieldcomp. Тогда будет подставляться вся подпоследовательность.

VD>>Вот тут я разницу не уловил.

D>Иногда yieldcomp — очень полезная штука. Как и returncomp (aka return! в F#). С точки зрения монады yieldcomp и returncomp очень близки.

Кстати, а foreach в этих компрешеншонах поддерживается?

Лично я for и while использую крайне редко, а вот foreach очень часто.
ереписывается в чистые циклы.

D>Я думаю, что такая же эффективность. Эффективнее просто быть не может. Макрос comp практически не создает ничего лишнего в случае list comprehension. Только работа с аккумулятором в тех местах, где прописан yield и yieldcomp.

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

D>Сначала все складывается в обратном порядке, а потом в конце вызывается Rev ().

Ну, вот еще и реверт. Это тоже накладные расходы. Как я уже писал макросный лист-компрешеншоны зачастую разворачивается в банальные циклы. Скажем если использовать лист-компрешеншон в foreach-е.

Ну, да не важно.

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

WH>>Меняй.

D>OK. Как будет доступ.

Еще раз повторюсь, что мыла от тебя с экаунтом не получил.

Если проблемы с мылом, то можно послать через наш сайт или передать по скайпу (VladD2) или MSN (тоже VladD2).

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

D>К тому же, так сделано в F# Должен сказать, что Дон Сайм очень хорошо все придумал и обдумал детали. Удивительно просто.

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

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

D>>Должен сказать, что Дон Сайм очень хорошо все придумал и обдумал детали. Удивительно просто.
WH>Просто для кого? Лично я не хочу видеть кучу ключевых слов которых может и не быть.

+1

Предлагаю сделать очень просто. dsorokin зальет свою реализацию, а ты ее причешишь (если не вылезет каких-то дополнительных проблем).

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

WH>что в хаскеле уже появилась перегрузка функций?

В том то и дело, что разные функции должны называться по разному. Принципиальная позиция. Yield и YieldComp — две разные функции. Yield : A -> M[A]. YieldComp : M[A] -> M[A]. А вообще, в хаскеле есть классы типов (type classes). Отчасти заменяют перегрузку. Так сказать, правильная перегрузка.

WH>Я имел в виду ограничения компилятора из-за которых приходится заниматься всякой фигней типа введения новых ключевых слов.

Думаю, что это здесь ни причем. По моему эти новые ключевые слова нужны, потому что того требует задача. К тому же это значительно упрощает написание макроса comp. Трансляция кода получается однозначной и независимой ни от конкретных типов, ни от билдеров, что само себе дорогого стоит.

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

VD>Предлагаю сделать очень просто. dsorokin зальет свою реализацию, а ты ее причешишь (если не вылезет каких-то дополнительных проблем).

Если мой голос что-то значит, то я резко против объединения Yield и YieldComp. Также Return и ReturnComp должны быть разными.

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

D>У них трудно определить монадный трансформер. Это действительно ограничение. А в остальном, все очень логично.

А в чем трудность?

WH>>Просто для кого? Лично я не хочу видеть кучу ключевых слов которых может и не быть.

D>Можно просто не определять и не использовать ReturnComp и YieldComp в случае чего. Это факультативно.

Не вникал в суть проблемы, но согласен с WolfHound-ом в том плане, что если можно обойтись без лишних ключевых слов воспользовавшись перегрузкой, то лучше так и поступить.

Возможно ты не учитываешь различие в языках. У Немерла локальный, но более мощный вывод типов. Он позволяет разруливать сложные перегрузки (хотя это может серьезно тормозить, так что нужно быть аккуратным). Этим, иногда, можно воспользоваться.

D>А необходимость их следует хотя бы из array comprehension, для которого

D>

D>yield $x      =>  $(acc : Name).Add ($x)
D>yieldcomp $x  =>  $(acc : Name).AddRange ($x)
D>

D>И я не представляю как одно можно было бы выразить через другое в общем случае... И то, и другое — must have однозначно.

Как раз через перегрузку. Если создать два варианта перегруженных методов:

ListAddHelper[T](ary : List[T], elem : T) { ... }
ListAddHelper[T](ary : List[T], elems : IEnumerable[T]) { ... }

...

| yield $x      =>  ListAddHelper($(acc : Name), $x)
| yieldcomp $x  =>  ListAddHelper($(acc : Name), $x)

а компилятор на стадии типизации сам подставит нужную функцию.

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

D>А главное, что YieldComp и ReturnComp обозначают, что в таком то месте есть монада. Это влияет на генерацию кода в целом. И не нужны типы. Все уже просчитано до нас

До нас оно было просчитано для языков с выводом типов по алгоритму Хиндли-Милера (модифицированному, конечно, но все же).

Так что Вольфхаунд тут может быть и прав.

В нашем распоряжении есть перегрузка, более мощный вывод типов и явное использование отложенной типизации. У авторов Хаскеля и F# всего этого не было и они ориентировались на возможности и особенности своих языков. Это могло серьезно повлиять на принимаемые решения и выбираемые подходы.

Так что я бы действительно подумал нельзя ли воспользоваться имеющимися преимуществами.

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

D>В том то и дело, что разные функции должны называться по разному. Принципиальная позиция. Yield и YieldComp — две разные функции. Yield : A -> M[A]. YieldComp : M[A] -> M[A]. А вообще, в хаскеле есть классы типов (type classes). Отчасти заменяют перегрузку. Так сказать, правильная перегрузка.

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

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

D>Если мой голос что-то значит, то я резко против объединения Yield и YieldComp. Также Return и ReturnComp должны быть разными.

Голос того кто что-то делает своими руками на благо общества значит почти все. Но и к другим голосам прислушиваться стоит.

Как я понимаю речь идет не об отказе от понятия, а об отказе от введения ключевых слов в пользу перегрузки. Если это возможно и не приведет к проблемам, то почему бы и нет? А yield можно просто назвать с большой буквы (Yield). Или даже YieldComp. Вопрос будет ли это оператором или функцией в определяемом пользователем классе.

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

VD>Что-то я его не получил. Слал на vc@rsdn.ru?

Странно. Письмо ушло в 21:54. Может быть, из аттача его зарубили? Мог и гугл запросто, через который уходило... Мой email: david тчк sorokin собака гмыло дот ком.

D>>Кстати, у них нотация do есть обобщение list comprehension.

VD>Разве? По-моему там мало общего. Разве что оператор "<-".

Эта стрелка и есть монадический bind. Можно тот же list comprehension записать в нотации do, поскольку список — это монада. Отличий будет мало. Только с предикатами немного по другому выйдет. Видимо, отсюда все и пошло.

VD>Лучше ComputationExpression.dll и ComputationExpression.Macro.dll.
VD>А в дальнейшем можно будет это дело перенести в Nemerle.dll и Nemerle.Macro.dll соответственно.

Так и сделаю. Только по-моему лучше s добавить на конце.

VD>Кстати, а foreach в этих компрешеншонах поддерживается?

Пока нет. Но это только вопрос времени. Но придется повозится с обычным for. Foreach поддерживать легче, но там лучше сразу ориентироваться на типизированный IEnumerable[T].

D>>Я думаю, что такая же эффективность. Эффективнее просто быть не может. Макрос comp практически не создает ничего лишнего в случае list comprehension. Только работа с аккумулятором в тех местах, где прописан yield и yieldcomp.

VD>Он приводит к выделению объектов в куче и косвенным вызовам.

Ну, тогда при желании можно оптимизировать. Для list и array comprehension трансляция почти не затрагивает исходный код. Лишь обрабатываются yield, yieldcomp, да еще пустой () местами вставляется (там, где выражение обязано заканчиваться монадой).

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

D>>У них трудно определить монадный трансформер. Это действительно ограничение. А в остальном, все очень логично.

VD>А в чем трудность?

В том, что один из билдеров (параметр монадного трансформера) является переменным. Наверное, здесь нужны макросы. Или классы типов.

VD>Возможно ты не учитываешь различие в языках. У Немерла локальный, но более мощный вывод типов. Он позволяет разруливать сложные перегрузки (хотя это может серьезно тормозить, так что нужно быть аккуратным). Этим, иногда, можно воспользоваться.

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

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

VD>Как я понимаю речь идет не об отказе от понятия, а об отказе от введения ключевых слов в пользу перегрузки. Если это возможно и не приведет к проблемам, то почему бы и нет? А yield можно просто назвать с большой буквы (Yield). Или даже YieldComp. Вопрос будет ли это оператором или функцией в определяемом пользователем классе.

Проблемы будут в понимании. Как минимум, у меня. YieldComp подразумевает монаду, а Yield — обычное значение. Я думаю, что ограничения ML здесь ни причем. Это пример правильной постановки задачи на мой взгляд. Перегрузка таит в себе скрытые опасности.

Сейчас какие-нибудь действия нужны с моей стороны или достаточно того, что я предоставил свой email? Могу попробовать переслать через ваш сайт, если подскажете как. Skype и MSN не использую.

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

VD>Если проблемы с мылом, то можно послать через наш сайт или передать по скайпу (VladD2) или MSN (тоже VladD2).

Письмо получил. Отослал два ответа. Одно с аттачем.

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


D>Проблемы будут в понимании. Как минимум, у меня. YieldComp подразумевает монаду, а Yield — обычное значение.

Те кто будет пользоваться всем этим скорее всего даже не будут задумываться над тем, что за всем этим стоят монады. Они будут воспринимать это как еще одну фичу.

D> Я думаю, что ограничения ML здесь ни причем. Это пример правильной постановки задачи на мой взгляд. Перегрузка таит в себе скрытые опасности.

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

D>Сейчас какие-нибудь действия нужны с моей стороны или достаточно того, что я предоставил свой email? Могу попробовать переслать через ваш сайт, если подскажете как. Skype и MSN не использую.

Я добавил тебя в комитеры (о чем написал по мылу). Так что можешь менять код.
Инструкция по генерации пароля и чекауту можно найти здесь:
http://code.google.com/p/nemerle/source/checkout

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

VD>>Лучше ComputationExpression.dll и ComputationExpression.Macro.dll.
VD>>А в дальнейшем можно будет это дело перенести в Nemerle.dll и Nemerle.Macro.dll соответственно.

D>Так и сделаю. Только по-моему лучше s добавить на конце.

VD>>Кстати, а foreach в этих компрешеншонах поддерживается?

В смысле ComputationExpressions?
Добавь.

D>Foreach поддерживать легче, но там лучше сразу ориентироваться на типизированный IEnumerable[T].

Гы-гы. Ты наверно даже не понимаешь насколько ты ошибаешься. foreach в Немерле раз в 10 навороченее чем его аналог в C#. Он по полной программе поддерживает паттерн-матчинг.

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

VD>Те кто будет пользоваться всем этим скорее всего даже не будут задумываться над тем, что за всем этим стоят монады. Они будут воспринимать это как еще одну фичу.

Согласен. Как и с linq