Is the type guard "merely ... convenience"?

[trijezdci]

I am trying to figure out whether Oberon allows addressing of a field in a record that is not present in said record's type declaration, but only in one of its extensions and do so without a type guard.

In PIO page 62, last sentence of the first paragaph, Wirth writes:

(1) "The further facility of the type guard is merely one of convenience."

In PIO page 59, first three sentences of the last paragraph before scetion 23.2 he writes:

(2) "The simple designator p.radius would not be acceptable, because p is of type Figure, which does not feature a field radius. With the type guard, the programmer can ascertain that in this case p is also of type Circle, in which case the field radius is indeed applicable. Whereas p is of base type Figure, p(Circle) is of type Circle."

On the one hand I interpret #2 such that the type guard is ***absolutely necessary*** in order to be able to address a field that is not in the designator's type declaration. Were it not for the type guard, addressing such a field should cause a compile time error.

On the other hand, if the type guard is merely a convenience as suggested by #1, then it could also be omitted. Its facility would simply be that of an assert and consequently the compiler could allow the addressing of a field that is not in the designator's type declaration.

Since the latter is not type safe I would be surprised if Wirth intended it that way.

I am therefore inclined to completely disregard #1.

How do Oberon implementors interpret this?

thanks in advance

[August Karlstrom]

Post by trijezdci
I am trying to figure out whether Oberon allows addressing of a field
in a record that is not present in said record's type declaration,
but only in one of its extensions and do so without a type guard.

As far as I understand, that is not possible (fortunately).

Post by trijezdci
(1) "The further facility of the type guard is merely one of
convenience."

Apart from using the WITH statement (or CASE statement in the latest
Oberon version) I see no other way of accessing a field in a variable of
an extended type declared as a proper base type. Like you, I don't
understand what he means here.

Post by trijezdci
I am therefore inclined to completely disregard #1.

Me too.


-- August

[trijezdci]

Post by August Karlstrom

Post by trijezdci
I am trying to figure out whether Oberon allows addressing of a field
in a record that is not present in said record's type declaration,
but only in one of its extensions and do so without a type guard.

As far as I understand, that is not possible (fortunately).

:-)

Post by August Karlstrom

Post by trijezdci
(1) "The further facility of the type guard is merely one of
convenience."

Apart from using the WITH statement (or CASE statement in the latest
Oberon version) I see no other way of accessing a field in a variable of
an extended type declared as a proper base type. Like you, I don't
understand what he means here.

Thanks for confirming.

It is not that I would want to be able to access such a field without a type guard, I don't. His statement of mere convenience simply threw me off. If Oberon allowed this, I wouldn't want to implement it that way -- We chose to replace variant records in our Modula-2 revision with Oberon extensible records.

Post by August Karlstrom

Post by trijezdci
I am therefore inclined to completely disregard #1.

Me too.

Am I right in the assumption that you have tried different Oberon implementations and all of those will require a type guard or else cause a compile time error for accessing what would have to be an undeclared field?

thanks again.

[trijezdci]

Actually, I found a way to dispense with type guard syntax altogether.

We can extend the CASE statement:

CASE msg OF TYPE
| DrawMsg : msg.draw(self)
| MoveMsg : msg.move(self, msg.dx, msg.dy)
| ...

At each label, the type has been established. It is no longer merely a claim by the programmer, but the compiler itself has determined it. As a result within the scope of each label, the tested parameter (here msg) can safely assume the type given in the label already at compile time. We can dispense with type guard syntax then.

[August Karlstrom]

Post by trijezdci
Actually, I found a way to dispense with type guard syntax
altogether.
CASE msg OF TYPE
| DrawMsg : msg.draw(self)
| MoveMsg : msg.move(self, msg.dx, msg.dy)
| ...

As I mentioned, the latest version of Oberon already has this kind of
CASE statement (without the TYPE keyword though). However, if you handle
only one subtype T0 extended from T, then it is more natural to use a
type guard.

Given the declarations

T0 = POINTER TO RECORD (T)
f: INTEGER
END

v: T

I prefer

v(T0).f := 0

to

ASSERT(v IS T0);
CASE v OF
T0: v.f := 0
END


-- August

[y***@z505.com]

Post by trijezdci

Post by August Karlstrom
Like you, I don't
understand what he means here.

Maybe if Wirth actually communicated, like a human being, he could discuss it. Then humans wouldn't have to make false assumptions, assertions, guesses, and other non scientific ways of thought. I.e. crapshooting, he said she said, guestimating, pretending to think you know psychically what Wirth meant (being a psychic, or astrologer... not a scientist or rational human)

Post by trijezdci

Post by August Karlstrom

Post by trijezdci
I am therefore inclined to completely disregard #1.

Me too.

Am I right in the assumption

There's that evil word again. Assumption. Why doesn't Wirth address this, from the horses mouth, right here, right now. Because he's out of site, out of mind.. never actually speaks to anyone except at rare conferences with Dijkstra where they eat wine and cheese, although I don't think he likes cheese. I guess they were always against mailing lists and groups because the response is too quick, whereas the old Dijkstra blog via postal snail mail worked great for them.... One could say "get with the times, lose your old ways, buy a computer Dijkstra and start using it" or at least send us some snail mail with pen and paper. Here's my snail mail address: Nah, just email me. Young grasshoppers, using teh internets... such naive kids these days.