Здравствуйте, ecinunice, Вы писали:
E>Вот и возник вопрос — есть ли такие особенности частичного применения, которые не нельзя приклеить ярлык синтаксического сахара (конкретный язык не важен).
Некоторые склонны разделять понятия синтаксического сахара и языковой абстракции. Хотя точную грань провести трудно, частичное применение — скорее второе.
Здравствуйте, Трурль, Вы писали:
Т>Некоторые склонны разделять понятия синтаксического сахара и языковой абстракции. Хотя точную грань провести трудно, частичное применение — скорее второе.
В том же окамле или хаскеле наоборот получается что функция с несколькими аргументами это синтаксический сахар для функции с одним аргументом + частичное применение.
Здравствуйте, deniok, Вы писали:
D>В Хаскелле частичное применение — устойчивый термин,
ОК, хотч я его что-то не слышал. Ну, да я не хаскелемен.
D> и стандартный ход в программировании.
Это в какм? Или у нас уже Хаскель и Немерле стали мэйнстримом?
D> Там просто вообще не надо даже _ (подчеркивание) для "неприменённых" аргументов указывать, поскольку арность идентификатора не перегружается.
Это значения не имеет. Это особенности хаскеля.
Вот только в Хаскеле этот самый Partial_application и реализуется за счет карринга. Так что тут ты, как я понимаю, не прав.
D>А карринг в Хаскелле (и вообще в ML) это преобразование функции от кортежа в ФВП одного аргумента
Вот про кортеж ты вопро спорный.
Белиберда с кортежами в Хаскеле получается просто потму, что в нем нет привычного скобочного синтаксиса.
По этому в нем функции получают не список аргументов и возвращают значение (как в привычных языка), а фукнция получает одни аргумет который может быть фунцкцией, ну, а много аргументов трактуются как копозиция функций каждая из которых получает по одному. Ну, и как я понимаю далее диет простая эвивалетность:
X * Y -> Z = X -> Y -> Z
для простых смертный это вообще не ястно, но вот как раз частичное применение на это деле получается как последовательного замыкание.
Собственно в раделе Definition в Википедии (по твоей ссылке) это и демонстрируется.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, deniok, Вы писали:
D>> и стандартный ход в программировании.
VD>Это в какм? Или у нас уже Хаскель и Немерле стали мэйнстримом?
В Хаскелле имелось ввиду.
VD>Вот только в Хаскеле этот самый Partial_application и реализуется за счет карринга. Так что тут ты, как я понимаю, не прав.
Неа. Карринг легко реализуется средствами языка (см. в конце поста), а возможность Partial application — это как раз одно из следствий ленивости, то есть нормального порядка редукций при вычислении. Недопримененный терм сохраняется как thunk, который используется при окончательном применении.
D>>А карринг в Хаскелле (и вообще в ML) это преобразование функции от кортежа в ФВП одного аргумента
VD>Вот про кортеж ты вопро спорный. VD>Белиберда с кортежами в Хаскеле получается просто потму, что в нем нет привычного скобочного синтаксиса.
Есть. Кортежи как раз позволяют записывать вызовы идентично этому синтаксису.
Кортеж из типов X и Y, сам по себе, и есть в математической нотации прямое произведение типов — X*Y. А каррирование — это преобразование функции из традиционного (с прямым произведением) вида в вид, пригодный для последовательного частичного применения.
Можно и в обратную сторону превратить все функции Хаскелла в скобочные.
-- берём, например, map ...
map :: (a -> b) -> [a] -> [b]
-- ... и "декаррируем" его, приводя к скобочной форме (кортежной, на самом деле)
mapWithBrackets = uncurry map
Здравствуйте, Трурль, Вы писали:
Т>Некоторые склонны разделять понятия синтаксического сахара и языковой абстракции. Хотя точную грань провести трудно, частичное применение — скорее второе.
А эти некоторые могут описать алгоритм проведения грани?
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, FR, Вы писали:
FR>В том же окамле или хаскеле наоборот получается что функция с несколькими аргументами это синтаксический сахар для функции с одним аргументом + частичное применение.
Это потому что некоторые фичи можно выразить друг через друга. Классический пример — циклы. И что для чего в таком случа является сахаром лично я сказать не решусь.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>А эти некоторые могут описать алгоритм проведения грани?
Алгоритм — вряд ли. Но можно придумать эмпирическое правило. Если все сводится чисто к синтаксическим преобразованиям, то это синтаксический сахар (или иногда синтаксический крысиный яд). Если же в дело вмешивается семантика, возникают новые понятия, то это уже абстрация.
Например, for — чистый сахар, а foreach — нет. И даже for в паскале нельзя считать просто сахаром.
Конечно, все это имеет смысл, если мы выделяем некоторое ядро языка. Собственно, термин возник, когда Ландин обозвал let синтаксическим сахаром для лямбды.
Здравствуйте, FR, Вы писали:
FR>В том же окамле или хаскеле наоборот получается что функция с несколькими аргументами это синтаксический сахар для функции с одним аргументом + частичное применение.
В окамле и хаскеле нет функций с несколькими аргументами и нет смысла говорить о частичном применении.
Точнее, говорить то можно, но это будет разговор не в терминах языка.
Здравствуйте, Трурль, Вы писали:
Т>В окамле и хаскеле нет функций с несколькими аргументами и нет смысла говорить о частичном применении.
Но тем не менее говорят. Хотя этот термин действительно не является необходимым.
Т>Точнее, говорить то можно, но это будет разговор не в терминах языка.
Здравствуйте, Трурль, Вы писали:
Т>Да, говорят. Так же, как сишники говорят об объектах и методах. Т>Просто рассуждать о сложении, как о Int -> Int -> Int очень неудобно.
Здравствуйте, Трурль, Вы писали:
Т>Алгоритм — вряд ли. Но можно придумать эмпирическое правило. Если все сводится чисто к синтаксическим преобразованиям, то это синтаксический сахар (или иногда синтаксический крысиный яд). Если же в дело вмешивается семантика, возникают новые понятия, то это уже абстрация.
ОК. Вот в C# есть using. Он в общем-то является сахаром для ручной реализации паттерна Dispose обеспечивающего детерминированый контроль освобождения ресурса (РАЮ, тык сызыть).
Т>Например, for — чистый сахар, а foreach — нет. И даже for в паскале нельзя считать просто сахаром.
Вот только for можно выразить через foreach, в foreach через for. В том же Немерел и foreach и for реализованы макросами на базе рекурсивных фунций.
Т>Конечно, все это имеет смысл, если мы выделяем некоторое ядро языка. Собственно, термин возник, когда Ландин обозвал let синтаксическим сахаром для лямбды.
Раз нет четкого алгоритма разделения на сахар и фичи, то все это балшит. Им можно пользоваться в выразительных целях, но и только. Четко утверждать, что что-то есть сахар, а что-то другое фича няльзя. Иначе у одного С++ будет сахаром для С. А у другого даже разный синтаксис лямбд бдудет новой фичей.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
VD>Вот только for можно выразить через foreach, в foreach через for. VD>Раз нет четкого алгоритма разделения на сахар и фичи, то все это балшит.
Вот стоит чашка с блюдцем: чашка сверху, блюдце снизу. Теперь я поставил блюдце на чашку. Получилось блюдце сверху, чашка снизу. Значит ли, что "сверху" и "снизу" суть балшит?
И есть ли алгоритм для разделения балшита и небалшита? А если нет алгоритма, то не балшит ли балшит?
Здравствуйте, VladD2, Вы писали:
Т>>Например, for — чистый сахар, а foreach — нет. И даже for в паскале нельзя считать просто сахаром.
VD>Вот только for можно выразить через foreach, в foreach через for.
В С# с соблюдением полной эквивалентности (читай с полученим идентичного IL-кода) нельзя.
... << RSDN@Home 1.2.0 alpha rev. 725 on Windows Vista 6.0.6000.0>>
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Lloyd, Вы писали:
L>>А побитовое или как мило будет выглядеть, просто загляденье L>>(_|_)
VD>Это будет просто ошибкой. Пробелы нужно ставить обязательно.
Занятно. А подчеркивание в Nemerle — это оператор? Зачем?
Здравствуйте, VladD2, Вы писали:
VD>Подчеркивание является виндкардом. Что-то вроде .* в регексах или % в SQL-е.
Я о другом. Требование разделения разных операторов определяется особенностями реализации токенайзера для более полного покрытия всех возможных вариантов операторов. И токенайзер в Nemerle получается разделяет понятия "_" и "_a"?
Здравствуйте, GlebZ, Вы писали:
GZ>Здравствуйте, VladD2, Вы писали:
VD>>Подчеркивание является виндкардом. Что-то вроде .* в регексах или % в SQL-е. GZ>Я о другом. Требование разделения разных операторов определяется особенностями реализации токенайзера для более полного покрытия всех возможных вариантов операторов. И токенайзер в Nemerle получается разделяет понятия "_" и "_a"?
Это во многих языках так. Wildcard не оператор, скорее ключевое слово, типа public. Нельзя же писать publicvar вместо public var
