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

vsb>>Немного не то сказал. Мой поинт в том, что неизменяемой переменной ты не будешь на ровном месте присваивать новое значение. Т.е. ты не будешь писать код kptm2 = 1; ...; kmpt2 = 2; print(kmpt2). Ты вернёшься на место объявления kptm2 и напишешь mutable kptm2 = 1; ...; kmpt2 = 2; print(kmpt2) к примеру. И вот этот пример уже выдаст ошибку — mutable переменная не была изменена.

N>Эээ.
N>1. А с чего бы это сразу объявлять ошибкой? Ну mutable, ну не изменена.
N>(На самом деле тут ещё один вопрос, конечно. Имеет смысл по умолчанию делать, что ситуации типа "присвоенное значение не используется" создают ошибки. Как минимум в release-сборке, если использовать это деление. Но есть же автоматическая генерация кода. Надо иметь возможность контекстно-локально отключать такие ошибки.)

Можно делить на ошибки и предупреждения, но в релизном коде не должно быть ни тех, ни других. Хотя я бы вообще предложил кардинальный подход — не делить на ошибки и предупреждения, а генерировать в отладочном режиме бинарник, даже если встречаются ошибки, которые можно локализовать. Я давным давно писал на жава в эклипсе, вот там такая фича была. И это было очень удобно. Не дописал функцию, и ладно. Если туда управление придёт, то вместо недокомпилированного кода вылетит ошибка. А так — какой-то кусок кода недописан, а ты тестируешь другой кусок и тебе на первый кусок пофиг, пускай генерирует, что может. Есть исключения вроде несбалансированных фигурных скобок, но обычно ошибку локализовать можно. А если немножко включить эвристики и проанализировать отступы, можно и про скобки подумать.

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

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

N>Надо смотреть на практику Питона, где эта диверсия по умолчанию.

Вот, кстати, да. Я на питоне не то, чтобы много писал, но немного писал. И конкретно эта фича мне проблем кажется не доставляла.

N>Так и тут — если ты напишешь "let kptm2 = foo()", или "kptm2 := foo()", как в Go с его присвоением-с-декларацией, а не "kptm2 = foo()", это будет совершенно минимальная добавка, зато исключит массу проблем.

Ну мне интересен эдакий минимализм в дизайне. С одной стороны минимум синтаксиса, с другой стороны максимум ограничений в нужных местах. Допускаю, что на практике проблем будет масса, хотя всё же считаю, что на практике будет вполне удобоваримо.

vsb>>Автовывод типа это уже давно стандарт де-факто почти во всех языках и подразумевается сам собой.

N>Да вот не совсем. Ты смешиваешь два автовывода — автовывод по инициализации и автовывод по всему использованию.
N>Первый — удел процедурных языков. Второй — группы *ML/Haskell/etc.

Я про первый. Автовывод типов для функций — вопрос сложный. С одной стороны для всяких лямбд он нужен по-любому, с другой стороны для "настоящих" функций типы должны быть фиксированы, когда я хаскель изучал, даже там рекомендовалось сигнатуры прописывать вручную.

vsb>>Все типы локальных переменных выводятся и это не опционально.

N>Ну да, ещё скажи, что ты не можешь сказать "int x" для локальной переменной, только "var x"
N>Непонятно, что ты имел в виду на самом деле, но сказано безнадёжно коряво. Перефразируй.

Не очень понял, что не понятно. У нас ведь в гипотетическом языке нет ни var ни int. У нас есть только x = 1 или x = get_int_value(). Иными словами типы всех локальных переменных выводятся автоматически и отказаться от этого нельзя. Максимум — добавить каст в инициализирующее выражение, чтобы привести его к нужному типу.