Частичное применение функций about lens HOT 8 CLOSED

1. Подумал и так, и эдак, но так и не понял, откуда вытекает этот пункт.
2. Все известные мне языки, которые поддерживают ЧПФ, не поддерживают перегрузку функций вообще. Поэтому считаю наличие такого требования к ЧПФ вполне обоснованным.

from lens.

1. Это не принципиальный момент, но так не потребуется разбирать generic-тип Func<...> и возиться с замыканием переменной, из которой вызван метод.

from lens.

Теперь понятно. Считаю такое ограничение допустимым, если оно существенно упрощает имплементацию. Всё равно основной юзкейс ЧПФ - это именно отдельные функции, а не инстанс-методы классов.

from lens.

В компиляторе C# есть такие понятия как "lambda expression" и "method group" - по сути, некий недоопределенный метод, конкретное действие которого зависит от места, где он использован. Думаю, нам следует тоже воспользоваться этой техникой и расширить ее (напишу отдельно).

from lens.

Перечитал свое первое сообщение и удивился. В чем вообще проблема? Если под переданный список аргументов подпадает только одно возможное переопределение - то его и используем. Если есть два и более - то AmbiguiosMatchException, точно так же, как при выборе подходящего override'а по типам аргументов.

Таким образом, если встречается вызов функции, мы ищем сначала список override'ов по имени и смотрим, есть ли точное совпадение по количеству аргументов. Если нет, то пробуем варианты, где аргументов больше и нет несоответствий типов. Также можно будет использовать placeholder (_) для пропуска аргументов. Например:

fun div:int (x:int y:int) -> x / y
fun div:double (x:double y:double) -> x / y

let five = div 10 2  // обычный вызов
let byTwo = div _ 2 // int
let other = div 13.37 // double
let wtf = div "test" // ошибка

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

Кстати, оно будет круто смотреться вместе с оператором композиции. Например:

fun add:int (a:int b:int) -> a + b
fun pow:int (a:int b:int) -> a ** b

let squareSum = add :> pow _ 2

from lens.

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

pow _ 2

Его можно представить в виде анонимной функции:

(x:? -> pow x 2)

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

Что делать - пока не понятно, поэтому откладываем.

from lens.

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

Для ЧПФ добавляется одно правило: вместо неуказанных аргументов ставится символ _, но общее количество аргументов должно совпадать! Итого:

fun add:int (a:int b:int) -> a + b
let add2 = add _ 2
let otherAdd2 = add 2 _ // trailing underscore is significant
let erroneous = add 2 // won't compile

from lens.

• Добавить поддержку в ресолвер
• Добавить Expand-правила
• Обеспечить работу в случае InvocationNode и NewObjectNode
• Добавить обработку _ в GetIdentifierNode
• Написать тесты
• Обновить документацию

from lens.