Здравствуйте, hardcase, Вы писали: H>Есть другие варианты синтаксиса пригодного для C#?
Ну для создателей лямбд, я думал, будет как-то не красиво лепить матч через свич-кейс.
Ну сделали бы уже нормальный матч, как в немерле, это же всего-то синтаксис.
Re[4]: Что нам готовит C# 7 (Часть 2. Pattern matching)
Здравствуйте, -n1l-, Вы писали:
N>Ну для создателей лямбд, я думал, будет как-то не красиво лепить матч через свич-кейс. N>Ну сделали бы уже нормальный матч, как в немерле, это же всего-то синтаксис.
Еще не вечер. Они только начали проектирование. Пилить будут года 2-3. Так что за это время они могут все поменять.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re: Что нам готовит C# 7 (Часть 2. Pattern matching)
Блин, лучше бы они отменили всю эту функциональщину.
Я конечно понимаю что языку развиваться нужно и что-то нужно добавлять, но по моему это уже экстенсивный путь. Напихаем всё, что только можно.
Всё таки сфера рационального применения Pattern matching в коммерческом софте довольно ограничена.
Символьная математика, написание трансляторов, экспертные системы, задачи распознавания ... всё это в функциональном стиле пишется конечно более естественно, хотя нельзя сказать что получается производительный код (если не вспоминать конечно про будущие сферические 100500 ядерные процессоры и естественную распараллеливаемость функционального кода). Только всё это нужно 1% разработчиков и для этого уже есть языки.
Я уже вижу знатоков С#, которые кинутся пользовать язык на всю катушку.
Я лично уже задолбался переубеждать коллег с подобными повадками, что язык на всю катушку это всегда хорошо.
Уже блин битовые операции через linq хреначат. Пофигу что тормозит, пофигу что высирает в кучу тонны мусора. Главное что язык на всю катушку.
А тут им такое счастье. Такая мощь. Они обязательно найдут ей применения в задаче вычисления 2 * 2.
Вообще у меня ощущение, что pattern matching это почти всегда write only код, если конечно не писать его постоянно. Ну приблизительно как регулярные выражения. Что бы понять, что он делает, нужно самому распарсить и почти выполнить этот код за процессор.
Даже самую простую задачу можно сделать невыполнимой, если провести достаточное количество совещаний
Re[2]: Что нам готовит C# 7 (Часть 2. Pattern matching)
Здравствуйте, tyomchick, Вы писали:
T>Всё таки сфера рационального применения Pattern matching в коммерческом софте довольно ограничена.
Применение ПМ ограничено не в коммерческом софте, а в тупом софте аля стахановсое формошлёпство, чем выдать больше кода в пятилетку, тем лучше. ПМ как раз один из инструментов, который при вдумчивом использовании позволит количество кода сократить, а пятилетки вообще устранить.
T>Символьная математика, написание трансляторов, экспертные системы, задачи распознавания ...
ПМ нас вплотную подводит к промышленному метапрограммированию, фактически единственной на сегодняшний день не утилизированной парадигме из заслуживающих внимания, которая позволит существенно повысить производительность труда программиста.
T>всё это в функциональном стиле пишется конечно более естественно, хотя нельзя сказать что получается производительный код (если не вспоминать конечно про будущие сферические 100500 ядерные процессоры и естественную распараллеливаемость функционального кода). Только всё это нужно 1% разработчиков и для этого уже есть языки.
Какие у тебя конкретные претензии к производительности ПМ кода? Судя по Немерле, написанному на коленке студентами, ПМ порождает весьма эффективный код, который в общем случае превосходит ручную спагетти из ифов.
T>Я уже вижу знатоков С#, которые кинутся пользовать язык на всю катушку. T>Я лично уже задолбался переубеждать коллег с подобными повадками, что язык на всю катушку это всегда хорошо. T>Уже блин битовые операции через linq хреначат. Пофигу что тормозит, пофигу что высирает в кучу тонны мусора. Главное что язык на всю катушку. T>А тут им такое счастье. Такая мощь. Они обязательно найдут ей применения в задаче вычисления 2 * 2.
Продолжай над этим работать. У тебя всё получится.
T>Вообще у меня ощущение, что pattern matching это почти всегда write only код, если конечно не писать его постоянно. Ну приблизительно как регулярные выражения. Что бы понять, что он делает, нужно самому распарсить и почти выполнить этот код за процессор.
Альтернатива ПМ — это спагетти из ифов. Ты хочешь сказать, что такой императивчег может даже в сто-кратном приближении быть понятнее декларативного кода? Даже не знаю что здесь комментировать
Если нам не помогут, то мы тоже никого не пощадим.
Re: Что нам готовит C# 7 (Часть 2. Pattern matching)
Expr Simplify(Expr e)
{
switch (e) {
case Mult(Const(0) as x, *):
case Mult(*, Const(0) as x): return x;
case Mult(Const(var l), Const(var r)): return Const(l*r);
case Mult(Const(1), var x):
case Mult(var x, Const(1)):
case Add(Const(0), var x) :
case Add(var x, Const(0)) : return Simplify(x);
case Add(Const(var l), Const(var r)): return Const(l+r);
case Neg(Const(var k)): return Const(-k);
default: return e;
}
}
Если нам не помогут, то мы тоже никого не пощадим.
Re[2]: Что нам готовит C# 7 (Часть 2. Pattern matching)
Здравствуйте, IT, Вы писали:
IT>Этот код должен быть таким: IT>
IT>Expr Simplify(Expr e)
IT>{
IT> switch (e) {
IT> case Mult(Const(0) as x, *):
IT> case Mult(*, Const(0) as x): return x;
IT> case Mult(Const(var l), Const(var r)): return Const(l*r);
IT> case Mult(Const(1), var x):
IT> case Mult(var x, Const(1)):
IT> case Add(Const(0), var x) :
IT> case Add(var x, Const(0)) : return Simplify(x);
IT> case Add(Const(var l), Const(var r)): return Const(l+r);
IT> case Neg(Const(var k)): return Const(-k);
IT>
Что-то не понял юмора. В исходном примере оптимизация умножения на 0 была верной. В твоей — не верная. В остальном просто не заметил разницы. Что я пропустил?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[3]: Что нам готовит C# 7 (Часть 2. Pattern matching)
Здравствуйте, IT, Вы писали:
VD>>Что-то не понял юмора. В исходном примере оптимизация умножения на 0 была верной. В твоей — не верная.
IT>Я её никак не менял.
Вот оригинал:
case Mult(Const(0), *): return Const(0);
case Mult(*, Const(0)): return Const(0);
вот твой вариант:
case Mult(Const(0) as x, *):
case Mult(*, Const(0) as x): return x;
Он не верен, так как при умножении на 0 всегда получается 0, а у тебя умножаемое число.
VD>>В остальном просто не заметил разницы. Что я пропустил?
IT>Да.
Так, что же я пропустил?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[5]: Что нам готовит C# 7 (Часть 2. Pattern matching)
Здравствуйте, IT, Вы писали:
VD>>Он не верен, так как при умножении на 0 всегда получается 0, а у тебя умножаемое число. IT>Уверен?
Посмотрел еще раз. Кажись понял. Ты новый синтаксис придумал. В предлагаемом шарпом варианте введение переменной без as делается.
IT>Разница в computation branch.
По этому поводу русский подводник чукче правильно ответил: "Ты не мудри! Ты пальцем покажи!".
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[7]: Что нам готовит C# 7 (Часть 2. Pattern matching)
Здравствуйте, VladD2, Вы писали:
VD>Посмотрел еще раз. Кажись понял. Ты новый синтаксис придумал. В предлагаемом шарпом варианте введение переменной без as делается.
Без as, так без as. Дело не в этом.
IT>>Разница в computation branch. VD>По этому поводу русский подводник чукче правильно ответил: "Ты не мудри! Ты пальцем покажи!".
Это ты так прикалываешься? Разница там только в том, что для группы паттернов используется один computation branch. Как это перевести на русский я не знаю.
Если нам не помогут, то мы тоже никого не пощадим.
Re[8]: Что нам готовит C# 7 (Часть 2. Pattern matching)
Здравствуйте, IT, Вы писали:
IT>Это ты так прикалываешься? Разница там только в том, что для группы паттернов используется один computation branch. Как это перевести на русский я не знаю.
Два паттерна в одном вхождении, наверно.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Если нам не помогут, то мы тоже никого не пощадим.
