Здравствуйте, Lloyd, Вы писали:
WH>>Это я не понимаю, какое отношение твой наезд на макросы имеет к добавлению фич в язык? WH>>Меж тем разница огромна. В случае с монолитным языком фича добаляется для всех и навсегда. WH>>В случае с макросами фичу используют только те, кому она нужна и только пока нужна.
L>Между тем, пример того же шарпа показывает, что даже имея ограниченый набор фич, предусмотреть все крайне сложно, что явно демонстрируют многочисленные этюды nikov-а.
Очередное доказательство того что читать ты не умеешь.
Я тебе говорю про то что применять мерки монолитных языков к языкам с макросами нельзя, а ты опять за свое...
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
WH>Правильное решение вообще выкинуть Null, а тем где нужно опциональное значение использовать тип Option[T] с двумя вариантами None и Some(T).
И что это даст, кроме синтаксического оверхеда? Вон в шарпе зачем-то сделали, что обращение к Nullable структуре идет через Value и что это дало, кроме синтаксического мусора?
Правильное решение это записывать Nullable типы как тип с вопросиком, но при этом обращение к нему должно идти обычным образом, без всяких мусорных None и Some.
WH>Причем чтобы достать оттуда значение нужно явно проверить, что там что-то есть.
Зачем для этого вводить кошмарный Option?
Я думаю современный компилятор способен понять, что такой код компилироваться должен:
Some? value = GetSome();
if (value == null)
return;
value.Func();
а такой нет:
Some? value = GetSome();
value.Func();
Re[23]: The variable is being used without being initialized
Здравствуйте, Lloyd, Вы писали:
L>Я там привел пример — например, выражение, содержащие циклы.
С циклами в F# тоже всё в порядке. Всё в порядке, когда язык не позволяет отторгать инициализацию переменной от её объявления. Причём, невозможность такого отторжения не ограничивает программиста.
Q>>
Q>>mutable y =
Q>> let sin_φ = sin(φ) in
Q>> f(sin_φ)
Q>>... // Здесь уже sin_φ нет, что и требовалось.
Q>>
L>И почему такой подход не применим в моем случае? :???:
Потому что let-in — это жёсткая конструкция, ограничивающая от произвола. Ты же предлагаешь (насколько я понял) что-то вроде:
И вот эти statement'ы могут делать что угодно, в частности, возвращать неинициализированную переменную. Ты просто скрыл недостижимую константность внутри. Снаружи всё константное, но внутри по прежнему программист может «вклиниться» в момент, где какая-то переменная уже создана, но ещё не инициализирована.
L>То, о чем мы ведем речь — это 2 независимых понятия: константность и проверка инициализированности. константность — это что переменную нельзя менять после инициазизации, "хитрая" инициализированность — это что переменная должна быть инициализирована до того, как к ней начали обращаться.
Примерно так.
Q>>Ок, и как он должен на это реагировать?
L>Ошибка, естественно. Так же как и другие обращения к неинициализированной переменной.
Тогда ты не можешь использовать эту переменную вне скоупа, загрязнённого «техническими» переменными типа sin_φ.
L>>>
L>>>Если ты видишь проблемы в первом варианте, то и во втором они тоже должны присутствовать. Можешь показать, как они будут выглядеть?
Q>>Точно так же будут выглядеть. Из лямбды вернётся неинициализированная (неконстантная, кстати) локальная переменная y.
L>Не понимаю. С какого перепуга она неинициализированная?
Просто вбей в редактор и проверь (именно так я и сделал). Только синтаксис C++0x-замыканий используй: «[=]() -> double { ...; return ...; }».
Q>>Это примерно то, что ты назвал «ужасным окончательным вариантом» из поста в начале ветки.
L>Именно потому, что этот вариант ужасен, я и предлагаю сахар.
Так в исходном комментарии я как раз этот сахар и запрашивал :) Да, сахар может быть основанным на лямбдах, согласно приведённому определению из книжки Митчелла.
В заключение хочу сказать вот что. Так как в наших широтах сейчас стоит прелестнейшая погода, предлагаю засчитать мне технических слив, а я отправлюсь бегать кросс.
Здравствуйте, Undying, Вы писали:
U>И что это даст, кроме синтаксического оверхеда?
Статический контроль.
U>Вон в шарпе зачем-то сделали, что обращение к Nullable структуре идет через Value и что это дало, кроме синтаксического мусора?
Это вообще к делу не относится.. В шарпе вообще очень много странных решений.
U>Правильное решение это записывать Nullable типы как тип с вопросиком, но при этом обращение к нему должно идти обычным образом, без всяких мусорных None и Some.
Правильное решение вообще не тащить никаких Nullable в язык.
U>Зачем для этого вводить кошмарный Option?
Кошмарный он для тех кто его ни разу не использовал.
Вся прелесть Option в том что это просто еще один тип в стандартной библиотеке.
И для компилятора он не отличается от любого другого типа.
U>Я думаю современный компилятор способен понять, что такой код компилироваться должен:
Эта проверка только на первый взгляд кажется простой.
Ты себе даже не представляешь насколько сильно придется надругаться на системой типов языка чтобы такое стало возможным.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[9]: C#: const для переменных, pattern-matching, ...
Здравствуйте, Ziaw, Вы писали:
L>>Ну вот и не усугубляйте. Добавление фичи в язык — проблема сложная не технически, а концептуально. Нужно чтобы фича хорошо "легла" на язык, чтобы грамотно состыковалась с остальными фичами. Путем выставления потрохов компилятора наружу и разрешения всем и каждому менять синтаксис, эта проблема не решается.
Z>Ситуация очень похожа на ситуацию с var в C#. Было огромное количество холиваров, по поводу опасности его использования. На рсдн в частности. Но был один интересный факт, все кто, яро отстаивал их опасность ни разу их не использовал в полной мере и эту опасность все выводили путем логических построений. Эти построения для выглядят очень убедительно. В результате мир C# раскололся на два лагеря, тех кто юзал var и не ощущал страшных последствий и тех, кто не юзал и бодро поддерживал теорию о его крайней опасности для читабельности и понимания кода.
Боюсь, вы сами того не ведая, написали пост в мою поддержку.
Даже такой простой выбор, как выбор между var и явной типизацией — весьма неоднозначен и приводит к долгим, продолжительным и безсмысленным спорам, не утихающим и до сих пор. Эти споры имеют место быть даже не смотря на то, что (я уверен) проектировшики языка сидели и целенаправленно рассматривали все плюсы и минусы этого решения.
Если теперь взять рядового программиста, которому которому платят денежку не за то, что он пишет расширения компилятора, а за решения бизнес-задач, то встает вопрос, а хватит ли ему времени, компетенции и желания на то, чтобы рассмотреть все возможные последствия изменения синтаксиса языка?
По-моему, ответ на этот вопрос очевиден.
Re[10]: C#: const для переменных, pattern-matching, ...
Здравствуйте, Lloyd, Вы писали:
L>Даже такой простой выбор, как выбор между var и явной типизацией — весьма неоднозначен и приводит к долгим, продолжительным и безсмысленным спорам, не утихающим и до сих пор. Эти споры имеют место быть даже не смотря на то, что (я уверен) проектировшики языка сидели и целенаправленно рассматривали все плюсы и минусы этого решения.
Ага... споры есть, а вреда нет.
И те кто использовал понимают что вреда нет.
И даже те ко использовал намного более мощьный вывод типов говорят что вреда нет даже от него.
Но теоретики всеравно спорят и кричат что вред есть.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[13]: C#: const для переменных, pattern-matching, ...
Здравствуйте, WolfHound, Вы писали:
WH>>>Это я не понимаю, какое отношение твой наезд на макросы имеет к добавлению фич в язык? WH>>>Меж тем разница огромна. В случае с монолитным языком фича добаляется для всех и навсегда. WH>>>В случае с макросами фичу используют только те, кому она нужна и только пока нужна.
L>>Между тем, пример того же шарпа показывает, что даже имея ограниченый набор фич, предусмотреть все крайне сложно, что явно демонстрируют многочисленные этюды nikov-а.
WH>Очередное доказательство того что читать ты не умеешь.
Очередное доказательство того, что ты не в состоянии понять прочитанное.
WH>Я тебе говорю про то что применять мерки монолитных языков к языкам с макросами нельзя, а ты опять за свое...
Ты рассмотри конечного потребителя доработанного языка. Ему глубоко фиолетово, захардкожена фича в компилятор или реализована макросом. Тот факт, что те или иные фичи можно отключать, не имеет особого значения.
Я веду речь о том, что изменение синтаксиса — задача концептуально не тривиальная.
Во избежание недоразумений: речь идет не о том, что сложно взять и залезть в потроха компилятора и поправить ast, а о том, что далеко не так просто внести изменения в язык, чтобы при этом он со временем не превратился в кривого уродца.
Re[5]: C#: Ограничение области видимости локальной переменно
Здравствуйте, Lloyd, Вы писали:
Q>>Но теперь переменная y перестаёт быть константой, помимо объявлений/определений появляются присваивания. Усугубляется тем, что всё вышеизложенное касается не только переменной y, но и любой другой переменной в примере.»[/q] L>Ну так это совсем другая проблема — невозможность объявить такую перепенную константной, хотя она очевидно таковой является.
final double y;
{
final double sin_φ = sin(φ);
y = 0.5 * log((1.0 + sin_φ) / (1.0 - sin_φ));
}
Всё работает, язык — Java.
Достаточно изменить немного семантику const-переменных. Они должны быть константными не с создания, а с первого присваивания.
Sapienti sat!
Re[24]: The variable is being used without being initialized
Здравствуйте, Qbit86, Вы писали:
L>>И почему такой подход не применим в моем случае?
Q>Потому что let-in — это жёсткая конструкция, ограничивающая от произвола. Ты же предлагаешь (насколько я понял) что-то вроде: Q>
Q>И вот эти statement'ы могут делать что угодно, в частности, возвращать неинициализированную переменную.
Каким образом statement может что-то возвращать?
Q>Ты просто скрыл недостижимую константность внутри. Снаружи всё константное, но внутри по прежнему программист может «вклиниться» в момент, где какая-то переменная уже создана, но ещё не инициализирована.
Каким образом?
Q>>>Ок, и как он должен на это реагировать?
L>>Ошибка, естественно. Так же как и другие обращения к неинициализированной переменной.
Q>Тогда ты не можешь использовать эту переменную вне скоупа, загрязнённого «техническими» переменными типа sin_φ.
По каким причинам я не могу этого сделать?
L>>Не понимаю. С какого перепуга она неинициализированная?
Q>Просто вбей в редактор и проверь (именно так я и сделал). Только синтаксис C++0x-замыканий используй: «[=]() -> double { ...; return ...; }».
Нет у меня редактора, я говорю о гипотетическом языке.
Q>>>Это примерно то, что ты назвал «ужасным окончательным вариантом» из поста в начале ветки.
L>>Именно потому, что этот вариант ужасен, я и предлагаю сахар.
Q>Так в исходном комментарии я как раз этот сахар и запрашивал Да, сахар может быть основанным на лямбдах, согласно приведённому определению из книжки Митчелла.
Предложенный let работает только в выражениях. Ты предлагаешт выбросить все императивные конструкции?
Q>В заключение хочу сказать вот что. Так как в наших широтах сейчас стоит прелестнейшая погода, предлагаю засчитать мне технических слив, а я отправлюсь бегать кросс.
Ну уж нет, рано или позно ты вернешься.
Re[14]: C#: const для переменных, pattern-matching, ...
Здравствуйте, Lloyd, Вы писали:
L>Ты рассмотри конечного потребителя доработанного языка. Ему глубоко фиолетово, захардкожена фича в компилятор или реализована макросом.
Это мягко говоря не так.
L>Тот факт, что те или иные фичи можно отключать, не имеет особого значения.
Не отключать, а подключать. Разница существенная.
L>Я веду речь о том, что изменение синтаксиса — задача концептуально не тривиальная. L>Во избежание недоразумений: речь идет не о том, что сложно взять и залезть в потроха компилятора и поправить ast, а о том, что далеко не так просто внести изменения в язык, чтобы при этом он со временем не превратился в кривого уродца.
Пятисотый раз повторяю: Твои слова справедливы для монолитов. Для макроязыков это не так.
Просто по тому что кривые фичи отомрут точно также как кривые библиотеки.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[11]: C#: const для переменных, pattern-matching, ...
Здравствуйте, WolfHound, Вы писали:
L>>Даже такой простой выбор, как выбор между var и явной типизацией — весьма неоднозначен и приводит к долгим, продолжительным и безсмысленным спорам, не утихающим и до сих пор. Эти споры имеют место быть даже не смотря на то, что (я уверен) проектировшики языка сидели и целенаправленно рассматривали все плюсы и минусы этого решения. WH>Ага... споры есть, а вреда нет. WH>И те кто использовал понимают что вреда нет. WH>И даже те ко использовал намного более мощьный вывод типов говорят что вреда нет даже от него. WH>Но теоретики всеравно спорят и кричат что вред есть.
Ты ведь правда понимаешь, что ты тем самым меня только поддерживаешь?
Re[6]: C#: Ограничение области видимости локальной переменно
Здравствуйте, Cyberax, Вы писали:
C>Всё работает, язык — Java.
C>Достаточно изменить немного семантику const-переменных. Они должны быть константными не с создания, а с первого присваивания.
Надеюсь теперь Qbit86-таки согласится, что это возможно.
Re[12]: C#: const для переменных, pattern-matching, ...
Здравствуйте, Lloyd, Вы писали:
L>Ты ведь правда понимаешь, что ты тем самым меня только поддерживаешь?
Я понял только одно. Логика у тебя очень странно работает.
Это особенно весело на фоне того что ты выступаешь на стороне тех кто кричит не разобравшись.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[15]: C#: const для переменных, pattern-matching, ...
Здравствуйте, WolfHound, Вы писали:
L>>Ты рассмотри конечного потребителя доработанного языка. Ему глубоко фиолетово, захардкожена фича в компилятор или реализована макросом. WH>Это мягко говоря не так.
Аргументы?
L>>Тот факт, что те или иные фичи можно отключать, не имеет особого значения. WH>Не отключать, а подключать. Разница существенная.
Нет никакой разницы.
L>>Я веду речь о том, что изменение синтаксиса — задача концептуально не тривиальная. L>>Во избежание недоразумений: речь идет не о том, что сложно взять и залезть в потроха компилятора и поправить ast, а о том, что далеко не так просто внести изменения в язык, чтобы при этом он со временем не превратился в кривого уродца. WH>Пятисотый раз повторяю: Твои слова справедливы для монолитов. Для макроязыков это не так.
Что именно для макроязыков не так? Для макроязыков так просто спроектировать фичу языка, что они хорошо ляжет на целевой язык? Благодаря чему?
WH>Просто по тому что кривые фичи отомрут точно также как кривые библиотеки.
Внимание, вопрос. Что делать с унаследованным кодом? А ну да, "настояшие" программисты от такого нос воротят.
Здравствуйте, WolfHound, Вы писали:
WH>Правильное решение вообще не тащить никаких Nullable в язык.
В реальных задачах Nullable типы составляют очень весомую часть всех типов, соответственно отказ от их прямой поддержки в языке и замена этой поддержки на костыли означает горы синтаксического мусора в коде.
WH>Эта проверка только на первый взгляд кажется простой. WH>Ты себе даже не представляешь насколько сильно придется надругаться на системой типов языка чтобы такое стало возможным.
Мы про систему типов шарпа или про проектирование языка с нуля?
Re[13]: C#: const для переменных, pattern-matching, ...
Здравствуйте, WolfHound, Вы писали:
L>>Ты ведь правда понимаешь, что ты тем самым меня только поддерживаешь? WH>Я понял только одно. Логика у тебя очень странно работает.
Ты что-то не понял в том посте? Если да, то не стесняйся, спрашивай. Я постараюсь ответить.
WH>Это особенно весело на фоне того что ты выступаешь на стороне тех кто кричит не разобравшись.
В чем именно я не разобрался?
P.S. WolfHound, если просто хочешь написать, что у меня плохо с головой, ты не стесьняйся, пиши. Нам обоим будет польза: и мне не прилется расшифровывать что именно ты имел в виду под "кричит не разобравшись", и тебе не придется сдерживать себя. Чистый win-win. А админов не бойся, они свои, не обидят.
Здравствуйте, Undying, Вы писали:
U>В реальных задачах Nullable типы составляют очень весомую часть всех типов, соответственно отказ от их прямой поддержки в языке и замена этой поддержки на костыли означает горы синтаксического мусора в коде.
Не в реальных задачах. А в твоем подходе к решения задач.
Почувствуй разницу.
Во многих языках null отсутствует и никто не страдает.
U>Мы про систему типов шарпа или про проектирование языка с нуля?
Один хрен там магия жуткая понадобится.
Причем на ровном месте. Просто по тому что тебе так захотелось.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[16]: C#: const для переменных, pattern-matching, ...
Здравствуйте, Lloyd, Вы писали:
L>Аргументы?
Уже много раз написал.
Но ты проигнорировал.
L>Что именно для макроязыков не так? Для макроязыков так просто спроектировать фичу языка, что они хорошо ляжет на целевой язык? Благодаря чему?
Благодаря тому что этой задачи нет вообще.
Я тебе тут давно об этом говорю.
А ты все понять не можешь.
Если макра кривая она просто умрет и все.
Точно также как умирают кривые библиотеки.
L>Внимание, вопрос. Что делать с унаследованным кодом? А ну да, "настояшие" программисты от такого нос воротят.
Тоже что делают с унаследованным кодом, в котором используется мертвая и кривая библиотека.
Разницы нет никакой.
Совсем.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
А еще:
0) нельзя использовать русские буквы в именах переменных и функций
1) нельзя сделать operator[](int index1, int index2)
2) и вообще переопределенных операторов как-то мало
3) нельзя return x,y ;
4) нет безымянных функций и нельзя сделать вот так "функция( { тут какое-нибудь выражение } )"
5) нельзя поймать исключение SegFault и продолжить работу
6) В STL нет контейнера "граф"
