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

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

S>>>> Я подправил потому, что изначальный смыл в том, что вычисления идут с права налево и нет лишних циклов если бы вычисляли слева направо c созданием новых коллекций

I>>>Ты путаешь linq и ленивую обработку коллекций. Linq это про соответствующие расширения, которые можно навесить на любой интерфейс, а не только IEnumerable. Более того — совсем необязательно это будет коллекция.
I>>>RX, XML, WMI, IQueryable и тд и тд и тд.

I>Судя по тому, что ты проигнорировал, ты или не понял, что здесь написано, или не согласен.
Ну вообщето говорим про IEnumerable, не про деревья выражений и IQueryable

I>>>Т.е. yield это частный случай для IEnumerable. То есть, частный случай частного случая

S>> Да но именно yield и создает IEnumerable ленивым. Посмотрим https://github.com/dotnet/runtime/blob/main/src/libraries/System.Linq/src/System/Linq/Where.cs

I> Ты в любой момент можешь отказаться от вызова MoveNext, а следовательно, IEnumerable сам по себе ленивый, безо всякого yield.
Да только нужно класс который генерит yield делат ручками. В Core для Where и Select так и сделали, но для других методов расширения оставили yield.
А во ыреймворке так и оставили.

I>Ты снова путаешь причину и следствие. yield это дешовый способ корректно генерировать IEnumerable. А раз это IEnumerable, то, следовательно, код будет ленивым.
Я как и говорю про дешевизну и легкость создания IEnumerable
I>Как по твоему реализовывали ленивые итерации до появления yield? Чудом, магией?
Я уже тебе писал, что для Б+ деревьев сам писал итераторы я обхода дерева.
I>>>Ты так пишешь.

S>>И вот в конце наконец вызвать FirstOrDefault вот она вся прелесть вычислений справо на лево в отличие от твой позиции с вычислением слева направо

I>IEnumerable в АПИ подразумевает что перформанс не нужен, т.к. ты можешь понаобъединять сколько угодно фильтров-проекций.
I>Когда важен перформанс, в АПИ не должно быть никаких подобных интерфейсов.

I>Дальше я повыбрасывал твои куски кода, т.к. ты объясняешь прописные истины. yield я использовал еще с 2008го года. А ты пишешь, как будто лично ты его изобрёл и добавил в язык ажно вчера.
Я пишу про то, что yield повлиял на многое в качестве легкого создания итераторов в том числе и Linq и async/awaite.
Просто он как то стоит в сторонке
S>>На yield построен Linq
S>>Непонятно?

I>Ты привел примеры частного случая. IQueryable гораздо лучше отражает Linq, нежели твой yield.
Я привел пример влияние yield на часть линка для коллекций. Деревья выражений это отдельная ветка Linq, хотя синтаксис и похож.
Вот видишь и ты так же как и все относятся к yield пренебрежительно!

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

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

S>>>> Я подправил потому, что изначальный смыл в том, что вычисления идут с права налево и нет лишних циклов если бы вычисляли слева направо c созданием новых коллекций

I>>>Ты путаешь linq и ленивую обработку коллекций. Linq это про соответствующие расширения, которые можно навесить на любой интерфейс, а не только IEnumerable. Более того — совсем необязательно это будет коллекция.
I>>>RX, XML, WMI, IQueryable и тд и тд и тд.

I>Судя по тому, что ты проигнорировал, ты или не понял, что здесь написано, или не согласен.
Ну вообщето говорим про IEnumerable, не про деревья выражений и IQueryable

I>>>Т.е. yield это частный случай для IEnumerable. То есть, частный случай частного случая

S>> Да но именно yield и создает IEnumerable ленивым. Посмотрим https://github.com/dotnet/runtime/blob/main/src/libraries/System.Linq/src/System/Linq/Where.cs

I> Ты в любой момент можешь отказаться от вызова MoveNext, а следовательно, IEnumerable сам по себе ленивый, безо всякого yield.
Да только нужно класс который генерит yield делат ручками. В Core для Where и Select так и сделали, но для других методов расширения оставили yield.
А во ыреймворке так и оставили.

I>Ты снова путаешь причину и следствие. yield это дешовый способ корректно генерировать IEnumerable. А раз это IEnumerable, то, следовательно, код будет ленивым.
Я как и говорю про дешевизну и легкость создания IEnumerable
I>Как по твоему реализовывали ленивые итерации до появления yield? Чудом, магией?
Я уже тебе писал, что для Б+ деревьев сам писал итераторы я обхода дерева.
I>>>Ты так пишешь.

S>>И вот в конце наконец вызвать FirstOrDefault вот она вся прелесть вычислений справо на лево в отличие от твой позиции с вычислением слева направо

I>IEnumerable в АПИ подразумевает что перформанс не нужен, т.к. ты можешь понаобъединять сколько угодно фильтров-проекций.
I>Когда важен перформанс, в АПИ не должно быть никаких подобных интерфейсов.

I>Дальше я повыбрасывал твои куски кода, т.к. ты объясняешь прописные истины. yield я использовал еще с 2008го года. А ты пишешь, как будто лично ты его изобрёл и добавил в язык ажно вчера.
Я пишу про то, что yield повлиял на многое в качестве легкого создания итераторов в том числе и Linq и async/awaite.
Просто он как то стоит в сторонке
S>>На yield построен Linq
S>>Непонятно?

I>Ты привел примеры частного случая. IQueryable гораздо лучше отражает Linq, нежели твой yield.

public static Maybe<T2> SelectMany<T1, T2>(
this Maybe<T1> source, Func<T1, Maybe<T2>> selector)
{
if (source is Maybe<T1>.Just j)
return selector(j.Value);

return new Maybe<T2>.Nothing();
}

public static T1 Ret<T1>(T1 value)
{
return value;
}

public static T1 Ret2<T1>(T1 value)
{
return value;
}
public static Maybe<T3> SelectMany<T1, T2, T3>(
this Maybe<T1> source, Func<T1, Maybe<T2>> collectionSelector, Func<T1, T2, T3> resultSelector)
{
//var t1 = source as Maybe<T1>.Just;
//var mt2 = collectionSelector(t1.Value);
//var t2 = (mt2 as Maybe<T2>.Just).Value;
//var res2 = resultSelector(t1.Value, t2);
return source.SelectMany(x =>
collectionSelector(Ret(x))
.SelectMany(y =>
resultSelector(x, Ret2(y)).
ToMaybe()));
}

Интересно, что SelectMany отрабатывает до collectionSelector и resultSelector.