<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv=Content-Type content="text/html; charset=iso-8859-1">
<meta name=Generator content="Microsoft Word 12 (filtered medium)">
<style>
<!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
span.E-MailFormatvorlage17
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;}
@page Section1
{size:612.0pt 792.0pt;
margin:70.85pt 70.85pt 2.0cm 70.85pt;}
div.Section1
{page:Section1;}
-->
</style>
<!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang=DE-CH link=blue vlink=purple>
<div class=Section1>
<p class=MsoNormal><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>If you assign a procedure in a module scope to a procedure
variable, only the entry address of this procedure needs to be stored. If you
want to assign a method (procedure in object scope), this address is not
sufficient since the method may depend on the current state of an particular
object instance. Therefore, the reference to that object instance needs to be
stored in the procedure variable, too.<o:p></o:p></span></p>
<p class=MsoNormal><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>
<p class=MsoNormal><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>TYPE<o:p></o:p></span></p>
<p class=MsoNormal><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'> Procedure = PROCEDURE();<o:p></o:p></span></p>
<p class=MsoNormal><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'> DelegateProcedure = PROCEDURE {DELEGATE} (…);<o:p></o:p></span></p>
<p class=MsoNormal><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>
<p class=MsoNormal><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>VAR<o:p></o:p></span></p>
<p class=MsoNormal><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'> p : Procedure;<br>
dp : DelegateProcedure;<o:p></o:p></span></p>
<p class=MsoNormal><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>
<p class=MsoNormal><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>In the above example, you can assign procedures to p but not
methods, since p is a procedure variable that only stores the procedure entry
point. If a procedure variable has the type PROCEDURE {DELEGATE} …, you
can also assign methods to it. Behind the scenes, both the procedure entry
point and the reference to the object instance it is bound to are stored in dp.<o:p></o:p></span></p>
<p class=MsoNormal><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>
<p class=MsoNormal><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>Best,<o:p></o:p></span></p>
<p class=MsoNormal><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>Sven Stauber<o:p></o:p></span></p>
<p class=MsoNormal><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>
<p class=MsoNormal><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>
<div style='border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0cm 0cm 0cm'>
<p class=MsoNormal><b><span lang=DE style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'>Von:</span></b><span
lang=DE style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'>
oberon-bounces@lists.inf.ethz.ch [mailto:oberon-bounces@lists.inf.ethz.ch] <b>Im
Auftrag von </b>Søren Renner<br>
<b>Gesendet:</b> Freitag, 31. Oktober 2008 15:27<br>
<b>An:</b> oberon@lists.inf.ethz.ch<br>
<b>Betreff:</b> [Oberon] Re: Oberon Digest, Vol 61, Issue 16<o:p></o:p></span></p>
</div>
<p class=MsoNormal><o:p> </o:p></p>
<p class=MsoNormal style='margin-bottom:12.0pt'>What's this {DELEGATE} syntax?
What does that do? <o:p></o:p></p>
<div>
<p class=MsoNormal>On Fri, Oct 31, 2008 at 6:00 AM, <<a
href="mailto:oberon-request@lists.inf.ethz.ch">oberon-request@lists.inf.ethz.ch</a>>
wrote:<o:p></o:p></p>
<p class=MsoNormal>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>
<span style='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>
**************************************</span><o:p></o:p></p>
</div>
<p class=MsoNormal><o:p> </o:p></p>
</div>
</body>
</html>