Нельзя ли как-нибудь засахарить субж?
Пример кода на C#:

var lst = new []{1,2,3,4,2,3,4,3,4,4};
var g = lst.GroupBy(_ => _);//передается identity function
var d = g.ToDictionary(_=>_.Key, _=>_.Count());

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

Перепишем на Nemerle:

def lst = [1,2,3,4,2,3,4,3,4,4];
def g = lst.GroupBy(x => x);//упс, сахара нет и '_' нельзя использовать
def d = g.ToDictionary(_.Key, _.Count());

Очевидно, что "lst.GroupBy(_)" не подходит...
Если сделать макрос

public macro __()
syntax ("__")
{
  <[ x => x ]>
}

, то получится писать так: "lst.GroupBy(__)".
Нельзя ли этот макрос добавить в стандартную библиотеку?

PS А еще было бы здорово сделать вот эту оптимизацию.
PPS Еще вот тут нашел велосипедик (см Id[T]).

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

A>PS А еще было бы здорово сделать вот эту оптимизацию.

Я бы сделал. Да там все через задницу написано

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

A>Нельзя ли как-нибудь засахарить субж?

Сколько пользуюсь Nemerle — вообще никогда не приходилось использовать вырожденную функцию. Зачем для нее сахар-то?

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

A>Нельзя ли этот макрос добавить в стандартную библиотеку?

А просто функции id не логичнее написать???

module Functions
{
    id[T](x: T):T { x }
}


using Functions;

...
def g = lst.GroupBy(id);

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

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

A>>Нельзя ли как-нибудь засахарить субж?

H>Сколько пользуюсь Nemerle — вообще никогда не приходилось использовать вырожденную функцию. Зачем для нее сахар-то?
Пользуюсь C#, периодически приходится использовать во всяких GroupBy, ToDictionary и OrderBy. Не часто, правда, но все же.

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

J>А просто функции id не логичнее написать???

Тогда уж лучше it =)

J>

J>module Functions
J>{
J>    id[T](x: T):T { x }
J>}


J>using Functions;

J>...
J>def g = lst.GroupBy(id);
J>

Только понадобится еще и одноименный expression. Как устранить конфликт имен я не знаю.

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

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

A>>Нельзя ли этот макрос добавить в стандартную библиотеку?

J>А просто функции id не логичнее написать???


J>

J>module Functions
J>{
J>    id[T](x: T):T { x }
J>}


J>using Functions;

J>...
J>def g = lst.GroupBy(id);
J>

Да, как вариант. Только using всегда писать придется, чтобы модуль Functions открыть.

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

H>>Сколько пользуюсь Nemerle — вообще никогда не приходилось использовать вырожденную функцию. Зачем для нее сахар-то?
A>Пользуюсь C#, периодически приходится использовать во всяких GroupBy, ToDictionary и OrderBy. Не часто, правда, но все же.

Имхо, проще написать свои перегрузки для таких случаев.

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

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

J>>А просто функции id не логичнее написать???

Z>Тогда уж лучше it =)

Ну я из haskell наименование взял. А где it используется (кроме Kotlin ? )

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

Z>>Тогда уж лучше it =)

J>Ну я из haskell наименование взял. А где it используется (кроме Kotlin ? )

Не знаю, но id не выглядит интуитивно понятным

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

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

Z>>>Тогда уж лучше it =)

J>>Ну я из haskell наименование взял. А где it используется (кроме Kotlin ? )

Z>Не знаю, но id не выглядит интуитивно понятным
Как и it, имхо

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

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

H>>>Сколько пользуюсь Nemerle — вообще никогда не приходилось использовать вырожденную функцию. Зачем для нее сахар-то?
A>>Пользуюсь C#, периодически приходится использовать во всяких GroupBy, ToDictionary и OrderBy. Не часто, правда, но все же.

Z>Имхо, проще написать свои перегрузки для таких случаев.
Перегрузка на каждую функцию — не красиво
И для ToDictionary перегрузку не напишешь — не понятно будет, первым параметром эта вырожденная ф-я идет или вторым.
Мне, чисто из эстетических соображений, хотелось бы видеть "__" — по аналогии с "_=>_", которые встречаю в коде на шарпе.
Если бы мои вкусы совпали со мнением большинства и никто этот "__" еще не использовал — можно было бы засунуть его в стандартную поставку.

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

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

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

Z>>>>Тогда уж лучше it =)

J>>>Ну я из haskell наименование взял. А где it используется (кроме Kotlin ? )

Z>>Не знаю, но id не выглядит интуитивно понятным
A>Как и it, имхо

скажи, а почему тебе id кажется не понятным?? Ты же сам назвал тему "Identity function"

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

A>Очевидно, что "lst.GroupBy(_)" не подходит...

Ага. Это частичное применение GroupBy.

A>Если сделать макрос
A>

A>public macro __()
A>syntax ("__")
A>{
A>  <[ x => x ]>
A>}
A>

Это уж перебор. Макрос тут совершенно не нужен. Достаточно объявить такое вот свойство:

module Function[T]
{
  public IdentityFunc : T -> T = x => x;
}

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

Вопрос только в имени. Id не пойдет, так как это слишком часто используемое сокращение от Identifier.
А если имя функции будет длиннее чем x => x, то большая часть людей предпочтет лямбду.

A>PS А еще было бы здорово сделать вот эту оптимизацию.

Она вроде как сделана. По крайней мере класс Identity есть в стандартной библиотеке. Вот только использовать его как ФВП напрямую невозможно. В общем, этого изыска я так и не понял.

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

VD>Она вроде как сделана. По крайней мере класс Identity есть в стандартной библиотеке. Вот только использовать его как ФВП напрямую невозможно. В общем, этого изыска я так и не понял.

Она не сделана. Класс объявлен, но оптимизация не производится.

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

A>Нельзя ли как-нибудь засахарить субж?

В порядке бреда:

' => '

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

_ => _ в Немерле не работает, потому что _ в Немерле не является правильным идентификатором.

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

J>Ну я из haskell наименование взял. А где it используется (кроме Kotlin ? )

Groovy

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

J>>Ну я из haskell наименование взял. А где it используется (кроме Kotlin :-) ? )

Z>Не знаю, но id не выглядит интуитивно понятным :shuffle:

Какие нафиг Котлины и Хаскелли. id — это математическое обозначение, такое же, как 0 в аддитивной группе, 1 в мульипликативной, etc.

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

Q>Какие нафиг Котлины и Хаскелли. id — это математическое обозначение, такое же, как 0 в аддитивной группе, 1 в мульипликативной, etc.

Извини за грубость, но в задницу эту вашу математику и подобную систему наименования.

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

J>

J>...
J>def g = lst.GroupBy(id);
J>

Теперь покажи это тем дотнетчикам, которые имеют дело с СУБД.
Идентификатор id в этом случае вообще контринтуитивен.

Здравствуйте, artelk, Вы писали:
A>Если сделать макрос
…
A>, то получится писать так: "lst.GroupBy(__)".
A>Нельзя ли этот макрос добавить в стандартную библиотеку?

Название не очень. Но что у нас есть: раз — спрос в фиче, несомненно, есть; два — фича используется редко, сами сказали.

Посему, предлагаю пойтить простейшим и очевиднейшим путём: заиспользовать символ ≡ (Triple bar).
Этот символ в точности соответствует двум приведённым выше фактам.

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

_FR>Посему, предлагаю пойтить простейшим и очевиднейшим путём: заиспользовать символ ≡ (Triple bar).
_FR>Этот символ в точности соответствует двум приведённым выше фактам.

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

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

_FR>>Посему, предлагаю пойтить простейшим и очевиднейшим путём: заиспользовать символ ≡ (Triple bar).
_FR>>Этот символ в точности соответствует двум приведённым выше фактам.

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

А три знака равенства "==="? Так можно назвать макрос? Или такой оператор уже где-то используется?

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

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

_FR>А три знака равенства "==="? Так можно назвать макрос? Или такой оператор уже где-то используется?

Назвать можно. В JavaSCript это строгое (с учетом типа) равенство объектов.

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

_FR>А три знака равенства "==="? Так можно назвать макрос? Или такой оператор уже где-то используется?

Можно. Даже метод можно так назвать. Только поймет ли кто-то смысл этого?

Боюсь, что от подобных изысков будут одни проблемы. Экономии по сравнению с "x => x" почти нет. А вот чтобы понять это нужно знать что означает этот самый "===".

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

VD>Экономии по сравнению с "x => x" почти нет.

Дело не в экономии. Любой значок для тождественного отображения лучше, чем явное указание лямбды, потому что обозначает всегда один и тот же экземпляр, а лямбда — теоретически разный.

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

_FR>>>Посему, предлагаю пойтить простейшим и очевиднейшим путём: заиспользовать символ ≡ (Triple bar).

_FR>А три знака равенства "==="? Так можно назвать макрос? Или такой оператор уже где-то используется?

А почему именно «≡» или «===»? Здесь «identity» нужно понимать не как «тождественное равенство», а как «тождественное отображение», то бишь, единицу в соответствующем моноиде. «ℯ», например, если «id» не нравится :)

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

Q>Дело не в экономии. Любой значок для тождественного отображения лучше, чем явное указание лямбды, потому что обозначает всегда один и тот же экземпляр, а лямбда — теоретически разный.

Хорошо, что у нас практический язык и библиотека, а не теоретический. В нем лямбды с одинаковым телом имеют одинаковый смысл.
В прочем, в теории это в точности так же.

Что до любого значка, то любой значок нужно изучать, а чтобы понять что означает "x => x" достаточно изучить понятие лямбда (без которого никуда).

Есть такой принцип "Бритава Оккама". Из него следует, что не надо плодить сущностей больше необходимого. Реальная необходимость в таком операторе есть? Очевидно — нет. Ну, так что делать финтифлюшки рада развлечения?

Сделать функцию Indentity в принципе можно, так как из самого названия будет ясно ее назначение. Но стоит ли? Тут уже количество лишних символов будет даже больше. А вот код будет читаться точно так же.

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

Q>А почему именно «≡» или «===»? Здесь «identity» нужно понимать не как «тождественное равенство», а как «тождественное отображение», то бишь, единицу в соответствующем моноиде. «ℯ», например, если «id» не нравится

Вот именно. Народ уже путается.

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

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

VD>Хорошо, что у нас практический язык и библиотека, а не теоретический. В нем лямбды с одинаковым телом имеют одинаковый смысл.

Нет. Если тебе в функцию приходит другая функция, то ты её можешь в целях оптимизации сравнить с существующим статическим экземпляром, скажем, Functions.Id. А если такой well known функции нет, то твоя лямбда вида x ↦ x будет не равна (ссылочно) такой же лямбде пользователя твоего API.

VD>Есть такой принцип "Бритава Оккама". Из него следует, что не надо плодить сущностей больше необходимого. Реальная необходимость в таком операторе есть? Очевидно — нет.

Очевидно, есть.

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

VD>Людям не пораженным математикой головного мозга...

Зря ты так. Математику нужно любить и изучать. Это наиболее достойная вещь для изучения.

VD>...думать о сквозной функции как о моноидах вряд ли захочется.

Какие ещё «сквозные функции»? Смысл выделения тождественной функции в том, что по отношению к операции композиции ∘ она является нейтральным элементом.

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

Q>Нет. Если тебе в функцию приходит другая функция, то ты её можешь в целях оптимизации сравнить с существующим статическим экземпляром, скажем, Functions.Id.

Ок, в каких сценариях эта оптимизация будет играть заметную роль?

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

Q>>Нет. Если тебе в функцию приходит другая функция, то ты её можешь в целях оптимизации сравнить с существующим статическим экземпляром, скажем, Functions.Id.

H>Ок, в каких сценариях эта оптимизация будет играть заметную роль?

Скажем, надо численно проинтегрировать задаваемую пользователем функцию. В качестве оптимизации очень полезно будет поискать в табличке первообразных, где храняться предпросчитанные функции для Math.Id, Math.Sin, etc.

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

VD>>Хорошо, что у нас практический язык и библиотека, а не теоретический. В нем лямбды с одинаковым телом имеют одинаковый смысл.

Q>Нет. Если тебе в функцию приходит другая функция, то ты её можешь в целях оптимизации сравнить с существующим статическим экземпляром, скажем, Functions.Id. А если такой well known функции нет, то твоя лямбда вида x ↦ x будет не равна (ссылочно) такой же лямбде пользователя твоего API.

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

Сравнение функций, в общем случае, не разрешимая на практике задача. По сему в Н она попросту не решается.

Но это никак не влияет на тот факт, что одинаковые функции имеют одинаковый смысл (семантику). Этого более чем достаточно чтобы понимать, что x => x и y => y означают (и делают) одно и то же.

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

Q>>Нет. Если тебе в функцию приходит другая функция, то ты её можешь в целях оптимизации сравнить с существующим статическим экземпляром, скажем, Functions.Id. А если такой well known функции нет, то твоя лямбда вида x ↦ x будет не равна (ссылочно) такой же лямбде пользователя твоего API.

VD>Казалось бы я на русском языке говорю, а меня умудряются не понимать.

Это ты меня не понимаешь.

VD>Сравнение функций, в общем случае, не разрешимая на практике задача.

Её не надо решать в общем случае. Нужно просто предоставить несколько важных частных. Тебя же не смущает присутствие члена String.Empty при наличии литерала ""?

VD>По сему в Н она попросту не решается.

Странная логика: если нечто не решается в общем случае, то и вообще забить? Кроме того, речь не столько про Н, сколько про .NET и вообще про API стандартных библиотек ФВП.

VD>Но это никак не влияет на тот факт, что одинаковые функции имеют одинаковый смысл (семантику).

Одинаковый смысл не отменяет того факта, что они ссылочно не равны, хотя могли бы, и это было бы полезно.

VD>Этого более чем достаточно чтобы понимать, что x => x и y => y означают (и делают) одно и то же.

Я уже показал

Автор: Qbit86
Дата: 04.08.11

, что дело не только в «понимать».

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

_FR>>>>Посему, предлагаю пойтить простейшим и очевиднейшим путём: заиспользовать символ ≡ (Triple bar).

_FR>>А три знака равенства "==="? Так можно назвать макрос? Или такой оператор уже где-то используется?

Q>А почему именно «≡» или «===»? Здесь «identity» нужно понимать не как «тождественное равенство», а как «тождественное отображение», то бишь, единицу в соответствующем моноиде. «ℯ», например, если «id» не нравится

Очень может быть, тут я не силён. Просто это первый символ, коорый пришёл мне в голову при необходимости обозначить некоторую идентичность. Про то, что такое «ℯ» я не в курсе, но выглядит это конечно лучше, чем оператор.

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

_FR>>А три знака равенства "==="? Так можно назвать макрос? Или такой оператор уже где-то используется?
VD>Можно. Даже метод можно так назвать. Только поймет ли кто-то смысл этого?

Да, тут загвоздка.

VD>Боюсь, что от подобных изысков будут одни проблемы. Экономии по сравнению с "x => x" почти нет. А вот чтобы понять это нужно знать что означает этот самый "===".

Согласен. Может быть, использоваь символ "=>"? Это конечно _немного более_ понятно. Справится ли парсер с этим?

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

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

_FR>>А три знака равенства "==="? Так можно назвать макрос? Или такой оператор уже где-то используется?

H>Назвать можно. В JavaSCript это строгое (с учетом типа) равенство объектов.

Другими словами, тождественность, идентичность. Именно это я и имел в виду.

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

_FR>Согласен. Может быть, использоваь символ "=>"? Это конечно _немного более_ понятно. Справится ли парсер с этим?

=> => =>

должно означать

(x => x) => (x => x)

Или что-то другое?

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

_FR>Здравствуйте, artelk, Вы писали:
A>>Если сделать макрос
_FR>…
A>>, то получится писать так: "lst.GroupBy(__)".
A>>Нельзя ли этот макрос добавить в стандартную библиотеку?

_FR>Название не очень.

Идея такая: _ означает частичное применение функции. Но для того, чтобы функция возникла, нужно c этим _ что-то сделать:

• "_.Key" преобразуется к "x=>x.Key"
  
• "1 + _" — к "x => 1 + x"
  
• "lst.GroupBy(_)" — к "x => lst.GroupBy(x)"

Т.е. _ захватывает свое ближайшее окружение и превращает его в функцию.
Тогда __ было бы специальным случаем частичного применения, когда окружение не захватывается, а оно само образовывало бы функцию.
И "lst.GroupBy(__)" перобразовывался бы к "lst.GroupBy(x=>x)", вместо "x => lst.GroupBy(x)".

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

A>PS А еще было бы здорово сделать [url=http://code.google.com/p/nemerle/issues/detail?id=542&q=label%3APriority-

Оптимизация будет, но сахара не будет, пользуйтесь x => x.

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

_FR>Согласен. Может быть, использоваь символ "=>"? Это конечно _немного более_ понятно. Справится ли парсер с этим?

Мне кажется, что это ситуация в которой просто ничего не надо делать. Хардкейс (вроде как) реализовал оптимизацию и теперь вместо любой сквозной лямбды будет подставляться ссылка на предопределенную функцию. Так что с производительностью все будет ОК. Выражение "x => x" коротко и кристально понятно. Ну, а кому не нравится заведет в личной библиотеке функцию с таким именем которое будет ему понятно.

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

_FR>>Согласен. Может быть, использоваь символ "=>"? Это конечно _немного более_ понятно. Справится ли парсер с этим?

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

Это круто. Пропустил как-то

VD>Так что с производительностью все будет ОК. Выражение "x => x" коротко и кристально понятно. Ну, а кому не нравится заведет в личной библиотеке функцию с таким именем которое будет ему понятно.

+100

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

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

A>>PS А еще было бы здорово сделать [url=http://code.google.com/p/nemerle/issues/detail?id=542&q=label%3APriority-

H>Оптимизация будет, но сахара не будет, пользуйтесь x => x.

Готово.

Судя по ILSpy эта оптимизация реализовалась в компиляторе и библиотеках около десятка раз.

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

VD>Людям не пораженным математикой головного мозга

Ломоносов и Кант о математике иначе отзывались.

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

VD>>Людям не пораженным математикой головного мозга

VE>Ломоносов и Кант о математике иначе отзывались.

В их времена она была несколько другой. И ее не пытались запихнуть в любую работу только чтобы придать ей весомости.