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

L>>Почему?

I>Там же написано: потому что "помимо объявлений/определений появляются присваивания".

Там же написано:

то совсем другая проблема — невозможность объявить такую перепенную константной, хотя она очевидно таковой является

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

D>варнинги же

На уровне по умолчанию VS их не выдает.

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

L>Там же написано:
L>

L>то совсем другая проблема — невозможность объявить такую перепенную константной, хотя она очевидно таковой является

goto здесь

Автор: igna
Дата: 23.04.11

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

Ф>но раз в неделю вам приходится написать 10 строчек на ЯП "Б", то не надо писать о "Б".

а если я всего 10 строчек кода в неделю пищу, то уже и совсем отвечать не стоит?

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

L>>Там же написано:
L>>

L>>то совсем другая проблема — невозможность объявить такую перепенную константной, хотя она очевидно таковой является

I>goto здесь

Автор: igna
Дата: 23.04.11

Идите подумайте, что именно я написал. В частности, рекомендую помедитировать над частью "хотя она очевидно таковой является".

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

Ф>Пожалуйста, выносите в заголовок ответа название языка.

Питон. Классические грабли скриптовых языков: отсутствие различия в передаче по ссылке или по значению, и мутная область видимости переменных:

def make_list(element, head=[]):
    head.append(element)
    return head

print make_list(42)
print make_list(42)

и http://rsdn.ru/forum/dynamic/3587540.1.aspx

Автор: Roman Odaisky
Дата: 31.10.09

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

L>Идите подумайте, что именно я написал. В частности, рекомендую помедитировать над частью "хотя она очевидно таковой является".

Есть!

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

L>Идите подумайте, что именно я написал. В частности, рекомендую помедитировать над частью "хотя она очевидно таковой [константной] является".

Кому очевидно? Переменная y (жаль, что повсеместно используется термин variable вместо assignable) уже не является константной, а всего лишь монотонной. В общем случае между объявлением и окончательным присваиванием может произойти выброс исключения с последующей ловлей. Так что даже компилятору будет тяжело поручиться в том, что y «на самом деле» константа.

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

L>>Идите подумайте, что именно я написал. В частности, рекомендую помедитировать над частью "хотя она очевидно таковой [константной] является".

Q>Кому очевидно? Переменная y (жаль, что повсеместно используется термин variable вместо assignable) уже не является константной,

Ну так объяви константой.

Q>а всего лишь монотонной.

Нет, она является кусочно-постоянно.

Q>В общем случае между объявлением и окончательным присваиванием может произойти выброс исключения с последующей ловлей.

А в let-е его не может произойти?

Q>Так что даже компилятору будет тяжело поручиться в том, что y «на самом деле» константа.

Нет никаких сложностей.

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

Q>>а всего лишь монотонной.
L>Нет, она является кусочно-постоянно. :-\

Я использовал термин «монотонное изменение состояния» в смысле, как в статье Кирпичёва, на которую выше давал ссылку.

Q>>В общем случае между объявлением и окончательным присваиванием может произойти выброс исключения с последующей ловлей.
L>А в let-е его не может произойти?

В синтаксисе let/where нельзя выцепить момент, в котором можно использовать переменную y до получения ею требуемого значения. А в C++/C# можно. Скажем, блок catch, если вызов sin бросит исключение в блоке try.

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

L>>Идите подумайте, что именно я написал. В частности, рекомендую помедитировать над частью "хотя она очевидно таковой [константной] является".

Q>Кому очевидно? Переменная y (жаль, что повсеместно используется термин variable вместо assignable) уже не является константной, а всего лишь монотонной. В общем случае между объявлением и окончательным присваиванием может произойти выброс исключения с последующей ловлей. Так что даже компилятору будет тяжело поручиться в том, что y «на самом деле» константа.

Просто смотри на блок кода, в котором происходит присваивание как на сахар над вызовом лямбды и тогда все встанет на свои места.

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

Q>>>а всего лишь монотонной.
L>>Нет, она является кусочно-постоянно.

Q>Я использовал термин «монотонное изменение состояния» в смысле, как в статье Кирпичёва, на которую выше давал ссылку.

Ок. Больше так не делай.

Q>>>В общем случае между объявлением и окончательным присваиванием может произойти выброс исключения с последующей ловлей.
L>>А в let-е его не может произойти?

Q>В синтаксисе let/where нельзя выцепить момент, в котором можно использовать переменную y до получения ею требуемого значения. А в C++/C# можно. Скажем, блок catch, если вызов sin бросит исключение в блоке try.

Я писал не о реальном языке, а о гипотетической фиче. С учетом этого, в чем смысл аппелирования к C++/C# с их "можно/неможно"?

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

L>Просто смотри на блок кода, в котором происходит присваивание как на сахар над вызовом лямбды и тогда все встанет на свои места.

Хотел бы, да не могу. Это ж императивные языки, тут превалируют statements, а не expressions. И они выполняются в определённом порядке, это надо учитывать.

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

L>>Просто смотри на блок кода, в котором происходит присваивание как на сахар над вызовом лямбды и тогда все встанет на свои места.

Q>Хотел бы, да не могу. Это ж императивные языки, тут превалируют statements, а не expressions.

Это не важно. Разбей в своем примере присваение и декларацию переменной и попробуй между ними вставить обращение к это переменной. Компилятор отследит использование неинициализированной переменной. Как видиш, никаких сложностей с этим нет. Осталось только убедить компилятор, что присваивать значение повторно такой переменной нельзя.

Q>И они выполняются в определённом порядке, это надо учитывать.

Это не имеет отношения.

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

L>Я писал не о реальном языке, а о гипотетической фиче. С учетом этого, в чем смысл аппелирования к C++/C# с их "можно/неможно"?

Смотри. Я считаю, что в C++/C# проблема ограничения видимости переменной в выражениях связана с отсутствием синтаксической поддержки ограничения видимости переменной в выражениях. И при переходе от гипотетической фичи к практическому расширению языка, имхо, стоит добавить эту самую синтаксическую поддержку аналогов let-in/where (например, как обёртку над замыканиями).

Ты же говоришь, что проблема ограничения видимости переменной в выражениях связана с отсутствием гибких возможностей по декларированию константности, а ограничение скоупа уже есть в виде фигурных скобок (хотя они в C++/C# ограничивают блок операторов, а не выражений). Хотя фактически, константность тут не при чём. Пусть, скажем, y задумана быть изменяемой (если язык допускает). Что-то типа такого (на псевдокоде):

mutable y = f(sin_φ) where sin_φ = sin(φ)
...
y = g(cos_φ) where cos_φ = cos(φ)

Уже константности от y никто не требует, но нотация с фигурными скобками и присваиванием по-прежнему скользкая в виду тех же самых исключений. Если в приведённом коде y может принимать только два значения (или не принимать их в случае исключения), то в C++/C#-коде к ним добавляется потенциально достижимое состояние, когда y не определена (или инициализирована по умолчанию).

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

L>>Я писал не о реальном языке, а о гипотетической фиче. С учетом этого, в чем смысл аппелирования к C++/C# с их "можно/неможно"?

Q>Смотри. Я считаю, что в C++/C# проблема ограничения видимости переменной в выражениях связана с отсутствием синтаксической поддержки ограничения видимости переменной в выражениях. И при переходе от гипотетической фичи к практическому расширению языка, имхо, стоит добавить эту самую синтаксическую поддержку аналогов let-in/where (например, как обёртку над замыканиями).

Аналог let-а — это полумера, т.к. проблема скоупа переменной останется проблемой для конструкций, не являющихся выражениями (например, циклы).

Q>Ты же говоришь, что проблема ограничения видимости переменной в выражениях связана с отсутствием гибких возможностей по декларированию константности, а ограничение скоупа уже есть в виде фигурных скобок (хотя они в C++/C# ограничивают блок операторов, а не выражений). Хотя фактически, константность тут не при чём.

Константность тут очень даже причем. Озвученая проблема скоупа решается блоком {}, но когда мы используем такое решение, то вылазит проблема ограниченности понятия константности.

Q>Пусть, скажем, y задумана быть изменяемой (если язык допускает). Что-то типа такого (на псевдокоде):
Q>

Q>mutable y = f(sin_φ) where sin_φ = sin(φ)
Q>...
Q>y = g(cos_φ) where cos_φ = cos(φ)
Q>

Q>Уже константности от y никто не требует, но нотация с фигурными скобками и присваиванием по-прежнему скользкая в виду тех же самых исключений.

Я не понимаю, где скользкость? И какое отношение пример с mutable имеет к обсуждению костантности тоже не понимаю.

Q>Если в приведённом коде y может принимать только два значения (или не принимать их в случае исключения), то в C++/C#-коде к ним добавляется потенциально достижимое состояние, когда y не определена (или инициализирована по умолчанию).

Как в приведенном примере достить такого состояния?

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

L>Аналог let-а — это полумера, т.к. проблема скоупа переменной останется проблемой для конструкций, не являющихся выражениями (например, циклы).

Ну и что, что полумера. Мне для выражений важнее, потому что я предпочитаю их операторам.

L>И какое отношение пример с mutable имеет к обсуждению костантности тоже не понимаю.

Отношение такое: даже в случае, когда не требуется константность, декларативный expressions based синтаксис с let-in/where «прямее» и безопаснее, чем императивный statements based синтаксис «1) объявить переменную; 2) изменить переменную в фигурных скобках».

Q>>Если в приведённом коде y может принимать только два значения (или не принимать их в случае исключения), то в C++/C#-коде к ним добавляется потенциально достижимое состояние, когда y не определена (или инициализирована по умолчанию).
L>Как в приведенном примере достить такого состояния?

На C++ не писал очень давно, так что извините, если что.

#include <cstdlib>
#include <iostream>
#include <stdexcept>

#define _USE_MATH_DEFINES
#include <math.h>

namespace
{
    double my_sin(double φ)
    {
        if (::rand() % 2 == 1)
            throw std::runtime_error("Some failure.");
        else
            return ::sin(φ);
    }
}

int main(int argc, char const* argv[])
{
    double const latitude = 37.0;
    double const radiansPerDegree = M_PI / 180.0;
    double const φ = latitude * radiansPerDegree;
    double y;
    try
    {
        double const sin_φ = my_sin(φ);
        y = 0.5 * ::log((1.0 + sin_φ) / (1.0 - sin_φ));
    }
    catch (std::runtime_error const&)
    {
    }
    
    std::cout << y << std::endl;

    return 0;
}

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

L>>Аналог let-а — это полумера, т.к. проблема скоупа переменной останется проблемой для конструкций, не являющихся выражениями (например, циклы).

Q>Ну и что, что полумера. Мне для выражений важнее, потому что я предпочитаю их операторам.

Ну я лично предпочитаю решения, покрывающие все случаи, а не только частности.

L>>И какое отношение пример с mutable имеет к обсуждению костантности тоже не понимаю.

Q>Отношение такое: даже в случае, когда не требуется константность, декларативный expressions based синтаксис с let-in/where «прямее» и безопаснее, чем императивный statements based синтаксис «1) объявить переменную; 2) изменить переменную в фигурных скобках».

Чо-та я опять не догоняю. В чем потоенный смысл рассмотрения не-константных переменных в ветке, посвязенной обсуждению их констатнных братьев.

Q>>>Если в приведённом коде y может принимать только два значения (или не принимать их в случае исключения), то в C++/C#-коде к ним добавляется потенциально достижимое состояние, когда y не определена (или инициализирована по умолчанию).
L>>Как в приведенном примере достить такого состояния?

Q>На C++ не писал очень давно, так что извините, если что.
Q>

Q>#include <cstdlib>
Q>#include <iostream>
Q>#include <stdexcept>

Q>#define _USE_MATH_DEFINES
Q>#include <math.h>

Q>namespace
Q>{
Q>    double my_sin(double φ)
Q>    {
Q>        if (::rand() % 2 == 1)
Q>            throw std::runtime_error("Some failure.");
Q>        else
Q>            return ::sin(φ);
Q>    }
Q>}

Q>int main(int argc, char const* argv[])
Q>{
Q>    double const latitude = 37.0;
Q>    double const radiansPerDegree = M_PI / 180.0;
Q>    double const φ = latitude * radiansPerDegree;
Q>    double y;
Q>    try
Q>    {
Q>        double const sin_φ = my_sin(φ);
Q>        y = 0.5 * ::log((1.0 + sin_φ) / (1.0 - sin_φ));
Q>    }
Q>    catch (std::runtime_error const&)
Q>    {
Q>    }
    
Q>    std::cout << y << std::endl;

Q>    return 0;
Q>}
Q>

И в этом случае компилятор не ругнется на использование неинициализированной переменной? Имхо, если это так, то это скорее упущение в компиляторе, но не свидетельство некорректности концепции.

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

L>Ну я лично предпочитаю решения, покрывающие все случаи, а не только частности.

Я предпочитаю два частных, но удобных решения для разных нужд, чем одно общее, но страшное решение для, опять таки, разных нужд.

L>Чо-та я опять не догоняю. В чем потоенный смысл рассмотрения не-константных переменных в ветке, посвязенной обсуждению их констатнных братьев.

Ветка посвящена не константности, а проблеме ограничения видимости. В частности, критиковалось такое решение этой проблемы: «1) Объявление; 2) Блок с присваиванием; 3) Использование». В качестве аргумента высказывались соображения константности. Но теперь вместо этого аргумента используются соображения безопасности, не имеющие отношения к константности. Наоборот, рассматривается случай, где константность не только недостижима, но и по каким-то соображениям нежелательна (скажем, дальше y передаётся в third-party функцию по ссылке на неконстанту для чтения и изменения). Всё, забудь про константность. Добавление хитрой константности в язык решит только пол-проблемы, ты же «лично предпочитаешь решения, покрывающие все случаи, а не только частности».

L>И в этом случае компилятор не ругнется на использование неинициализированной переменной? Имхо, если это так, то это скорее упущение в компиляторе, но не свидетельство некорректности концепции. :xz:

Боюсь, что это упущение в языке. Компилятор не может в compile-time понять, будет ли присвоена переменная y в run-time. А если вообще запретить использование «сомнительной» переменной y вне try-catch-блока, то где ж её тогда использовать? Внутри нельзя, мы ж специально старались вынести работу с y из скоупа, чтоб не мешали вспомогательная переменные типа sin_φ.

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

Ф>Что вам не нравится в языке, на котором вы пишете

В шарпе не хватает NotNullable типов классов. Будь такие типы код бы стал проще и надежнее.