OberonCore

Где есть? Если нет на Обероне, в крайнем случае подойдёт на каком-нибудь родственном языке. Сразу для тех, кто скажет, что это нельзя сделать на Обероне. Делается так: заводится тип "вариант" (обычно он есть в Оберонах, в A2/ЯОС их штуки 3, наверное, тут описывал https://tvoygit.ru/budden/ja-o-s/src/branch/главная/док/язык-и-библиотека/динамически-типизированный-укль-и-вариантные-типы.md ), и конструкторы для него. Далее создаётся массив аргументов. В A2/ЯОС это можно (наверное) сделать через конструктор мат. массивов, будет как-то так:


В более продвинутой реализации можно сделать и функцию с произвольными аргументами. В A2/ЯОС уже есть встроенная процедура TRACE, в которой уже встроен механизм произвольных аргументов, разбираемых во время компиляции, и я уже освоил клонирование этого механизма, когда делал процедуру пПиши (одна из частей реализации тут https://tvoygit.ru/budden/ja-o-s/src/co ... .Mod#L6376 , но в целом реализация размазана по всему компилятору ) . Мне нужен только лишь механизм разбора форматной строки.

Если не пытаться следовать С до буквы, то «форматная строка» на AO и CP может выглядеть так:Без механизма разбора форматной строки, как и без возможных ошибок разбора во время исполнения.

Не до буквы, но по мотивам. В принципе, для текущей задачи можно и такой костыль применить. Спасибо, не догадался сам. Но он не сработает, к примеру, если есть задача хранить форматные сообщения на разных языках. Впрочем, в такой ситуации и printf не сработает. Касаемо разбора форматной строки, он должен производиться в приличной реализации во время компиляции, вместе с анализом типов аргументов. Не знаю, как в Си, а в Окамле неверное просто не скомпилируется. Другое дело, что эта же причина затрудняет и локализацию в Окамле, т.к. не помню, что там бывает с форматными строками, не являющимися литералами.

Это очень распространённый паттерн даже не в AO и CP, а вообще. Естественно, на его основе можно сделать и вариант с локализацией, просто выглядеть будет немного иначе. Правда, форматированный вывод в журнал - это сам по себе костыль, которому локализация не нужна.

В A2/ЯОС в интерпретаторе есть интерполяция выражений. Это менее популярная техника, чем форматные строки, для маленьких шаблонов, и более популярная для больших (вспоминаем PHP и другие шаблонизатора). Выглядит так:


печатает следующее:

Естественно, тут можно и подставлять значения переменных интерпретатора.

Если так вдуматься, то, наверное так и получится: для простых шаблонов оптимальнее форматные строки, а для сложных - интерполяция. Но это не точно. Интерполяция, позволяющая вставлять выражения прямо внутрь строки - это штука, конечно, мощная, но стрёмноватая.
Сомнительно, что она подходит под понятие "пути Оберона" вообще. С другой стороны, этот форум написан на PHP, где интерполяция вообще была изначально основным, ради чего создавался инструмент, и в движке данного форума она вовсю используется.

Видимо, для текущей задачи хватит такого решения:

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

Ну что ж, тогда придётся продублировать некоторые процедуры потока, чтобы они возврщали поток. Если нам будет нужна строка, то получится как-то так:


Дикость, конечно, в том же JS можно написать гораздо проще:

Зато минималистично. Соответствующий класс Строки8.Строкодел (да и Строки32.Строкодел) уже есть.

>>>
{Test77.Do@185:data^= Hello 123 5.6789E+2;}

Спасибо, я уже сделал по мотивам идеи, высказанной Константином, примерно так:



Строкодел - это и есть Strings.Buffer, просто я добавил к нему несколько методов. Согласен, что выглядит уродливо, но это временный костыль, и вообще, мы в мире Оберона, где такое принято терпеть. Зато при выводе числа можно передать в качестве параметра ширину поля, а в ситуации с операцией "+" этого сделать нельзя. Это стало решающим фактором. Кроме того, я стараюсь избегать переопределения операций в A2/ЯОС, т.к. мне не нравится, как там сделан полиморфизм. И, как я уже писал, я считаю, что конкатенация (в т.ч. конкатенация строк) должна обозначаться другим значком, а не плюсом.