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

ie>Я вот тут подумал, а ведь этой фитчи мне нехватало пару раз
ie>Например, вот такой случай (я заменил * на $, аля Хаскелл-стайл ):

ie>Думаю надо сувать в Nemerle.Builtins.Function. Сегодня забью feature request и если Немерловцы не против, вчекиню в SVN.
ie>Что по поводу символа оператора? Мож лучше '$', а не '*'?

'$' в Хаскелле — не композиция, а применение функции к аргументу.

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

PM>'$' в Хаскелле — не композиция, а применение функции к аргументу.

Да, я в курсе. Просто точку то мы точно в Немерле заюзать не сможем, а вот '$' пожалуйста. В любом случае я предложил Немерлистам F#-овский вариант: '>>' — композиция и '|>' — пайплайн (аналог Хаскелевского '$', тока задом наперед). Тока Камилу что-то идея с композицией не подуше пришлась

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

ie>Тока Камилу что-то идея с композицией не подуше пришлась

В итоге таки добавили:
'>>' — композиция: (a: 'a->'b) >> (b: 'b->'c) : 'a->'c
'|>' — пайплайн: (a: 'a) |> (b: 'a->'c) : 'c

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

ie>В итоге таки добавили:
ie>'>>' — композиция: (a: 'a->'b) >> (b: 'b->'c) : 'a->'c
ie>'|>' — пайплайн: (a: 'a) |> (b: 'a->'c) : 'c

Уррра!

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

ie>В итоге таки добавили:

using Nemerle.Builtins.Function;
using System.Console;

WriteLine((_ + _ >> _.ToString())(1,2)); // OK
(_ + _ >> _.ToString())(1,2) |> WriteLine // typing fails on ambiguity between overloads

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

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

ie>>Тока Камилу что-то идея с композицией не подуше пришлась

ie>В итоге таки добавили:
ie>'>>' — композиция: (a: 'a->'b) >> (b: 'b->'c) : 'a->'c
ie>'|>' — пайплайн: (a: 'a) |> (b: 'a->'c) : 'c

в каком билде...
в ночном 7392 — нет...

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

M>в каком билде...
M>в ночном 7392 — нет...

Там есть баг: надо обязательно указать:

using Nemerle.Builtins.Function;

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

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

M>>в каком билде...
M>>в ночном 7392 — нет...

N>Там есть баг: надо обязательно указать:

N>

N>using Nemerle.Builtins.Function;
N>

Такое не компилиться:

using Nemerle.Builtins.Function;
using System.Console;

WriteLine((_ + _ >> _.ToString())(1,2));

Ошибка:

sam_7.n:4:12:4:33: error: cannot find the operator `op_RightShift' on (? * ?) -> ? and ? -> ?

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

ie>>В итоге таки добавили:
ie>>'>>' — композиция: (a: 'a->'b) >> (b: 'b->'c) : 'a->'c
ie>>'|>' — пайплайн: (a: 'a) |> (b: 'a->'c) : 'c

N>Уррра!

А я вот сомневаюсь, что запихивание в язык всего что моожно — это хорошо.

Ведь каждая фича усложняет изучение языка. Если она интуитивно понятно, то проблем от нее почти нет. А вот такие навороты будут весьма усложнять восприятие кода новичками.

Как бы не сделать из языка чудовище.

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

ie>>>'>>' — композиция: (a: 'a->'b) >> (b: 'b->'c) : 'a->'c
ie>>>'|>' — пайплайн: (a: 'a) |> (b: 'a->'c) : 'c

VD>А я вот сомневаюсь, что запихивание в язык всего что моожно — это хорошо.

VD>Ведь каждая фича усложняет изучение языка. Если она интуитивно понятно, то проблем от нее почти нет. А вот такие навороты будут весьма усложнять восприятие кода новичками.

VD>Как бы не сделать из языка чудовище.

Согласен. Я вот смотрю на эту запись, и сходу трудно уловить, что она означает. Хорошо, что хоть в курсе происходящего . Только вот нагромождение всех этих палочек/скобочек какой угодно язык сделают птичим, и как бы вот не стало, что в один прекрасный день вместо интуитивно понятного языка мы не увидили бы жуткого монстрика

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

ie>>>В итоге таки добавили:
ie>>>'>>' — композиция: (a: 'a->'b) >> (b: 'b->'c) : 'a->'c
ie>>>'|>' — пайплайн: (a: 'a) |> (b: 'a->'c) : 'c

N>>Уррра!

VD>А я вот сомневаюсь, что запихивание в язык всего что моожно — это хорошо.

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

VD>Ведь каждая фича усложняет изучение языка. Если она интуитивно понятно, то проблем от нее почти нет. А вот такие навороты будут весьма усложнять восприятие кода новичками.

Согласен. Я и сам отношусь к добавлению новых фич скептически. Однако, я предложил добавление этих операторов руководствуясь следующим:
1. В функциональных языках, как правило, есть оператор композиции функций.
2. В некотрых ситуациях он позволяет делать код более выразительным (в своих немногочисленных исходниках на Немерле, я нашел несколько мест, где его применение было бы оправдано).
3. На практике, не так много мест, куда этот оператор можно воткнуть, т.е. вряд ли найдутся умельцы, которые начнут пихать этот оператор направо и налево, тем самым делая код запутанным. Но там где его таки можно использовать по делу, код становиться нагляднее.

Вот оператором '|>', пожалуй, може прибавить путаницы в ряде случаев, я один кусок кода на F# долго понять не мог, причиной тому было неоправданное применение '|>', где только можно. Хотя, в тот момент я пожалуй впервые сталкнулся с '|>', чуть позже этот код читался без проблем.

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

VD>Как бы не сделать из языка чудовище.

Намек понял В следующий раз семь раз (сорри за тавтологию) подумаю, прежде чем предлагать что-то

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

VD>А я вот сомневаюсь, что запихивание в язык всего что моожно — это хорошо.

C этим трудно не согласится, но речь о запихивании всего и не идет.
Просто если в языке функции FCO — то к ним прилагаются и соответствующие способы их конструирования. Если этот набор беден — то уж преимуществом это наврятли может стать.

VD>Ведь каждая фича усложняет изучение языка. Если она интуитивно понятно, то проблем от нее почти нет. А вот такие навороты будут весьма усложнять восприятие кода новичками.

Я с этим не согласен. Композиция не в большей степени птичий язык, чем, допустим, частичное применение. Да и конвейер — вещь интуитивно понятная, как мне кажется.
Вообще эти >> и |> — может и выглядят жутковато сами по себе, но если привести пример кода, от которого они избавляют сразу видно, что существуют они не зря.
Как вот можно читать какой нибудь ужас вроде E(D(C(B(A())))) — у меня от этих скобочек крыша едет. И читается это задом наперед. Конвейер же выглядит вполне нормально A |> B |> C |> D |> E
Так что я считаю, что эти операторы были добавлены совершенно оправдано и обоснованно.

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

ie>Согласен. Я и сам отношусь к добавлению новых фич скептически. Однако, я предложил добавление этих операторов руководствуясь следующим:
ie>1. В функциональных языках, как правило, есть оператор композиции функций.

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

Данные возможности можно было реализовать и без этих расширений. Так что думаю, что они нанесут только вред. Особенно >>, так как в C#, C, C++ и Яве это операторы сдвига, а в С++ это обычно потоковый ввод.

ie>2. В некотрых ситуациях он позволяет делать код более выразительным (в своих немногочисленных исходниках на Немерле, я нашел несколько мест, где его применение было бы оправдано).

Он не интуитивен. И для чтобы его понять надо сначало износиловать себе мозги Хаскелем. А этого болшиство делать не будут просто потому что они себе не враги.

ie>3. На практике, не так много мест, куда этот оператор можно воткнуть,

Это конечно радует, но так же это аргумент за то чтобы вообще не втыкать этого.

ie>т.е. вряд ли найдутся умельцы, которые начнут пихать этот оператор направо и налево, тем самым делая код запутанным. Но там где его таки можно использовать по делу, код становиться нагляднее.

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

ie>Вот оператором '|>', пожалуй, може прибавить путаницы в ряде случаев, я один кусок кода на F# долго понять не мог, причиной тому было неоправданное применение '|>', где только можно. Хотя, в тот момент я пожалуй впервые сталкнулся с '|>', чуть позже этот код читался без проблем.

Во-во. Это аргумент за его полный запрет.

В общем, 1-2 таких выверта язык еще проглотит. А если они будут добавляться как подснежники по весне, то пиши пропало. Язык будет таким же птичьим как Хаскель или ОКамл.

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

Посему еще раз призываю быть особо остарожными в предожении новых фич. Даже если они кажутся вам "супер-кульными" и прекрасными.

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

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

VD>>А я вот сомневаюсь, что запихивание в язык всего что моожно — это хорошо.

K>C этим трудно не согласится, но речь о запихивании всего и не идет.

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

K>Просто если в языке функции FCO — то к ним прилагаются и соответствующие способы их конструирования. Если этот набор беден — то уж преимуществом это наврятли может стать.

В языке уже были аналоги этих операторов. Это еще один путь. И он привдет только к одному. Нечитаемости кода для массового программиста.

Я понимаю, что ты и ie этот код в силах понять, но мне будет очень обидно если на этом список будет исчерпан.

VD>>Ведь каждая фича усложняет изучение языка. Если она интуитивно понятно, то проблем от нее почти нет. А вот такие навороты будут весьма усложнять восприятие кода новичками.

K>Я с этим не согласен. Композиция не в большей степени птичий язык, чем, допустим, частичное применение. Да и конвейер — вещь интуитивно понятная, как мне кажется.

Хрен там. Это из серии переворачивания мога. Любой императивный программист даже на понимании объеяснения действия этих оператора мозг свихент. А уж если он увидит без объяснения, то вообще задница будет.

Что косается частичного применения, то оно дает реальный выигрыш на прктике. К сожалению, оно тоже не очень интуитивно, но обяснить его куда проще.

K>Вообще эти >> и |> — может и выглядят жутковато сами по себе, но если привести пример кода, от которого они избавляют сразу видно, что существуют они не зря.
K>Как вот можно читать какой нибудь ужас вроде E(D(C(B(A())))) — у меня от этих скобочек крыша едет. И читается это задом наперед. Конвейер же выглядит вполне нормально A |> B |> C |> D |> E
K>Так что я считаю, что эти операторы были добавлены совершенно оправдано и обоснованно.

Я уже говорил, что нормальным входом из ситуации является не введение |>, а реализация методов-расширения. К тому же ситуация когда есть много функций с одинм параметром — это утопия. Реальность несколько сложнее. Функции расширения без проблем справляются с этим.

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

С++ и современные ФЯ тоже не сразу стали монстрами. Их к этому привели бездумие и наплевательское отношение на новичков их авторов.

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

K>Как вот можно читать какой нибудь ужас вроде E(D(C(B(A())))) — у меня от этих скобочек крыша едет. И читается это задом наперед. Конвейер же выглядит вполне нормально A |> B |> C |> D |> E

А можно тупой вопрос? Как мне в виде конвейера записать

E(D(C(B(A()),48)))

?

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

БП>А можно тупой вопрос? Как мне в виде конвейера записать

E(D(C(B(A()),48)))

?

(A()|>B,48)|>C|>D|>E

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

ie>

ie>(A()|>B,48)|>C|>D|>E
ie>

Только весь вывод типов слетел к чертям.

def a () {1};
def b (x) {x};
def c (x, y) {x * y.GetArrayRank()};
def res = c(b(a()), typeof(int));

Компиляется на ура, но

def a () {1};
def b (x) {x};
def c (x, y) {x * y.GetArrayRank()};
def res = (a()|>b,typeof(int))|>c;

Говорит: "Вы чего? какой такой GetArrayRank???"

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

ie>>2. В некотрых ситуациях он позволяет делать код более выразительным (в своих немногочисленных исходниках на Немерле, я нашел несколько мест, где его применение было бы оправдано).
VD>Он не интуитивен. И для чтобы его понять надо сначало износиловать себе мозги Хаскелем. А этого болшиство делать не будут просто потому что они себе не враги.

Причем тут Хаскель? Чтоб понять лямбду тоже себе мозги насиловать надо? Про композицию функций рассказывают на первом курсе!

ie>>т.е. вряд ли найдутся умельцы, которые начнут пихать этот оператор направо и налево, тем самым делая код запутанным. Но там где его таки можно использовать по делу, код становиться нагляднее.

VD>Поверь, умельцы найдутся на раз. А потом туча народа будут как бараны на новые ворота смотрить.
VD>До сих пор когда я приводил код на Немерле людям знакомым с С-подобными языками у них он особых проблем в понимании не вызвал. А твой вызовет обязательно. Что на мой взгля прямой вред.

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

Автор: Vinick
Дата: 10.02.07

:

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

А что там в функции process? Ничего, кроме patter-matching'а! Так что для программистов C#, C, C++ и Java, там многое будет новое.

ie>>Вот оператором '|>', пожалуй, може прибавить путаницы в ряде случаев, я один кусок кода на F# долго понять не мог, причиной тому было неоправданное применение '|>', где только можно. Хотя, в тот момент я пожалуй впервые сталкнулся с '|>', чуть позже этот код читался без проблем.
VD>Во-во. Это аргумент за его полный запрет.

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

VD>Посему еще раз призываю быть особо остарожными в предожении новых фич. Даже если они кажутся вам "супер-кульными" и прекрасными.

Ну я уже пообещал

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

БП>Только весь вывод типов слетел к чертям.
БП>Говорит: "Вы чего? какой такой GetArrayRank???"

Ага, слетает, nikov уже подмечал

Автор: nikov
Дата: 08.02.07

Можно оформить '|>' в виде макроса, тогда проблем такого рода быть не должно, но, к сожалению, вылезут другие

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

ie>Можно оформить '|>' в виде макроса, тогда проблем такого рода быть не должно, но, к сожалению, вылезут другие

А какие другие? Вот такой простой макрос работает неплохо:

macro @|> (a, b)
{
    <[ $b($a) ]>
}

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