🚀 go-pugleaf

My reference is 'Programming in Oberon.'
I don't have a copy of the report handy.
When I _did_ I don't recall any differences, but of course, your
memory may vary (probably in sync with facts).

----Quoting Michael Griebling----
> Is the following statement legal?
> VAR s: SHORTINT; i: INTEGER;
> INC (i, s)
I'd say yes. A.10.2 Table A.3 only specifies "integer type"

> VAR s: SomePtr;
> INC (SYSTEM.VAL(LONGINT, s), 4);
Offhand, I'd say no. A.12 Table A4, where this function is listed, is
titled "Function Procedures."  Thus, it's a function and can't
be an LVAL.  OTOH, I gather it's purpose is to let you treat arbetrary
sections of memory as any type you please (or need to), so I'd then
have to say, well, maybe.  From the syntax I'd always assumed that the T
in "VAL(T,x)" was a defined, rather than integral, type.

> Is type testing/guarding a NIL pointer legal?
I'd say no, but I can see the alternate argument.  To me, you've
typed the pointer, but there's no object if the pointer is NIL, and
the whole purpose of the type guard is to find check what the object
is NOW.  If it's NIL it can't be any type your checking against.
The question I see open is, should it refuse to compile, crash the
program, or simply fail the type guard check?  Given my druthers, I
think I'd prefer to see it do the third in real programs, but since
there are other ways to handle all this (ie: check for a NIL pointer)
I think I'd prefer to have the compiler tell me I've got a problem.

	- Bill

-- 
+----------------------------------------------------------------
| William J. Leary Jr.
| Paralyn Associates