🚀 go-pugleaf

In article <1996Jan22.125737.5658@zermelo.comlab.ox.ac.uk>,
Mike Spivey <mike@comlab.ox.ac.uk> wrote:
>Oberon allows procedures to be passed as arguments of other
>procedures, and to be stored as components of records: in fact, this
>is the basis of Oberon's use in object-oriented programming.  But
>
>For example, we can define collections that support iterator methods,
>but these methods would be more useful if their arguments could be
>local procedures.  To give a trivial example:
>
>	PROCEDURE sum(xs: intset);
>	  VAR s: integer;
>
>	  PROCEDURE add(x: integer);
>	  BEGIN s := s + x END add;
>
>	BEGIN
>	  s := 0;
>	  xs.do(add);
>	  RETURN s
>	END sum;
>
>Is there any good reason why Oberon doesn't allow this?  I don't seem
>to have any serious difficulty in implementing it!

Yes, there is. When add is passed to xs.do, it's whole context must be passed
to, i.e. variable s which is used within add. If xs.do happened to assign the
passed procedure variable (here: add) to a global variable and then later on
called the associated procedure, the context would be gone (sum is left) and
you would get quite interesting results accessing s...
That's why this was forbidden.
In fact, this was not always the case. There used to be Object Oberon which
allowed you to pass local procedures as procedure parameters, but (I think)
the implementation/definition was everything else than straightforward.

Stephan
>
>-- Mike Spivey


------------------------------------------------------------------------------
Stephan Gehring                            Email:  gehring@inf.ethz.ch
Institute for Computer Systems             Phone:  +41 1 632 73 15
ETH-Zentrum                                FAX:    +41 1 632 13 07
CH-8092 Zurich, Switzerland