Здравствуйте, CodingUnit, Вы писали:
CU>Здравствуйте, _Claus_, Вы писали:
_C_>>необходимость в новом имени только тогда когда за => идут вложенные match, иначе хватит и _ — имя по умолчанию для результата.
CU>а если мы после => используем символ подстановки _ , например obj.SomeAction(_ => loc_func(3)), этот символ много еще где используется и использовать его как переменную текущей видимости матча не совсем хорошо. За что боремся, чтобы типы писать с маленькой буквы, и под это переламывать все остальное, хорошо ли это?
CU>а если мы после => используем символ подстановки _ , например obj.SomeAction(_ => loc_func(3)), этот символ много еще где используется и использовать его как переменную текущей видимости матча не совсем хорошо. За что боремся, чтобы типы писать с маленькой буквы, и под это переламывать все остальное, хорошо ли это?
в лямбды понятно он не присваивается. никогда и нигде. ничего не нарушаем. но если программист усомнился, то "_ as x" решает все и сразу. но это редко, когда придется писать лишних три символа.
но мы синтаксисом разруливаем однозначно. это главное. не вводить мутные правила. завязывать семантику на стиль- серьезный косяк. мамой клянусь.
Здравствуйте, CodingUnit, Вы писали:
CU>Здравствуйте, _Claus_, Вы писали:
CU>>>ну вообще переменные это вещь полезная, они используются в ПМ но реже,
CU>а стоит ли вообще морочиться с типами с маленькой буквы, неужели они часто используются? В .net вообще рекомендуется все писать в camel case, и уже люди привыкли, переменные используются гораздо чаще чем типы с маленькой буквы, если уж используются то можно прибегать к x() синтаксису или x(a, b), но вообще отказываться от переменных не стоит.
Ну вот F# работает аналогично. (учитывая общие корни от ML).
Однако там никто это менять не собирается.
P.S.
Я не против логичного поведения.
Но нужно убедиться, что ситуация не ухудшается.
итого по итогам обсуждения есть такой промежуточный вариант на все
1)
match(var)
{
x => //x - тип, в этой ветке здесь var вводится как приведенное к x
var.fld_x
x() => //то же что выше + вводятся все открытые поля x
//т. е. если у x есть fld1, fld2, то сразу можно написать
methodn(fld1, fld2)
}
2)
match(method(n))
{
x => //x - тип
x as var => x - тип, var - значение
x() => // вводятся все открытые поля результата method(n)
//т. е. если у него есть fld1, fld2, то сразу можно написать
methodn(fld1, fld2)
_ as var => используем var
_ => как обычно
}
Здравствуйте, _Claus_, Вы писали:
_C_>в лямбды понятно он не присваивается. никогда и нигде. ничего не нарушаем. но если программист усомнился, то "_ as x" решает все и сразу. но это редко, когда придется писать лишних три символа. _C_>но мы синтаксисом разруливаем однозначно. это главное. не вводить мутные правила. завязывать семантику на стиль- серьезный косяк. мамой клянусь.
в лямбды понятно не присваивается, но если мы захотим использовать эту переменную где то в той же лямбде каких случаев полно
| _ => lst.FoldLeft([], fold_func(a, _, _, _))
здесь три символа подстановки одним я хочу захватить внешнюю переменную а двумя параметры для FoldLeft функции значение и аккумулятор, так какое он значение должен подставлять туда? Неочевидно, нет подстановка используется очень часто, использовать как переменную текущей области видимости будет очень неудобно, ради этого придется городить еще какое то разрешение неоднозначностей и все ради того чтобы кому то облегчить не писать x() в паттерне. Давай все же отложим эти разговоры до времени, в фшарп действительно поддерживаются маленькие буквы и для типов и для переменных, но там глобальный вывод типов и нет макросов, для немерле это будет наверное непростое решение, я например не вижу сейчас как это реализовывать, над этим стоит долго подумать.
Здравствуйте, _Claus_, Вы писали:
_C_>такой вариант вызывает возражения по существу?
Оба варианта очень плохи из-за неявного введения переменных с именами, как у открытых полей. Если выше по коду есть переменная, которую используют в обработчике матча, то добавление в класс поля с таким же именем внезапно поменяет поведение кода. И я не вижу способа это заметить.
Пример:
class x
{
public fld1 : int;
// public fld2 : int;
}
main() : void
{
def xx = x();
def fld2 = 5;
match (xx)
{
| x() =>
something = fld2; // если добавить поле fld2 в класс x, то присвоено будет совсем другое значение
// И понять это можно только если точно знать, что в классе есть поле с таким именем
}
}
Таким образом, добавление новых полей в классы становится опасной операцией. С моей точки зрения это совершенно неприемлемо.
Давай все же отложим эти разговоры до времени, в фшарп действительно поддерживаются маленькие буквы и для типов и для переменных, но там глобальный вывод типов и нет макросов, для немерле это будет наверное непростое решение, я например не вижу сейчас как это реализовывать, над этим стоит долго подумать.
F# не поддерживает маленькие буквы в вариантах:
type Color =
| red
error FS0053: Discriminated union cases and exception labels must be uppercase identifiers
зачем так призывать, как мы уже выяснили переменные используются на много чаще чем типы с маленькой буквы, зачем вводить для них синтаксис длинее. Уже 7 лет такой потребности в Немерле не возникало, сейчас она зачем, x() выглядит короче. В том же фшарпе для проверки типа используется | :? type as t паттерн, или | {field = f}, а для переменных | x =>. Надо оставить так как есть.
Здравствуйте, _NN_, Вы писали:
_NN>Ну вот F# работает аналогично. (учитывая общие корни от ML). _NN>Однако там никто это менять не собирается.
не совсем аналогично, переменные там также с маленькой буквы а распознавания типов таким образом нет, там используется синтаксис:
| :? point as p -> // для динамического определения типа
| {field = f} -> // для распознавания рекорд паттерна
| x -> // просто переменная
но в фшарпе глобальный вывод типов и нет макросов.
_NN>P.S. _NN>Я не против логичного поведения. _NN>Но нужно убедиться, что ситуация не ухудшается.
если мы делаем аналогично, например с помощью вывода типов как предложил один товарищ, так например если в макросе цитировать матч, а в нем тип, которого еще не существует и открыть его ниоткуда невозможно, то получается создаться переменная, этот вариант сразу отбрасывается. Если хитрить и распознавать x как тип, что даже в фшарпе нет, то получится мы ради редкого использования большей частью сообщества типов с маленькой буквы, мы теряем возможность частого использования переменных как здесь:
| x when (x.IsSomeOne()) => x
| x when (x.IsSomeTwo()) => x
я все же склоняюсь к трезвому использованию x() в редких случаях использования типа как разрешение неоднозначности с переменной.
Здравствуйте, _NN_, Вы писали:
_NN>Здравствуйте, CodingUnit, Вы писали:
_NN>Давай все же отложим эти разговоры до времени, в фшарп действительно поддерживаются маленькие буквы и для типов и для переменных, но там глобальный вывод типов и нет макросов, для немерле это будет наверное непростое решение, я например не вижу сейчас как это реализовывать, над этим стоит долго подумать.
_NN>F# не поддерживает маленькие буквы в вариантах:
но поддерживает маленькие буквы для классов/рекородов
Здравствуйте, _Claus_, Вы писали:
_C_>такой вариант вызывает возражения по существу?
оба варианта имеют свои подводные камни, зачем раскрывать все поля, их может быть очень много, зачем загромождать область видимости? Как показывает практика обычно требуется одно два три поля по которым производится матч. Да и действительно невидимые переменные могут дать больше багов чем видимые, потому что для них не существует подсветки. Хотя если честно поначалу мне эта идея понравилась, но это точно надо только как то включать спец.синтаксисом явно, иначе может получится не весть что.
Во вторый как я уже сказал для переменных вводить синтаксис длинее чем для типов неудобно, сейчас они оба живут в компактном синтаксисе:
| A =>
| x =>
и ни у кого пока не возникало неоднозначностей или неудобства. Так что многие я думаю будут не рады. Как я начал говорить что при ПМ тип преобразуется в тип и части могут быть константами и переменными, а иногда весь паттерн переменная и это очень частый случай, например:
match (lst)
{
| [] => // пустой список
| lst => // список но не пустой, и работаем с ним, это очень частый случай, уж никто не будет здесь ожидать типа, поверь мне на слово
}
Поэтому если вариант с полями еще можно как то попробовать реализовать для какого нибудь синтаксиса, но вариант с маленькими буквами переменными никуда не годится.
Re[3]: логика подстановки в паттерн-матчинге - 2
От:
Аноним
Дата:
12.01.12 17:08
Оценка:
M>Таким образом, добавление новых полей в классы становится опасной операцией. С моей точки зрения это совершенно неприемлемо.
при желании косяк можно найти в любом правиле. боишься — не используй оператор контекста. его никто не навязывает, как и любой другой.
эта фича — для двукратного сокращения кода.
CU>оба варианта имеют свои подводные камни, зачем раскрывать все поля, их может быть очень много, зачем загромождать область видимости? Как показывает практика обычно требуется одно два три поля по которым производится матч. Да и действительно невидимые переменные могут дать больше багов чем видимые, потому что для них не существует подсветки. Хотя если честно поначалу мне эта идея понравилась, но это точно надо только как то включать спец.синтаксисом явно, иначе может получится не весть что.
если страх велик, а фича нравится, могу предложить его эксплист вариант
match(var)
{
x() => // если у x есть fld1, fld2, то сразу можно написать
methodn(.fld1, .fld2)
}
Здравствуйте, Аноним, Вы писали:
А>если страх велик, а фича нравится, могу предложить его эксплист вариант
А>match(var) А>{ А> x() => // если у x есть fld1, fld2, то сразу можно написать А> methodn(.fld1, .fld2) А>}
А>так неоднозначности не будет даже при расширении.
такие молодцы придумывать разработчикам разные варианты синтаксиса мастаки, а как нам это реализовывать вы не подозреваете. Это переделка парсера и аст как минимум, а стоит ли, сильно оно сокращает код, без точки это реализовывать проще, опять же:
| x() as y => methodn(y.fld1, y.fld2)
для включения такой функции можно использовать спец. нотацию, это сделать проще, чтобы не конфликтовало с существующим и не включало неявно что не надо. Варианты:
match (var)
{
| *x => // наподобие разъименования указателя в С++
| &x => // наподобие взятия адреса в С++
| @x => // monkey type
| :? x => // как в фшарп тест типа
}
Но здесь немалый труд по реализации, добавление содержимого в область видимости, правка типизатора, чтобы добывать внутренние поля, не знаю когда и будет ли это реализовано, хотя идея мне нравится.
CU>match (var)
CU>{
CU> | *x => // наподобие разъименования указателя в С++
CU> | &x => // наподобие взятия адреса в С++
CU> | @x => // monkey type
CU> | :? x => // как в фшарп тест типа
CU>}
CU>
Я думаю это даже проще делать не на основе ПМ, а сделать отдельный оператор, который добавляет в область видимости содержимое какой то переменной типа, например:
look_into(obj); // после этого ниже видно все содержимое obj, включая поля, свойства методы и их можно вызывать без объекта
func(field1);
WriteLine(Method());
Здравствуйте, _Claus_, Вы писали:
_C_>все таки как быть с текущим косяком (чувствительность к регистру), неужели все согласны оставить?
Это вряд ли можно назвать косяком, типы в основном всегда с верхней буквы, неоднозначность маленьких букв типов можно разрешить легко, меня да я думаю и многих не затрудняет работа с типами с большой буквы тем более сейчас возможно x() и x(a, b) для классов. Стоит подумать на эту тему и посоветоваться в узком кругу, тут возможно несколько решений, но это надо обмозговать, если вообще стоит за это браться. Влад все еще занят и из него трудно выбить слово, а его решение здесь бывает ключевым.
