🚀 go-pugleaf

bostjan@ wrote:
> ... 
>   For me the right solution to the above problem would be to
>   specify that the type guard p(PXList) may be used whenever
>   one knows that p is of type PXList OR p is equal to NIL.
>   In that case Version 2 would work (as well as Version 3).
>   The objection that p(PXList) guarantees the existence
>   of p(PXList).key, and therefore p should not be equal to NIL
>   when a typeguard is used is countered by remarking that the
>   actual existence of the component p(PXList).key may be
>   ascertained by a separate NIL check. That should not be too
>   onerous as NIL checking is an integral part of any pointer
>   processing algorithm
> ...

Your remarks are right on the point. I also feel that
the type guard (and type test, where - I think - the problem
is actually worse) is ill-defined (It is defined by the
compiler only. The language reports [Oberon, Oberon-2,
Oberon/L] do unfortunately not explicitely define this case.)
in Oberon(-2) in the case of NIL.

To quote the language report: v IS T stands for "the dynamic
type of v is T (or an extension of T)" and is called a type test.

Clearly, there are reasons for defining NIL IS T to be true and
for defining it to be false. Both in practice and in theory
I prefer it to be true. (A 3-valued logic might solve the
problem.)

One of the arguments against this is that - the way the ETH
compilers generate code - it would take an implicit NIL test
in the machine code. On the other hand, the current operational
definition does not allow for any optimizing compiler to do
any static analysis.

But exactly this static analysis is where the current
compilers screw. v IS T gets evaluated to true at compile
time if v is of static type T. Hence, v IS T is true at
run time, even if v is NIL, undefined or of a different
type (assigned with SYSTEM.VAL). (One could now argue that
v IS T is a programming error if v is of static type T,
but why then do the ETH compilers explicitely optimize this
case?) This interpretation clearly differs from the
language report in the case of v undefined or assigned
an alien type with SYSTEM.VAL.

In summary, I would vote for defining NIL IS T to be
true, but can also live with the opposite. What I do dislike
is the failure of the language report to define this case
clearly and the inconsistency of the "definition" given
by the compiler.


-- Martin
====================================================================
Abo Akademi University          | email: mbuechi@ra.abo.fi
Department of Computer Science  | phone: +358 (9)21 265-4072
Lemminkaisenkatu 14a            | fax:   +358 (9)21 265-4732
20520  Turku                    | www:   http://www.abo.fi/~mbuechi/
FINLAND                         | time:  UTC +0200
--------------------------------------------------------------------
Statistics show that birthdays are good for your health. People who
have more birthdays get older.
====================================================================