Ответ на »сообщение 1373« (Max Belugin)
___________________________

а closures в обероне есть? например, можно ли транслировать вот такой код:

function adder(x){
  var counter=0;
  return function (){
    return counter+=x;
  }
}
var a1 = adder(1);
var a2 = adder(2);

WScript.Echo(a1());
WScript.Echo(a1());
WScript.Echo(a2());
WScript.Echo(a2());


Ну и ужас Вы привели! Вот после таких примеров люди и начинают показывать пальцем на функциональное программирование и говорить: "Фу! Кака!" 8-о

Это отличный пример того, как НЕ НАДО делать!
Здесь теряется самое главное свойство ФП - чистота функций! Обе эти функции a1 и a2 при каждом новом вызове возвращают каждый раз разные результаты, хотя судя по их параметрам (точнее, по отсутствию таковых) они не должны иметь такого непредсказумого поведения...

Вы ведь должны понимать, что такой стиль приведёт к таким неуловимым багам, что страшно становится...
Ну даже если багов случайно и не окажется, понять такой код без документации в десять раз более объёмной - mission imposible!

ЗЫ. Вообще, имхо, если уж заниматься функциональным программированием - то лучше на функциональных языках, причём чистых, где приведённый Вами код просто недопустим в виду побочных эффектов.

Ответ на »сообщение 1403« (Alexey Veselovsky)
___________________________
Хотя нет, не проще - так же.

Проще и нагляднее будет как раз на C++. Что-то типа:

typedef typed_int<struct color_tag> Color;

Ответ на »сообщение 1401« (Сергей Губанов)
___________________________

Ответ на »сообщение 1400« (Alexey Veselovsky)
___________________________
TYPE
  Color* = RECORD value-: INTEGER END;
  Volume* = RECORD value-: INTEGER END;


Это уже лучше, только вот "простота и наглядность" куда-то подевалась. Завести константу такого типа нельзя. Вернуть по значению такой тип нельзя. Получается что-то типа:

VAR c: Colors.Color;
BEGIN
    Colors.InitRed( c );
    Paint( c );

Ответ на »сообщение 1402« (Alexey Veselovsky)
___________________________

Спасибо.
Гм... Получается тот же механизм что и в С++, только существенно проще.

Хотя нет, не проще - так же.
Только в С++ можно еще и операции безопасные привычные сделать(типа умножения и т.п.). Но в данном случае это видимо излишне.

Ну если реально, тогда просто INTEGER-ами они быть не должны (это полумера), так как один INTEGER-тип от другого динамически (во время исполнения программы) отличить нельзя. Нужен скрытый тег. А раз так, то Вам необходимо использовать следующие типы:

TYPE
  Color* = RECORD value-: INTEGER END;
  Volume* = RECORD value-: INTEGER END;


Спасибо.
Гм... Получается тот же механизм что и в С++, только существенно проще.

Ответ на »сообщение 1400« (Alexey Veselovsky)
___________________________

Реально боитесь перепутать или так, для понта?

Реально. Особенно когда над проектом работают много людей. Особенно когда некоторые из них новички (в данном конкретном проекте), а сроки поджимают...

А такая вот строгая субтипизация, во-первых позволяет выявлять множество неприятных (глупых)ошибок еще на этапе компиляции, во-вторых заставляет более глубоко анализировать задачу.

Ну если реально, тогда просто INTEGER-ами они быть не должны (это полумера), так как один INTEGER-тип от другого динамически (во время исполнения программы) отличить нельзя. Нужен скрытый тег. А раз так, то Вам необходимо использовать следующие типы:

TYPE
  Color* = RECORD value-: INTEGER END;
  Volume* = RECORD value-: INTEGER END;

Реально боитесь перепутать или так, для понта?

Реально. Особенно когда над проектом работают много людей. Особенно когда некоторые из них новички (в данном конкретном проекте), а сроки поджимают...

А такая вот строгая субтипизация, во-первых позволяет выявлять множество неприятных (глупых)ошибок еще на этапе компиляции, во-вторых заставляет более глубоко анализировать задачу.

Ответ на »сообщение 1397« (Alexey Veselovsky)

Я просто хочу чтобы типу COLOR (цвет) нельзя было присвоить значение переменной типа VOLUME (громкость). Вот и все. Физически и то и другое является целым числом без ограничения (языкового) на множество значений.

Реально боитесь перепутать или так, для понта?

Ответ на »сообщение 1392« (Илья Ермаков)
___________________________

Назначьте псевдоним:


Немногим лучше, чем "прочтите документацию"...

Как показывает практика, никакого принципиального ущерба от этого не замечается.


Моя практика показывает совершенно обратное.


В Оберонах принята практика в начале каждой процедуры ВСЕГДА писать неотключаемый ASSERT


ASSERT не поможет. Обрати внимание на то, что значения констант в примере одинаковые. Не говоря уже о принципиальной разнице compile-time и run-time.


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


Всплывают как миленькие. Уж сколько раз я рефакторил код на предмет подобного рода багов. Бродит вот такой INTEGER из функции в функцию и фиг знает кто и когда его его делает невалидным. После типизирования - все как на ладони.


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

Все наоборот. Контроль типа требуется ровно в одном месте - там где переменная такого типа приходит извне в виде набора битов (из файла, ее вводит пользователь, и т.п.). А вот контроль на входе процедур как раз оказывается многократно накладнее.

Ответ на »сообщение 1396« (Илья Ермаков)
___________________________

Ответ на »сообщение 1393« (Alexey Veselovsky)
___________________________

Ответ на »сообщение 1392« (Илья Ермаков)
___________________________
Повтори пожалуйста почему отказались от строгой субтипизации.
Потому что INTEGER+константы легко расширяется без перекомпиляции. Ввели новые константы, старые клиенты работают, ничего не зная о них. При субтипизации - одно из двух: либо введение в перечисление/диапазон новых элементов требуем перекомпилировать всех клиентов, и компонентность летит в..., либо требуется изобретать какой-то навороченный механизм расширения субтипов и контроля соответствия версий.

Гм... А при чем тут перечисления и диапазоны?
Я просто хочу чтобы типу COLOR (цвет) нельзя было присвоить значение переменной типа VOLUME (громкость). Вот и все. Физически и то и другое является целым числом без ограничения (языкового) на множество значений.