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

G>Да ладно. Говорите нет нормальных оправданий для when? И спор не за названия. Тогда скажите на каком из двух нижеприведенных утверждений вы в серьез готовы наставивать:

G>1. Выражение if[/else] всегда вычисляется в void;
G>2. Если выражение if содержит else, то оно вычисляется "нормально". Иначе, оно вычисляется в void.

G>Причем, у меня почему-то нет сомнений, что вы и сами можете привести весьма и весьма серьезные доводы против любого из этих утверждений. Альтернативы?

Второе конечно.

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

def a = if (cond) f0() 
        else f1()

А такая — нет:

def a = if (cond) f0()

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

I>>Эта специфика требует, что бы вход был достаточно пологим. Нынешняя концепция Немерле это макро-ориентированое программирование == новая парадигма.

DS>Не надо ля-ля. Ты можешь спокойно использовать Н ничего не зная о макросах.

Это не так. Все развитие языка идет через макры. Почти все примеры, либы и тд и тд, это макры, макры, макры

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

I>Вполне очевидно, что такая запись должна компилироваться:

I>

I>def a = if (cond) f0() 
I>        else f1()
I>

I>А такая — нет:

I>

I>def a = if (cond) f0()
I>

А кому очевидно-то? Вам? Мне? Или новичку, который закоментил else и у него вылезло, что-то типа this expression was expected to have type void but here has type X?! И тыкают, его не в assignment, а в сам if... не, ну а что, очевидно же

Вы бы, кстати, поинтересовались на досуге, как в F# относятся к такому if По сути, если вы хотите пойти таким же путем (неявный else, вычисляемый в void), то придется вводить ещё и третий вариант — ибо вложенные if придется как-то учиться разбирать... ну чтоб хоть "ругаться" осмысленно в случае чего.

Я уж молчу про то, что на практике else от своего if может находится — скажем так — весьма далеко. А "нам надо знать"

И да... к чему, в конце концов, все эти "танцы"?! Считаете, что новичкам трудно? Ну так свояйте для них, какую-нибудь Nemerle.Macro.Newby — кто запрещает-то?!

---
С уважением, Константин Сиваков

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

G>А кому очевидно-то? Вам? Мне? Или новичку, который закоментил else и у него вылезло, что-то типа this expression was expected to have type void but here has type X?! И тыкают, его не в assignment, а в сам if... не, ну а что, очевидно же

Ещё раз говорю, такой код очевидно не должен компилироваться:

def a = if (cond) f0()

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

G>Я уж молчу про то, что на практике else от своего if может находится — скажем так — весьма далеко. А "нам надо знать"
Как это дело относится? Если у тебя if/else возвращает значение, то ты не будешь коментировать else. А если и будешь, то справедливо получишь по рукам.

G>И да... к чему, в конце концов, все эти "танцы"?! Считаете, что новичкам трудно? Ну так свояйте для них, какую-нибудь Nemerle.Macro.Newby — кто запрещает-то?!
Я считаю, что текущая ситуация никому ничего не даёт, но в то же время отпугивает новичков, тем что "в Немерле два синтаксиса для if".

И, вообще, это самая малая из проблем, которые сейчас есть у Немерле. Мне, как и большинству реально пишущих на Немерле, она не мешает. А новых пользователей ждать не приходится. Так что весь этот разговор — переливание из пустого в порожнее.

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

G>Да ну?!

Ну да.

G>МП — само по себе — очень даже востребовано. Так?

Думаю, это утверждение требует обоснования или, как минимум, уточнения — кем МП востребовано.
Лично я, со своей стороны, на абсолютную истину не претендую. Возможно я не прав. Но мое ощущение именно такое — что МП является далеко не мейнстримным направлением.

G>Есть какие-то причины, по которым МП — при снижении порога вхождения — стало вдруг не востребовано?

А кем оно должно быть востребовано? Всеми? Мной вот не востребовано, например.

ARK>> Хотя бы потому, что мало кто вообще представляет, как это сделать. А кто-то может и думает, что представляет, а в результате его представлений получится неподдерживаемая смесь бульдога с носорогом.
G>А примеры можно?

Нет.

G>А то вот я вижу, что шаблоны плюсов во всю используют... и в качестве МП тоже.

Это, ИМХО, несколько другое.

G>Язык позволяет сделать, так как надо именно тебе, именно сейчас и конкретно в этом месте. Сделать весьма просто.

Угу. А потом придешь на место такого знатока и разгребай кучу мусора, которая черт знает что и значит.

G>Но, спор о том, как должен _называться_ конкретный макрос — это именно что спор о красоте. Тем более в языке, который позволяет назвать его так, как удобно именно тебе.
G>И аргументов против, кроме "я путаюсь" — особо-то и не слышно, что характерно.

А есть еще не аргумент, а факт — у Немерле за много лет не появилось сообщества-коммунити. И обычная реакция людей на Немерле тоже весьма показательна: http://habrahabr.ru/post/239421/

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

I>

I>def a = if (cond) f0() 
I>        else f1()
I>

I>А такая — нет:

I>

I>def a = if (cond) f0()
I>

С чего бы это ?
void можно использовать в качестве результата в Nemerle , чтобы писать более общий код.

using System;
public class Test
{
    public static Main() : void
    {
        def f() {}
        def a = f();
        a;
    }
}

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

_NN>С чего бы это ?
_NN>void можно использовать в качестве результата в Nemerle , чтобы писать более общий код.

_NN>

_NN>using System;
_NN>public class Test
_NN>{
_NN>    public static Main() : void
_NN>    {
_NN>        def f() {}
_NN>        def a = f();
_NN>        a;
_NN>    }
_NN>}
_NN>

То есть ты реально за то, чтобы такой код компилировался?

def a = if(true) 1;

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

I>То есть ты реально за то, чтобы такой код компилировался?

I>

I>def a = if(true) 1;
I>

Тут warning должен быть "пиши так: if(true) _ = 1;"

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

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

_NN>>С чего бы это ?
_NN>>void можно использовать в качестве результата в Nemerle , чтобы писать более общий код.

_NN>>

_NN>>using System;
_NN>>public class Test
_NN>>{
_NN>>    public static Main() : void
_NN>>    {
_NN>>        def f() {}
_NN>>        def a = f();
_NN>>        a;
_NN>>    }
_NN>>}
_NN>>

I>То есть ты реально за то, чтобы такой код компилировался?

I>

I>def a = if(true) 1;
I>

Nemerle поддерживает отношение к void более-менее как к нормальному типу.
Я не вижу смысла это запрещать.
Да, это возможно кого-то удивит, но почему в одних случаях void нормально, а в этом только нет?

Например, операция '=' возвращает 'void'.
Несмотря на это ее можно присвоить дальше и это не ошибка.

_ = _ = _ = ();

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

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

_NN>>С чего бы это ?
_NN>>void можно использовать в качестве результата в Nemerle , чтобы писать более общий код.

_NN>>

_NN>>using System;
_NN>>public class Test
_NN>>{
_NN>>    public static Main() : void
_NN>>    {
_NN>>        def f() {}
_NN>>        def a = f();
_NN>>        a;
_NN>>    }
_NN>>}
_NN>>

I>То есть ты реально за то, чтобы такой код компилировался?

I>

I>def a = if(true) 1;
I>

Я приводил реализацию влоб макроса if-else макроса, с опциональным else

Автор: STDray
Дата: 10.10.14

На что WolfHound показал, в чем может быть проблема

Если говорить про Dangling_else, то else всегда привязывается к ближайшему if (вроде привычное всем поведение)

    IF(true)
      IF(false) WriteLine("3434");
      ELSE      WriteLine("3434");

С выражениями вида

def x = IF(true) 1 ELSE 2;

проблем нет никаких — все по прежнему (относительно Немерле).

Если опустить ELSE рождается Warning.


Но его можно убрать стандартным способом

IF(true) _ =  1;

Если опустить ELSE (допустим случайно) и попытаться запомнить результат,

    
    def y = IF(true) 1;
    WriteLine(y);

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



Вроде никаких шокирующих новостей.

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

I>Конкретная ситуация — это чистой воды пуризм авторов.

Хуже. Это просто артефакт, ошибка проектирования (может даже и в угоду чистоте линий, не важно). А поправить то ли лень, то ли совместимость поломает.

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

ARK>А есть еще не аргумент, а факт — у Немерле за много лет не появилось сообщества-коммунити. И обычная реакция людей на Немерле тоже весьма показательна: http://habrahabr.ru/post/239421/

Да там и пример показателен. MVC, основная идея которого — отделить шаблоны страниц от контроллеров, объективно становится основным .net фреймворком для веба. А там все с точностью до наоборот — давайте смешаем контроллер и вьюху в одно целое.
Нет, я вполне верю что, при правильном подходе, и в NemerleWeb можно расцепить вьюхи и контроллер. Но пример в статье ...!
Все это демонстрирует одну важную вещь — рулят не столько крутые инструментальные фигушечки, сколько правильная концепция. А в проектировании языков оно рулит еще больше, чем в проектировании фреймворков. А уж как это реализовано — вопрос хоть и тоже важный, но второго порядка.

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

I>И, вообще, это самая малая из проблем, которые сейчас есть у Немерле.

Сама по себе — да. Но из кучи таких проблемок складывается картинка. Тут, ИМХО, без вариантов: хочется создать коммьюнити — без целенаправленной работы над устранением лишних шероховатостей с C# не обойтись. Причем это необходимое, но не достаточное условие.

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

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

I>Ещё раз говорю, такой код очевидно не должен компилироваться:

I>

I>def a = if (cond) f0()
I>

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

Возможно, вам что-то там и очевидно. А я, например, не понимаю почему этот код "очевидно не должен компилироваться"?! В erlang, например, аналогичная конструкция очень даже компилируется

Поймите, если пойти по пути F# (а в нем примерно такой if, который, как я понимаю, вам так хочется), то компилироваться перестанет и просто

if (cond) f0()

при условии, что f0() вычисляется не в void. Собственно, предложенная вами конструкция, "очевидно не компилируется" по причине не возможности вычислить if, а не выполнить assignment. А если вычисление таки прошло, и мы получили свой "заветный" void, то и assignment будет вычислен успешно (на что вам ниже и указал _NN_). Просто нет причин, по которым он "очевидно не должен" этого делать

Я так понимаю, что вам хотится таки честный statement. А их нету

I>Я считаю, что текущая ситуация никому ничего не даёт, но в то же время отпугивает новичков, тем что "в Немерле два синтаксиса для if".

Ну т.е. в C# "два синтаксиса для if" их, надо понимать, не пугает. А вот в Nemerle — аж по коленкам бежит?!

---
С уважением, Константин Сиваков

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

G>>МП — само по себе — очень даже востребовано. Так?

ARK>Думаю, это утверждение требует обоснования или, как минимум, уточнения — кем МП востребовано.

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

Исключением можно, наверное, признать лишь lisp. Но, там особые прикладники, и там, кстати, "это норма"

ARK>А кем оно должно быть востребовано? Всеми? Мной вот не востребовано, например.

А вы таки пробовали?! А если бы у вас был более нормальный инструмент?

G>>А то вот я вижу, что шаблоны плюсов во всю используют... и в качестве МП тоже.

ARK>Это, ИМХО, несколько другое.

В чем другое-то?!

G>>Язык позволяет сделать, так как надо именно тебе, именно сейчас и конкретно в этом месте. Сделать весьма просто.

ARK>Угу. А потом придешь на место такого знатока и разгребай кучу мусора, которая черт знает что и значит.

Ну т.е. не пробовали

ARK>А есть еще не аргумент, а факт — у Немерле за много лет не появилось сообщества-коммунити. И обычная реакция людей на Немерле тоже весьма показательна: http://habrahabr.ru/post/239421/

И виной всему, следует полагать, if/else?!

---
С уважением, Константин Сиваков

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

G>Поймите, если пойти по пути F# (а в нем примерно такой if, который, как я понимаю, вам так хочется), то компилироваться перестанет и просто
G>

G>if (cond) f0()
G>

G>при условии, что f0() вычисляется не в void. Собственно, предложенная вами конструкция, "очевидно не компилируется" по причине не возможности вычислить if, а не выполнить assignment. А если вычисление таки прошло, и мы получили свой "заветный" void, то и assignment будет вычислен успешно (на что вам ниже и указал _NN_). Просто нет причин, по которым он "очевидно не должен" этого делать

Действительно, def a = when (true) 1; вполне себе присваивает "a" void. Если честно, не знал этого раньше.
Только я всё-таки не понимаю, что это меняет. if без else может быть фактически аналогом when, то есть тот же if, тело которого возвращает void. Единственная проблема в том, что компилятор не даёт warning, если внутри тела будет вычислено значение, которое в последствие не используется. Но учитывая то, что левая часть станет void, компиляция у тебя так и так завершится с ошибкой.

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

AVK>Да там и пример показателен. MVC, основная идея которого — отделить шаблоны страниц от контроллеров, объективно становится основным .net фреймворком для веба. А там все с точностью до наоборот — давайте смешаем контроллер и вьюху в одно целое.

Там вообще-то MVVM, который является очень хорошим решением для интерактивных интерфейсов. MVC больше подходит для статичного рендеринга, и его выбор в популярных фреймворках, имхо, скорее обусловлен тем, что основная масса пользователей с MVC уже знакома. Ну и тем, что MVVM вышел из под крыла MS.

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

DS>>Не надо ля-ля. Ты можешь спокойно использовать Н ничего не зная о макросах.

I>Это не так. Все развитие языка идет через макры. Почти все примеры, либы и тд и тд, это макры, макры, макры

Ну и? Но ты можешь и не вникать в макры: ты просто пишешь ключевые слова в редакторе и все. Когда тебе понадобится что-то большее можно начинать думать о макрах. Чем и хорошь Н — что можно двигаться по ступенькам вверх. А то чем ты занимаешься — это демагогия.

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

I>Действительно, def a = when (true) 1; вполне себе присваивает "a" void. Если честно, не знал этого раньше.
I>Только я всё-таки не понимаю, что это меняет. if без else может быть фактически аналогом when, то есть тот же if, тело которого возвращает void. Единственная проблема в том, что компилятор не даёт warning, если внутри тела будет вычислено значение, которое в последствие не используется. Но учитывая то, что левая часть станет void, компиляция у тебя так и так завершится с ошибкой.

Получается, что проблемы нет.

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

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

I>>Действительно, def a = when (true) 1; вполне себе присваивает "a" void. Если честно, не знал этого раньше.
I>>Только я всё-таки не понимаю, что это меняет. if без else может быть фактически аналогом when, то есть тот же if, тело которого возвращает void. Единственная проблема в том, что компилятор не даёт warning, если внутри тела будет вычислено значение, которое в последствие не используется. Но учитывая то, что левая часть станет void, компиляция у тебя так и так завершится с ошибкой.

_NN>Получается, что проблемы нет.

О том и разговор. Осталось только позволить использовать if без else