OberonCore

Коллеги, процедура SYSTEM.TYP определена вот так:



Я понимаю это так, что аргументом должно быть значение записного типа.

Однако процедура работает и с именами типов, вот так:
TYPE Type = POINTER TO RECORD ... END;
x := SYSTEM.TYP(Type)

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


Что скажете?

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

Только там тогда не name, а type qualident лучше написать.

Но стаким описанием можно ожидать, что будет работать и SYSTEM.TYP(REAL)

record type qualident
(как там для массивов, вопрос? А то non-basic type...)

Просто массив ошибка, а вот указатель на массив валит компилятор.

Нельзя, потому что уточнено в 4 столбике:

TYP(T) type name INTEGER type tag of record type T

Если написать квалидент - это подразумевает обязательно указание имени модуля, не?

Не, там в грамматике у квалидента [xxxx.]yyyy

Вы ведь хотите прояснить, а получается наоборот.
Второй столбик описывает аргументы, а четвертый - результат. Остается неясным, какой будет результат функции, если T - не record type.
Далее, чем "type name" отличается от аналогичных параметров MIN, MAX, SIZE, ADR, где используется просто "type"?
Наконец, неплохо бы прояснить, что такое "type tag" и чем оно отличается от "address of Descriptor of T", возвращаемого ADR.

И еще. Может, это вовсе не преднамеренное поведение? И надо не описывать, а править компилятор.

Пожалуй, вы меня убедили: раз есть разделение информации по столбикам, надо во 2м указать исчерпывающе и однозначно.


Строго говоря, если использовать просто type, то должно работать SYSTEM.TYP(POINTER TO RECORD END). Поэтому я и предложил type name. Но PSI не отличается вообще такой строгостью; пожалуй, можно как в MIN написать: T = [pointer to] record type


Отличное замечание! Действительно, Type tag = address of Descriptor of T. Но в PSI это явно не оговаривается, и в описаниях процедур используются эти два отличных термина. Возможно, стоит либо, всамделе, явно прояснить, либо избавиться от одного - наверное, от тэга.

Кроме того, получается, что есть двойственность: SYSTEM.ADR(T) = SYSTEM.TYP(T). Кажется, есть что выкинуть из компилятора. Я не обращал внимания, что есть такая форма ADR.


Зачем такое дублирование процедур - непонятно. Но вариант SYSTEM.TYP(T) используется в Kernel наряду с SYSTEM.ADR(T) и SYSTEM.TYP(rec).
Так что, может, стоит поправить и компилятор, и PSI.

Кроме того, в PSI написано, что SYSTEM.ADR принимает аргумент T: a record type, однако фактически он принимает и A: an array type, и P: a procedural type. То есть SYSTEM.ADR возвращает адрес дескриптора для всех дескриптируемых типов: структурных, указательных и процедурных.

При этом SYSTEM.TYP принимает только записные и указатели на записные, и не дифференцирует их:
TYPE Rec = RECORD END; PRec = POINTER TO Rec;
SYSTEM.TYP(Rec) = SYSTEM.TYP(PRec)

Получается, единственный случай, когда результаты SYSTEM.TYP и .ADR отличаются - это если T - указатель на безымянный тип:
TYPE T = POINTER TO RECORD END;
SYSTEM.ADR(T) # SYSTEM.TYP(T)

Но это имеет, как кажется, такую ничтожную практическую значимость, что SYSTEM.TYP на мой взгляд - кандидат на исключение вообще.

Получается, что SYSTEM.TYP всегда даёт именно дескриптор записевого типа, при обращении к указательному разыменовывая его до .base[0].

Если для TYPE T = POINTER TO ARRAY OF RECORD ... END работает взятие SYSTEM.ADR(T^) и оно эквивалентно SYSTEM.TYP, то последний и правда избыточен. А иначе - важен (потому что тогда статически не получить тип именно записи для таких случаев, а на практике нужен именно он постоянно).

А дескриптируемый тип - это тип, для которого SYSTEM.ADR что-то возвращает.
Я вообще не представляю, как можно использовать SYSTEM.ADR(T), кроме того случая, когда оно совпадает с SYSTEM.TYP(T).

К дескриптируемым типам в ББ относятся записи, массивы, указатели на записи, указатели на массивы, и процедурные типы; я их все перечислил выше.
Поправлю: .base[.level]

Обе процедуры работают с именами типов => анонимный тип невозможно им передать. Запись T^ формально некорректна (разыменование неприменимо к именам типов), хотя мы, человеки, легко догадываемся, что имеется в виду. Для записи в приведенном вами примере не подойдет ни .ADR, ни .TYP.

А вот такой текст приводит к аварии в компиляторе - как раз там, где ожидается имя базового типа, а, поскольку тип безымянный, приходится разыменовывать NIL.
TYPE T = POINTER TO ARRAY OF RECORD END;
tag := SYSTEM.TYP(T);

В случае TYPE T = POINTER TO RECORD END компилятор принудительно назначает безымянному типу RECORD END имя, если не ошибаюсь T^, поэтому там, где имя базового типа ожидается, оно находится, и аварии не происходит.

Если я вас правильно понял, именно для случая указателя на безымянную запись, вы полагаете, стоит иметь SYSTEM.TYP?

Я смысла этого понятия не улавливаю. У записей есть дескрипторы, они передаются в качестве параметров. А что такое дескриптор указателя, массива или процедуры?

Скорее всего имеется в виду некая область памяти (указатель или ссылка на оную) с описанием дополнительных свойств и ограничений данных объектов. Некоторым образом, это - часть инфраструктуры функционирования некоего rtti, который не только часть ран-тайма, но и часть набора артефактов времени компиляции.(как у Михаэля Франца).
Прошу учесть, что я не говорю сейчас о конкретике частностей реализации в конкретном языке.
В любом случае есть типовые и неизбежные подходы, решения и средства которые мы вынуждены или обязаны организовывать и применять в реализации языка и его рантайма, чтобы организовывать контексты выполнения и иметь возможность получать доступ к свойствам объектов программы.
Меня просто беспокоит возможность риска ухода в глубину обсуждения частностей и нюансов конкретики именно определённой реализации и ПОСТУЛИРОВАНИЯ именно конкретных решений, без понимания возможности рассмотрения изменения этих решения, с учётом опыта эксплуатации и смены видения на эффективность, логичность, расширяемость и удобство использования таких средств и инфраструктуры.
Фухххх....

Ну так в ББ Kernel.Type есть и для массива, и для процедуры.
Для динамического массива он также лежит по -4 от базового адреса объекта в куче.