логика подстановки в паттерн-матчинге
От: _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 раз это используют наибольшее количество людей значит с этим надо считаться и переделать свое мышление.
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.