Re[2]: логика подстановки в паттерн-матчинге - 2
От: Mumitroller Беларусь  
Дата: 12.01.12 16:15
Оценка: 1 (1) +1
Здравствуйте, _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, то присвоено будет совсем другое значение
                              // И понять это можно только если точно знать, что в классе есть поле с таким именем
    }
}


Таким образом, добавление новых полей в классы становится опасной операцией. С моей точки зрения это совершенно неприемлемо.

Mumitroller
... << RSDN@Home 1.2.0 alpha 4 rev. 0>>
Re[7]: логика подстановки в паттерн-матчинге - 2
От: catbert  
Дата: 12.01.12 19:09
Оценка: 1 (1)
Здравствуйте, _Claus_, Вы писали:

_C_>все таки как быть с текущим косяком (чувствительность к регистру), неужели все согласны оставить?


Ну вот Бейсик к регистру не чувствителен и что-то никому Бейсик не нравится.

Да, Немерле в некоторых случаях плохо работает с типами, чье имя начинается с маленькой буквы. Но типов таких очень мало, а случаи редкие. Поэтому решение должно быть локальным; например, какой-нибудь символ, который означает, что мы имеем в виду класс а не переменную, и наоборот.
Re[3]: логика подстановки в паттерн-матчинге - 2
От: Аноним  
Дата: 12.01.12 17:32
Оценка: +1
CU>оба варианта имеют свои подводные камни, зачем раскрывать все поля, их может быть очень много, зачем загромождать область видимости? Как показывает практика обычно требуется одно два три поля по которым производится матч. Да и действительно невидимые переменные могут дать больше багов чем видимые, потому что для них не существует подсветки. Хотя если честно поначалу мне эта идея понравилась, но это точно надо только как то включать спец.синтаксисом явно, иначе может получится не весть что.

если страх велик, а фича нравится, могу предложить его эксплист вариант

match(var)
{
x() => // если у x есть fld1, fld2, то сразу можно написать
methodn(.fld1, .fld2)
}

так неоднозначности не будет даже при расширении.
логика подстановки в паттерн-матчинге
От: _Claus_  
Дата: 12.01.12 11:02
Оценка:
обнаружен момент, который, на мой взгляд, противоречит и интуитивному ожиданию, и логике.
описан в соседней ветке
Автор: _Claus_
Дата: 10.01.12
, поэтому повторяться не буду, предложу решение.


match(var)
{
  x =>
  x() =>
}


если и впрямь не всегда возможно понять x тип или нет (сомнительно, но пусть), то можно обойтись тем, что x всегда некий тип.
логика такая


match(var)
{
  x => //x - тип, в этой ветке здесь var вводится как приведенное к x
        var.fld_x

  x() => //то же что выше + вводятся все открытые поля x
         //т. е. если у x есть fld1, fld2, то сразу можно написать
         methodn(fld1, fld2)
}


смысла трактовать x как переменную нет никакого.

плюсы — избавляемся от мощного неадеквата с регистром + ясность.
минус — обратная совместимость под вопросом.
Re: логика подстановки в паттерн-матчинге
От: Аноним  
Дата: 12.01.12 11:20
Оценка:
Здравствуйте, _Claus_, Вы писали:

_C_>обнаружен момент, который, на мой взгляд, противоречит и интуитивному ожиданию, и логике.

_C_>описан в соседней ветке
Автор: _Claus_
Дата: 10.01.12
, поэтому повторяться не буду, предложу решение.



_C_>
_C_>match(var)
_C_>{
_C_>  x =>
_C_>  x() =>
_C_>}
_C_>


_C_>если и впрямь не всегда возможно понять x тип или нет (сомнительно, но пусть), то можно обойтись тем, что x всегда некий тип.

_C_>логика такая


_C_>
_C_>match(var)
_C_>{
_C_>  x => //x - тип, в этой ветке здесь var вводится как приведенное к x
_C_>        var.fld_x

_C_>  x() => //то же что выше + вводятся все открытые поля x
_C_>         //т. е. если у x есть fld1, fld2, то сразу можно написать
_C_>         methodn(fld1, fld2)
_C_>} 

_C_>


_C_>смысла трактовать x как переменную нет никакого.


_C_>плюсы — избавляемся от мощного неадеквата с регистром + ясность.

_C_>минус — обратная совместимость под вопросом.

Если var это функция?
Re[2]: логика подстановки в паттерн-матчинге
От: _Claus_  
Дата: 12.01.12 11:33
Оценка:
А>Если var это функция?

если функция то это ж тип тоже. если нет, то плз пример на посмотреть
Re: логика подстановки в паттерн-матчинге
От: CodingUnit Россия  
Дата: 12.01.12 11:37
Оценка:
Здравствуйте, _Claus_, Вы писали:

_C_>
_C_>match(var)
_C_>{
_C_>  x =>
_C_>  x() =>
_C_>}
_C_>


_C_>если и впрямь не всегда возможно понять x тип или нет (сомнительно, но пусть), то можно обойтись тем, что x всегда некий тип.

_C_>логика такая

_C_>смысла трактовать x как переменную нет никакого.

с чего ты взял что смысла нет трактовать как переменную? если мы делаем маленький регистр не значит что надо весь ПМ сделать как нам хочется, у тебя еще не столько опыта чтобы просто так выбрасывать функцию из языка. Переменные нужны это основы ПМ, их так просто менять не будем и не зачем. Маленькая буква это всегда переменная, если нужно проверять тип то x() вот и все.

_C_>плюсы — избавляемся от мощного неадеквата с регистром + ясность.


к этому просто надо привыкнуть, не стоит ломать синтаксис из за этого
_C_>минус — обратная совместимость под вопросом.
там и не только, там все может стать не пойми чем. Просто привыкай к функциональным языкам, все в них сделано не просто так.
Re[2]: логика подстановки в паттерн-матчинге
От: CodingUnit Россия  
Дата: 12.01.12 11:39
Оценка:
Здравствуйте, Аноним, Вы писали:

А>Если var это функция?


не надо так оверквотить (цитировать), на что отвечаете то и цитируйте
Re[2]: логика подстановки в паттерн-матчинге
От: _Claus_  
Дата: 12.01.12 11:48
Оценка:
CU>с чего ты взял что смысла нет трактовать как переменную? если мы делаем маленький регистр не значит что надо весь ПМ сделать как нам хочется, у тебя еще не столько опыта чтобы просто так выбрасывать функцию из языка.

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

CU>Переменные нужны это основы ПМ, их так просто менять не будем и не зачем. Маленькая буква это всегда переменная, если нужно проверять тип то x() вот и все.


хай так.

_C_>>плюсы — избавляемся от мощного неадеквата с регистром + ясность.

CU>к этому просто надо привыкнуть, не стоит ломать синтаксис из за этого

я не ломаю, а вношу ясность и простоту туда, где ее не наблюдаю.
Re: логика подстановки в паттерн-матчинге
От: hardcase Пират http://nemerle.org
Дата: 12.01.12 11:54
Оценка:
Здравствуйте, _Claus_, Вы писали:

_C_>плюсы — избавляемся от мощного неадеквата с регистром + ясность.


А я вот готов побить того, кто догадался типы со строчной буквы называть.
/* иЗвиНите зА неРовнЫй поЧерК */
Re[2]: логика подстановки в паттерн-матчинге
От: _Claus_  
Дата: 12.01.12 12:06
Оценка:
H>А я вот готов побить того, кто догадался типы со строчной буквы называть.

за Ad hominem даже в лучших домах Парижа бъют канделябром.
Re[3]: логика подстановки в паттерн-матчинге
От: Аноним  
Дата: 12.01.12 12:16
Оценка:
Здравствуйте, _Claus_, Вы писали:


H>>А я вот готов побить того, кто догадался типы со строчной буквы называть.


на уровне языка есть запрет делать типы с маленькой а переменные с большой?
это контролируется?
Re[2]: логика подстановки в паттерн-матчинге
От: catbert  
Дата: 12.01.12 12:20
Оценка:
Здравствуйте, hardcase, Вы писали:

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


_C_>>плюсы — избавляемся от мощного неадеквата с регистром + ясность.


H>А я вот готов побить того, кто догадался типы со строчной буквы называть.


Ну тут стандартная отговорка "Тип не мой! Я просто разместил объяву использую чужую библиотеку!!!"
Re[3]: логика подстановки в паттерн-матчинге
От: CodingUnit Россия  
Дата: 12.01.12 12:35
Оценка:
Здравствуйте, _Claus_, Вы писали:

_C_>да я же сколько раз просил пример, где это надо или без этого не обойтись, или даже код будет некрасивый.

_C_>а ты мне все про мою неопытность. возрази мне плз кодом. мы ж программисты типа, а не философы.

ну пример самый распространенный:

match (obj.GetSomeVal(abc))
{
  | Abc([])                      => // работаем с типом у которого параметр пустой список
  | x when (x.CheckValue() == 3) => // работаем с переменной, если значение метода какое нужно
  | Abc(_ :: _ as lst) as x      => // также работаем с переменной и получаем список из Abc и матчим по типу
  | x                            => // просто работаем с переменной очень сокращает результат функции
}


ну вообще переменные это вещь полезная, они используются в ПМ но реже, когда долго программишь конечно понимаешь что это нужно, если их обрубить это лишило бы некоторой свободы в ПМ. Там вообще жуткая теория, все из функциональной алгебры, тип должен преобразовываться в тип, какие то части типа являются константами, как утверждение паттерна, какие то связываться переменными, в конечном счете получается полезное преобразование. Там умные дядки лет 20 все это придумывали и довольно неплохо получилось. Это просто надо изучать как предмет, ПМ, практически подчистую сделан как в МЛ подобных языках, неровности мы только пытаемся выровнить.
А товарищ правильно высказался типы вообще не принято называть с маленькой буквы, хоть в языке есть свобода как их называть, и где то может во внешней библиотеке могут быть типы с маленькой, но в принципе это такой выработанный хороший стиль, называть с большой, и это не только прерогатива МС. В принципе ничто не мешает их использовать в ПМ я показал, просто различать x и x() где нужно, а так если с маленькой не использовать, то еще проще все.
Re[4]: логика подстановки в паттерн-матчинге
От: _Claus_  
Дата: 12.01.12 13:05
Оценка:
давай попробуем не прибегая к регистровой логике
CU>
CU>match (obj.GetSomeVal(abc))
CU>{
CU>  | Abc([])                      => _ - 
CU>  | x when (x.CheckValue() == 3) => // работаем с переменной, если значение метода какое нужно
     | _ when (_.CheckValue() == 3) => c этой стороны _ - значение match
CU>  | Abc(_ :: _ as lst) as x      => // также работаем с переменной и получаем список из Abc и матчим по типу
CU>  | x                            => // просто работаем с переменной очень сокращает результат функции
       _ => используем дальше _  - не менее выразительно
       _ as s => если дальше идет навороченная логика
CU>}
CU>


CU>ну вообще переменные это вещь полезная, они используются в ПМ но реже,


возражение по путанной логике, без которой легко обойтись.

хоть так
match(x = method(d))

или так
match(method(d))
{
_ => _.ToString()
}

P.S. очень удобно, когда пишешь программу, думать только o решаемой проблеме. это
возможно, когда логика в языке не меняется там, где не должна. и тогда новичкам не придется курить в недоумении мануалы.
Re: логика подстановки в паттерн-матчинге
От: _NN_ www.nemerleweb.com
Дата: 12.01.12 13:48
Оценка:
Здравствуйте, _Claus_, Вы писали:

Вместо прямого использования переменных в виде:
match (a)
{
  | p when p > 10 => ()
  | p => ()
}


Предлагается добавлять "_ as"
match (a)
{
  | _ as p when p > 10 => ()
  | _ as p => ()
}


Конечно добавляет немного многословности..
http://rsdn.nemerleweb.com
http://nemerleweb.com
Re: логика подстановки в паттерн-матчинге
От: catbert  
Дата: 12.01.12 14:02
Оценка:
Здравствуйте, _Claus_, Вы писали:

_C_>смысла трактовать x как переменную нет никакого.


Ну, мне вот всегда казалось что есть.
Re[5]: логика подстановки в паттерн-матчинге
От: CodingUnit Россия  
Дата: 12.01.12 14:06
Оценка:
Здравствуйте, _Claus_, Вы писали:

CU>>ну вообще переменные это вещь полезная, они используются в ПМ но реже,


а стоит ли вообще морочиться с типами с маленькой буквы, неужели они часто используются? В .net вообще рекомендуется все писать в camel case, и уже люди привыкли, переменные используются гораздо чаще чем типы с маленькой буквы, если уж используются то можно прибегать к x() синтаксису или x(a, b), но вообще отказываться от переменных не стоит.

_C_>возражение по путанной логике, без которой легко обойтись.


_C_>хоть так

_C_>match(x = method(d))

_C_>или так

_C_>match(method(d))
_C_>{
_C_> _ => _.ToString()
_C_>}

непонятно чем это лучше, я думаю это микроскопическое улучшение ничего не дает, а от плохих привычек писать типы с маленькой буквы надо избавляться.
Re[2]: логика подстановки в паттерн-матчинге
От: _Claus_  
Дата: 12.01.12 14:10
Оценка:
_NN>Предлагается добавлять "_ as"
_NN>
_NN>match (a)
_NN>{
_NN>  | _ as p when p > 10 => ()
_NN>  | _ as p => ()
_NN>}
_NN>


_NN>Конечно добавляет немного многословности..


необходимость в новом имени только тогда когда за => идут вложенные match, иначе хватит и _ — имя по умолчанию для результата.
Re[2]: логика подстановки в паттерн-матчинге
От: _Claus_  
Дата: 12.01.12 14:12
Оценка:
C>Ну, мне вот всегда казалось что есть.

вот как без него http://www.rsdn.ru/forum/nemerle/4573910.1.aspx
Автор: _Claus_
Дата: 12.01.12
Re[6]: логика подстановки в паттерн-матчинге
От: _Claus_  
Дата: 12.01.12 14:20
Оценка:
CU>непонятно чем это лучше, я думаю это микроскопическое улучшение ничего не дает, а от плохих привычек писать типы с маленькой буквы надо избавляться.

или мы следуем логике, или не следуем. я предлагаю следовать. раз типы разрешены с маленькой, значит от это ничего не должно зависеть.
аналогично переменные разрешены с большой — будьте любезны. а иначе это детская наивность получается, — мне петя не нравится — дам ему в морду.
Re[3]: логика подстановки в паттерн-матчинге
От: CodingUnit Россия  
Дата: 12.01.12 14:26
Оценка:
Здравствуйте, _Claus_, Вы писали:

_C_>необходимость в новом имени только тогда когда за => идут вложенные match, иначе хватит и _ — имя по умолчанию для результата.


а если мы после => используем символ подстановки _ , например obj.SomeAction(_ => loc_func(3)), этот символ много еще где используется и использовать его как переменную текущей видимости матча не совсем хорошо. За что боремся, чтобы типы писать с маленькой буквы, и под это переламывать все остальное, хорошо ли это?
Re[7]: логика подстановки в паттерн-матчинге
От: CodingUnit Россия  
Дата: 12.01.12 14:41
Оценка:
Здравствуйте, _Claus_, Вы писали:

_C_>или мы следуем логике, или не следуем. я предлагаю следовать. раз типы разрешены с маленькой, значит от это ничего не должно зависеть.

_C_>аналогично переменные разрешены с большой — будьте любезны. а иначе это детская наивность получается, — мне петя не нравится — дам ему в морду.

если разрешено, это не значит что это хорошо, переменные никто не пишет с большой это неверный стиль. Просто есть серьезные вопросы по исправлению/улучшению языка, я думаю совсем не сложно подчиняться правилам грамматики, да может когда переходишь с языка на язык учить все снова дело непростое, но если мне что то не нравится в синтаксисе это не повод переделывать язык заново. Конечно твои вопросы хороши тем что независимы, ты недавно начал изучать язык, поэтому глаз не замылен как у других, но какие то вещи просто надо смириться и писать так, от этого будет только лучше, в данном случае это именно так. Я вижу что надо типы писать с большой буквы это имеет больший приоритет, переменные с маленькой, тогда для разрешения неоднозначности подходит синтаксис | x(), а сами переменные | x раз это используют наибольшее количество людей значит с этим надо считаться и переделать свое мышление.
Re[4]: логика подстановки в паттерн-матчинге
От: _NN_ www.nemerleweb.com
Дата: 12.01.12 14:57
Оценка:
Здравствуйте, CodingUnit, Вы писали:

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


_C_>>необходимость в новом имени только тогда когда за => идут вложенные match, иначе хватит и _ — имя по умолчанию для результата.


CU>а если мы после => используем символ подстановки _ , например obj.SomeAction(_ => loc_func(3)), этот символ много еще где используется и использовать его как переменную текущей видимости матча не совсем хорошо. За что боремся, чтобы типы писать с маленькой буквы, и под это переламывать все остальное, хорошо ли это?


Согласен.
Кроме того _ не всегда сработает

match (1)
{
  | _ => System.Console.WriteLine(_); // Error :?
}


Лучше уже призывать писать "_ as x" тогда уж.
http://rsdn.nemerleweb.com
http://nemerleweb.com
Re[4]: логика подстановки в паттерн-матчинге
От: _Claus_  
Дата: 12.01.12 14:59
Оценка:
CU>а если мы после => используем символ подстановки _ , например obj.SomeAction(_ => loc_func(3)), этот символ много еще где используется и использовать его как переменную текущей видимости матча не совсем хорошо. За что боремся, чтобы типы писать с маленькой буквы, и под это переламывать все остальное, хорошо ли это?

в лямбды понятно он не присваивается. никогда и нигде. ничего не нарушаем. но если программист усомнился, то "_ as x" решает все и сразу. но это редко, когда придется писать лишних три символа.
но мы синтаксисом разруливаем однозначно. это главное. не вводить мутные правила. завязывать семантику на стиль- серьезный косяк. мамой клянусь.
Re[6]: логика подстановки в паттерн-матчинге
От: _NN_ www.nemerleweb.com
Дата: 12.01.12 15:00
Оценка:
Здравствуйте, CodingUnit, Вы писали:

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


CU>>>ну вообще переменные это вещь полезная, они используются в ПМ но реже,


CU>а стоит ли вообще морочиться с типами с маленькой буквы, неужели они часто используются? В .net вообще рекомендуется все писать в camel case, и уже люди привыкли, переменные используются гораздо чаще чем типы с маленькой буквы, если уж используются то можно прибегать к x() синтаксису или x(a, b), но вообще отказываться от переменных не стоит.


Ну вот F# работает аналогично. (учитывая общие корни от ML).
Однако там никто это менять не собирается.

P.S.
Я не против логичного поведения.
Но нужно убедиться, что ситуация не ухудшается.
http://rsdn.nemerleweb.com
http://nemerleweb.com
Re: логика подстановки в паттерн-матчинге - 2
От: _Claus_  
Дата: 12.01.12 15:11
Оценка:
итого по итогам обсуждения есть такой промежуточный вариант на все

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

  _ => как обычно
}


такой вариант вызывает возражения по существу?
Re[5]: логика подстановки в паттерн-матчинге
От: CodingUnit Россия  
Дата: 12.01.12 16:13
Оценка:
Здравствуйте, _Claus_, Вы писали:

_C_>в лямбды понятно он не присваивается. никогда и нигде. ничего не нарушаем. но если программист усомнился, то "_ as x" решает все и сразу. но это редко, когда придется писать лишних три символа.

_C_>но мы синтаксисом разруливаем однозначно. это главное. не вводить мутные правила. завязывать семантику на стиль- серьезный косяк. мамой клянусь.

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


| _ => lst.FoldLeft([], fold_func(a, _, _, _))


здесь три символа подстановки одним я хочу захватить внешнюю переменную а двумя параметры для FoldLeft функции значение и аккумулятор, так какое он значение должен подставлять туда? Неочевидно, нет подстановка используется очень часто, использовать как переменную текущей области видимости будет очень неудобно, ради этого придется городить еще какое то разрешение неоднозначностей и все ради того чтобы кому то облегчить не писать x() в паттерне. Давай все же отложим эти разговоры до времени, в фшарп действительно поддерживаются маленькие буквы и для типов и для переменных, но там глобальный вывод типов и нет макросов, для немерле это будет наверное непростое решение, я например не вижу сейчас как это реализовывать, над этим стоит долго подумать.
Re[6]: логика подстановки в паттерн-матчинге
От: _NN_ www.nemerleweb.com
Дата: 12.01.12 16:29
Оценка:
Здравствуйте, CodingUnit, Вы писали:

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

F# не поддерживает маленькие буквы в вариантах:

type Color =
    | red


error FS0053: Discriminated union cases and exception labels must be uppercase identifiers


http://ideone.com/u6mKp
http://rsdn.nemerleweb.com
http://nemerleweb.com
Re[5]: логика подстановки в паттерн-матчинге
От: CodingUnit Россия  
Дата: 12.01.12 16:32
Оценка:
Здравствуйте, _NN_, Вы писали:

_NN>Согласен.

_NN>Кроме того _ не всегда сработает

_NN>
_NN>match (1)
_NN>{
_NN>  | _ => System.Console.WriteLine(_); // Error :?
_NN>}
_NN>


_NN>Лучше уже призывать писать "_ as x" тогда уж.


зачем так призывать, как мы уже выяснили переменные используются на много чаще чем типы с маленькой буквы, зачем вводить для них синтаксис длинее. Уже 7 лет такой потребности в Немерле не возникало, сейчас она зачем, x() выглядит короче. В том же фшарпе для проверки типа используется | :? type as t паттерн, или | {field = f}, а для переменных | x =>. Надо оставить так как есть.
Re[7]: логика подстановки в паттерн-матчинге
От: CodingUnit Россия  
Дата: 12.01.12 16:45
Оценка:
Здравствуйте, _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() в редких случаях использования типа как разрешение неоднозначности с переменной.
Re[7]: логика подстановки в паттерн-матчинге
От: CodingUnit Россия  
Дата: 12.01.12 16:50
Оценка:
Здравствуйте, _NN_, Вы писали:

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


_NN>Давай все же отложим эти разговоры до времени, в фшарп действительно поддерживаются маленькие буквы и для типов и для переменных, но там глобальный вывод типов и нет макросов, для немерле это будет наверное непростое решение, я например не вижу сейчас как это реализовывать, над этим стоит долго подумать.


_NN>F# не поддерживает маленькие буквы в вариантах:


но поддерживает маленькие буквы для классов/рекородов
Re[2]: логика подстановки в паттерн-матчинге - 2
От: CodingUnit Россия  
Дата: 12.01.12 17:01
Оценка:
Здравствуйте, _Claus_, Вы писали:

_C_>такой вариант вызывает возражения по существу?



оба варианта имеют свои подводные камни, зачем раскрывать все поля, их может быть очень много, зачем загромождать область видимости? Как показывает практика обычно требуется одно два три поля по которым производится матч. Да и действительно невидимые переменные могут дать больше багов чем видимые, потому что для них не существует подсветки. Хотя если честно поначалу мне эта идея понравилась, но это точно надо только как то включать спец.синтаксисом явно, иначе может получится не весть что.

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

| A =>
| x =>


и ни у кого пока не возникало неоднозначностей или неудобства. Так что многие я думаю будут не рады. Как я начал говорить что при ПМ тип преобразуется в тип и части могут быть константами и переменными, а иногда весь паттерн переменная и это очень частый случай, например:

match (lst)
{
 | []  => // пустой список
 | lst => // список но не пустой, и работаем с ним, это очень частый случай, уж никто не будет здесь ожидать типа, поверь мне на слово
}


Поэтому если вариант с полями еще можно как то попробовать реализовать для какого нибудь синтаксиса, но вариант с маленькими буквами переменными никуда не годится.
Re[3]: логика подстановки в паттерн-матчинге - 2
От: Аноним  
Дата: 12.01.12 17:08
Оценка:
M>Таким образом, добавление новых полей в классы становится опасной операцией. С моей точки зрения это совершенно неприемлемо.

при желании косяк можно найти в любом правиле. боишься — не используй оператор контекста. его никто не навязывает, как и любой другой.
эта фича — для двукратного сокращения кода.
Re[4]: логика подстановки в паттерн-матчинге - 2
От: CodingUnit Россия  
Дата: 12.01.12 17:54
Оценка:
Здравствуйте, Аноним, Вы писали:

А>если страх велик, а фича нравится, могу предложить его эксплист вариант


А>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 => // как в фшарп тест типа
}



Но здесь немалый труд по реализации, добавление содержимого в область видимости, правка типизатора, чтобы добывать внутренние поля, не знаю когда и будет ли это реализовано, хотя идея мне нравится.
Re[4]: логика подстановки в паттерн-матчинге - 2
От: catbert  
Дата: 12.01.12 18:00
Оценка:
Здравствуйте, Аноним, Вы писали:

А>эта фича — для двукратного сокращения кода.


Каким образом эта фича двукратно сократит код?
Re[5]: логика подстановки в паттерн-матчинге - 2
От: CodingUnit Россия  
Дата: 12.01.12 18:01
Оценка:
Здравствуйте, CodingUnit, Вы писали:

арианты:

CU>

CU>match (var)
CU>{ 
CU>  | *x => // наподобие разъименования указателя в С++
CU>  | &x => // наподобие взятия адреса в С++
CU>  | @x => // monkey type
CU>  | :? x => // как в фшарп тест типа
CU>}
CU>



Я думаю это даже проще делать не на основе ПМ, а сделать отдельный оператор, который добавляет в область видимости содержимое какой то переменной типа, например:


look_into(obj); // после этого ниже видно все содержимое obj, включая поля, свойства методы и их можно вызывать без объекта

func(field1);
WriteLine(Method());


можно с областью действия, например:


look_into(obj)
{
 func(field1);
 WriteLine(Method());
}


второй вариант даже быстро можно сделать макросом, но первый наверное потребует правки компилятора.
Re[5]: логика подстановки в паттерн-матчинге - 2
От: Аноним  
Дата: 12.01.12 18:09
Оценка:
C>Каким образом эта фича двукратно сократит код?

x(_, fld1, fld2, _, _) => fld1 + fld2
x() => fld1 + fld2
Re[6]: логика подстановки в паттерн-матчинге - 2
От: _Claus_  
Дата: 12.01.12 18:23
Оценка:
все таки как быть с текущим косяком (чувствительность к регистру), неужели все согласны оставить?
Re[7]: логика подстановки в паттерн-матчинге - 2
От: CodingUnit Россия  
Дата: 12.01.12 18:49
Оценка:
Здравствуйте, _Claus_, Вы писали:

_C_>все таки как быть с текущим косяком (чувствительность к регистру), неужели все согласны оставить?


Это вряд ли можно назвать косяком, типы в основном всегда с верхней буквы, неоднозначность маленьких букв типов можно разрешить легко, меня да я думаю и многих не затрудняет работа с типами с большой буквы тем более сейчас возможно x() и x(a, b) для классов. Стоит подумать на эту тему и посоветоваться в узком кругу, тут возможно несколько решений, но это надо обмозговать, если вообще стоит за это браться. Влад все еще занят и из него трудно выбить слово, а его решение здесь бывает ключевым.
Re[6]: логика подстановки в паттерн-матчинге - 2
От: catbert  
Дата: 12.01.12 19:05
Оценка:
Здравствуйте, Аноним, Вы писали:

C>>Каким образом эта фича двукратно сократит код?


А>x(_, fld1, fld2, _, _) => fld1 + fld2

А>x() => fld1 + fld2

Это не "двукратно сократит код", это "значительно сократит некоторые выражения образца".

Данная фича, имхо, полезна очень редко. Настолько редко, что ее добавление неоправданно.
Re[7]: логика подстановки в паттерн-матчинге - 2
От: Аноним  
Дата: 12.01.12 19:54
Оценка:
C>Это не "двукратно сократит код", это "значительно сократит некоторые выражения образца".
фич, которые глобально укорачивают код, всего одна — отступы. и большинство здесь ее игнорируют.

C>Данная фича, имхо, полезна очень редко. Настолько редко, что ее добавление неоправданно.

у меня такое сплошь и рядом. мне бы очень пригодилось.
Re[8]: логика подстановки в паттерн-матчинге - 2
От: CodingUnit Россия  
Дата: 12.01.12 20:11
Оценка:
Здравствуйте, Аноним, Вы писали:

C>>Данная фича, имхо, полезна очень редко. Настолько редко, что ее добавление неоправданно.

А>у меня такое сплошь и рядом. мне бы очень пригодилось.

Тут опять же на помощь приходят макросы, можно например сделать такой:


look_obj match (obj)
{
 | x() => // здесь получаете содержимое x
}



суть этого макроса проста, надо просканировать дерево выражений и найти использование членов класса obj, для этого надо знать его тип, он задается паттерном, берете его члены и смотрите не ссылается ли какое то выражение типа PExpr.Ref на такое имя и подставляете туда объект. Вообщем такой код:


look_obj match (obj)
{
 | x() => Use(field1, Method2()) // здесь field1 и Method2 принадлежат объекту, но неоднозначности надо отслеживать
}

// макросом надо переписать в такой:

match (obj)
{
 | x as id => Use(id.field1, id.Method2()) // здесь field1 и Method2 принадлежат объекту, но неоднозначности надо отслеживать
}


это прямая задача макросов уровня выражения, чтобы укрощать синтаксис, помоему очень декларативное решение получается и не затрагивает основы.
Re[8]: логика подстановки в паттерн-матчинге - 2
От: CodingUnit Россия  
Дата: 12.01.12 20:25
Оценка:
Здравствуйте, catbert, Вы писали:

C>Да, Немерле в некоторых случаях плохо работает с типами, чье имя начинается с маленькой буквы. Но типов таких очень мало, а случаи редкие. Поэтому решение должно быть локальным; например, какой-нибудь символ, который означает, что мы имеем в виду класс а не переменную, и наоборот.


Предлагаю оставить совместимый экспериментальный вариант, который готов в моей ветке, собран и ждет залития в мастер, после ревью Влада и который можно скачать со страницы Download в репо:

| x            => // переменная
| x()          => // может быть класс
| x(a, b)      => // все основные паттерны работают с типом нач.нам маленькую букву
| x(field = a) =>
| x as var     =>
| var is x     =>


остальные паттерны работают по прежнему (изменения касаются только маленькой буквы в начале). Пока самое лучшее совместимое решение для возможности работать с маленькими буквами, а дальше будем думать что еще можно сделать.
Re: логика подстановки в паттерн-матчинге
От: calc.exe Россия  
Дата: 12.01.12 20:28
Оценка:
Здравствуйте, _Claus_, Вы писали:

_C_>обнаружен момент, который, на мой взгляд, противоречит и интуитивному ожиданию, и логике.


Когда-то давно у меня было сообщение именно на эту тему Несогласованность в языке
Автор: calc.exe
Дата: 11.10.10
.

А вообще у меня предложение самое радикальное. Я предлагаю внутри языка полностью запретить типы/варианты/перечисления с маленькой буквы. Импортированный тип с маленькой буквы, если уж таковой случиться, тогда нельзя будет использовать в pattern matching. А что? Подобные случаи очень редки и их можно разрулить с помощью обычной логики на ифах. А в ПМ идентификатор с маленькой буквы автоматически будет только переменной.
.
Re[2]: логика подстановки в паттерн-матчинге
От: CodingUnit Россия  
Дата: 12.01.12 20:48
Оценка:
Здравствуйте, calc.exe, Вы писали:

CE>А вообще у меня предложение самое радикальное. Я предлагаю внутри языка полностью запретить типы/варианты/перечисления с маленькой буквы. Импортированный тип с маленькой буквы, если уж таковой случиться, тогда нельзя будет использовать в pattern matching. А что? Подобные случаи очень редки и их можно разрулить с помощью обычной логики на ифах. А в ПМ идентификатор с маленькой буквы автоматически будет только переменной.


Маленькие буквы совсем не невозможно использовать, мы говорим о том что уже есть синтаксис разруливания:


// уже устал одно и тоже везде писать
| x   => // переменная
| x() => // пожалуйста используйте тип с маленькой буквы, только покажите скобками
| SomeEnum.a => // тоже подойдет если у вас перечисление


Здесь введена доп эвристика для x() что если конструктор (), то это тип, также в is, as, так что пожалуйста используйте, теперь это возможно, но товарищ начал с того что ему этого мало, ему надо чтобы все записи считались типами, но целый день сегодня об этом говорим, это не совсем то. Так что радикализм хорошо, но мы не совсем консерваторы чтобы вообще исключать возможные улучшения, разумный синтаксис вводиться, и он как правило совместим со старым решением. Экспериментальная версия с работающим синтаксисом из печи уже лежит в разделе Downloads, попробуйте и/или выдвигайте разумные доводы/аргументы.
Re[3]: логика подстановки в паттерн-матчинге
От: CodingUnit Россия  
Дата: 12.01.12 20:50
Оценка:
Здравствуйте, CodingUnit, Вы писали:

CU>Маленькие буквы совсем не невозможно использовать, мы говорим о том что уже есть синтаксис разруливания:


CU>

CU>| a() => // тоже подойдет если у вас перечисление

CU>


с перечислением тот же синтаксис действует
Re[4]: логика подстановки в паттерн-матчинге - 2
От: Mumitroller Беларусь  
Дата: 13.01.12 07:27
Оценка:
Здравствуйте, <Anonymous>, Вы писали:

A>при желании косяк можно найти в любом правиле. боишься — не используй оператор контекста. его никто не навязывает, как и любой другой.

A>эта фича — для двукратного сокращения кода.

Нет, эта фича — для многократного ухудшения читабельности кода, так как понять, что означает имя в обработчике матча можно только видя, откуда оно взялось. А предлагаемая фича скрывает самый ближний и наиболее вероятный источник имен. То есть вместо того, чтобы взглянув на строчку-две выше увидеть, что имя является полем сматченного объекта, придется удостовериться, что это не локальная переменная, объявленая выше и не поле текущего объекта. Ещё хуже скрытная подмена локальных переменных и полей инстанса (как показывалась выше). До кучи — появляющаяся опасность расширения уже существующих классов. Спасибо, мы такой радости ещё в Delphi наелись по самое нехочу...

Как показал уважаемый CodingUnit, любители короткого кода вполне могут использовать макрос, который реализует эту фичу. А вот делать это штатной возможностью лучше не надо, ибо при коллективной разработке обязательно найдутся индивидумы, которые начнут использовать её направо и налево. А контролировать неиспользование макроса гораздо проще, чем неиспользование штатной возможности.

Mumitroller
... << RSDN@Home 1.2.0 alpha 4 rev. 0>>
Re[4]: логика подстановки в паттерн-матчинге - 2
От: Mumitroller Беларусь  
Дата: 13.01.12 07:33
Оценка:
Здравствуйте, <Anonymous>, Вы писали:

A>если страх велик, а фича нравится, могу предложить его эксплист вариант


A>match(var)

A>{
A> x() => // если у x есть fld1, fld2, то сразу можно написать
A> methodn(.fld1, .fld2)
A>}

A>так неоднозначности не будет даже при расширении.


Да, в таком виде вроде все проблемы решаются.

Mumitroller
... << RSDN@Home 1.2.0 alpha 4 rev. 0>>
Re: логика подстановки в паттерн-матчинге
От: BogdanMart Украина  
Дата: 13.01.12 09:52
Оценка:
Здравствуйте, _Claus_, Вы писали:
_C_> x() =>

это слишком жостко

Хотя бы x(*) и только для рекордов и вариантов, хотя, ИМХО, не нужная фитча, только неясность вносит (чтобы понять что ты хочешь ушло минут 8)
Re[2]: логика подстановки в паттерн-матчинге
От: Аноним  
Дата: 13.01.12 11:02
Оценка:
Здравствуйте, BogdanMart, Вы писали:

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

_C_>> x() =>

BM>это слишком жостко


BM>Хотя бы x(*) и только для рекордов и вариантов, хотя, ИМХО, не нужная фитча, только неясность вносит (чтобы понять что ты хочешь ушло минут 8)


Если так то надо просто ввести в язык правило проверки — тип с только с большой переменная только с маленькой и проверять выдавать на нарущение ошибку.
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.