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

K>И да, кстати, включите мне разрешение на коммит в nemerle, мой гугл-аккаунт на http://code.google.com/p/nemerle-std/ указан.

Я ни разу не подлючал именно гугль-экаунты. У всех до этого были жмэйлы.

Если я правильно понял, твой экаунт это klapaucius.the.constructor?

Я его подключил в коммитеры. Попробуй. Если я ошибся, сообщи мне об этом и напиши точное имя экаунта.

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

K>Вообще, я на завершающей стадии работы, но эта завершающая стадия месяц уже продолжается

Ну, так может поднажмешь? Или возьмешь кого-то в помощники?

Я очень хочу до конца года выолжить релиз-кандидат в который хочу включить и эту библиотеку. А то не будет реальных откликов.

И вообще, давно пора ее сливать с компилятором. Хотя бы выложить в отдельное пространство имен.

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

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

Поглядел исходники. В них используется пространство имен System.Linq и типы от туда (например, Enumerable).
Многие высказывались, что используют 2-ой фрэймворк для развертывания своих приложений. Так что стандартная бибилотека не должна быть основана на библиотеках из 3+ фрэймворков.

Надо бы заменить Enumerable на свой велосипед.

Что такое SeqSeq в таблице API?

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

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

Может лучше переименовать MaxIndex в UpperBound?

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

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

В добавок к методам XxxOrNone нужно бы добавить методы XxxOrDefault.

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

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

Это не предложение, а вопрос по языку.

Как я понимаю тут

    public Tail[T](
      [NotNull] this source : Seq[T]
    ) : Seq[T]
    {
      match(source) {
        | source is LazyIterator[T] => source.Tail()
        | _                         => source.TailSeq()
      }
    }

если source является LazyIterator, то должен вызваться специальный метод. Однако я не вижу, почему здесь не будет вечной рекурсии. При проверке is Type в правом выражении переменная автоматически приводится к Type? Как-то неявно это...

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

А если так?
L>Как я понимаю тут
L>

L>    public Tail[T](
L>      [NotNull] this source1 : Seq[T]
L>    ) : Seq[T]
L>    {
L>      match(source1) {
L>        | source2 is LazyIterator[T] => source2.Tail()
L>        | _                         => source1.TailSeq()
L>      }
L>    }
L>

L>если source является LazyIterator, то должен вызваться специальный метод. Однако я не вижу, почему здесь не будет вечной рекурсии. При проверке is Type в правом выражении переменная автоматически приводится к Type? Как-то неявно это...

source1 : Seq[T]
source2 : LazyIterator[T]
там скорее всего есть перегрузка подобная Tail[T](this source : LazyItertor[T]) : LazyItertor[T]

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

L>При проверке is Type в правом выражении переменная автоматически приводится к Type? Как-то неявно это...

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

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

L>При проверке is Type в правом выражении переменная автоматически приводится к Type? Как-то неявно это...

Дык это и есть паттерн проверки типа. Он так работает. Если тип соответствует проверяемому, то внутри блока переменная приводится к этому типу. Аналог гардов из Оберона. Да и в Окамле так можно, если не ошибаюсь.

Чем IEnumerable<> плох?

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

Z>source1 : Seq[T]
Z>source2 : LazyIterator[T]
Z>там скорее всего есть перегрузка подобная Tail[T](this source : LazyItertor[T]) : LazyItertor[T]

А, да, я слепой просто. Спасибо!

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

Z>Сори, не сразу понял суть вопроса. Да, приводится и это очень удобно при матчинге базового типа иерархий объектов. Насчет явности вопрос спорный, для меня было бы нелогичным требование приводить переменную к более строгому типу явно, если уже есть гарантия, что она ему соответствует.

Прикол в том, что я принял

| source is LazyIterator => ...

за guard, а не за паттерн из-за использования is — кажется, что это не булево выражение. Соответственно source для меня был старой, а не новой переменной с таким же именем. В Scala этот паттерн выглядит более явно

case source: LazyIterator => ...

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

L>за guard, а не за паттерн из-за использования is — кажется, что это не булево выражение. Соответственно source для меня был старой, а не новой переменной с таким же именем. В Scala этот паттерн выглядит более явно
L>

L>case source: LazyIterator => ...
L>

Не вижу тут ничего более явного. ":" в немерле — это оператор уточнения типа (не меняющий тип). Он тоже допустим, но скорее всего вызовет ворнинг.

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

VD>Не вижу тут ничего более явного. ":" в немерле — это оператор уточнения типа (не меняющий тип). Он тоже допустим, но скорее всего вызовет ворнинг.

Я ничего и не предлагаю. Я объяснил причину, по которой я неверно прочитал код. В Scala это не оператор уточнения типа, в Scala — это объявление переменной source с типом LazyIterator[T], которая сравнивается с выражением под match. Nemerle — не Scala, но синтаксис очень схож, это и ввело меня в заблуждение.

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

L>Прикол в том, что я принял
L>

L>| source is LazyIterator => ...
L>

L>за guard, а не за паттерн из-за использования is — кажется, что это не булево выражение. Соответственно source для меня был старой, а не новой переменной с таким же именем. В Scala этот паттерн выглядит более явно
L>

L>case source: LazyIterator => ...
L>

В C# и немерле "is" как раз булево выражение, а ":" в данном случае будет upcast (или downcast, все время путаю где там верх, где низ). Вобщем приведение к менее строгому типу.

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


Z>В C# и немерле "is" как раз булево выражение, а ":" в данном случае будет upcast (или downcast, все время путаю где там верх, где низ). Вобщем приведение к менее строгому типу.

: — это указание типа (мнемоническое правило: двоеточие используется при объявлении).
:> — это приведение типа (от общего к частному).

Когда-то в шаблонах вместо is использовался :>

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

Z>В C# и немерле "is" как раз булево выражение,

На самом деле это не так. "is" в Немерле — это паттерн, а не булево выражение. Но смысл, да, близкий.

Z>а ":" в данном случае будет upcast (или downcast, все время путаю где там верх, где низ). Вобщем приведение к менее строгому типу.

В данном случае это тоже не соввсем верно. ":" в паттерн-матчинге — это старый синтаксис для is. Его пометили как деприкейтед именно потому, что его действие шло в разрез со смыслом оператора ":" в языке. Так что впринципе upcast тоже будет работать:

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

H>Когда-то в шаблонах вместо is использовался :>

В каких еще шаблонах? И когда это такое было? Мне кажется, ты что-то путаешь.

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

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

H>>Когда-то в шаблонах вместо is использовался :>

VD>В каких еще шаблонах? И когда это такое было? Мне кажется, ты что-то путаешь.

А, ну значит двоеточие. Я эти времена не застал, просто видел мельком в исходниках.