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