Здравствуйте, VladD2, Вы писали:
VD>Откровенно говоря и ленво, и энергично не отражают суть. Особенно "энергично". Здесь более подошло бы отложено, то есть deferred или delayed. Но тут точно не ясно с антонимом, да и боюсь многие наших лингвистических изысков не поймут 
.
Ну так "энергично" — это как раз и есть антоним к слову "лениво".
VD>Резонно. Но тогда конфликт может начаться уже в головах. Люди будут путать разные по семантике фукнции. Так что я бы все же предпочел нарочито другое имя описывающее суть происходящего.
VD>Плюс раз уж у нас язык с перегрузкой, то перегружать нужно только идентичные алгоритмы, а это уже сильно разные.
Ну, с тем, что они сильно разные я не согласен. zip просто более специализированная версия zipWith где в качестве функционального параметра подставлен конструктор тупла.
VD>Дык компилятор думать не умет. Он использует тупой перебор вариантов. Так что он будет рассматривать раскрытие макроса и для V.
VD>Откровенно говоря временами я подумывал об отказе от неявного преобразования кортежей в параметрах.
Полагаю, что это все-таки слишком полезная вешь, чтобы от нее отталкиваться. Более правильным было бы усовершенствовать механизм разрешения перегрузки. По-моему, по сигнатуре ф-и большинство вариантов можно быстро отсечь. Сделать библиотеку с легкими для перегрузки сигнатурами или вовсе без перегрузок мы можем, но пользователь языка-то все равно будет писать ф-и, сложные для разрешения перегрузки.
VD>Тут я уже просто настаиваю, что для всего для чего есть Iter должен быть так же реализован и IEnumerable[T].
Ну, это само собой разумеется.
K>>Да, это было бы полезно. Кстати, по поводу Zip-а, в Haskell есть такое расширение для лист компрехеншн, называется Parallel List Comprehensions.
K>>В nemerle бы такое тоже не помешало. Или уже есть?
VD>Есть http://en.wikibooks.org/wiki/F_Sharp_Programming/Computation_Expressions
Это другое. В немерле
$[ (x, y) | x in l1, y in l2]
разворачивается в
mutable res = [];
foreach (x in l1)
foreach (y in l2)
res ::= (x, y);
res.Rev ()
Аналогичная семантика и у кода на хаскеле:
[(x, y) | x <- l1, y <- l2]
Parallel List Comprehensions позволяет писать
[(x, y) | x <- l1 | y <- l2]
и это то же самое, что и
zip l1 l2
VD>А что это даст на практике? Я же говорю. Уже было... Толку — 0.
Если предполагается выбирать в рантайме специализированные версии мапов, фильтров и т.д. то нужно же предоставить возможность для расширения этой специализации:
public static Map[T, R](this seq : Seq[T], T -> R f) : Seq[R]
{
| xs is IFunctor[T] => xs.Map(f)
| xs is array[T] => xs.Map(f)
| xs is list[T] => xs.Map(f)
| xs is SCG.List[T] => xs.Map(f)
| _ => xs.MapLazy(f)
}
Тогда разработчик коллекции может просто реализовать IFunctor (IMapable, да как угодно) и ф-я Map будет работать с коллекцией специализированным образом. А если реализовать этот интерфейс для списка, словаря, множества из библиотеки, то и для них не понадобится делать явную проверку как для стандартных коллекций вроде массива и SCG.List[T].
VD>Ну, так у нас на то есть классы и инкапсуляция. 
Ну так это разделение и будет реализовано с помошью классов и инкапсуляции.
VD>Ну, до этого еще далеко. Если только зависимые типы реализуем. Или еще что-то подобное.
Зависимые типы для этого не нужны.
VD>Как я понял из википедии 2-3_tree — это и есть твои фингертри, только в чуть упрощенном виде.
Ну, в finger tree главное не то, что они 2-3 — это не обязательно.
главное то, что они finger:
... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
