Здравствуйте, VladD2, Вы писали:
VD>А вот если ты знаешь, что return-ов нет в принципе, то ситуация в корне меняется.
Хочу уточнить один момент — ты выше пишешь, что в Немерле ретурн использовать можно. То есть гарантий (что его не будет) всё-таки нет? Или он там ведёт себя как-то иначе?
Re[6]: Почему в качестве statement может быть только assigment, call, increment
Здравствуйте, VladD2, Вы писали:
VD>А вот если ты знаешь, что return-ов нет в принципе, то ситуация в корне меняется. Ты уже знаешь, что выполнение не прервется где-то выше.
Т.е. в исходном примере точки true, false и name1.Equals(name2) не являются прерывающими?
VD>И код начинает выглядеть по другому. В коде появляются четкие потоки управления.
Здравствуйте, IT, Вы писали:
Doc>>На nemerle не писал, поэтому как-то не заметил что данный код легко читаемый. IT>Это быстро проходит.
Ну с привычной и asm читать легко
IT>Синтаксис лямбд в C# уже не требует return и как-то все до сих пор живы и счастливы. Так что return действительно лишний элемент в языке.
Что-то не встречал лямбд в экране высотой.
Re[5]: Почему в качестве statement может быть только assigment, call, increment
Здравствуйте, Doc, Вы писали:
Doc>>>На nemerle не писал, поэтому как-то не заметил что данный код легко читаемый. IT>>Это быстро проходит. Doc>Ну с привычной и asm читать легко
Это так. С другой стороны некоторые, чтобы доказать всем правильность своих суждений, любят отрицать очевидные вещи, в которых сами ничего не понимают.
IT>>Синтаксис лямбд в C# уже не требует return и как-то все до сих пор живы и счастливы. Так что return действительно лишний элемент в языке. Doc>Что-то не встречал лямбд в экране высотой.
У тебя есть прибор для измерения правильности лямбд? Дай попользоваться.
Если нам не помогут, то мы тоже никого не пощадим.
Re[7]: Почему в качестве statement может быть только assigment, call, increment
Здравствуйте, DarkEld3r, Вы писали:
VD>>А вот если ты знаешь, что return-ов нет в принципе, то ситуация в корне меняется. DE>Хочу уточнить один момент — ты выше пишешь, что в Немерле ретурн использовать можно. То есть гарантий (что его не будет) всё-таки нет? Или он там ведёт себя как-то иначе?
return в Немерле представляет собой подключаемый макрос и для его использования нужно сделать определённые телодвижения. Отличие одно — им можно сделать выход из глубин вложенности, что само по себе уже является функциональной ересью.
Если нам не помогут, то мы тоже никого не пощадим.
Re[7]: Почему в качестве statement может быть только assigment, call, increment
Здравствуйте, DarkEld3r, Вы писали:
DE>Хочу уточнить один момент — ты выше пишешь, что в Немерле ретурн использовать можно. То есть гарантий (что его не будет) всё-таки нет? Или он там ведёт себя как-то иначе?
Дело в том, что return, continue, break реализованы в виде макросов. Для использования return, continue, break нужно открыть (using-ом) пространство имен Nemerle.Imperative.
В коде может быть именованный блок:
public FirstFailedIndex : int
{
get
{
ret:
{
def state = _parseResult.ast[AstPointer + 2];
when (state != ParseResult.AstParsedState)
{
foreach (rule in Sequence.Subrules with i)
when (rule.State > state)
ret(i - 1);
ret(Sequence.Subrules.Length - 1);
}
-1
}
}
}
На практике, они встречаются очень редко.
Кроме того в команде вырабатывается соглашение (у нас оно негласно выработалось) не применять return, continue, break или именованные блоки внутри больших функций и вообще, без особой необходимости. Так что на практике можно быть уверенным, что код их не содержит.
Хотя есть код где не только return, но и goto есть. Мне даже пришлось реализовать макрос goto для этого, так как раньше в языке goto не поддерживалось. Wolfhound считает, что с ними писать алгоритмы парсинга проще. В основном это генерируемый код. Но 7 goto в гражданском коде есть .
В общем, ничего не должно становиться догмой. 99% нашего кода не имеет даже return-ов, но это не означает, что мы совсем против него. Просто это дает реальные преимущества на практике.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[7]: Почему в качестве statement может быть только assigment, call, increment
то функция всегда будет возвращать true, а компилятор выдаст предупреждение о том, что значение выражения "if..." теряется.
Первое время это не привычно, но потом не понимаешь как жил без этого раньше.
Doc>Ну тогда это вполне реализуемо и на C# Doc>
Для частного случая — да. В общем, это очень неудобно/невозможно и никто так писать не будет. А для приведенного случая и return-ы сойдут. Тут ведь весь код на ладони.
Doc>Хотя кончено, как говориться, на вкус и цвет товарищей нет.
Все знакомые кто пробовал так писать дольше месяца сходятся во мнении, что "return не нужен". Как правильно сказал IT в лямбдах шарпа тоже обходятся без return-ов и не видят в этом проблемы. Это просто шаг к улучшению поддержки функционального стиля программирования.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[6]: Почему в качестве statement может быть только assigment, call, increment
Здравствуйте, IT, Вы писали:
IT>Это так. С другой стороны некоторые, чтобы доказать всем правильность своих суждений, любят отрицать очевидные вещи, в которых сами ничего не понимают.
Проблема в том, что очевидны они только для тех кто сам на практике их познал. А для теоретизирующих они не очевидны. Более того, даже краткое знакомство не поможет оценить многие решения. Ведь для их оценки нужно немного перестроить сознание. А для этого нужно время и практика.
Обычно понимание приходит когда возвращаться обратно. Никак не забуду тот батхерт/ломку когда после месячного программирования на Немерле вызвал обратный переход на Шарп. Казалось что мне выкрутили руки. Потом привык и стал относиться даже как-то по философски. Но первая реакция была просто потрясающей.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[6]: Почему в качестве statement может быть только assigment, call, increment
Здравствуйте, IT, Вы писали:
IT>Это так. С другой стороны некоторые, чтобы доказать всем правильность своих суждений, любят отрицать очевидные вещи, в которых сами ничего не понимают.
Эк куда тебя понясло. Куча воды и не слова по сути.
Doc>>Что-то не встречал лямбд в экране высотой. IT>У тебя есть прибор для измерения правильности лямбд? Дай попользоваться.
Как "измерение правильности лямбд" относится к объему кода?
Re[8]: Почему в качестве statement может быть только assigment, call, increment
Здравствуйте, VladD2, Вы писали:
VD>Первое время это не привычно, но потом не понимаешь как жил без этого раньше.
Со стороны больше похоже на "сахар". Если подставить return, то, за рядом моментов, получится C# код.
VD>Тут ведь весь код на ладони.
Если код не влезает в экран, то для меня это повод задуматься над его разделением на методы.
VD>Все знакомые кто пробовал так писать дольше месяца сходятся во мнении, что "return не нужен". Как правильно сказал IT в лямбдах шарпа тоже обходятся без return-ов и не видят в этом проблемы.
Только стоит еще отметить, что там обычно несколько строк кода, а то и вовсе что-то вроде a+b.
VD>Это просто шаг к улучшению поддержки функционального стиля программирования.
Заинтересовали, если вдруг найду время — попробую
Re[7]: Почему в качестве statement может быть только assigment, call, increment
Здравствуйте, Doc, Вы писали:
IT>>Это так. С другой стороны некоторые, чтобы доказать всем правильность своих суждений, любят отрицать очевидные вещи, в которых сами ничего не понимают. Doc>Эк куда тебя понясло. Куча воды и не слова по сути.
Началось.
Doc>>>Что-то не встречал лямбд в экране высотой. IT>>У тебя есть прибор для измерения правильности лямбд? Дай попользоваться. Doc>Как "измерение правильности лямбд" относится к объему кода?
Какое отношение имеет экран к лямбдам?
Если нам не помогут, то мы тоже никого не пощадим.
Re[8]: Почему в качестве statement может быть только assigment, call, increment
Здравствуйте, Doc, Вы писали:
Doc>Просто — объем кода. Переспрошу — у тебя часто получаются / встречаются лямбды занимающие весь экран (где-то 50 строк кода).
А почему не 49 или 51?
Если нам не помогут, то мы тоже никого не пощадим.
Re[10]: Почему в качестве statement может быть только assigment, call, increment
Здравствуйте, Doc, Вы писали:
Doc>Кстати, под VS2013 планы есть? Что-то не хочется 12 ставить ради попробовать.
Для 2013 сборка есть, но он пока не автоматизирована. Вручную можно из исходников собрать.
Качаешь репозиторий (он большой) и запускаешь BuildInstallerFast-4.5.1.cmd (чтобы собрать инсталлятор) или DevBuildQuick-4.5.1.cmd (чтобы собрать и зарегистрировать отладочную весрию).
Doc>+ на nemerle.org страница Wiki дает 404
У меня все ОК. Видимо работы какие-то велись.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[10]: Почему в качестве statement может быть только assigment, call, increment
Если нам не помогут, то мы тоже никого не пощадим.
.
