Так как замечательный — даже не знаю, как назвать, оператор? — "_" обрабатывается видимо по принципу: самое первое выражение, которое его содержит и которое отлично от "_" превращается в функцию, то это приводит к тому, что выражение в функции, которая будет создана с помощью "_", зависит от таких вещей как приоритет операторов.
Собственно, вопрос — это сайд-эффект или задумывалось специально? Есть ли какое-нибудь описание того, как должно вести себя частичное применение в различных случаях?
Здравствуйте, Воронков Василий, Вы писали:
ВВ>Так как замечательный — даже не знаю, как назвать, оператор? — "_" обрабатывается видимо по принципу: самое первое выражение, которое его содержит и которое отлично от "_" превращается в функцию, то это приводит к тому, что выражение в функции, которая будет создана с помощью "_", зависит от таких вещей как приоритет операторов.
ВВ>Собственно, вопрос — это сайд-эффект или задумывалось специально? Есть ли какое-нибудь описание того, как должно вести себя частичное применение в различных случаях?
Вообще ничего не понял. Можно на примерах.
ЗЫ
"_" — это символ-заместитель (вилдкард). Он в разных местах используется по разному.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
ВВ>>Собственно, вопрос — это сайд-эффект или задумывалось специально? Есть ли какое-нибудь описание того, как должно вести себя частичное применение в различных случаях?
VD>Вообще ничего не понял. Можно на примерах.
Я про partial application и, соответственно, использование "_" для объявления функций. Примеры простые:
def x = 2 * 3 + _; //OK
def x = 2 + 3 * _; //error
Понятно, почему error, понятно в принципе, какова "внутренняя логика" компилятора (или даже парсера?) здесь.
Непонятно — это было сделано специально или получилось "само собой". И если специально — собственно, какой rationale для такого поведения?
Мне вот такое поведение показалось не очень правильным
Здравствуйте, Воронков Василий, Вы писали:
ВВ>Я про partial application и, соответственно, использование "_" для объявления функций.
С этого надо было начинать.
ВВ>Примеры простые:
ВВ>def x = 2 * 3 + _; //OK
ВВ>def x = 2 + 3 * _; //error
ВВ>Понятно, почему error, понятно в принципе, какова "внутренняя логика" компилятора (или даже парсера?) здесь.
Это логика любого компилятора у которого есть приоритеты операторов.
На самом деле, код бессмысленный в обоих примерах. Просто в первом за счет приоритета оператора "*" выше и выражение получается таким: "(2 * 3) + _" что переписывается в fun(x) { 6 + _ } так как для констант производится свертка.
Во втором случае, в следствии приоритета оператора "*", код переписывается в "2 + fun(x) { 6 + x }" и естественно получается ошибка, так как производится попытка сложить функцию и целое значение.
ВВ>Непонятно — это было сделано специально или получилось "само собой". И если специально — собственно, какой rationale для такого поведения?
Все было сделано специально само собой.
Просто ты как-то странно понимаешь этот самый "_". "_" — это заглушка. В данном случае она идет вместо одного из операндов оператора "+" или "*" и превращает их в функцию от одного аргумента возвращающую результата операции.
ВВ>Мне вот такое поведение показалось не очень правильным
Ты видимо считал, что все выражение должно превратиться в функцию. Но это не так.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Это логика любого компилятора у которого есть приоритеты операторов. VD>На самом деле, код бессмысленный в обоих примерах. Просто в первом за счет приоритета оператора "*" выше и выражение получается таким: "(2 * 3) + _" что переписывается в fun(x) { 6 + _ } так как для констант производится свертка. VD>Во втором случае, в следствии приоритета оператора "*", код переписывается в "2 + fun(x) { 6 + x }" и естественно получается ошибка, так как производится попытка сложить функцию и целое значение.
Это я прекрасно понимаю, я не понимаю, почему приоритет операторов тут должен играть какую-то роль.
VD>Все было сделано специально само собой. VD>Просто ты как-то странно понимаешь этот самый "_". "_" — это заглушка. В данном случае она идет вместо одного из операндов оператора "+" или "*" и превращает их в функцию от одного аргумента возвращающую результата операции.
Почему странно понимаю? Так и понимаю. По сути в вышепоказанных примерах "_" используется как сокращенный синтаксис для объявления функции.
ВВ>>Мне вот такое поведение показалось не очень правильным VD>Ты видимо считал, что все выражение должно превратиться в функцию. Но это не так.
На мой взгляд было бы более логичным если бы в обоих случаях все выражение справа превратилось бы в функцию. Собственно, вопрос — зачем так было сделано? Я не вижу проблем в реализации разбора так, чтобы в обоих случаях получился корректный код. Есть какая-то идеология, которая стоит за этим?
Кстати, а откуда была взята эта идея с "_"? Есть какие-то еще языки с подобной реализацией partial application?
Здравствуйте, Воронков Василий, Вы писали:
ВВ>Это я прекрасно понимаю, я не понимаю, почему приоритет операторов тут должен играть какую-то роль.
Потому что ты имеешь дело с операторами.
Выражение сначала парсится и в нем выявляются операторы, а потому же выполняется вся остальная логика компилятора.
ВВ>Почему странно понимаю?
Хороший вопрос, но не ко мне.
ВВ>Так и понимаю. По сути в вышепоказанных примерах "_" используется как сокращенный синтаксис для объявления функции.
Ага. Из оператора.
ВВ>На мой взгляд было бы более логичным если бы в обоих случаях все выражение справа превратилось бы в функцию.
Искусственный интеллект еще не изобрели .
ВВ>Кстати, а откуда была взята эта идея с "_"?
Это ты у авторов спаси.
ВВ>Есть какие-то еще языки с подобной реализацией partial application?
Все языки линейки МЛ (МЛ, ОКамл, Хаскель...) обладали каррингом. Но из-за этого карринга там все функции записываются в стиле x -> y -> z, а не x * y -> z, что конфликтует с применением скобок (как в математике и С) и создает ряд своих проблем. Поляки придумали прямую поддержку частичному применению.
ЗЫ
На мой взгляд частичное применение как и карринг — это не более чем мелкий сахарок. Я не понимаю почему некоторые фанаты уделяют ему такое внимание.
Так что если сомневаешься, то просто используй макрос =>. Много не проиграешь, зато всем будет ясно твое намерение.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Воронков Василий, Вы писали: ВВ>>Это я прекрасно понимаю, я не понимаю, почему приоритет операторов тут должен играть какую-то роль. VD>Потому что ты имеешь дело с операторами. VD>Выражение сначала парсится и в нем выявляются операторы, а потому же выполняется вся остальная логика компилятора.
У меня, например, частичное применение отслеживается вообще еще на уровне парсера — причем можно с легкостью добиться такого же поведения, как в Немерле. Это вопрос, когда именно нам нужно "смотреть", стоит ли превращать выражение в функцию или нет. В общем случае — у меня есть лишь одна проверка на уровне продукции Expr. В итоге код:
let x1 = 2 * 3 + _;
let x2 = 2 + 3 * _;
cout x1(4);
cout x2(4);
вполне валиден и выводит
10
14
Само собой не все так просто, и в ряде случаев, например, для операторов, операндами которых должны быть функции (например, композиция функций), приходится вставлять дополнительные проверки, но в целом ничего страшного.
Причем, как бы ни реализовывать, все равно будет куча ситуаций, где окажется не совсем очевидным, "сколько тут функций", какое именно выражение попадает в функцию и пр.
Я вот затрудняюсь ответить на вопрос, что бы я хотел увидеть в таком случае:
let x3 = f(_, 2) + f2(_);
Но в любом случае это довольно странный код, и так писать явно не стоит.
ВВ>>Почему странно понимаю? VD>Хороший вопрос, но не ко мне.
А к кому?
"Правильное" понимание ты мне таки не объяснил. Чем плохо за рядом исключений рассматривать все выражение справа как функцию, если в нем присутствует "_"?
Я не спорить о чем-то хочу, мне просто интересно.
ВВ>>На мой взгляд было бы более логичным если бы в обоих случаях все выражение справа превратилось бы в функцию. VD>Искусственный интеллект еще не изобрели .
Не изобрели. Поэтому тут, грубо, возможно два варианта — то, что я попытался описать в первом посте и то как это сейчас работает в Немерле (первое же выражение с "_" становится функцией, а потом и зависимость от приоритета операторов полная) и все что справа становится функцией.
Если хочешь — вопрос, чем плох мой вариант?
ВВ>>Кстати, а откуда была взята эта идея с "_"? VD>Это ты у авторов спаси.
Мне покажется по сути ты сейчас и есть автор
ВВ>>Есть какие-то еще языки с подобной реализацией partial application? VD>Все языки линейки МЛ (МЛ, ОКамл, Хаскель...) обладали каррингом. Но из-за этого карринга там все функции записываются в стиле x -> y -> z, а не x * y -> z, что конфликтует с применением скобок (как в математике и С) и создает ряд своих проблем. Поляки придумали прямую поддержку частичному применению.
Мне так казалось — возможно, я что-то упустил — карринг в МЛ можно читать так: если в функции с n-параметрами передано n-1 параметров, то ее вызов возвращает новую функцию имеющую n-1 параметров. В таком ключе, я не вижу проблем для реализации МЛьного карринга в С-подобном синтаксисе. Возможно, я что-то упускаю из виду.
Другой вопрос, что механизм с "_" все же более мощный и универсальный.
VD>На мой взгляд частичное применение как и карринг — это не более чем мелкий сахарок. Я не понимаю почему некоторые фанаты уделяют ему такое внимание. VD>Так что если сомневаешься, то просто используй макрос =>. Много не проиграешь, зато всем будет ясно твое намерение.
Здравствуйте, Воронков Василий, Вы писали:
ВВ>Мне так казалось — возможно, я что-то упустил — карринг в МЛ можно читать так: если в функции с n-параметрами передано n-1 параметров, то ее вызов возвращает новую функцию имеющую n-1 параметров. В таком ключе, я не вижу проблем для реализации МЛьного карринга в С-подобном синтаксисе. Возможно, я что-то упускаю из виду.
Не n-1, а 1. При таком подходе не получится сделать overload resolution
Здравствуйте, SergASh, Вы писали:
ВВ>>Мне так казалось — возможно, я что-то упустил — карринг в МЛ можно читать так: если в функции с n-параметрами передано n-1 параметров, то ее вызов возвращает новую функцию имеющую n-1 параметров. В таком ключе, я не вижу проблем для реализации МЛьного карринга в С-подобном синтаксисе. Возможно, я что-то упускаю из виду. SAS>Не n-1, а 1. При таком подходе не получится сделать overload resolution
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Воронков Василий, Вы писали: ВВ>>Про overload resolution вообще речи не было. VD>А тем не менее он есть.
Меня на самом деле смутила твоя фраза, что карринг невозможен в Сишном синтаксисе. Тут я связи, честно говоря, не вижу.
А overload resolution понятие из другого лагеря, мне кажется, в языках ML-ного типа оно вообще лишено смысла. Собственно, карринг и есть своего рода альтернатива overload resolution.
Другой вопрос, что, несмотря на это, частичное применение а ля Немерле мне кажется более мощным и гибким механизмом, чем ML-ный карринг. Т.е. даже в тех случаях, когда реализация карринга не несет с собой каких-либо проблем, частичное применение мне кажется более предпочтительным.
Возможно, я что-то не понимаю в карринге, конечно.
Частичное применение можно использовать как сокращенную форму для объявления функций, вспомним тот же _ + _, заменяющий операторы как first-class функции. Наконец placeholder можно вставить на место любого параметра, предположим, мы хотим функцию вида Foo(x, y) привести к функции вида Foo(x), т.е. подставить значение вместо второго параметра. Как это выразить через карринг? Я так понимаю, придется явно описывать лямбду.
Здравствуйте, Воронков Василий, Вы писали:
ВВ>Меня на самом деле смутила твоя фраза, что карринг невозможен в Сишном синтаксисе. Тут я связи, честно говоря, не вижу.
Я уже привык что ты не видишь многих, казалось бы, элементарных вещей. Попробуй внимательно проанализировать все предпосылки.
ВВ>А overload resolution понятие из другого лагеря, мне кажется, в языках ML-ного типа оно вообще лишено смысла. Собственно, карринг и есть своего рода альтернатива overload resolution.
Последнее утверждение полная ерунда. Чем-то похожим на перегрузку является классы типов в Хаскеле. Но в F# их нет. Да и аналогом они являются весьма условным. На самом деле они ближе к хитро вывернутым интерфейсам. Ну, да это вообще отдельная тема.
Первое вывернуто на изнанку. Оно не лишено смысла, а невозможно в рамках выборанных дизайнерских решений (вывод типов по алгоритму Хидли-Милера, карринг, логическое представление функций в виде лямбд).
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Воронков Василий, Вы писали:
ВВ>Другой вопрос, что, несмотря на это, частичное применение а ля Немерле мне кажется более мощным и гибким механизмом, чем ML-ный карринг. Т.е. даже в тех случаях, когда реализация карринга не несет с собой каких-либо проблем, частичное применение мне кажется более предпочтительным.
Не знаю. Мне ничего подобного не кажется. Обе фичи решают сходные задачи. Обе делают это сносно. При этом обе они зависят от дизайна языка и не могут быть применены в языке с другим дизайном.
ВВ>Частичное применение можно использовать как сокращенную форму для объявления функций, вспомним тот же _ + _, заменяющий операторы как first-class функции.
Карринг тоже. В МЛ-подобных языках операторы это те же функции. Так что можно написать например так: (+) 1 — это будет суффиксальная (функциональная) запись вызова оператора "+". Результатом будет функция int -> int увеличивающая значение параметра на единицу (инкремент).
ВВ> Наконец placeholder можно вставить на место любого параметра, предположим, мы хотим функцию вида Foo(x, y) привести к функции вида Foo(x), т.е. подставить значение вместо второго параметра. Как это выразить через карринг? Я так понимаю, придется явно описывать лямбду.
Как я понимаю — тут карринг действительно сосет. А может есть какие-то методы вроде пустой запятой. Не знаю.
Но это не такой уж недостаток на практике, так как функции предназначенные для карринга обычно проектируются так, что подставляемые параметры обычно идут в начале.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Воронков Василий, Вы писали: ВВ>>Меня на самом деле смутила твоя фраза, что карринг невозможен в Сишном синтаксисе. Тут я связи, честно говоря, не вижу. VD>Я уже привык что ты не видишь многих, казалось бы, элементарных вещей. Попробуй внимательно проанализировать все предпосылки.
Тогда объясни сначала, что ты называешь Сишным синтаксисом. В Немерле, при его "все есть expression", Сишный синтаксис?
А передаются ли параметры через запятую или нет на карринг никак не влияет.
ВВ>>А overload resolution понятие из другого лагеря, мне кажется, в языках ML-ного типа оно вообще лишено смысла. Собственно, карринг и есть своего рода альтернатива overload resolution. VD>Последнее утверждение полная ерунда. Чем-то похожим на перегрузку является классы типов в Хаскеле. Но в F# их нет. Да и аналогом они являются весьма условным. На самом деле они ближе к хитро вывернутым интерфейсам. Ну, да это вообще отдельная тема.
Я написал не похожим, а альтернативой. Те задачи, которые обычно решаются через перегрузку, в том же F# можно решать через карринг.
VD>Первое вывернуто на изнанку. Оно не лишено смысла, а невозможно в рамках выборанных дизайнерских решений (вывод типов по алгоритму Хидли-Милера, карринг, логическое представление функций в виде лямбд).
Оно невозможно если все без исключения функции являются first class. И да, сдается мне, что именно лишено смысла в таком случае. Т.к. функция == значение. Попытка ввести в такую схему какую-то перегрузку приведет... ну не знаю, к созданию делегатов, видимо
Здравствуйте, VladD2, Вы писали:
VD>Карринг тоже. В МЛ-подобных языках операторы это те же функции. Так что можно написать например так: (+) 1 — это будет суффиксальная (функциональная) запись вызова оператора "+". Результатом будет функция int -> int увеличивающая значение параметра на единицу (инкремент).
В МЛ-е операторы *уже* first class функции. Но если бы это было не так, то столь же легко их как в Немерле их в first class функции превратить бы не получилось. Речь лишь о том, что частичное применение можно использовать как некую сокращенную литеральную запись для функций. Карринг — нет.
ВВ>> Наконец placeholder можно вставить на место любого параметра, предположим, мы хотим функцию вида Foo(x, y) привести к функции вида Foo(x), т.е. подставить значение вместо второго параметра. Как это выразить через карринг? Я так понимаю, придется явно описывать лямбду. VD>Как я понимаю — тут карринг действительно сосет. А может есть какие-то методы вроде пустой запятой. Не знаю. VD>Но это не такой уж недостаток на практике, так как функции предназначенные для карринга обычно проектируются так, что подставляемые параметры обычно идут в начале.
Не скажу, что глубоко копал, но как я понял — нельзя.
Здравствуйте, Воронков Василий, Вы писали:
ВВ>Здравствуйте, VladD2, Вы писали:
VD>>Карринг тоже. В МЛ-подобных языках операторы это те же функции. Так что можно написать например так: (+) 1 — это будет суффиксальная (функциональная) запись вызова оператора "+". Результатом будет функция int -> int увеличивающая значение параметра на единицу (инкремент).
ВВ>В МЛ-е операторы *уже* first class функции. Но если бы это было не так, то столь же легко их как в Немерле их в first class функции превратить бы не получилось. Речь лишь о том, что частичное применение можно использовать как некую сокращенную литеральную запись для функций. Карринг — нет.
ВВ>>> Наконец placeholder можно вставить на место любого параметра, предположим, мы хотим функцию вида Foo(x, y) привести к функции вида Foo(x), т.е. подставить значение вместо второго параметра. Как это выразить через карринг? Я так понимаю, придется явно описывать лямбду. VD>>Как я понимаю — тут карринг действительно сосет. А может есть какие-то методы вроде пустой запятой. Не знаю. VD>>Но это не такой уж недостаток на практике, так как функции предназначенные для карринга обычно проектируются так, что подставляемые параметры обычно идут в начале.
ВВ>Не скажу, что глубоко копал, но как я понял — нельзя.
Прямо нельзя, но можно использовать flip, переставляющий аргументы:
foo2 == (flip foo) yVal
-- вызов foo2 x эквивалентен foo x yVal
Здравствуйте, Воронков Василий, Вы писали:
ВВ>Тогда объясни сначала, что ты называешь Сишным синтаксисом.
Ну, можно назвать его школьно-математичеким.
ВВ>В Немерле, при его "все есть expression", Сишный синтаксис?
Речь идет только о вызове функций/методов и о способе передачи им аргументов: f(x, y).
На сегодня распространены:
Сишный: f(x, y)
ML-ный: f x y
Lisp-овый: (f x y)
ВВ>А передаются ли параметры через запятую или нет на карринг никак не влияет.
Покажи нам карринг с сишным синтаксисом.
ВВ>Я написал не похожим, а альтернативой.
У тебя видимо и "альтернатива" имеет свой смысл.
ВВ>Те задачи, которые обычно решаются через перегрузку, в том же F# можно решать через карринг.
Да ну? И как же релизовать перегрузку в F# (для фукнций не принимающих кортежи)?
Мне кажется, что ты в очередной раз говоришь о том в чем не полностью разобрался. Перегрузка есть перегрузка. Ей попросту нет места в системах типов хиндли-милера и синтаксисе ML-я.
Автор F#-а нашел весьма красивое решение — стал рассматривать дотнетные функции (для которых нужна перегрузка) как функции принимающие кортежи и для них разрешили перегрузку. Это позволило и карринг с хиндли-миллером оставить, и перегрузку для вызова дотентных функций ввести.
VD>>Первое вывернуто на изнанку. Оно не лишено смысла, а невозможно в рамках выборанных дизайнерских решений (вывод типов по алгоритму Хидли-Милера, карринг, логическое представление функций в виде лямбд).
ВВ>Оно невозможно если все без исключения функции являются first class.
В Немерле "все без исключения функции являются first class", но это как-то не влияет на поддержку перегрузки.
ВВ>И да, сдается мне, что именно лишено смысла в таком случае. Т.к. функция == значение. Попытка ввести в такую схему какую-то перегрузку приведет... ну не знаю, к созданию делегатов, видимо
Ни к чему это не приведет. "функция == значение" а) совершенно не обязательное допущение, б) не приводит к каким-то фатальным последствиям.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Воронков Василий, Вы писали:
ВВ>В МЛ-е операторы *уже* first class функции.
Это вопрос сугубо философский. Физически — это не та. А на логическом уровне может быть как угодно.
ВВ>Но если бы это было не так, то столь же легко их как в Немерле их в first class функции превратить бы не получилось. Речь лишь о том, что частичное применение можно использовать как некую сокращенную литеральную запись для функций. Карринг — нет.
Опять же вопрос точки зрения. По факту карринг и частичное применение позволяет добиться одинаковых результатов.
ВВ>Не скажу, что глубоко копал, но как я понял — нельзя.
Ну, вот тут товрищь подсказывает, что есть функция flip переставляющая арзументы местами. Это позволяет извернуться.
Я, кстати, раньше часто видел ее применение, но что-то тормознул.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
