Здравствуйте, Пельмешко, Вы писали:

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

G>>Здравствуйте, Пельмешко, Вы писали:

G>>Неправльно выразился. Там делегатов нету.
G>>Суть в том что подсовывать this в этот все равно код нету возможности.

П>В FastFunc<>? Там что угодно сгенерить можно, почему не так:
П>

П>[Serializable]
П>internal class clo@9_1 : FastFunc<string, int>
П>{
П>    public override int Invoke(String s)
П>    {
П>        return s.Length;
П>    }
П>}
П>

Вот Вам и функциональный тип из instance-метода, с подменой this, лямбда fun s -> s.Length то же самое сгенерит

Теперь понял о чем речь.
Только зачем усложнять компилятор (кто знает что потянет за собой такая фича), если можно просто писать fun s -> s.Length?

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

G>Только зачем усложнять компилятор (кто знает что потянет за собой такая фича), если можно просто писать fun s -> s.Length?

Можно, конечно
Просто, знакомясь с F# и вообще ФП, я ожидал некой однородности языка плане функциональных типов...
Я абсолютно был уверен, что instance-метод можно рассматривать как функциональный тип, и ожидал какой-нибудь синтаксис для этого...

Ненаю, наверное я неправильно думаю...

Здравствуйте, Пельмешко, Вы писали:

П>Просто, знакомясь с F# и вообще ФП, я ожидал некой однородности языка плане функциональных типов...
В старых версиях в F# был свой стандартный модуль string. Я его успел застать только по литературе, потому слабо представляю, что там было и по каким причинам они перешли на стандартную строку.

П>Я абсолютно был уверен, что instance-метод можно рассматривать как функциональный тип, и ожидал какой-нибудь синтаксис для этого...
Я тоже ожидал. Но тут даже не в instance-методах дело. Статические методы не F# тоже не функциональные типы.

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

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

MC>Здравствуйте, Пельмешко, Вы писали:
П>>Почему бы не разрешить подобное на уровне компилятора в F# для reference-типов?
MC>Т.е. встроить в язвк шорткат для fun s -> s.Method?
MC>Это как раз работа для простого макроса. Как там в F# с метапрограммированием?

П>

П>"hello"
П>|> String.Length
П>

Этот вариант вполне работает, но если бы не работал и часто встречалось

fun s -> s.Length

то шоткат можно и самому написать

let inline length a =
    (^a : (member Length: int) a)

будет ещё короче и подходить не только для строк

"hello" |> length

Это конечно не совсем то о чём спрашивалось, но в реальности мне эта возможность требовалась настолько редко, что я даже не задумывался и вполне обходился чем-нить вроде String.length

P.S. Значительно более полезным оказался кейворд function.

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

П>>

П>>"hello"
П>>|> String.Length
П>>

K>Этот вариант вполне работает, но если бы не работал и часто встречалось
Этот не работает, работает этот

"hello"
|> String.length

где String — module String from Microsoft.FSharp.Core


K>то шоткат можно и самому написать

Было бы круто, если бы их можно было не писать...

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

K>>то шоткат можно и самому написать
S>Было бы круто, если бы их можно было не писать...
Согласен, но часто ты страдал от отсутствия это фичи? Можно написать предложение разработчикам, до беты вполне успели бы включить, но ИМХО ценность фичи слишком призрачна.

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

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

K>>>то шоткат можно и самому написать
S>>Было бы круто, если бы их можно было не писать...
K>Согласен, но часто ты страдал от отсутствия это фичи? Можно написать предложение разработчикам, до беты вполне успели бы включить, но ИМХО ценность фичи слишком призрачна.

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

Ценность фичи действительно призрачна, пока используются библиотеки F#-а, либо ограниченный набор типов, для которых можно написать шоткаты вручную (или даже нагенерить их). Но вот на стыке со всеми другими библиотеками она немного скрасит жизнь.

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

S>Не сказать чтобы страдал, потому как воспринимал это как данное свыше. Но вот если бы такая фича была, было бы очень здорово. И хотелось бы больше — набор каррированных оберток вокруг всех мембер методов! Только боюсь, что это может вылезти какой-нибудь кривизной...
+1

S>Ценность фичи действительно призрачна, пока используются библиотеки F#-а, либо ограниченный набор типов, для которых можно написать шоткаты вручную (или даже нагенерить их). Но вот на стыке со всеми другими библиотеками она немного скрасит жизнь.

Как вывод можно сказать, что "недостатки" F# это следствие его жизни внутри .NET впрочем его преимущество над OCaml в этом-же. А на стыке с любыми другими библиотка стоит от греха подальше сразу нагенерить нормальных обёрток и потом пользоватьс только ими.

Правда в некоторых случаях анализатор подкладывает сладкие плюшки вида

> let f = Int32.TryParse;;
val f : string -> bool * int

вместо

> let f = Int32.TryParse;;
val f : (string * byref int) -> bool

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