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

K>Работы ведутся. С наработками и экспериментами можно ознакомиться тут. Принимаются предложения и критика в любой форме. Особенно приветствуются предложения по именованию, для разрешения конфликов с LINQ.

В плане наименований / дизайна / используемых функций не смотрели как это сделано в Scala? Не будет ли это лучше, чем смотреть на Haskell? Nemerle всё-таки на Scala больше похож, чем на Haskell.

http://www.scala-lang.org/api/current/index.html

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

K>Как бы я написал функцию Choose:
K>

K>source.Map(f).CatOptions()
K>

K>Именно так, по моему мнению, и нужно писать на ФЯ — используя комбинаторы. Но компилятор не делает дефорестацию и тут будет промежуточный список, а потому так написать библиотечную функцию я не могу.

А нельзя сделать макрос, который приводит source к sequence, над ней делает эти операции, а затем результат обратно приводит к списку? VM не свернёт это в цикл?

И ещё — на макросах, насколько я понимаю, можно написать fusion для подобных выражений.

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

L>А нельзя сделать макрос, который приводит source к sequence, над ней делает эти операции, а затем результат обратно приводит к списку? VM не свернёт это в цикл?

В принципе возможно.
Проблема втом, что нужно этому макросу как-то сообщить семантику операций, грубо говоря, передать AST кода Map и CatOptions.

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

H>В принципе возможно.
H>Проблема втом, что нужно этому макросу как-то сообщить семантику операций, грубо говоря, передать AST кода Map и CatOptions.

Мы как-то с Камилом думали о введении маросов-расширений, на манер методов-расширений. Выглядеть они должны как обычные методы и разрешение перегрузки для них должно отрабатывать как для обычного метода, но дальше должен вызваться макрос который уже будет генерировать оптимальный код.

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

L>В плане наименований / дизайна / используемых функций не смотрели как это сделано в Scala?

Смотрел, спасибо, просто поленился включить в сводную таблицу.

L>Не будет ли это лучше, чем смотреть на Haskell? Nemerle всё-таки на Scala больше похож, чем на Haskell.

Дело в том, что система типов nemerle от системы типов scala очень существенно отличается. На CLR-дженериках библиотеку скалы просто не повторить. А смотрел я (помимо прочего, вроде библиотеки F#) не на haskell вообще, а в основном на Data.List, допотопный модуль, который практически никаких особенностей системы типов хаскеля не использует и может быть портирован на любой язык с первоклассными функциями. Алексей Романов его, например, на C# портировал.

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

VD>Это аналог Async-а.

Ну нет, это такой обобщенный zip, на async совсем не похоже.

VD>А это уж больно на линк смахивает (что у нас так же имеется).

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

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

L>А нельзя сделать макрос, который приводит source к sequence, над ней делает эти операции, а затем результат обратно приводит к списку? VM не свернёт это в цикл?

VM не свернет.

L>И ещё — на макросах, насколько я понимаю, можно написать fusion для подобных выражений.

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

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

K>В принципе можно, при условии, что есть исходный код этих функций. В общем случае это не так — функции могут быть импортированы из бинарных библиотек.

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

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

K>В этом треде обсуждаются и принимаются пожелания по стандартной библиотеке. А именно по методам расширениям, интерфейсам, операторам, структурам данных, которые нужны вам в стандартной библиотеке, но по какой-то причине туда не включены или реализованы не так как вам нужно. Предложения по макросам пока принимаются где-нибудь в другом месте. Также желательно, я думаю, оформлять свои предложения в виде фич-реквеста в багтрекере.

Хотелось бы таки выпустить в этом месяце релиз-кондидат. Фактически ждем на сегодня мы завершения работы над поддержкой компиляции C# и новой версии библиотеки.

Что с библиотекой? Ее ведь нужно еще с компилятором и шаблонами проектов/элементов в Интеграции интегрировать.

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

VD>Что с библиотекой? Ее ведь нужно еще с компилятором и шаблонами проектов/элементов в Интеграции интегрировать.

Большая часть уже сделана и протестирована.
Тем не менее еще есть работа, я собственно уже писал

Автор: Klapaucius
Дата: 25.10.10

, что только к концу месяца планирую ее доделать. Да и это предположительно — у меня все-таки и другие дела есть.
С комментариями не все так радужно, но комментарии можно и к релизу доделать, я потом еще и описание предполагаю сделать, но на русском, надеюсь, если будет нужно, переводчик найдется.

VD>Фактически ждем на сегодня мы новой версии библиотеки.

Виноват.

VD>Хотелось бы таки выпустить в этом месяце релиз-кондидат.

Можно попробовать успеть сделать то, что потом нельзя уже будет поменять (вроде сигнатур функций) пораньше, а потом еще что-нибудь добавить. Тут важно знать, возможны будут еще какие-то работы с библиотекой после выхода релиз-кандидата и насколько они могут быть ломающими. но в любом случае ее до релиза еще тестировать надо, я имею в виду — пользователями тестировать. Тесты у меня есть, но тесты это тесты. Да и отзывов мало, похоже, что стандартная библиотека мало кого интересует.

Да, к слову, есть в Nemerle связывание паттерна с переменной вроде такого:

| Cons(_) @ cons => cons.Foo() // - вызываем метод варианта Cons

Все, что я смог придумать это:

match(lst) {
    | Cons(_) with cons = lst :> InitCell => cons.Foo()

но это как-то уродливо, да и не надежно, каст без проверки в компайл-тайм.

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

K>Да, к слову, есть в Nemerle связывание паттерна с переменной вроде такого:
K>

K>| Cons(_) @ cons => cons.Foo() // - вызываем метод варианта Cons
K>

Как я понял тебе нужно это:

| Cons(_) as cons => cons.Foo() // - вызываем метод варианта Cons

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

K>Можно попробовать успеть сделать то, что потом нельзя уже будет поменять (вроде сигнатур функций) пораньше, а потом еще что-нибудь добавить. Тут важно знать, возможны будут еще какие-то работы с библиотекой после выхода релиз-кандидата и насколько они могут быть ломающими.

Возможно конечно, но все же надо что-то выложить.

K>но в любом случае ее до релиза еще тестировать надо, я имею в виду — пользователями тестировать. Тесты у меня есть, но тесты это тесты. Да и отзывов мало, похоже, что стандартная библиотека мало кого интересует.

Пока она не окажется в общей поставке никаких серьезных откликов ты и не получишь. Потому надо переместить то что есть в Nemerle.dll и начать ее использовать. Тогда и отклик будет.

K>Да, к слову, есть в Nemerle связывание паттерна с переменной вроде такого:
K>

K>| Cons(_) @ cons => cons.Foo() // - вызываем метод варианта Cons
K>

| Cons(_) as cons => cons.Foo() // - вызываем метод варианта Cons

Традиционный вопрос — когда?

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

K>С комментариями не все так радужно, но комментарии можно и к релизу доделать, я потом еще и описание предполагаю сделать, но на русском, надеюсь, если будет нужно, переводчик найдется.

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

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

__>Переводчиков хватит.
__>Тут проблемы не будет.

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

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

__>Переводчиков хватит.
__>Тут проблемы не будет.

Где, кстати, репозиторий либы находится?

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

VD>Где, кстати, репозиторий либы находится?

http://code.google.com/p/nemerle-std/

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

VD>Откровенно говоря по мне так все эти Iter-ы нужно просто выбросить.

Я полностью согласен с тем, что императивный код лучше отделать явно, но я часто применяю такой паттерн:

def processItem(item)
{
  //код обработки отдельного айтема вынесен чтобы не захламлять основной алгоритм
}

// основной алгоритм
...
items.Iter(processItem);
...

Превращать последнюю строчку в

foreach (item in items)
  processItem(item)

очень не хочется

В C# я не использую такой подход, т.к. там нет локальных функций. Там полностью оправдано отсутствие Iter. Можно конечно еще допилить foreach для краткой записи Iter, но я и так не могу запомнить все его возможности.

Либо написать макру типа.

apply processItem on items;

Все же, мне кажется, меньшим злом будет оставить Iter.

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

VD>Традиционный вопрос — когда?

Вообще, я на завершающей стадии работы, но эта завершающая стадия месяц уже продолжается — у меня было не очень много времени для работы над библиотекой. Хотя гуглкод утверждает, что активность проекта "высокая", так что значит, что я не очень ленюсь.
И да, кстати, включите мне разрешение на коммит в nemerle, мой гугл-аккаунт на http://code.google.com/p/nemerle-std/ указан.

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

Z>// основной алгоритм
Z>...
Z>items.Iter(processItem);
Z>...
Z>[/nemerle]

Z>Превращать последнюю строчку в
Z>

Z>foreach (item in items)
Z>  processItem(item)
Z>

Z>очень не хочется

Я по началу тоже так мыслил. Со временем пришел к тому, что не фига маскировать императив под ФП.
К тому же у foreach есть ощутимые преимущества. Он всегда инлайнится, что убирает лишний вызов из колстека, делает код быстрее и упрощает отладку (очень существенно).