Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!cornell!uw-beaver!rice!titan!preston
From: preston@titan.rice.edu (Preston Briggs)
Newsgroups: comp.lang.modula2
Subject: Re:  Overloading Operators: Extension to Language
Message-ID: <1922@brazos.Rice.edu>
Date: 4 Oct 89 20:19:29 GMT
Sender: root@rice.edu
Reply-To: preston@titan.rice.edu (Preston Briggs)
Organization: Rice University, Houston
Lines: 38

In article <46075cda.1199f@apollo.HP.COM> lsmith@apollo.HP.COM (Lawrence C. Smith) writes:

>Wirth has some very definite blind spots for language design that really puzzle
>me in a man so otherwise gifted.  You'd think that returning records would be
>simple, obvious, and orthogonal and so would be one of his top hot buttons.

>Does Oberon allow them?  Does it allow them but not implement them?
>
>Another of Wirth's blind spots is strings.  To get real efficiency with strings
>you've just gotta have help from the compiler, but Wirth never, ever believed in
>them.

>Larry Smith


Oberon doesn't allow structured types (records or arrays) to be returned
from functions.  There's slightly more suport for strings than
before.  Basically, he's using null-terminated arrays of char,
rather like C.

However, I think he's correct not to allow functions to return
structured values.  In fact, I think he should modify his
standard parameter passing mechanism to something like:

	PROCEDURE zap(VAR a, b, c: aType;
		      CON x, y, z: bType);

This would allow all structured types to be passed by reference,
rather than copying.  If you need to copy it later, fine; but
not as part of the call.  As a bonus, optimizers would be able to do
a better job around procedure calls, without the necessity of
interprocedural analysis.

Overall, I'm down on "hidden" costs arising
from copying large arrays and records.

Regards,
Preston Briggs