[Oberon] Re: Oberon Digest, Vol 61, Issue 16

Søren Renner soren.renner at gmail.com
Fri Oct 31 15:27:04 MET 2008


What's this {DELEGATE} syntax? What does that do?

On Fri, Oct 31, 2008 at 6:00 AM, <oberon-request at lists.inf.ethz.ch> wrote:

> Send Oberon mailing list submissions to
>        oberon at lists.inf.ethz.ch
>
> To subscribe or unsubscribe via the World Wide Web, visit
>        https://lists.inf.ethz.ch/mailman/listinfo/oberon
> or, via email, send a message with subject or body 'help' to
>        oberon-request at lists.inf.ethz.ch
>
> You can reach the person managing the list at
>        oberon-owner at lists.inf.ethz.ch
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Oberon digest..."
>
>
> Today's Topics:
>
>   1. Re: Oberon and closures (Aubrey.McIntosh at Alumni.UTexas.Net)
>   2. Re: Oberon and closures (Alexander Iljin)
>   3. Re: Oberon and closures (B. Smith-Mannschott)
>   4. Re: Oberon and closures (B. Smith-Mannschott)
>   5. Re: Oberon and closures (Thomas Frey)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Thu, 30 Oct 2008 10:02:50 -0500
> From: Aubrey.McIntosh at Alumni.UTexas.Net
> Subject: Re: [Oberon] Oberon and closures
> To: "ETH Oberon and related systems" <oberon at lists.inf.ethz.ch>
> Message-ID:
>        <6d278c720810300802ia8c47e0s2e2576523d1ff990 at mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1
>
> I thing I read that procedure variables are being depreciated because
> the literature finds some problem with them.  I forget what the
> problem is.  Also, I haven't any clue what a "closure" is other than
> this discussion, so I would appreciate any pointer to info that may be
> more focused than my own Google search.
>
> Anyway, I tried to modify the example a bit more so that it used type
> bound procedures, not procedure variables.  Here is the version for
> Component Pascal.
>
>
> MODULE PrivClosureExample;
> (* my oberon is also a little rusty *)
>
> TYPE
>  Printer = POINTER TO Closure;
>
>  Closure = RECORD
>   n-: INTEGER;
>  END;
>
> VAR p, q: Printer;
>
> PROCEDURE (this:Printer) Print, NEW;
> END Print;
>
> PROCEDURE CreatePrinter*(i: INTEGER): Printer;
>  VAR s: Printer;
>  BEGIN
>   NEW(s); s.n :=i; RETURN s
>  END CreatePrinter;
>
> BEGIN
>  p:=CreatePrinter(2);
>  q:=CreatePrinter(3);
>  p.Print;
>  q.Print
> END PrivClosureExample.
>
>
> On Thu, Oct 30, 2008 at 3:25 AM, Jörg Straube <joerg.straube at iaeth.ch>
> wrote:
> >
> >>> From Wikipedia we find
> >>> As a consequence, closures can be used to hide state,
> >>> and thus to implement object-oriented programming
> >
> > As Oberon is object-oriented, we don't need the concept
> > of "closures" to implement OOP.
> >
> > Joerg
> >
> >
> > --
> > Oberon at lists.inf.ethz.ch mailing list for ETH Oberon and related systems
> > https://lists.inf.ethz.ch/mailman/listinfo/oberon
> >
>
>
>
> --
> --
> Aubrey McIntosh, Ph.D.
> 1502 Devon Circle
> Austin TX 78723-1814
> http://home.grandecom.net/~amcintosh/aubrey/Search/<http://home.grandecom.net/%7Eamcintosh/aubrey/Search/>
>
>
> ------------------------------
>
> Message: 2
> Date: Thu, 30 Oct 2008 21:11:05 +0600
> From: "Alexander Iljin" <ajsoft.gm at gmail.com>
> Subject: Re: [Oberon] Oberon and closures
> To: "ETH Oberon and related systems" <oberon at lists.inf.ethz.ch>
> Message-ID:
>        <950bc9920810300811g1f930c2frc7227bd64c1bf01c at mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1
>
> Hello!
>
> On 10/30/08, Aubrey.McIntosh at alumni.utexas.net
> <Aubrey.McIntosh at alumni.utexas.net> wrote:
> > I would appreciate any pointer to info that may be
> > more focused than my own Google search.
>
> http://en.wikipedia.org/wiki/Closure_(computer_science)<http://en.wikipedia.org/wiki/Closure_%28computer_science%29>
>
>
> ------------------------------
>
> Message: 3
> Date: Thu, 30 Oct 2008 17:54:24 +0100
> From: "B. Smith-Mannschott" <benpsm at gmail.com>
> Subject: Re: [Oberon] Oberon and closures
> To: ETH Oberon and related systems <oberon at lists.inf.ethz.ch>
> Message-ID: <9014DD6E-0B81-4246-9021-D52AF8A7291E at gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes
>
>
> On Oct 30, 2008, at 09:11, Jörg Straube wrote:
>
> >
> > What about this?
> >
> > MODULE Example;
> > (* my oberon is also a little rusty *)
> > TYPE
> >  Printer = POINTER TO Closure;
> >  Closure = RECORD
> >    n-: INTEGER;
> >    Print: PROCEDURE();
> >  END;
> > PROCEDURE CreatePrinter*(i: INTEGER): Printer;
> >  VAR s: Printer;
> >  BEGIN
> >    NEW(s); s.n :=i; RETURN Printer
> >  END
> >
> > VAR p, q: Printer;
> > BEGIN
> >  p:=CreatePrinter(2);
> >  q:=CreatePrinter(3);
> >  p.Print
> >  q.Print
> > END Example.
> >
> >
> > Joerg
>
> Indeed, there is an equivalence between objects (state with behavior)
> and
> closures (behavior with state).
>
> Anton van Straaten observed a few years ago (more humorously than I
> could manage):
>
> <http://people.csail.mit.edu/gregs/ll1-discuss-archive-html/msg03277.html
>  >
>   The venerable master Qc Na was walking with his student, Anton.
> Hoping to
> prompt the master into a discussion, Anton said "Master, I have heard
> that
> objects are a very good thing - is this true?"  Qc Na looked pityingly
> at
> his student and replied, "Foolish pupil - objects are merely a poor
> man's
> closures."
> Chastised, Anton took his leave from his master and returned to his
> cell,
> intent on studying closures.  He carefully read the entire "Lambda: The
> Ultimate..." series of papers and its cousins, and implemented a small
> Scheme interpreter with a closure-based object system.  He learned
> much, and
> looked forward to informing his master of his progress.
>
>   On his next walk with Qc Na, Anton attempted to impress his master by
> saying "Master, I have diligently studied the matter, and now understand
> that objects are truly a poor man's closures."  Qc Na responded by
> hitting
> Anton with his stick, saying "When will you learn? Closures are a poor
> man's
> object."  At that moment, Anton became enlightened.
> // Ben
>
> ------------------------------
>
> Message: 4
> Date: Thu, 30 Oct 2008 18:00:28 +0100
> From: "B. Smith-Mannschott" <benpsm at gmail.com>
> Subject: Re: [Oberon] Oberon and closures
> To: ETH Oberon and related systems <oberon at lists.inf.ethz.ch>
> Message-ID: <7E838A5B-F59A-4033-A414-E59C97CC60C7 at gmail.com>
> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
>
>
> On Oct 30, 2008, at 09:16, Bob Walkden wrote:
>
> >>> So, yes, you can create a closure in Oberon.
> >>
> >> Well, no, not really.  The Module being a single giant closure over
> >> all the procedures defined in it is *not* what is generally meant by
> >> "closure".  In particular, languages which support closures generally
> >> allow something like this:
> >>
> >> MODULE Example;
> >> (* my oberon's a little rusty *)
> >> TYPE
> >>   Printer = PROCEDURE();
> >> VAR
> >>   p, q: Printer;
> >>
> >> PROCEDURE CreateNumberPrinter(n: INTEGER): Printer;
> >>     PROCEDURE PrintingProcedure;
> >>     BEGIN Out.WriteInt(n)
> >>     END PrintingProcedure;
> >> BEGIN
> >>     RETURN PrintingProcedure
> >> END CreateNumberPrinter;
> >>
> >> BEGIN
> >>   p := CreateNumberPrinter(1);
> >>   q := CreateNumberPrinter(2);
> >>   p; (* prints 1 *)
> >>   q; (* prints 2 *)
> >> END Example;
> >>
> >> Note that each invocation of CreateNumberPrinter creates a new
> >> closure
> >> over the nested procedure PrintingProcedure. In fact the fact that
> >> Pascal/Modula/Oberon only allows top-level procedures as procedure
> >> values appears to be a direct result of the fact that the language
> >> doesn't support proper closures. (In order to support closures as
> >> above you need something more involved than a simple stack as an
> >> instance of PrintingProcedure needs to find its "n", even after the
> >> CreateNumberPrinter that created it is no longer active on the
> >> stack).
> >>
> >
> > "the language doesn't support proper closures"
> >
> > What are the benefits of supporting this? It doesn't feel to me as
> > though it is
> > in 'the spirit of Oberon'. It feels like the kind of accident
> > waiting to happen
> > that Prof. Wirth preferred to avoid.
>
> Yes supporting full closures would have complicated the compiler and/or
> the runtime system considerably and wouldn't have been in Wirth's style.
> By choosing not to indulge in this feature he was able to keep his
> languages
> and compilers far smaller and simpler than they otherwise would have
> been.
>
> There's no law that says that every language must support closures (or
> tail call eliminiation, or mult-methods, continuations, or ...)  and I
> for
> one am glad that Wirth chose to keep Oberon simple.
>
> // Ben
>
>
> ------------------------------
>
> Message: 5
> Date: Thu, 30 Oct 2008 20:58:26 +0100
> From: Thomas Frey <thomas.frey at alumni.ethz.ch>
> Subject: Re: [Oberon] Oberon and closures
> To: ETH Oberon and related systems <oberon at lists.inf.ethz.ch>
> Message-ID: <490A11E2.1070508 at alumni.ethz.ch>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> In Active Oberon we have an additional way of simulating (strongly
> typed) closures.
>
> Concept:
> the reachable state of the closure function is stored in the fields of a
> local OBJECT type (POINTER TO RECORD) (Note : Bound variables in
> functional languages are "read only", here we rely on the programmer)
> The closure itself is then a delegate procedure variable bound to a
> method of an instance of the local OBJECT (class). The delegate
> encapsulates the code and the state (as a closure)
>
> The advantage of this way of doing a "closure" is that the computational
> effort is visible to the programmer and not hidden behind the scene as
> in other languages. (Note : Using objects and delegates normally allows
> for more natural solutions than the following example which tries to
> mimic closures as closely as possible)
>
> MODULE Closure; (** AUTHOR "tf"; PURPOSE "closure simulation"; *)
>
> IMPORT
>   Out := KernelLog;
>
> TYPE
>   Printer = PROCEDURE {DELEGATE} ();
>
> (* creates a closure *)
> PROCEDURE CreatePrinter(nr : LONGINT): Printer;
> TYPE
>   (* container for the accessed scope *)
>   PrinterClosure = OBJECT
>   VAR nr : LONGINT; (* state *)
>
>     (* functionality, able to access the "copied scope"*)
>     PROCEDURE Print;
>     BEGIN
>       Out.Int(nr, 0); Out.Ln;
>     END Print;
>   END PrinterClosure;
>
> VAR
>    closure : PrinterClosure;
> BEGIN
>   (* create the container for the bound variables *)
>   NEW(closure);
>   (* "bind" the variables *)
>   closure.nr := nr;
>   (* return the closure *)
>   RETURN closure.Print;
> END CreatePrinter;
>
>
> PROCEDURE Test*;
> VAR print : Printer;
> BEGIN
>   print := CreatePrinter(5);
>   (* use the closure *)
>   print();
> END Test;
>
> END Closure.
>
> Closure.Test
>
> --Thomas
>
> B. Smith-Mannschott schrieb:
> >
> > On Oct 30, 2008, at 09:16, Bob Walkden wrote:
> >
> >>>> So, yes, you can create a closure in Oberon.
> >>>
> >>> Well, no, not really.  The Module being a single giant closure over
> >>> all the procedures defined in it is *not* what is generally meant by
> >>> "closure".  In particular, languages which support closures generally
> >>> allow something like this:
> >>>
> >>> MODULE Example;
> >>> (* my oberon's a little rusty *)
> >>> TYPE
> >>>   Printer = PROCEDURE();
> >>> VAR
> >>>   p, q: Printer;
> >>>
> >>> PROCEDURE CreateNumberPrinter(n: INTEGER): Printer;
> >>>     PROCEDURE PrintingProcedure;
> >>>     BEGIN Out.WriteInt(n)
> >>>     END PrintingProcedure;
> >>> BEGIN
> >>>     RETURN PrintingProcedure
> >>> END CreateNumberPrinter;
> >>>
> >>> BEGIN
> >>>   p := CreateNumberPrinter(1);
> >>>   q := CreateNumberPrinter(2);
> >>>   p; (* prints 1 *)
> >>>   q; (* prints 2 *)
> >>> END Example;
> >>>
> >>> Note that each invocation of CreateNumberPrinter creates a new closure
> >>> over the nested procedure PrintingProcedure. In fact the fact that
> >>> Pascal/Modula/Oberon only allows top-level procedures as procedure
> >>> values appears to be a direct result of the fact that the language
> >>> doesn't support proper closures. (In order to support closures as
> >>> above you need something more involved than a simple stack as an
> >>> instance of PrintingProcedure needs to find its "n", even after the
> >>> CreateNumberPrinter that created it is no longer active on the stack).
> >>>
> >>
> >> "the language doesn't support proper closures"
> >>
> >> What are the benefits of supporting this? It doesn't feel to me as
> >> though it is
> >> in 'the spirit of Oberon'. It feels like the kind of accident waiting
> >> to happen
> >> that Prof. Wirth preferred to avoid.
> >
> > Yes supporting full closures would have complicated the compiler and/or
> > the runtime system considerably and wouldn't have been in Wirth's style.
> > By choosing not to indulge in this feature he was able to keep his
> > languages
> > and compilers far smaller and simpler than they otherwise would have
> been.
> >
> > There's no law that says that every language must support closures (or
> > tail call eliminiation, or mult-methods, continuations, or ...)  and I
> for
> > one am glad that Wirth chose to keep Oberon simple.
> >
> > // Ben
> > --
> > Oberon at lists.inf.ethz.ch mailing list for ETH Oberon and related systems
> > https://lists.inf.ethz.ch/mailman/listinfo/oberon
> >
>
>
> ------------------------------
>
> --
> Oberon at lists.inf.ethz.ch mailing list for ETH Oberon and related systems
> https://lists.inf.ethz.ch/mailman/listinfo/oberon
>
>
> End of Oberon Digest, Vol 61, Issue 16
> **************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.inf.ethz.ch/pipermail/oberon/attachments/20081031/0fdc97d2/attachment.html


More information about the Oberon mailing list