OberonCore

Это больше на Лейбница уже смахивает.

Можно ссылку? А то в хакадже есть библиотека для работы с физическими размерностями, кому надо -- пользуются...
http://hackage.haskell.org/package/Measure например...

Это не размерности, а единицы измерения.

Вот поэтому и не следует экспортировать объекты без указания их типов.

Так мы же, вроде, стараемся избегать неявностей. Все правила, приводящие к значению данного типа, должны быть частью описания данного типа. А создавать тип "исходя из способа использования объекта" - значит либо погоню за "эффективностью", когда не используемые в данные момент правила считаются лишними и не включаются в описание типа, либо у программиста отсутствует полное представление о типе.

А если объект вдруг был использован неправильно, то тип будет наделён лишней семантикой, что вообще является ошибкой, ради устранения которых и вводилась типизация. То есть, позволяя выводить тип исходя из способов использования объекта, мы добавляем себе геморроя по построению типа, но не избавляемся от ошибок, ради которых типы используются.

Так это как будто я предлагаю.

Это ФПшники. Биют себя пяткой в грудь и вопят, что жизнь не мила без автовывода типов по Хинди-Милнеру.
И утверждают, что это ничего не стоит. И даже можно было бы, типа, в Обероне иметь.

Я и привёл пример хороший - что в случае с очень многими средствами народ забывает про раздельную компиляцию. Просто потому, что с привычкой к Build All даже не в курсе, что это и зачем.

Способ использования задается математической моделью соответствующей физической теории. Возьмем, например, теплофизику и формулу pV/T=const.

Использование переменных типа p, V, T вне контекста очевидно не будет содержать ошибки. Значит, экспортирование размерных переменных не может производиться без экспорта теории.

Таким образом, физическая теория соответствует программистскому понятию интерфейса. Соотношения типов должны быть доступны через интерфейс.

Аппарат и задачка для реализации любопытная, да.

Только тащить в язык не стоит.

А вот сделать генерационную надстройку - если вдруг кому-то много-много надо чисто с таким работать...

Описания таких типов, правил - и формул в выражениях - сделать, например, как вьюшки в тексте. И пусть из них КП-код генерится.

Ну, наплодите Вы кучу модулей, экспортирующих различные теории. Насколько я понял, у программиста есть <возможность> использовать их не иначе как комбинационным способом. Какова вероятность того, что результат комбинации будет иметь реальный физический смысл?
Другая крайность:
Есть ещё и эмпирические формулы. Может статься так, что экспортированная эмпирика вкупе с использованием модуля, экспортирующего теорию даст весьма неожиданный результат, найти физический смысл которого будет тоже очень трудно.

А по интерфейсам в этих случаях будет всё в порядке..

По моему, создать такой программисткий аппарат не менее затратно чем создать математический аппарат. Возможно имеет смысл если мат аппарата еще нет. А так лучше сосредоточиться на составлении грамотных ассертов.

Ну да. Чем RECORD и процедуры-операции - не решение...

Зачем кучу модулей. Возьмем понятия механики, как пример достаточно общей теории.
Вы, таки, будете смеяться, но требуется всего 1 модуль и 3 базовых типа, например, длина, время и масса, а все прочие типы будут производные (говорят, достаточно двух базовых типов, но я не проверял).

Впрочем, я согласен с мнением, что вся эта требуха интереснее как задача, а не как кандидат в Оберон

Пример "аппарата"

MODULE Mechanics;

type Dlina- = REAL;
Vremja- = REAL;
Massa- = REAL;
Skorost- = REAL;
Uskorenie- = REAL;
(*pragma type Skorost- = Dlina / Vremja *)
(*pragma type Uskorenie- = Skorost / Vremja *)

const g- : Uskorenie = 9.8;

END Mechanics;

-------------------------------

MODULE Moja_Zadacha;
IMPORT Mechanics;

var h: Mechanics.Dlina;
t: Mechanics.Vremja;

In.Real(t);
h := Mechanics.g * t ^2 / 2;
Out.Real(h)

END Moja_Zadacha;

Поскольку паскаль у нас компонентный, то выдираем из транслятора синтаксический анализ и прибабахиваем к нему вместо генератора кода проверщик размерностей в выражениях на основе прагм. Такой вот, возможно бесполезный, инструмент...

По такому принципу сделан DevAnalyzer.

А так не лучше? При том, что реализацию можно нагрузить конкретными особенностями и ограничениями

MODULE Mechanics;
TYPE
Values* = POINTER TO ABSTRACT RECORD END;

PROCEDURE (v: Values) SetSkorost* (a:REAL); NEW, ABSTRACT;
PROCEDURE (v: Values) SetUskorenie* (a:REAL); NEW, ABSTRACT;
PROCEDURE (v: Values) SetDlina* (a:REAL); NEW, ABSTRACT;
PROCEDURE (v: Values) SetMassa* (a:REAL); NEW, ABSTRACT;
PROCEDURE (v: Values) SetVremja* (a:REAL); NEW, ABSTRACT;

PROCEDURE (v: Values) GetSkorost* ():REAL; NEW, ABSTRACT;
PROCEDURE (v: Values) GetUskorenie* ():REAL; NEW, ABSTRACT;
PROCEDURE (v: Values) GetDlina* ():REAL; NEW, ABSTRACT;
PROCEDURE (v: Values) GetMassa* ():REAL; NEW, ABSTRACT;
PROCEDURE (v: Values) GetVremja* ():REAL; NEW, ABSTRACT;

END Mechanics;

Берите гауссову систему, и меряйте все в степенях Гэв-а.
В далеком и счастливом "детстве" - ПРОВЕРЯЛ лично, никаких проблем
Типа e^2 = p^2 + m^2 - и всего делов
Нет также сомнений, что если "объединичить" гравитационную постоянную, то вообще все будет безразмерными единицами.

Уже достигнуто. Только меряют не в гэвах, а в реалах (REAL) и дублях (DOUBLE), см. паскали, сия, джавы и т.д.

Не, ну это несерьёзно, имхо..

Все эти рассуждения очень напоминают ситуацию смешения парадигм.
Человек (топикстартер) столкнулся, видимо, с ФП, и оно ему понравилось.
А затем столкнулся с Обероном (чистой императивщиной, IMO), ну вот и понеслась.

Не надо путать теплое с мягким!
В ФП заложена огромная сила (с выводом типов, каррированными функциями и пр.).
В Обероне заложена огромная сила (со строгой типизацией, чистой модульностью и пр.).

И в той, и в другой области есть свои проблемы, которые, кстати, нередко успешно решаются.

Но если средства одной области бездумно (т.е. без особой надобности) тащить в другую, получится плохо.

При чём здесь ФП? Человек (топикстартер) столкнулся с Адой, а это не менее чистый императив, чем Оберон.
В Аде такое возможно (удобная работа с единицами измерений), даже в С++. В Оберене -- нет...
Не очень строгая типизация в вашем обероне...