Данное предложение навеяно обсуждением По поводу foreach / else

Автор: VladD2
Дата: 22.07.10

, где предлагается расширить макросы циклов загадочной Питоновской фичей "else" которая, по всей видимости, была введена в язык для поиска значений в коллекциях методом перебора (если я не прав, то объясните мне глубинную суть этой фичи).

Если я прав и основная цель данной фичи — это поиск, то намного лучше было бы вместо вместо добавления else/otherwise к циклам создать некий макрос find, который позволит сделать синтаксис поиска более компактным, а сам поиск более эффективным? Синтаксис может быть примерно таким:

"find" "(" idOrPattern "when" condition "in" collection  ("with" index)? ")" body ("notfound" expr)?

где

idOrPattern : PExpr // может быть как просто именем переменной, так и сложным паттерном (как в foreach).
condition   : PExpr
index       : PExpr
collection  : PExpr
body        : PExpr
expr        : PExpr

Примеры использования:

def res = find (x when x > 10 && x % 2 == 0 in [1 .. 100]) x * 42 notfound 0;

// или императивный (возвращающий void) вариант:
mutable res;

find (x when x > 10 && x % 2 == 0 in [1 .. 100])
  res = x; // тут...
notfound
  res = 0; // и тут, естественно, могут быть любые выражения, в том числе блок кода.

Вариант с индексом и без notfound:
def ary = arry[1 .. 100];

find (x when x > 10 && x % 2 == 0 in ary with i) // В i находится индекс найденного элемента
  ary[i] = x * 42; // обновляем первый найденный элемент массива (но не все, как в случае с циклом).

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

find == seq.Filter().FirstOrDefault(), да?

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

C>find == seq.Filter().FirstOrDefault(), да?

Все несколько сложнее. Примеры я привел (там можно использовать императив). К тому же реализация будет более эффективна. Ведь Filter() возвратит все элементы подходящие под критерии поиска. Но в целом что-то вроде этого.

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

C>find == seq.Filter().FirstOrDefault(), да?

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

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

C>find == seq.Filter().FirstOrDefault(), да?

Если переписывать это дело в функции высшего порядка, то скорее аналогом будет:

seq.Find(...) ?? ...;

или:

match (seq.Find(...))
{
  | Some(value) => Use(value)
  | _           => DoDefaultStaff()
}

или, для вариантов без notfound:

when (seq.Find(...) is Some(value)
  Use(value);

Но при этом код будет переписываться в циклы, что простит отладку и повысит скорость работы кода.

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

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

C>>find == seq.Filter().FirstOrDefault(), да?

VD>Фактически макрос будет разворачиваться в циклы и if-ы, для эффективности. Плюс упрощается обработка результата (найденный результат можно специальным образом обработать или сделать при его нахождении некие императивные действия).

Ну, у меня принцип: не сотвори макрос для того, что можно сделать комбинатором.

К тому же, в linq уже есть select/where. Никто ведь не мешает его специализировать для IEnumerable.

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

C>Ну, у меня принцип: не сотвори макрос для того, что можно сделать комбинатором.

Это фиговый принцип. Скажем по этому принципу макросы: if/else, when, for, foreach, а почти все макросы являются лишними.

C>К тому же, в linq уже есть select/where. Никто ведь не мешает его специализировать для IEnumerable.

Она и так с IEnumerable работают. Вот только код для поиска конкретного элемента короче не становится от этого. И уж точно не становится быстрее.

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

when (seq.Find(x => x % 2 == 0) is Some(value))
  Use(value);

Или:

def index = seq.FindIndex(x => x % 2 == 0);

when (i >= 0)
  Use(value & index);

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

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

VD>Это фиговый принцип. Скажем по этому принципу макросы: if/else, when, for, foreach, а почти все макросы являются лишними.

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


VD>Она и так с IEnumerable работают. Вот только код для поиска конкретного элемента короче не становится от этого. И уж точно не становится быстрее.

Под "специализировать" я имел в виду "сделать быстрее".

VD>Я себя много раз ловил на том, что при поиске элемента я вынужден описывать некий стандартный паттерн, вроде:
VD>

VD>when (seq.Find(x => x % 2 == 0) is Some(value))
VD>  Use(value);
VD>

VD>Или:
VD>

VD>def index = seq.FindIndex(x => x % 2 == 0);

VD>when (i >= 0)
VD>  Use(value & index);
VD>

У класса option есть методы Map и Iter: seq.Find(predicate).Iter(Use). Use, соответственно, исполняется только для Some.

VD>Конечно это не такой уж большой объем кода, и не такой уж большой оверхэд, но зачем все это, если свою мысль можно выразить более прямо и не иметь никакого оверхэда?

Оверхэд — новый синтаксис, который дублирует linq, методы в стандартной библиотеке, и про который нужно узнать новичкам. Ну, и сам макрос, который нужно будет поддерживать в дальнейшем.

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

VD>>Это фиговый принцип. Скажем по этому принципу макросы: if/else, when, for, foreach, а почти все макросы являются лишними.

C>Уровня выражений — ну не знаю, я редко использую другие (часто еще анонимные классы и with, которые нельзя заменить комбинаторами). На уровне классов — почти все незаменимы.

Ты не используешь if/else, when, for, foreach?

VD>>Она и так с IEnumerable работают. Вот только код для поиска конкретного элемента короче не становится от этого. И уж точно не становится быстрее.

C>Под "специализировать" я имел в виду "сделать быстрее".

А как можно IEnumerable сделать быстрее? В макросах как раз и есть кайф в том, что в них можно проанализировать тип коллекции и сгенерировать более эффективный код. Плюс к тому же макросы позволяют обходиться без лямбд, что с одной стороны упрощает синтаксис, а с другой делает код более быстрым (избавляя его от замыканий, а значит от динамически создаваемых объектов). Что касается производительности, то конечно более грамотно было бы сделать более аггресивный оптимизирующий инлайнинг, но эта задача весьма не простая. На нее нужно много времени. А макрос можно добавить за 2-3 часа и он даст преимущества именно там где они нужны и уже сейчас!

C>У класса option есть методы Map и Iter: seq.Find(predicate).Iter(Use). Use, соответственно, исполняется только для Some.

Ага, есть. Только, правда, методы расширения, но это не так важно.
Важнее то, что даже я о них не очень то помню, а уж многие новички и подавно. И важно, то что это приводит к дополнительному наворачиванию лямбд, функциональных объектов, и главное, паттернов. А это значит замедление в рантайме, необходимость тратить время на распознавание паттернов в коде и как результат усложнение понимания кода и его отладки. И ради чего это? Ради мифической чистоты?

Мне кажется, что идея наличия одного пути — это не про Немерл. Это про Хаскель, возможно про ВБ, но не про Немерл.
Так что не вижу ничего плохого если будет и ФВП и аналогичный макрос. В конеце концов никто же не возмущается, что есть foreach и Iter?

VD>>Конечно это не такой уж большой объем кода, и не такой уж большой оверхэд, но зачем все это, если свою мысль можно выразить более прямо и не иметь никакого оверхэда?

C>Оверхэд — новый синтаксис, который дублирует linq, методы в стандартной библиотеке, и про который нужно узнать новичкам.

Да сам линк дублирует многие функции из стандартной библиотеки. Ну, и что?
Я как раз вижу алогизм в том, что у нас есть foreach/Iter, но нет find/Find.

C>Ну, и сам макрос, который нужно будет поддерживать в дальнейшем.

Мы поддерживаем уже кучу макросов и как-то не испытываем от этого неудобств.
Меня больше заботит простота чтения кода и эффективность получаемых программ. Именно это я и имею в виду под словом "оверхэд".

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

VD>Ты не используешь if/else, when, for, foreach?

If, when и for довольно сложно заменить комбинаторами, поэтому я ими как раз пользуюсь. Неправильно прочитал ваши строки.

VD>А как можно IEnumerable сделать быстрее? В макросах как раз и есть кайф в том, что в них можно проанализировать тип коллекции и сгенерировать более эффективный код. Плюс к тому же макросы позволяют обходиться без лямбд, что с одной стороны упрощает синтаксис, а с другой делает код более быстрым (избавляя его от замыканий, а значит от динамически создаваемых объектов). Что касается производительности, то конечно более грамотно было бы сделать более аггресивный оптимизирующий инлайнинг, но эта задача весьма не простая. На нее нужно много времени. А макрос можно добавить за 2-3 часа и он даст преимущества именно там где они нужны и уже сейчас!

Вот именно это можно сделать в макросе linq.

VD>Ага, есть. Только, правда, методы расширения, но это не так важно.

Нет, они встроенные. Потому что option — не коллекция.

VD>Важнее то, что даже я о них не очень то помню, а уж многие новички и подавно. И важно, то что это приводит к дополнительному наворачиванию лямбд, функциональных объектов, и главное, паттернов. А это значит замедление в рантайме, необходимость тратить время на распознавание паттернов в коде и как результат усложнение понимания кода и его отладки.

Лямбды должны инлайнится, паттерны — разворачиваться в if'ы. Не так ли? Судя по тому, что показывает дебаггер, в большинстве простых случаев так и происходит.

VD>И ради чего это? Ради мифической чистоты?

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

VD>Да сам линк дублирует многие функции из стандартной библиотеки. Ну, и что?
VD>Я как раз вижу алогизм в том, что у нас есть foreach/Iter, но нет find/Find.

Я думал, foreach больше для совместимости с C#. А по вашей логике, нужно еще sort (seq) { ... } добавить, group (seq ) by { ... }, filter и так далее. То есть, опять-таки, получится linq (я не против linq, но у нас уже есть один).

VD>Мы поддерживаем уже кучу макросов и как-то не испытываем от этого неудобств.
VD>Меня больше заботит простота чтения кода и эффективность получаемых программ. Именно это я и имею в виду под словом "оверхэд".

Как по мне, комбинатор проще чем макрос, к которому никогда не знаешь всех возможных опций (я только недавно узнал, что Accessor может делать protected-поля).

Хочу заметить, я не против макроса find самого по себе. Пусть себе живет в Nemerle.Extensions. Но в Nemerle.Core (или даже Nemerle.Utility) он вряд ли нужен.

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

VD>find (x when x > 10 && x % 2 == 0 in ary with i) // В i находится индекс найденного элемента
VD>  ary[i] = x * 42; // обновляем первый найденный элемент массива (но не все, как в случае с циклом). 
VD>

Индекс будет инкркментироваться только при выполнении критерия поиска или для каждого элемента из ary? Оба варианта могут быть одинаково полезны в зависимости от ситуации, так что с интуитивностью дело плохо. Может вместо просто i писать кортеж, например так

find (x when x > 10 && x % 2 == 0 in ary with (i, j)) // В i находится индекс найденного элемента, в j номер итерации

или так

find (x when x > 10 && x % 2 == 0 in ary with (i, _))
find (x when x > 10 && x % 2 == 0 in ary with (_, j))

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

C>Как по мне, комбинатор проще чем макрос, к которому никогда не знаешь всех возможных опций (я только недавно узнал, что Accessor может делать protected-поля).

Это кстати проблема документирования макросов и доступа к этой документации.
Кстати было бы здорово, чтобы к макросам <summary/> можно было писать (или я просто об этом не знаю?).

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

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

VD>>find (x when x > 10 && x % 2 == 0 in ary with i) // В i находится индекс найденного элемента
VD>>  ary[i] = x * 42; // обновляем первый найденный элемент массива (но не все, как в случае с циклом). 
VD>>

SAS>Индекс будет инкркментироваться только при выполнении критерия поиска или для каждого элемента из ary? Оба варианта могут быть одинаково полезны в зависимости от ситуации, так что с интуитивностью дело плохо. Может вместо просто i писать кортеж, например так
SAS>

SAS>find (x when x > 10 && x % 2 == 0 in ary with (i, j)) // В i находится индекс найденного элемента, в j номер итерации 
SAS>

SAS>или так
SAS>

SAS>find (x when x > 10 && x % 2 == 0 in ary with (i, _))
SAS>find (x when x > 10 && x % 2 == 0 in ary with (_, j))
SAS>

/* hardcase */

Кортежи не айс — что есть номер найденного элемента, а что — индекс в последовательности?

Лучше разделить имена и добавить недвусмысленные ключевые слова:

find (x when x > 10 && x % 2 == 0 in ary index i position pos)

i — порядковый номер найденного элемента
pos — абсолютный номер в последовательности

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

VD>Данное предложение навеяно обсуждением По поводу foreach / else

Автор: VladD2
Дата: 22.07.10

, где предлагается расширить макросы циклов загадочной Питоновской фичей "else" которая, по всей видимости, была введена в язык для поиска значений в коллекциях методом перебора (если я не прав, то объясните мне глубинную суть этой фичи).

В питоне есть такое понятие как "питоничность". Это когда написанный код максимально выдержан в духе "дзена питона", каковой описан официально в одном из PEP. Так вот (с моей, дилетантской т.з.) "немерличной" эта фича могла бы выглядеть, как введение нового паттерна "итератор" в конструкцию PM:

def res = match([1..100])
{
    | iter x when x > 10 && x % 2 == 0 => x * 42
    | _ => 0
}

match(ary)
{
    | iter x with i when x > 10 && x % 2 == 0 => ary[i] = x * 42
    | _ => {}
}

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

VD>>А как можно IEnumerable сделать быстрее? В макросах как раз и есть кайф в том, что в них можно проанализировать тип коллекции и сгенерировать более эффективный код. Плюс к тому же макросы позволяют обходиться без лямбд, что с одной стороны упрощает синтаксис, а с другой делает код более быстрым (избавляя его от замыканий, а значит от динамически создаваемых объектов). Что касается производительности, то конечно более грамотно было бы сделать более аггресивный оптимизирующий инлайнинг, но эта задача весьма не простая. На нее нужно много времени. А макрос можно добавить за 2-3 часа и он даст преимущества именно там где они нужны и уже сейчас!

C>Вот именно это можно сделать в макросе linq.

В одном слове — нельзя.

VD>>Ага, есть. Только, правда, методы расширения, но это не так важно.

C>Нет, они встроенные. Потому что option — не коллекция.

Коллекция тут не причем. Как и все другие структуры данных немерла (даже list[T]) option[T] — это банальный класс.
Ознакомься на досуге: option.n
Перечисленные тобой методы реализованы в виде методов-расширений (т.е. статических функций) в модуле Option:

  public module Option
  {
    ...
    /**
     * Safe optional value mapping.
     */
    public Map [T, TTo] (this x : option [T], f : T -> TTo) : option [TTo]
    {
      match (x) {
        | Some (x) => Some (f (x))
        | null     => throw System.ArgumentException ("option can't be null")
        | None => None ()
      }
    }    

    /**
     * Same as ignore (Map (x, f)).
     */
    public Iter [T] (this x : option [T], f : T -> void) : void
    {
      match (x) {
        | Some (x)    => f (x)
        | null | None => ()
      }
    }

VD>>Важнее то, что даже я о них не очень то помню, а уж многие новички и подавно. И важно, то что это приводит к дополнительному наворачиванию лямбд, функциональных объектов, и главное, паттернов. А это значит замедление в рантайме, необходимость тратить время на распознавание паттернов в коде и как результат усложнение понимания кода и его отладки.

C>Лямбды должны инлайнится

Это очень не просто, особенно если функция в которую они передаются является библиотечной. Ведь для инлайнинга лябд нужно инлайнить и фукнцию которая их получает. Плюс при инлайнинге возникает очень много вопросов. Ведь язык императивный (хотя бы на половину). Так что многие предположения могут оказаться неверны.

C>, паттерны — разворачиваться в if'ы. Не так ли?

Под паттернами здесь я понимаю некие приемы програмирования. Скажем чтобы найти элемент мне мало вызвать функцию Find. Мне так же нужно обработать результат и случай когда элемент не найден. В предлагаемом макросе эти вопросы решаются. В случае функций высшего порядка мы имеем грязь от лямбд, плюс грязь код который обрабатывает результат. В место получается некоторый объем лишнего кода (кода которого могло бы не быть). А так как применяется данный метод часто, то со временем код проекта загромождается этим ничего не дающим кодом.

C>Судя по тому, что показывает дебаггер, в большинстве простых случаев так и происходит.

Я не знач то там тебе показывает дебагер. Я знаю как работает компилятор. Если лямбда передается в метод, она превращается или в статическую функцию, или в класс. Пол любому при вызове лямбды создается объект, а вызов производится через виртуальные методы.

VD>>И ради чего это? Ради мифической чистоты?

C>Скорее, ради того, чтобы библиотека языка не превращалась в свалку полезных в разной степени функций и макросов.

Это и есть мифическая чистота. Макрос вроде foreach, when и т.п. тоже бесполезны, если смотреть на макросы в таком ключе. Однако на практике их используют значительно чаще чем аналогичные функции, так как это проще, быстрее и удобнее. В общем, если макрос решает некоторую проблему лучше чем функция, то он имеет право на жизнь. И на мой взгляд тут макрос find ничем не отличается от макроса foreach, к примеру. И то и другое автоматизация паттерна программирования.

C>Я думал, foreach больше для совместимости с C#.

Ты ошибаешся. foreach многократно удобнее (во многих случаях), нагляднее, мощнее и быстрее Iter. Я часто, в коде компилятора, заменяю использование Iter на foreach. Это упрощает отладку и повышает читаемость кода. В отличии от Iter foreach полностью инлайнится, что упрощает отладку и ускоряет код.

C>А по вашей логике, нужно еще sort (seq) { ... } добавить, group (seq ) by { ... }, filter и так далее. То есть, опять-таки, получится linq (я не против linq, но у нас уже есть один).

Моя логика проста. Если макра дает приемущества, то ее надо добавить. Собственно для group и т.п. макрос есть — это поддержка синтаксиса линка. В случае с group он дает преимущества. Так что от части твои слова верны.

VD>>Мы поддерживаем уже кучу макросов и как-то не испытываем от этого неудобств.
VD>>Меня больше заботит простота чтения кода и эффективность получаемых программ. Именно это я и имею в виду под словом "оверхэд".

C>Как по мне, комбинатор проще чем макрос, к которому никогда не знаешь всех возможных опций (я только недавно узнал, что Accessor может делать protected-поля).

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

C>Хочу заметить, я не против макроса find самого по себе. Пусть себе живет в Nemerle.Extensions. Но в Nemerle.Core (или даже Nemerle.Utility) он вряд ли нужен.

Мне кажется все макросы одного класса должны быть в одном пространстве имен. Хотя в прочем, тот вопрос уже не так важен.

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

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

VD>>find (x when x > 10 && x % 2 == 0 in ary with i) // В i находится индекс найденного элемента
VD>>  ary[i] = x * 42; // обновляем первый найденный элемент массива (но не все, как в случае с циклом). 
VD>>

SAS>Индекс будет инкркментироваться только при выполнении критерия поиска или для каждого элемента из ary?

Это не цикл. Тело find вызовется один раз и только если элемент был найден.

SAS>Оба варианта могут быть одинаково полезны в зависимости от ситуации, так что с интуитивностью дело плохо.

Я совершенно не понимаю о чем идет речь.

SAS>Может вместо просто i писать кортеж, например так
SAS>[Nemerle]
SAS>find (x when x > 10 && x % 2 == 0 in ary with (i, j)) // В i находится индекс найденного элемента, в j номер итерации

И чем эти значения отличаются?

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

H>Кстати было бы здорово, чтобы к макросам <summary/> можно было писать (или я просто об этом не знаю?).

На сегодня нельзя.

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

VD>Это не цикл. Тело find вызовется один раз и только если элемент был найден.

SAS>>Оба варианта могут быть одинаково полезны в зависимости от ситуации, так что с интуитивностью дело плохо.

VD>Я совершенно не понимаю о чем идет речь.

Тогда не слишком понятно зачем нужен таковой макрос. Слишком уж задача специфическая мне кажется...

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

VD>Это не цикл. Тело find вызовется один раз и только если элемент был найден.

Ну если только один раз, то вопрос снимается. Я думал предполагалось, что find вернет коллекцию или список.

Тогда другой вопрос. Какой тип будет у выражения find? Раз уж часть notfound необязательная, то надо, видимо, возваращать option. Но если notfound указан, то option будет только мешать. Кажется логичным отдавать option[T] в первом случае и T во втором.

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

SAS>Ну если только один раз, то вопрос снимается. Я думал предполагалось, что find вернет коллекцию или список.

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

SAS>Тогда другой вопрос. Какой тип будет у выражения find?

Зависит от того какой тип будет у выражения внутри тела. В том числе это может быть и void.

SAS>Раз уж часть notfound необязательная, то надо, видимо, возваращать option.

Если часть notfound не указана, то тип будет void и возвращать ничего будет нельзя. Иначе опять же проще использовать метод Find.

SAS>Но если notfound указан, то option будет только мешать. Кажется логичным отдавать option[T] в первом случае и T во втором.

Мне кажется, что option[T] лишний. Если нужна обработка, то проще просто не указывать notfound и сделать нужные действия в теле find.