Если написанное — банальщина, не обессудьте. Профан я в этих делах, так только, мысль когда посетит мимолетная.
Почитал я, что в Nemerle def не хотят менять на var из-за навязываемой иммутабельности. Попутно вспоминают Скалу с val/var. Но что за странная идея делать мутабельный или иммутабельный вывод типов! Иммутабельность не есть ли свойство самого типа? Так не лучше ли вернуть старый добрый const?
Было:
def o = new MyType(); // Immutable.
var o = new MyType(); // Mutable.
Стало:
MyType o = new MyType(); // Mutable.
const MyType o = const new MyType(); // Immutable.
Тогда и вывод типов будет единообразный. Достаточно одного var.
var o = new MyType(); // Mutable.
var o = const new MyType(); // Immutable.
А еще лучше, если const будет по умолчанию:
const MyType o = new MyType(); // Immutable.
var o = new MyType(); // Immutable.
MyType o = var new MyType(); // Mutable.
var o = var new MyType(); // Mutable.
Здравствуйте, SV., Вы писали:
SV.>Если написанное — банальщина, не обессудьте. Профан я в этих делах, так только, мысль когда посетит мимолетная.
SV.>Почитал я, что в Nemerle def не хотят менять на var из-за навязываемой иммутабельности. Попутно вспоминают Скалу с val/var. Но что за странная идея делать мутабельный или иммутабельный вывод типов! Иммутабельность не есть ли свойство самого типа? Так не лучше ли вернуть старый добрый const?
В дотнете тип не несет признаков иммутабельности. А значит, по типу выражения нельзя сказать, будет ли результат иммутабелен. Иммутабельность в дотнете — только лишь сигнал компилятору о необходимости выброса ошибки при повторном присванивании.
SV.>А еще лучше, если const будет по умолчанию:
SV.>
SV.>const MyType o = new MyType(); // Immutable.
SV.>var o = new MyType(); // Immutable.
SV.>MyType o = var new MyType(); // Mutable.
SV.>var o = var new MyType(); // Mutable.
SV.>
Здравствуйте, SV., Вы писали:
SV.>Если написанное — банальщина, не обессудьте. Профан я в этих делах, так только, мысль когда посетит мимолетная.
SV.>Почитал я, что в Nemerle def не хотят менять на var из-за навязываемой иммутабельности. Попутно вспоминают Скалу с val/var. Но что за странная идея делать мутабельный или иммутабельный вывод типов! Иммутабельность не есть ли свойство самого типа? Так не лучше ли вернуть старый добрый const?
Мы не def не хотим менять на var. Речь шла о замене mutable на var. В Scala вообще дурь с var/val — эти два ключевых слова крайне похожи друг на друга (расстояние Хэмминга равно 1) и читая код без подсветки синтаксиса легко их попутать.
SV.>Было:
SV.>
SV.>def o = new MyType(); // Immutable.
SV.>var o = new MyType(); // Mutable.
SV.>
SV.>Стало:
SV.>
SV.>MyType o = new MyType(); // Mutable.
SV.>const MyType o = const new MyType(); // Immutable.
SV.>
SV.>Тогда и вывод типов будет единообразный. Достаточно одного var.
Какой вывод типов?? Ты упомянул MyType там где его можно было не указывать (DRY)
Здравствуйте, SV., Вы писали:
SV.>Почитал я, что в Nemerle def не хотят менять на var из-за навязываемой иммутабельности.
Вообще-то речи о замене def на var никогда не шло. Вообще никогда. Разговор был о замене ключевого слова mutable, которое, по мнению многих начинающих изучать язык товарищей слишком длинное. Вот только это мнение резко меняется после месяца другого использования языка.
SV.>Попутно вспоминают Скалу с val/var. Но что за странная идея делать мутабельный или иммутабельный вывод типов!
Какой еще вывод типов? Изменяемость — это признак переменных. Выводу типов совершенно по барабану тип чего выводится. Ну, разве что проверка делается на возможность присвоения переменной нового значения.
SV.>Иммутабельность не есть ли свойство самого типа?
По большому счету — нет. Изменяться или нет могут только переменные (локальные или поля).
Но в принципе помечать типы как состояние — это разумная оптимизация. Вот только тип не изменяющий свое сотояние может изменять чужое состояние. Или он может испльзовать изменяемые локальные переменные. Все эти вещи мало связаны друг с другом. От того встает большой вопрос что же таки понимать под неизменяемостью типа. На мой взгляд логично было бы предположить, что речь пойдет об неизменяемости его полей. Вот только это не гарантирует функциональной чистоты. А она очень важна во многих случаях. Например, при распараллеливании кода. Ведь совершенно все равно какой состояние меняется. Важно что это может привести к гонками в многопоточном коде или еще к каким-то проблемам.
SV.>Так не лучше ли вернуть старый добрый const?
Он далеко не добрый. В С++ он скорее злой. Проблем создает больше чем решает.
SV.>Было:
SV.>
SV.>def o = new MyType(); // Immutable.
SV.>var o = new MyType(); // Mutable.
SV.>
SV.>Стало:
SV.>
SV.>MyType o = new MyType(); // Mutable.
SV.>const MyType o = const new MyType(); // Immutable.
SV.>
Эти фрагменты не эквивалентны, как понимаю. В первом варианте неизменяемой является только переменная. Во-втором, явно подразумевается наложение ограничений на сам объект.
И очень плохо то, что ограничение налогается не на тип, а на конкретный объект. Это по сути означает, что тем самым для каждого типа вводится еще один тип, а тип объекта может меняться по ходу пьесы. Именно это и создавало проблемы в плюсах.
В кругах ФЯ неизменяемость имеет куда больший смысл и работать с ней куда удобнее и проще. В этих языках давно поняли, что важны не столько неизменяемые значения, сколько чистые функции — функции не производящие побочных эффектов.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
SV.>>Попутно вспоминают Скалу с val/var. Но что за странная идея делать мутабельный или иммутабельный вывод типов!
VD>Какой еще вывод типов? Изменяемость — это признак переменных. Выводу типов совершенно по барабану тип чего выводится. Ну, разве что проверка делается на возможность присвоения переменной нового значения.
Я предлагаю взглянуть на это по-новому. Если вы пишете
def o = new MyType();
mutable o = new MyType();
и в том, и в другом случае происходит вывод типов. Так? И в том, и в другом случае выводится тип одного и того же выражения. Так? Но в первом случае получаем переменную, которую нельзя менять, а во втором — можно. Вполне можно сказать, что это разные способы вывода типов. Отличаются они некоторым свойством (или признаком, что одно и то же). Если этот признак процесса вывода типа назовем "изменяемостью применительно к процессу выводу типов" (новое понятие), то можно сказать, что изменяемость применительно к процессу вывода типов влияет на изменяемость объявляемой при этом переменной. А это уже общепринятое понятие, см. выделенное мною в вашей цитате.
Эти рассуждения я поскипал, а начал сразу с того, что "изменяемость применительно к процессу выводу типов" мне не нравится. Вполне можно обойтись одним var'ом.
SV.>>Иммутабельность не есть ли свойство самого типа?
VD>По большому счету — нет. Изменяться или нет могут только переменные (локальные или поля). VD>Но в принципе помечать типы как состояние — это разумная оптимизация. Вот только тип не изменяющий свое сотояние может изменять чужое состояние. Или он может испльзовать изменяемые локальные переменные. Все эти вещи мало связаны друг с другом. От того встает большой вопрос что же таки понимать под неизменяемостью типа. На мой взгляд логично было бы предположить, что речь пойдет об неизменяемости его полей. Вот только это не гарантирует функциональной чистоты. А она очень важна во многих случаях. Например, при распараллеливании кода. Ведь совершенно все равно какой состояние меняется. Важно что это может привести к гонками в многопоточном коде или еще к каким-то проблемам.
То, что предложил я, однозначно переводится в существующий код Nemerle. Правила перевода даны.
На самом деле, я все думаю, как бы я сделал так, чтобы переход с шарпа на более функциональный язык оказался менее болезненным. Мой подход позволяет 1) оставить привычный var, что не может не радовать глаз, и 2) при сохранении привычного синтаксиса инстанцирования навязать иммутабельность. Продажа, понимаете?
Здравствуйте, SV., Вы писали:
SV.>На самом деле, я все думаю, как бы я сделал так, чтобы переход с шарпа на более функциональный язык оказался менее болезненным. Мой подход позволяет 1) оставить привычный var, что не может не радовать глаз,
Имхо, не нужен var. Ни такой ценой, ни вообще. def/let вполне понятны и привыкнуть к ним — вопрос одного дня.
SV.>и 2) при сохранении привычного синтаксиса инстанцирования навязать иммутабельность. Продажа, понимаете?
инстанцирования?
Вы навязываете иммутабельность выражению, вы это понимаете? Какой смысл в иммутабельности выражения?
SV.>2Samius,
>>var i = var 0? >>не слишком будет?
SV.>Пишите int i = 0;
Предлагаете отказываться от вывода типов?
SV.>def o = new MyType();
SV.>mutable o = new MyType();
SV.>
SV.>и в том, и в другом случае происходит вывод типов. Так?
Так.
SV.>И в том, и в другом случае выводится тип одного и того же выражения. Так?
Да. И он один и тот же.
SV.>Но в первом случае получаем переменную, которую нельзя менять, а во втором — можно.
Правильно, так как это признак переменной.
SV.>Вполне можно сказать, что это разные способы вывода типов.
Нет. В данном случае тип один и тот же. Скорее можно говорить об особенностях разрешения имен которое является частью процесса типизации (как и вывод типов). Но напрямую вывод типов и неизменяемость переменных не связана.
SV.>Отличаются они некоторым свойством (или признаком, что одно и то же).
Тип и неизменяемость — это атрибут (свойство) переменной. Но к типу это отношение не имеет.
Вот в С++ попытались втащить "константноть" в типы. Вышла жуткая фигня. Люди мучуются потому, как приходится учитывать тот факт, что любого типа может быть два. Простой и "константный". И шаблонами это не лечится.
SV.>Если этот признак процесса вывода типа назовем "изменяемостью применительно к процессу выводу типов" (новое понятие), то можно сказать, что изменяемость применительно к процессу вывода типов влияет на изменяемость объявляемой при этом переменной. А это уже общепринятое понятие, см. выделенное мною в вашей цитате.
Ты перепутал разные понятия. Вывод типов — это совершенно отдельная фича. Ее в языке может и не быть. Например, в С ее нет. Есть процесс типизации. Вот с ним, наверно, ты и путаешь вывод типов.
Далее переменная — это сущность фигурирующая в процессе типизации. Точнее сущность фигурирующая в процессе разрешения имен. Он, в принципе, может быть выделен в отдельную стадию и не иметь отношения к типизации.
Тип же — это такой же атрибут переменной как неизменяемость.
SV.>Эти рассуждения я поскипал, а начал сразу с того, что "изменяемость применительно к процессу выводу типов" мне не нравится. Вполне можно обойтись одним var'ом.
Можно обойтись и без переменных вообще. Но зачем? Наличие изменяемых и не изменяемых переменных позволяет явно декларировать намерения программиста и уберегает от ошибок. При этом она не приводит к геморрою, как в случае с const из С++. В прочем, я уже объяснял, что это разные вещи.
SV.>То, что предложил я, однозначно переводится в существующий код Nemerle. Правила перевода даны.
То что предложил ты а) не четко сформулировано, б) неудобно, в) не нужно.
SV.>На самом деле, я все думаю, как бы я сделал так, чтобы переход с шарпа на более функциональный язык оказался менее болезненным.
А какова связь между темой и безболезненностью перехода от шарпа к ФЯ?
SV.>Мой подход позволяет 1) оставить привычный var, что не может не радовать глаз, и 2) при сохранении привычного синтаксиса инстанцирования навязать иммутабельность. Продажа, понимаете?
Я понимаю только одно. Наличие def ни разу не останавливает от освоения языка. Общая близость синтаксиса, возможно упрощает переход. Но сап по себе def — это чистое расширение которое все кто осваивал язык считают очень полезным. Так что по сути отсутствует сама обсуждаемая проблема. Возможно ты просто заметив какую-то другую проблему подумал, что ее причина это наличие def. Но это не так.
SV.>2Samius,
>>var i = var 0? >>не слишком будет?
SV.>Пишите int i = 0;
Это древесный форум. Тут нужно отвечать каждому оппоненту отдельным сообщением.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
H>Мы не def не хотим менять на var. Речь шла о замене mutable на var. В Scala вообще дурь с var/val — эти два ключевых слова крайне похожи друг на друга (расстояние Хэмминга равно 1) и читая код без подсветки синтаксиса легко их попутать.
Здравствуйте, Ka3a4oK, Вы писали:
H>>Мы не def не хотим менять на var. Речь шла о замене mutable на var. В Scala вообще дурь с var/val — эти два ключевых слова крайне похожи друг на друга (расстояние Хэмминга равно 1) и читая код без подсветки синтаксиса легко их попутать.
KK>На скале не писал, но если это так, то это жесть.
Пофиг, на самом деле. Причём по той же причине, по которой немерлисты защищают многобуквенный mutable: его крайне редко используют. Есть ещё warning типа "значение не меняется, можно юзать val вместо var". Хотя лично я на эту тему ни разу не опечатывался.
Здравствуйте, VladD2, Вы писали:
VD>То что предложил ты а) не четко сформулировано, б) неудобно, в) не нужно.
a) Возможно, я спец по другим вещам. В конце концов все поняли, и это главное.
б) и в) В настоящее время рекордсменом по "не нужно" среди посетителей этого ресурса является кое-что другое. И это была отправная точка моих рассуждений.
Резюме — объективные возражения, если есть, я с удовольствием послушаю, а про удобство и нужность я бы вообще постеснялся.
Здравствуйте, SV., Вы писали:
SV.>Здравствуйте, VladD2, Вы писали:
VD>>То что предложил ты а) не четко сформулировано, б) неудобно, в) не нужно.
SV.>a) Возможно, я спец по другим вещам. В конце концов все поняли, и это главное. SV.>б) и в) В настоящее время рекордсменом по "не нужно" среди посетителей этого ресурса является кое-что другое. И это была отправная точка моих рассуждений.
SV.>Резюме — объективные возражения, если есть, я с удовольствием послушаю, а про удобство и нужность я бы вообще постеснялся.
Вводить в язык модификатор изменяемости выражения или даже rvalue вместо модификатора изменяемости переменной ради вывода компилятором модификатора изменяемости переменной — очень сомнительная идея.
Возьмем исходный посыл
MyType o = var new MyType(); // Mutable.
var o = var new MyType(); // Mutable.
Что будет если после этой строчки я напишу
o = /*const*/new MyType();
?
Должен ли измениться модификатор o от присвоения ему immutable значения? Если нет, то видимо надо запрещать такое? Если запрещать — ниужели при любом присваивании мутабельной переменной нужно писать var?
var i = var 0;
i = var i + 1;
В таком случае, "=var" будет обязательным для любого присваивания мутабельной переменной. Так не логичнее было бы ввести спец оператор для присваивания изменяемым переменным? Например, ":=". Ни в коем случае не призываю к такому, просто пытаюсь показать несуразность предложения с var-ом.
