OberonCore

Для одной задачки компьютерной алгебры делаю некую квази-файловую системку.
Выясняется следующее.

Райдеры (Reader, Writer) модуля Stores (это, кстати, записи на стеке) подсоединяются к нужному файлу посредством метода .ConnectTo( файл ),
а затем нацеливаются на нужное место в файле методом .SetPos( pos ).

На самом деле точнее было бы подсоединять их не к файлу, а к райдеру, типа:

Stores.Writer.BindTo( baton: Files.Writer ); (* baton = эстафетная палочка *)

Райдеры модуля Files помнят своё положение, и из-за этого очищается код:
ансамбль процедурок обмениваются таким baton-ом без необходимости мусолить Pos, SetPos и передавать соответствующее целое.

Для себя я добавил в Stores простые процедуры

PROCEDURE BindReader (VAR rd: Reader; to: Files.Reader);
PROCEDURE BindWriter (VAR wr: Writer; to: Files.Writer);

но чище было бы сделать их стандартным средством каркаса, привязав к Reader/Writer.

Это предложение по развитию каркаса.

PS
Разумеется, я пробовал всякие варианты вроде того, чтобы роль эстафетной палочки играл указатель на Stores.Writer, размещённый на куче. Как-то обойтись можно -- но ценой грязи в коде.
Объективная логика диктует вышеописанное решение.

Поддерживаю.

Еще одно преимущество такой схемы - возможность программисту уменьшить нагрузку на динамическую память: можно единожды создать бегунок/райдер и передавать его разным чтецам/писцам.

Я ради этой экономии создаю глобальные "кешированные" чтецы/писцы и/или бегунки, но ясности программе это, конечно, не добавляет. И чаше работаю с текстами, чем с файлами.

Читатели, конечно, пытаются повторно использовать уже созданные бегунки, и внутри .ConnectTo вызывают .NewReader(rd); однако "старый" бегунок может быть не совместим с той реализацией текста/файла, к которой подсоединяется читатель, и поэтому создается новый.

Можно расширить, чтобы не ломать старые программы:

PROCEDURE (rd: Stores.Writer) ConnectToRd (rd: Files.Reader), NEW;