Оберон-клуб «ВЄДАsoft»

Может быть специально для таких системных случаев добавить специальный вид процедур (не в Оберон, а в Ofront, навроде PROCEDURE-)?
Введем процедуры с переменным числом параметров вида Такая процедура имеет единственный параметр и не может возвращать значение (не функция). Знак ".." после этого параметра означает, что можно вызывать не только Proc(exp1), но и Proc(exp1,exp2) или Proc(exp1,exp2,exp3,exp4,exp5). Т.е. процедура может иметь любое количество фактических параметров (не менее одного), но все эти параметры должны быть одинакового типа.
Вызов Proc(exp1,exp2,...,expN) понимается как Proc(exp1);Proc(exp2);... Proc(expN)
Тогда можно было бы сделать и Asm.Code с любым числом строчек и еще много чего полезного.

P.S. По терминологии. Наверно лучше назвать это не "процедура с переменным числом параметров" (как в С, где доп.параметры могут быть любых типов), а "процедура с мультипараметром", потому что формальный параметр один (при описании процедуры), хотя и может повторяться сколько угодно раз при вызове.

Начать можно с модуля OPP:

Конечно, это только начало. Остальное надо дописывать.

Олежка, прошу не обижаться, но мне эта фишка кажется излишней. Так теряется дополнительный контроль количества байтов, слов, строк. А число в Asm.CodeN даже добавляет строгости. Можно потом сказать: моя процедура занимает N строк на асме.

Зато проще при редактировании вставлять-удалять строки, не пересчитывая.

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

Плюсы у такого переменного числа параметров тоже есть, не буду спорить. Но это уход от строгости Оберона и Модулы, хоть и для системных целей, но всё же.

Ну да бог с вами, можно сделать. Особенно если поможете.

Предпоследняя строка.

IF (fpar # NIL) & (fpar^.link^.vis # multiPar) THEN err(65) END (* учтем мультипараметр*)

Если fpar^.link=NIL, то ошибки левой не даст? Предлагаю:

IF (fpar # NIL) & ~((fpar^.link#NIL) & (fpar^.link^.vis = multiPar)) THEN err(65) END (* учтем мультипараметр*)

Да, верно. Если формальных параметров ровно на 1 больше, и это не мультипараметр, то fpar^.link=NIL, что даст ошибку.
Действительно, нужно внести такое исправление, спасибо.

А зачем нужен контроль количества строк? Я понимаю, если байты, слова или еще какие-то элементы. Тогда можно написать "я размещаю в этом буфере 512 байтов, вот они...". И если далее указать иное количество, то контроль должен это обнаружить. Но строки в листинге ассемлера... Ведь каждая из них может порождать 1, 2, 3 или даже более байтов , или 0 (комментарий например или макрос). Вообще, часто ли программисту приходится считать строки или операторы? Разве что для оплаты (столько-то центов за строчку) или в конкурсе "программа из наименьшего числа строк".
Контроль - это когда сравнивается информация, полученная разными путями. Например, контрольная сумма, вычисленная для принятых данных, сравнивается с КС, которая передана с этими данными. Или END, соответствующий по вложенности BEGIN-у процедуры, сравниваестя с END-ом, помеченным именем этой процедуры.
Контроль бы работал, если бы программист заранее знал точное число строчек ассемблера. "Ага, чтобы перекрасить спрайт, мне надо 5 строчек. Ставим 5, пишем строчки, запускаем... Ошибка - я уложился в 4. Какую строчку я забыл?" Никто заранее не вычисляет количество строк. Если мы введем контроль по количеству, то программист как и раньше будет писать строки программы не задумываясь об их количестве , потом пальцем пересчитает строчки и поставит результат подсчета в нужное место. Что даст такой контроль, кроме развития начальных арифметических навыков?
Но ассемблерная вставка - это не Оберон и не Модула, это Ассемблер! Эти текстовые строчки по смыслу именно операторы Ассемблера, следующие друг за другом, как и в программе на Обероне операторы Оберона идут друг за другом через ";". Оберон в разумной строгости своей не требует "для контроля" указывать в скобках после BEGIN количество операторов, которые идут до соответствующего END. В любом ЯП можно свободно соединять сколько угодно операторов, не пересчитывая их вручную. Но мы не можем писать в программе на Обероне операторы ассемблера напрямую и приходится использовать специальную процедуру, у которой эти операторы выражаются через фактические параметры. А параметров у процедуры не может быть переменное количество.
Так что "строгость, простота и контроль" относятся к требованию Оберона иметь у процедуры фиксированное количество параметров. Это весьма разумное требование само по себе, но нам оно мешает потому, что вызов процедуры Asm.Code - это программа на ассемблере и параметры - это операторы ассемблера.

Посмотрите, какой механизм процедур с переменным числом параметров у Си. Чтобы извлечь очередной параметр нужно вручную указывать его тип, через макросы передвигать указатель по стеку. Компилятор никак не контролирует ни количество параметров, ни их размер. Вот уж где бескрайний простор для ошибок! Вот чего в Обероне быть не должно!
"Имя процедуры однозначно задает количество параметров"-это наиболее простой принцип. Если бы это было не так, то пришлось бы вводить понятия "профиль процедуры", описывать синтаксис "необязательный параметр", вводить функцию, сообщающую число параметров и пр. Из этого принципа появляется возможность контролировать при вызове соответствие имени процедуры и фактически указанное количество параметров, что выловит некоторые ошибки.
А много ли мы теряем из-за такой строгости? Нет. Если у процедуры может по смыслу быть разное количество параметров, то создайте несколько процедур. А внутри эти процедуры могут вызывать друг друга или вызывать некую общую, скрытую внутри модуля. Если процедура - это некое действие, то иное количество параметров означает немного иное действие.
Простота описания ЯП, простота компилятора, возможность контроля - всё это перевешивает "экономию на именах процедур". Стоит ли нам отходить от этого принципа? Пусть процедура с мультипараметром имеет достаточно ясную и строгую семантику. Но это расширение ЯП Оберон (пусть для системных нужд, но чего лукавить, расширяя Ofront, мы фактически расширяем ЯП, который транслируется Ofront-ом). А внесение фичей в сам язык (тем более новых, не опробованных в родственных компиляторах) - это крайнее средство, к которому нужно прибегать, если иное не сработало и если это расширение сулит значительную выгоду.
Для чего же мы это затеяли, какую значительную выгоду купим введением несовместимого, эзотерического диалекта ? "Так ещё чище асм-код будет смотреться"

Так не только не обижаюсь, Олежка, но и согласен!
Эти мультипараметры - не более чем "синтаксический сахар", причем "слащавый". Впрочем, Asm.Code4 - тоже сахар. Но здесь хотя бы не нужно расширять ЯП и реализовать можно за 5 минут и накладных расходов практически никаких. А мультипараметры когда еще напишем, когда еще отладим. Но тем не менее, по мне так и
достаточно наглядно. Повтор имен процедуры слева и ); справа сливаются в некий узор, который может и не будет отвлекать внимание, если привыкнуть (как багет не мешает изучению картины, а занавес просмотру спектакля). Тем более, если редактор выделяет текстовые константы особой раскраской.
Трудно писать каждый раз "Asm.Code("? Так есть буфер обмена, есть контекстная замена, есть автоматический ввод ключевых слов. Можно подумать над каким-то специальным средством IDE, для сокрытия повторяющихся имен процедуры (или замены их на ---"---). Внешний вид кода - это дело редактора IDE, а не синтаксиса и семантики ЯП (в данном случае). Если мы пишем на ассемблере, то главное - это операторы ассемблера, а Asm.Code( - это техническое обрамление.

ИТАК. Процедуры с мультипараметром - фича малополезная, а учитывая сложность реализации и несовместимость ЯП, так и вовсе вредная. Полезность может быть только в том, что дан повод 1)для полезной дискуссии про "Oberon-way" 2)для изучения Ofront.
Если кто-то реализует процедуры с мультипараметром и продемонстрирует великую полезность для чего-то еще, тогда может и будет повод к этому вернуться.
Хотя не представляю пока эту "великую полезность". Задание константного массива или иной структуры, например, где в каждой строке не одна текстовая константа а разное количество параметров, поэтому как-то тут мультипараметры сильно лучше? Вряд ли...
Вообщем, моё мнение - мультипараметрами заниматься не нужно. Прошу прощения за провокацию

Прочитал с внутренним согласием.
Да, гораздо полезнее будет развивать другие направления.