<div dir="ltr">I don't know what the exhortation to "bottom-post if you can" is asking me to do!</div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Sep 28, 2017 at 2:27 PM, <span dir="ltr"><<a href="mailto:oberon-request@lists.inf.ethz.ch" target="_blank">oberon-request@lists.inf.ethz.ch</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;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" rel="noreferrer" target="_blank">https://lists.inf.ethz.ch/<wbr>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.<wbr>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. Procedure variables and local procedures (August Karlstrom)<br>
2. Re: Oberon Digest, Vol 160, Issue 21 (S?ren Renner)<br>
3. Raytracing research (Skulski, Wojciech)<br>
4. Re: Oberon Digest, Vol 160, Issue 21 (Liam Proven)<br>
5. A2 on ARM Linux Platform (Skulski, Wojciech)<br>
6. Re: Oberon Digest, Vol 160, Issue 21 (Peter Matthias)<br>
7. Procedure variables and local procedures (Andreas Pirklbauer)<br>
8. Procedure variables and local procedures (Andreas Pirklbauer)<br>
9. Re: Procedure variables and local procedures (Skulski, Wojciech)<br>
10. Re: Procedure variables and local procedures (Skulski, Wojciech)<br>
11. Procedure variables and local procedures (Andreas Pirklbauer)<br>
<br>
<br>
------------------------------<wbr>------------------------------<wbr>----------<br>
<br>
Message: 1<br>
Date: Thu, 28 Sep 2017 12:14:29 +0200<br>
From: August Karlstrom <<a href="mailto:fusionfile@gmail.com">fusionfile@gmail.com</a>><br>
To: ETH Oberon and related systems <<a href="mailto:oberon@lists.inf.ethz.ch">oberon@lists.inf.ethz.ch</a>><br>
Subject: [Oberon] Procedure variables and local procedures<br>
Message-ID: <<a href="mailto:4b1fd5a6-3768-0117-5e80-c9597a5975b6@gmail.com">4b1fd5a6-3768-0117-5e80-<wbr>c9597a5975b6@gmail.com</a>><br>
Content-Type: text/plain; charset=utf-8; format=flowed<br>
<br>
In the latest revision of the Oberon language, access to identifiers in<br>
intermediate scopes is denied. Doesn't this imply that the restriction<br>
that only globally defined procedures can be assigned to procedure<br>
variables, is the unnecessary?<br>
<br>
-- August<br>
<br>
<br>
------------------------------<br>
<br>
Message: 2<br>
Date: Thu, 28 Sep 2017 08:47:09 -0400<br>
From: S?ren Renner <<a href="mailto:soren.renner@gmail.com">soren.renner@gmail.com</a>><br>
To: <a href="mailto:oberon@lists.inf.ethz.ch">oberon@lists.inf.ethz.ch</a><br>
Subject: Re: [Oberon] Oberon Digest, Vol 160, Issue 21<br>
Message-ID:<br>
<<a href="mailto:CAJuGca_ooAL8BHLn6EiZ7S8PkC-yRAfnp7swNNRHMGP3jYEbOw@mail.gmail.com">CAJuGca_ooAL8BHLn6EiZ7S8PkC-<wbr>yRAfnp7swNNRHMGP3jYEbOw@mail.<wbr>gmail.com</a>><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
Also, AOS and Oberon will become much more widely noticed as soon as my<br>
raytracing research receives the attention and praise that it deserves.<br>
<br>
On Thu, Sep 28, 2017 at 6:00 AM, <<a href="mailto:oberon-request@lists.inf.ethz.ch">oberon-request@lists.inf.<wbr>ethz.ch</a>> wrote:<br>
<br>
> 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" rel="noreferrer" target="_blank">https://lists.inf.ethz.ch/<wbr>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.<wbr>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: General - Academic vs Commercial applications<br>
> (Felix Friedrich)<br>
> 2. Re: General - Xerox PARC 1970 (Tomas Kral)<br>
> 3. Re (2): General - Academic vs Commercial applications<br>
> (<a href="mailto:peter@easthope.ca">peter@easthope.ca</a>)<br>
> 4. NativeOberon's FileName limitations - HOW2 extend? (eas lab)<br>
> 5. Re: General - Academic vs Commercial applications (eas lab)<br>
><br>
><br>
> ------------------------------<wbr>------------------------------<wbr>----------<br>
><br>
> Message: 1<br>
> Date: Wed, 27 Sep 2017 12:17:23 +0200<br>
> From: Felix Friedrich <<a href="mailto:felix.friedrich@inf.ethz.ch">felix.friedrich@inf.ethz.ch</a>><br>
> To: ETH Oberon and related systems <<a href="mailto:oberon@lists.inf.ethz.ch">oberon@lists.inf.ethz.ch</a>><br>
> Subject: Re: [Oberon] General - Academic vs Commercial applications<br>
> Message-ID: <<a href="mailto:d04806c6-955e-fa5d-d726-09ba6622c2c5@inf.ethz.ch">d04806c6-955e-fa5d-d726-<wbr>09ba6622c2c5@inf.ethz.ch</a>><br>
> Content-Type: text/plain; charset="utf-8"; format=flowed<br>
><br>
> In fact Oberon is still taught at ETH Zurich.<br>
><br>
> We are giving a course on System Construction and discuss some Oberon<br>
> language dialects, Oberon inspired operating or runtime systems and<br>
> programmable hardware supporting or based on Oberon related languages<br>
> and systems. In more detail we teach<br>
><br>
> (a) The Minos Runtime System (based on HeliOS, system control for<br>
> unmanned helicopters), programmed in a dialect of Oberon07 [FF]<br>
> (b) The A2 runtime system and GUI together with Active Oberon [FF]<br>
> (c) Oberon running on FPGAs: the RISC processor [Paul Reed]<br>
> (d) Systems on a Chip, FPGA and Hybrid Systems, programmed using Active<br>
> Cells, another dialect of Oberon [FF]<br>
><br>
> cf. <a href="http://lec.inf.ethz.ch/syscon/2017/" rel="noreferrer" target="_blank">http://lec.inf.ethz.ch/syscon/<wbr>2017/</a><br>
><br>
> Without exaggeration and with a little bit of pride I can say that<br>
> students like this course a lot -- because we really show how these<br>
> systems work behind the scenes over all levels. We (Paul and I) can say<br>
> that we understand every single bit of it and bring this accross as a<br>
> strong argument for simplicity.<br>
><br>
> Apart from that I am the "last man standing" for Oberon at ETH. I have a<br>
> lecturer position at ETH and am giving large computer science service<br>
> courses at ETH (hundred of students, C++, Java or whatever is<br>
> requested), which limits my time for working with and for Oberon. I love<br>
> to play around with the language, compiler and runtime systems and<br>
> optimize them according to what I, personally, find the most optimal way<br>
> to present or use the langauge. Because much is driven by personal<br>
> taste, I hesitate to sell my own ideas as "the truth", while I have some<br>
> strong opinions. I feel responsible for the A2 repository comprising the<br>
> A2 Multicore OS, its graphical user Interface and the FoxCompiler<br>
> toolchain.<br>
><br>
> I should not forget to mention that the dialects of Oberon and the<br>
> systems that we teach are in use in real-world commercial systems sold<br>
> by companies that in fact use Oberon for commercial development. For our<br>
> course this is a very important argument underpinning that following the<br>
> principle of simplicity can have very positive practical impact, even if<br>
> it is hard to sell academically.<br>
><br>
> Kind regards<br>
> Felix Friedrich<br>
><br>
><br>
><br>
><br>
> > On Tue, 26 Sep 2017 10:36:35 +0000<br>
> > Treutwein Bernhard <<a href="mailto:Bernhard.Treutwein@Verwaltung.Uni-Muenchen.DE">Bernhard.Treutwein@<wbr>Verwaltung.Uni-Muenchen.DE</a>><br>
> > wrote:<br>
> ><br>
> >> yes, afaik, with the retirement of J?rg Gutknecht the "Native Systems<br>
> >> Group" was shut down.<br>
> > Having said that, Oberon is no longer taught, developed, and included<br>
> > in informatics research sylabus, at ETH University?<br>
> ><br>
> > So is AOS dropped as well?<br>
> ><br>
><br>
><br>
><br>
> ------------------------------<br>
><br>
> Message: 2<br>
> Date: Wed, 27 Sep 2017 12:49:38 +0200<br>
> From: Tomas Kral <<a href="mailto:thomas.kral@email.cz">thomas.kral@email.cz</a>><br>
> To: <a href="mailto:oberon@lists.inf.ethz.ch">oberon@lists.inf.ethz.ch</a><br>
> Subject: Re: [Oberon] General - Xerox PARC 1970<br>
> Message-ID: <20170927124938.6c945698@<wbr>raspberrypi><br>
> Content-Type: text/plain; charset=UTF-8<br>
><br>
> On Sun, 24 Sep 2017 03:30:24 -0700<br>
> Douglas G Danforth <<a href="mailto:danforth@greenwoodfarm.com">danforth@greenwoodfarm.com</a>> wrote:<br>
><br>
> > She showed me the Alto when I visited PARC.? Its hard drive was a<br>
> > large platter which, iirc, held only of data.<br>
><br>
> 14MB given the enthropy of information may seem like today's 14GB, as I<br>
> see similar stuff on Alto's screen as on mobile displays, say from<br>
> a higher level of perspective, so to speak. That is 1970.<br>
><br>
> I remember a decade after (1982 ZX/ATARI, etc), popular 8-bit home<br>
> computing, 64K of RAM was unheard of limit, possible only in mainframes<br>
> before.<br>
><br>
> Then `1984' - Orwell's Big Brother was chosen as the main theme of<br>
> Apple's marketing campaign, for their computer released 1984.<br>
><br>
> Workstation's like Alto, were a dream, also the price $40.000,<br>
> something like that. Which was not a market price just the cost of<br>
> development, probably?<br>
><br>
> I am lead to believe, that what maters is relative performance.<br>
><br>
> Between various releases of today's user s/w, I usually notice, slower,<br>
> more complicated and requiring faster h/w, but that could well be my<br>
> paranoia as I get older :-)<br>
><br>
> --<br>
> Tomas Kral <<a href="mailto:thomas.kral@email.cz">thomas.kral@email.cz</a>><br>
><br>
><br>
> ------------------------------<br>
><br>
> Message: 3<br>
> Date: Wed, 27 Sep 2017 09:58:27 -0700<br>
> From: <a href="mailto:peter@easthope.ca">peter@easthope.ca</a><br>
> To: <a href="mailto:oberon@lists.inf.ethz.ch">oberon@lists.inf.ethz.ch</a><br>
> Subject: [Oberon] Re (2): General - Academic vs Commercial<br>
> applications<br>
> Message-ID: <E1dxFfH-0000rF-Hc@xo-53-1d-<wbr>bb.localdomain><br>
><br>
> Felix,<br>
><br>
> Thanks for your overview.<br>
><br>
> From: Felix Friedrich <<a href="mailto:felix.friedrich@inf.ethz.ch">felix.friedrich@inf.ethz.ch</a>><br>
> Date: Wed, 27 Sep 2017 12:17:23 +0200<br>
> > Apart from that I am the "last man standing" for Oberon at ETH.<br>
><br>
> One is better than zero. Thanks for your dedication! This<br>
> circumstance is a good argument for incuding the language report for<br>
> Active Oberon as HTML in the wikibook. Being a wiki, anyone can work<br>
> on it. Subject to your permission of course.<br>
><br>
> Incidentally, accesses to the front page has settled to 400-500/month.<br>
> <a href="https://en.wikibooks.org/w/index.php?title=Oberon&action=info" rel="noreferrer" target="_blank">https://en.wikibooks.org/w/<wbr>index.php?title=Oberon&action=<wbr>info</a><br>
> Certain to climb as the content increases and improves.<br>
><br>
> Regards, ... Lyall E.<br>
> --<br>
><br>
> 123456789 123456789 123456789 123456789 123456789 123456789 123456789<br>
> Tel: <a href="tel:%2B1%20360%20639%200202" value="+13606390202">+1 360 639 0202</a> Pender Is.: <a href="tel:%2B1%20250%20629%203757" value="+12506293757">+1 250 629 3757</a><br>
> <a href="http://easthope.ca/Peter.html" rel="noreferrer" target="_blank">http://easthope.ca/Peter.html</a> Bcc: peter at easthope. ca<br>
><br>
><br>
><br>
> ------------------------------<br>
><br>
> Message: 4<br>
> Date: Wed, 27 Sep 2017 17:09:16 +0000<br>
> From: eas lab <<a href="mailto:lab.eas@gmail.com">lab.eas@gmail.com</a>><br>
> To: <<a href="mailto:oberon@inf.ethz.ch">oberon@inf.ethz.ch</a>><br>
> Subject: [Oberon] NativeOberon's FileName limitations - HOW2 extend?<br>
> Message-ID:<br>
> <CAN3-DLH2igPv3gRQFWk8CCPh_<wbr>frLdqLEpode9r-5sFjCYJ67Pg@<br>
> <a href="http://mail.gmail.com" rel="noreferrer" target="_blank">mail.gmail.com</a>><br>
> Content-Type: text/plain; charset="UTF-8"<br>
><br>
> Linux : X11 is a monster, but LNO [121104] runs in a FrameBuffer nicely;<br>
> also under 64bit.<br>
> Why would you NEED LNO ?<br>
> 1. to have multiple files visible together on the same screen;<br>
> 2. with powerfull mouse-chording ability;<br>
> PublicDomain wily [needs X11], copied from ETHO, is even better, except<br>
> lacks<br>
> 3. ETHO's coloring capability: to give an extra dimension to<br>
> complex relationships between texts, possibly in multiple files.<br>
><br>
> Mildly complex tasks, soon need 4, 5, 6 ...TextFrames viewable-together.<br>
> Since screen-area is the limiting factor, M$'s wastefull <staggered<br>
> frames>,<br>
> copied by Aos, is NOT acceptable. The paper-book, where each of hundreds<br>
> of pages "automatically line-up", is a magical concept!<br>
><br>
> The big problem/weakness of LNO: not being able to immediately read/write<br>
> to files anywhere in the file-tree, can be reduced by:<br>
> 1. use a convenient file-navigator, like mc, which allows to<br>
> 2. <push a button> at the reqired-file, which stores its /PATH/Name to a<br>
> fixed location, which<br>
> 3. is accessed by LNO to mount the file-to-be-accessed by LNO.<br>
><br>
> Right now, while composing this text, via USBstik:Linux:TinyCore46:LNO<br>
> I want to access some Oberon:V4 files on the M$-partition.<br>
> I failed: apparently LNO can't mount FATFS, like LEO can.<br>
> It shouldn't be difficult to extend the capability?<br>
><br>
> But read/write to V4 files in LinuxFS, is OK via:<br>
> FileSystem.Mount V4 LinuxFS /mnt/sdb2/CRG/ETHO/V4dirTree/<br>
> usr/local/oberon/Text/~<br>
><br>
> The 4-string command/M.P had the last/long string stored in the known<br>
> location;<br>
> so "V4" is my chosen name and string1, string3 are in the <Tools Text>;<br>
> and the user need only add his chosen name to make the 4-string command.<br>
> Then System.Directory ^ V4:* lists the directory contents; giving<br>
> immediate<br>
> access to the 96 files:-----------<br>
> V4:.<br>
> V4:..<br>
> V4:Analyzer.Tool<br>
> V4:AsciiCoder.Tool<br>
> V4:Backup.Tool<br>
> V4:Balloon.Text<br>
> V4:BalloonIdx.hlp<br>
> ...<br>
> V4:Find.Tool<br>
><br>
> V4:Welcome.Text<br>
> V4:Xref.Tool<br>
><br>
> 96 files ----------------<br>
> LNO can access all: Aos, *nix, FATFS and presumably V4 formats.<br>
> The PROBLEM remains, to access eg. "tmp:mc-root", where "mc-root"<br>
> is not a valid <FileName>.<br>
> AFAIR <Linux ETH Oberon> was able to access such filenames by quoting?<br>
> Can we extend LNO, perhaps based on LEO?<br>
><br>
> == Chris Glur.<br>
><br>
> PS. The fact that ETHO's System.Directory output is not available:<br>
> ordered by recentcy, is a serious deficiency: not acknowledging that<br>
> <the stack and tree> are central to cognition & thus computing ?<br>
><br>
><br>
> ------------------------------<br>
><br>
> Message: 5<br>
> Date: Thu, 28 Sep 2017 01:51:22 +0000<br>
> From: eas lab <<a href="mailto:lab.eas@gmail.com">lab.eas@gmail.com</a>><br>
> To: ETH Oberon and related systems <<a href="mailto:oberon@lists.inf.ethz.ch">oberon@lists.inf.ethz.ch</a>><br>
> Subject: Re: [Oberon] General - Academic vs Commercial applications<br>
> Message-ID:<br>
> <CAN3-DLGTDX=a5fnxA7=<wbr>w54ZsMjzh6ZY4Y22xMtga2OtrJ++<wbr>Oww@mail.<br>
> <a href="http://gmail.com" rel="noreferrer" target="_blank">gmail.com</a>><br>
> Content-Type: text/plain; charset="UTF-8"<br>
><br>
> Looks like a brilliant syllabus: teaching universal 1st-principles,<br>
> and not just the current FB, twitter fads.<br>
><br>
> When RPi first came out, I wanted to build a P-code interpreter,<br>
> as I had done in the 70s for Fairchild-F8, 63xx/68xx, Intel16bit;<br>
> but I couldn't see how to <single step design asm-instructions><br>
> [as I had always done - I coded the F8 via a teletype in *HEX*]<br>
> since appaently the ARM assembler takes the user's <intentions><br>
> and OPTIMISES it, in the background, to generate the actual.<br>
> single-instructions.<br>
><br>
> No one on the RPi NNTP could understand my query, because today<br>
> it's always "doA, doB...", without understanding the underlying<br>
> principles. But now, I see the critical reference to "OPTIMIZED" in<br>
> <a href="http://lec.inf.ethz.ch/syscon/2017/slides/LSC17Slides0926.pdf" rel="noreferrer" target="_blank">http://lec.inf.ethz.ch/syscon/<wbr>2017/slides/LSC17Slides0926.<wbr>pdf</a><br>
><br>
> == Chris Glur.<br>
><br>
><br>
> ------------------------------<br>
><br>
> Subject: Digest Footer<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" rel="noreferrer" target="_blank">https://lists.inf.ethz.ch/<wbr>mailman/listinfo/oberon</a><br>
><br>
><br>
> ------------------------------<br>
><br>
> End of Oberon Digest, Vol 160, Issue 21<br>
> ******************************<wbr>*********<br>
><br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://lists.inf.ethz.ch/pipermail/oberon/attachments/20170928/7e9b0ed0/attachment-0001.html" rel="noreferrer" target="_blank">http://lists.inf.ethz.ch/<wbr>pipermail/oberon/attachments/<wbr>20170928/7e9b0ed0/attachment-<wbr>0001.html</a>><br>
<br>
------------------------------<br>
<br>
Message: 3<br>
Date: Thu, 28 Sep 2017 14:50:46 +0000<br>
From: "Skulski, Wojciech" <<a href="mailto:skulski@pas.rochester.edu">skulski@pas.rochester.edu</a>><br>
To: ETH Oberon and related systems <<a href="mailto:oberon@lists.inf.ethz.ch">oberon@lists.inf.ethz.ch</a>><br>
Subject: [Oberon] Raytracing research<br>
Message-ID:<br>
<<a href="mailto:DM5PR0701MB36720B68EF2FCDAA6AEC89C7FF790@DM5PR0701MB3672.namprd07.prod.outlook.com">DM5PR0701MB36720B68EF2FCDAA6A<wbr>EC89C7FF790@DM5PR0701MB3672.<wbr>namprd07.prod.outlook.com</a>><br>
<br>
Content-Type: text/plain; charset="iso-8859-1"<br>
<br>
Hi:<br>
<br>
would you mind providing a web pointer to your preliminary results on ray tracing? Also, why is AOS part of it?<br>
<br>
Wojtek<br>
______________________________<wbr>__________<br>
From: Oberon [<a href="mailto:oberon-bounces@lists.inf.ethz.ch">oberon-bounces@lists.inf.<wbr>ethz.ch</a>] on behalf of S?ren Renner [<a href="mailto:soren.renner@gmail.com">soren.renner@gmail.com</a>]<br>
Sent: Thursday, September 28, 2017 8:47 AM<br>
To: <a href="mailto:oberon@lists.inf.ethz.ch">oberon@lists.inf.ethz.ch</a><br>
Subject: Re: [Oberon] Oberon Digest, Vol 160, Issue 21<br>
<br>
Also, AOS and Oberon will become much more widely noticed as soon as my raytracing research receives the attention and praise that it deserves.<br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 4<br>
Date: Thu, 28 Sep 2017 16:59:54 +0200<br>
From: Liam Proven <<a href="mailto:lproven@gmail.com">lproven@gmail.com</a>><br>
To: ETH Oberon and related systems <<a href="mailto:oberon@lists.inf.ethz.ch">oberon@lists.inf.ethz.ch</a>><br>
Subject: Re: [Oberon] Oberon Digest, Vol 160, Issue 21<br>
Message-ID:<br>
<<a href="mailto:CAMTenCHeOFgSonCM9PwDWpp5sepAkqAKG8ymVPn8eV6n5UDE5w@mail.gmail.com">CAMTenCHeOFgSonCM9PwDWpp5sepA<wbr>kqAKG8ymVPn8eV6n5UDE5w@mail.<wbr>gmail.com</a>><br>
Content-Type: text/plain; charset="UTF-8"<br>
<br>
On 28 September 2017 at 14:47, S?ren Renner <<a href="mailto:soren.renner@gmail.com">soren.renner@gmail.com</a>> wrote:<br>
> Also, AOS and Oberon will become much more widely noticed as soon as my<br>
> raytracing research receives the attention and praise that it deserves.<br>
<br>
<br>
Please bottom-post if you can!<br>
<br>
I am hoping to help or facilitate a port of A2 to the Raspberry Pi,<br>
hardware for which it seems ideal. Bolt on a Ceres CPU emulator and it<br>
would be a lovely platform for the OS, and the OS an ideal educational<br>
tool, I think.<br>
<br>
But I'm probably daydreaming...<br>
<br>
<br>
--<br>
Liam Proven ? Profile: <a href="https://about.me/liamproven" rel="noreferrer" target="_blank">https://about.me/liamproven</a><br>
Email: <a href="mailto:lproven@cix.co.uk">lproven@cix.co.uk</a> ? Google Mail/Talk/Plus: <a href="mailto:lproven@gmail.com">lproven@gmail.com</a><br>
Twitter/Facebook/Flickr: lproven ? Skype/LinkedIn/AIM/Yahoo: liamproven<br>
UK: <a href="tel:%2B44%207939-087884" value="+447939087884">+44 7939-087884</a> ? ?R/WhatsApp/Telegram/Signal: <a href="tel:%2B420%20702%20829%20053" value="+420702829053">+420 702 829 053</a><br>
<br>
<br>
------------------------------<br>
<br>
Message: 5<br>
Date: Thu, 28 Sep 2017 15:08:34 +0000<br>
From: "Skulski, Wojciech" <<a href="mailto:skulski@pas.rochester.edu">skulski@pas.rochester.edu</a>><br>
To: ETH Oberon and related systems <<a href="mailto:oberon@lists.inf.ethz.ch">oberon@lists.inf.ethz.ch</a>><br>
Subject: [Oberon] A2 on ARM Linux Platform<br>
Message-ID:<br>
<<a href="mailto:DM5PR0701MB3672BA29A5F6BFB77E4A6369FF790@DM5PR0701MB3672.namprd07.prod.outlook.com">DM5PR0701MB3672BA29A5F6BFB77E<wbr>4A6369FF790@DM5PR0701MB3672.<wbr>namprd07.prod.outlook.com</a>><br>
<br>
Content-Type: text/plain; charset="us-ascii"<br>
<br>
Liam:<br>
<br>
please consider a general "ARM Linux Platform" rather than just Rpi. The latter is closed source and bound to a particular company. They try hard to make it look like open hardware, which it is not. Broadcom is not even selling the Rpi processors to anyone except their subsidiary who is building Rpi boards.<br>
<br>
The "ARM Linux Platform" would cover Rpi, BeagleBone which is open source, and a whole variety of chinese-built open source boards. This would be much more in the spirit of Oberon, which is open to everyone. Supporting shrewd business M$-like strategy, which Rpi really is, is much less in the spirit of Oberon.<br>
<br>
Thanks,<br>
Wojtek<br>
______________________________<wbr>__________<br>
From: Oberon [<a href="mailto:oberon-bounces@lists.inf.ethz.ch">oberon-bounces@lists.inf.<wbr>ethz.ch</a>] on behalf of Liam Proven [<a href="mailto:lproven@gmail.com">lproven@gmail.com</a>]<br>
Sent: Thursday, September 28, 2017 10:59 AM<br>
To: ETH Oberon and related systems<br>
Subject: Re: [Oberon] Oberon Digest, Vol 160, Issue 21<br>
<br>
I am hoping to help or facilitate a port of A2 to the Raspberry Pi,<br>
hardware for which it seems ideal. Bolt on a Ceres CPU emulator and it<br>
would be a lovely platform for the OS, and the OS an ideal educational<br>
tool, I think.<br>
<br>
But I'm probably daydreaming...<br>
<br>
<br>
------------------------------<br>
<br>
Message: 6<br>
Date: Thu, 28 Sep 2017 17:45:20 +0200<br>
From: Peter Matthias <<a href="mailto:PeterMatthias@web.de">PeterMatthias@web.de</a>><br>
To: <a href="mailto:oberon@lists.inf.ethz.ch">oberon@lists.inf.ethz.ch</a><br>
Subject: Re: [Oberon] Oberon Digest, Vol 160, Issue 21<br>
Message-ID: <<a href="mailto:8e373c2e-a9f0-7216-2ddd-480b1b5d3c8d@web.de">8e373c2e-a9f0-7216-2ddd-<wbr>480b1b5d3c8d@web.de</a>><br>
Content-Type: text/plain; charset=utf-8; format=flowed<br>
<br>
Am 28.09.2017 um 16:59 schrieb Liam Proven:<br>
> I am hoping to help or facilitate a port of A2 to the Raspberry Pi,<br>
> hardware for which it seems ideal. Bolt on a Ceres CPU emulator and it<br>
> would be a lovely platform for the OS, and the OS an ideal educational<br>
> tool, I think.<br>
><br>
> But I'm probably daydreaming...<br>
<br>
If you read the slides Chris posted today, you must came to the<br>
conclusion that A2 for RPi (bare metal) exists. Obviously not openly<br>
available. Sad.<br>
<br>
Peter<br>
<br>
<br>
------------------------------<br>
<br>
Message: 7<br>
Date: Thu, 28 Sep 2017 18:11:11 +0200<br>
From: Andreas Pirklbauer <<a href="mailto:andreas_pirklbauer@yahoo.com">andreas_pirklbauer@yahoo.com</a>><br>
To: ETH Oberon and related systems <<a href="mailto:oberon@lists.inf.ethz.ch">oberon@lists.inf.ethz.ch</a>><br>
Subject: [Oberon] Procedure variables and local procedures<br>
Message-ID: <<a href="mailto:17EB1E4F-3874-42FE-9670-7E665055095E@yahoo.com">17EB1E4F-3874-42FE-9670-<wbr>7E665055095E@yahoo.com</a>><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
Note that even though the Oberon language report of Oberon-07 still states that ?If a procedure P is assigned to a procedure variable of type T [...]. P must not be declared local to another procedure?, in the current implementation of Oberon-07, this restriction is not actually checked - at least not in the case when the procedure variable to which a local procedure is assigned is itself declared locally in the same scope, as in the following example:<br>
MODULE M;<br>
<br>
PROCEDURE P;<br>
VAR p: PROCEDURE;<br>
PROCEDURE Q; BEGIN END Q;<br>
BEGIN p := Q<br>
END P;<br>
END M.<br>
<br>
which compiles correctly under Oberon 2013 without an error message.<br>
AP<br>
------------------------------<wbr>------------------------------<wbr>--------------<br>
August Karlstrom <a href="mailto:fusionfile@gmail.com">fusionfile@gmail.com</a> <mailto:<a href="mailto:fusionfile@gmail.com">fusionfile@gmail.com</a>> Thu Sep 18 12:14:29 CEST 2017<br>
In the latest revision of the Oberon language, access to identifiers in<br>
intermediate scopes is denied. Doesn't this imply that the restriction<br>
that only globally defined procedures can be assigned to procedure<br>
variables, is the unnecessary?<br>
<br>
-- August<br>
<br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://lists.inf.ethz.ch/pipermail/oberon/attachments/20170928/5ea5b981/attachment-0001.html" rel="noreferrer" target="_blank">http://lists.inf.ethz.ch/<wbr>pipermail/oberon/attachments/<wbr>20170928/5ea5b981/attachment-<wbr>0001.html</a>><br>
<br>
------------------------------<br>
<br>
Message: 8<br>
Date: Thu, 28 Sep 2017 18:57:34 +0200<br>
From: Andreas Pirklbauer <<a href="mailto:andreas_pirklbauer@yahoo.com">andreas_pirklbauer@yahoo.com</a>><br>
To: ETH Oberon and related systems <<a href="mailto:oberon@lists.inf.ethz.ch">oberon@lists.inf.ethz.ch</a>><br>
Subject: [Oberon] Procedure variables and local procedures<br>
Message-ID: <<a href="mailto:51B3C3C8-2439-4C48-BD67-16478CB2BFE0@yahoo.com">51B3C3C8-2439-4C48-BD67-<wbr>16478CB2BFE0@yahoo.com</a>><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
Addendum: Another way to read the sentence ?P must not be declared local to ANOTHER procedure? is that in fact ?P may be declared local to the SAME procedure?. This is the case in the example below. Either way, the assignment to procedure variables is not restricted to globally defined procedures.<br>
AP<br>
<br>
On 28 Sep 2017, at 18:11, Andreas Pirklbauer <<a href="mailto:andreas_pirklbauer@yahoo.com">andreas_pirklbauer@yahoo.com</a>> wrote:<br>
><br>
> Note that even though the Oberon language report of Oberon-07 still states that ?If a procedure P is assigned to a procedure variable of type T [...]. P must not be declared local to another procedure?, in the current implementation of Oberon-07, this restriction is not actually checked - at least not in the case when the procedure variable to which a local procedure is assigned is itself declared locally in the same scope, as in the following example:<br>
><br>
> MODULE M;<br>
><br>
> PROCEDURE P;<br>
> VAR p: PROCEDURE;<br>
> PROCEDURE Q; BEGIN END Q;<br>
> BEGIN p := Q<br>
> END P;<br>
> END M.<br>
><br>
> which compiles correctly under Oberon 2013 without an error message.<br>
> AP<br>
> ------------------------------<wbr>------------------------------<wbr>--------------<br>
> August Karlstrom <a href="mailto:fusionfile@gmail.com">fusionfile@gmail.com</a> <mailto:<a href="mailto:fusionfile@gmail.com">fusionfile@gmail.com</a>> Thu Sep 18 12:14:29 CEST 2017<br>
> In the latest revision of the Oberon language, access to identifiers in<br>
> intermediate scopes is denied. Doesn't this imply that the restriction<br>
> that only globally defined procedures can be assigned to procedure<br>
> variables, is the unnecessary?<br>
><br>
> -- August<br>
><br>
<br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://lists.inf.ethz.ch/pipermail/oberon/attachments/20170928/8eed0aaf/attachment-0001.html" rel="noreferrer" target="_blank">http://lists.inf.ethz.ch/<wbr>pipermail/oberon/attachments/<wbr>20170928/8eed0aaf/attachment-<wbr>0001.html</a>><br>
<br>
------------------------------<br>
<br>
Message: 9<br>
Date: Thu, 28 Sep 2017 17:06:44 +0000<br>
From: "Skulski, Wojciech" <<a href="mailto:skulski@pas.rochester.edu">skulski@pas.rochester.edu</a>><br>
To: ETH Oberon and related systems <<a href="mailto:oberon@lists.inf.ethz.ch">oberon@lists.inf.ethz.ch</a>><br>
Subject: Re: [Oberon] Procedure variables and local procedures<br>
Message-ID:<br>
<<a href="mailto:DM5PR0701MB3672F7E0CB41BFC7E889161CFF790@DM5PR0701MB3672.namprd07.prod.outlook.com">DM5PR0701MB3672F7E0CB41BFC7E8<wbr>89161CFF790@DM5PR0701MB3672.<wbr>namprd07.prod.outlook.com</a>><br>
<br>
Content-Type: text/plain; charset="Windows-1252"<br>
<br>
Andreas:<br>
<br>
is the following code correct? If so, can another module import M and call M.proc()? What is the intent, if it is possible?<br>
<br>
MODULE M;<br>
TYPE PROC* = PROCEDURE;<br>
VAR proc*: PROC;<br>
<br>
PROCEDURE P () : PROC;<br>
VAR p: PROCEDURE;<br>
<br>
PROCEDURE Q; BEGIN END Q;<br>
<br>
BEGIN p := Q<br>
RETURN p<br>
END P;<br>
END M.<br>
<br>
<br>
______________________________<wbr>__________<br>
From: Oberon [<a href="mailto:oberon-bounces@lists.inf.ethz.ch">oberon-bounces@lists.inf.<wbr>ethz.ch</a>] on behalf of Andreas Pirklbauer [<a href="mailto:andreas_pirklbauer@yahoo.com">andreas_pirklbauer@yahoo.com</a>]<br>
Sent: Thursday, September 28, 2017 12:57 PM<br>
To: ETH Oberon and related systems<br>
Subject: [Oberon] Procedure variables and local procedures<br>
<br>
Addendum: Another way to read the sentence ?P must not be declared local to ANOTHER procedure? is that in fact ?P may be declared local to the SAME procedure?. This is the case in the example below. Either way, the assignment to procedure variables is not restricted to globally defined procedures.<br>
<br>
AP<br>
<br>
<br>
On 28 Sep 2017, at 18:11, Andreas Pirklbauer <<a href="mailto:andreas_pirklbauer@yahoo.com">andreas_pirklbauer@yahoo.com</a><<wbr>mailto:<a href="mailto:andreas_pirklbauer@yahoo.com">andreas_pirklbauer@<wbr>yahoo.com</a>>> wrote:<br>
<br>
<br>
Note that even though the Oberon language report of Oberon-07 still states that ?If a procedure P is assigned to a procedure variable of type T [...]. P must not be declared local to another procedure?, in the current implementation of Oberon-07, this restriction is not actually checked - at least not in the case when the procedure variable to which a local procedure is assigned is itself declared locally in the same scope, as in the following example:<br>
<br>
MODULE M;<br>
<br>
PROCEDURE P;<br>
VAR p: PROCEDURE;<br>
<br>
PROCEDURE Q; BEGIN END Q;<br>
<br>
BEGIN p := Q<br>
END P;<br>
END M.<br>
<br>
<br>
which compiles correctly under Oberon 2013 without an error message.<br>
<br>
AP<br>
<br>
------------------------------<wbr>------------------------------<wbr>--------------<br>
<br>
August Karlstrom <a href="mailto:fusionfile@gmail.com">fusionfile@gmail.com</a><mailto:<a href="mailto:fusionfile@gmail.com">fu<wbr>sionfile@gmail.com</a>> Thu Sep 18 12:14:29 CEST 2017<br>
<br>
In the latest revision of the Oberon language, access to identifiers in<br>
intermediate scopes is denied. Doesn't this imply that the restriction<br>
that only globally defined procedures can be assigned to procedure<br>
variables, is the unnecessary?<br>
<br>
-- August<br>
<br>
<br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 10<br>
Date: Thu, 28 Sep 2017 17:11:05 +0000<br>
From: "Skulski, Wojciech" <<a href="mailto:skulski@pas.rochester.edu">skulski@pas.rochester.edu</a>><br>
To: ETH Oberon and related systems <<a href="mailto:oberon@lists.inf.ethz.ch">oberon@lists.inf.ethz.ch</a>><br>
Subject: Re: [Oberon] Procedure variables and local procedures<br>
Message-ID:<br>
<<a href="mailto:DM5PR0701MB36720365ADB37C9853339E2EFF790@DM5PR0701MB3672.namprd07.prod.outlook.com">DM5PR0701MB36720365ADB37C9853<wbr>339E2EFF790@DM5PR0701MB3672.<wbr>namprd07.prod.outlook.com</a>><br>
<br>
Content-Type: text/plain; charset="Windows-1252"<br>
<br>
Edit to my example:<br>
______________________________<wbr>__________<br>
<br>
Andreas:<br>
<br>
is the following code correct? If so, can another module import M and call M.proc()? What is the intent, if it is possible?<br>
<br>
MODULE M;<br>
TYPE PROC* = PROCEDURE;<br>
VAR proc*: PROC;<br>
<br>
PROCEDURE P () : PROC;<br>
VAR p: PROCEDURE;<br>
<br>
PROCEDURE Q; BEGIN END Q;<br>
<br>
BEGIN p := Q<br>
RETURN p<br>
END P;<br>
BEGIN<br>
proc := P()<br>
END M.<br>
<br>
<br>
______________________________<wbr>__________<br>
From: Oberon [<a href="mailto:oberon-bounces@lists.inf.ethz.ch">oberon-bounces@lists.inf.<wbr>ethz.ch</a>] on behalf of Andreas Pirklbauer [<a href="mailto:andreas_pirklbauer@yahoo.com">andreas_pirklbauer@yahoo.com</a>]<br>
Sent: Thursday, September 28, 2017 12:57 PM<br>
To: ETH Oberon and related systems<br>
Subject: [Oberon] Procedure variables and local procedures<br>
<br>
Addendum: Another way to read the sentence ?P must not be declared local to ANOTHER procedure? is that in fact ?P may be declared local to the SAME procedure?. This is the case in the example below. Either way, the assignment to procedure variables is not restricted to globally defined procedures.<br>
<br>
AP<br>
<br>
<br>
On 28 Sep 2017, at 18:11, Andreas Pirklbauer <<a href="mailto:andreas_pirklbauer@yahoo.com">andreas_pirklbauer@yahoo.com</a><<wbr>mailto:<a href="mailto:andreas_pirklbauer@yahoo.com">andreas_pirklbauer@<wbr>yahoo.com</a>>> wrote:<br>
<br>
<br>
Note that even though the Oberon language report of Oberon-07 still states that ?If a procedure P is assigned to a procedure variable of type T [...]. P must not be declared local to another procedure?, in the current implementation of Oberon-07, this restriction is not actually checked - at least not in the case when the procedure variable to which a local procedure is assigned is itself declared locally in the same scope, as in the following example:<br>
<br>
MODULE M;<br>
<br>
PROCEDURE P;<br>
VAR p: PROCEDURE;<br>
<br>
PROCEDURE Q; BEGIN END Q;<br>
<br>
BEGIN p := Q<br>
END P;<br>
END M.<br>
<br>
<br>
which compiles correctly under Oberon 2013 without an error message.<br>
<br>
AP<br>
<br>
------------------------------<wbr>------------------------------<wbr>--------------<br>
<br>
August Karlstrom <a href="mailto:fusionfile@gmail.com">fusionfile@gmail.com</a><mailto:<a href="mailto:fusionfile@gmail.com">fu<wbr>sionfile@gmail.com</a>> Thu Sep 18 12:14:29 CEST 2017<br>
<br>
In the latest revision of the Oberon language, access to identifiers in<br>
intermediate scopes is denied. Doesn't this imply that the restriction<br>
that only globally defined procedures can be assigned to procedure<br>
variables, is the unnecessary?<br>
<br>
-- August<br>
<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://urldefense.proofpoint.com/v2/url?u=https-3A__lists.inf.ethz.ch_mailman_listinfo_oberon&d=DwIF-g&c=kbmfwr1Yojg42sGEpaQh5ofMHBeTl9EI2eaqQZhHbOU&r=uUiA_zLpwaGJIlq-_BM9w1wVOuyqPwHi3XzJRa-ybV0&m=OFID7JBDuyitL8Vy-y5NbjL3dP1cJrzjiNdMGyYS9TU&s=gCQHSBghumD6Tp5nFRhB_q7o35sKKw25mVOIDewH0BY&e=" rel="noreferrer" target="_blank">https://urldefense.proofpoint.<wbr>com/v2/url?u=https-3A__lists.<wbr>inf.ethz.ch_mailman_listinfo_<wbr>oberon&d=DwIF-g&c=<wbr>kbmfwr1Yojg42sGEpaQh5ofMHBeTl9<wbr>EI2eaqQZhHbOU&r=uUiA_<wbr>zLpwaGJIlq-_<wbr>BM9w1wVOuyqPwHi3XzJRa-ybV0&m=<wbr>OFID7JBDuyitL8Vy-<wbr>y5NbjL3dP1cJrzjiNdMGyYS9TU&s=<wbr>gCQHSBghumD6Tp5nFRhB_<wbr>q7o35sKKw25mVOIDewH0BY&e=</a><br>
<br>
<br>
------------------------------<br>
<br>
Message: 11<br>
Date: Thu, 28 Sep 2017 20:26:53 +0200<br>
From: Andreas Pirklbauer <<a href="mailto:andreas_pirklbauer@yahoo.com">andreas_pirklbauer@yahoo.com</a>><br>
To: ETH Oberon and related systems <<a href="mailto:oberon@lists.inf.ethz.ch">oberon@lists.inf.ethz.ch</a>><br>
Subject: [Oberon] Procedure variables and local procedures<br>
Message-ID: <<a href="mailto:92FDC6A8-6F8E-4628-A8CA-AAAF2070559C@yahoo.com">92FDC6A8-6F8E-4628-A8CA-<wbr>AAAF2070559C@yahoo.com</a>><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
Wojtek,<br>
sure, this is possible - below is a slightly modified version. Compile M and N, then activate N.Run.<br>
<br>
MODULE M;<br>
IMPORT Texts, Oberon;<br>
<br>
TYPE PROC* = PROCEDURE;<br>
VAR proc*: PROC;<br>
W: Texts.Writer;<br>
<br>
PROCEDURE P () : PROC;<br>
VAR p: PROCEDURE;<br>
<br>
PROCEDURE Q;<br>
BEGIN Texts.WriteString(W, "Q executing"); Texts.Append(Oberon.Log, W.buf)<br>
END Q;<br>
<br>
BEGIN p := Q;<br>
RETURN p<br>
END P;<br>
<br>
BEGIN Texts.OpenWriter(W); proc := P()<br>
END M.<br>
<br>
MODULE N;<br>
IMPORT M;<br>
<br>
PROCEDURE Run*;<br>
BEGIN M.proc()<br>
END Run;<br>
<br>
END N.<br>
<br>
Local procedures are in fact almost identical to global procedures - they are compiled just like any (global) procedure, they have a fixed static starting address within the module block (where they are stored, just like global procedures). Therefore, they can of course also be assigned to variables and/or returned as the result of a function procedure, as shown in the above example.<br>
<br>
The only difference to global procedures is that it can only be *accessed by name* (i.e. in the source code) from the enclosing scope. For example, the local procedure Q can only *accessed by name* from the enclosing procedure P - i.e. only P can reference Q by name: it might of course call Q directly, but it can also assign Q to a local or global variable. Such an assignment is perfectly legitimate (recall that internally simply the address of Q is copied).<br>
<br>
So the fact that a local procedure Q can only be *accessed by name* from the enclosing scope does NOT mean that it somehow ?disappears? once the enclosing procedure P has been executed. In other words, local procedures do NOT behave like local variables, which are allocated on the stack and indeed disappear once the procedure declaring them has been executed. By contrast, ?local" procedures don?t go away, once the enclosing procedure has been executed. They are still there, it?s just that they can be accessed by their name only when the enclosing procedure executes.<br>
<br>
Andreas<br>
<br>
---------------------------<br>
Thu Sep 28 19:06:44 CEST 2017 Skulski, Wojciech skulski at <a href="http://pas.rochester.edu" rel="noreferrer" target="_blank">pas.rochester.edu</a> <<a href="http://pas.rochester.edu/" rel="noreferrer" target="_blank">http://pas.rochester.edu/</a>> wrote:<br>
Andreas:<br>
<br>
is the following code correct? If so, can another module import M and call M.proc()? What is the intent, if it is possible?<br>
<br>
MODULE M;<br>
TYPE PROC* = PROCEDURE;<br>
VAR proc*: PROC;<br>
<br>
PROCEDURE P () : PROC;<br>
VAR p: PROCEDURE;<br>
<br>
PROCEDURE Q; BEGIN END Q;<br>
<br>
BEGIN p := Q<br>
RETURN p<br>
END P;<br>
END M.<br>
<br>
<br>
______________________________<wbr>__________<br>
From: Oberon [oberon-bounces at <a href="http://lists.inf.ethz.ch" rel="noreferrer" target="_blank">lists.inf.ethz.ch</a> <<a href="https://lists.inf.ethz.ch/mailman/listinfo/oberon" rel="noreferrer" target="_blank">https://lists.inf.ethz.ch/<wbr>mailman/listinfo/oberon</a>>] on behalf of Andreas Pirklbauer [andreas_pirklbauer at <a href="http://yahoo.com" rel="noreferrer" target="_blank">yahoo.com</a> <<a href="https://lists.inf.ethz.ch/mailman/listinfo/oberon" rel="noreferrer" target="_blank">https://lists.inf.ethz.ch/<wbr>mailman/listinfo/oberon</a>>]<br>
Sent: Thursday, September 28, 2017 12:57 PM<br>
To: ETH Oberon and related systems<br>
Subject: [Oberon] Procedure variables and local procedures<br>
<br>
Addendum: Another way to read the sentence ?P must not be declared local to ANOTHER procedure? is that in fact ?P may be declared local to the SAME procedure?. This is the case in the example below. Either way, the assignment to procedure variables is not restricted to globally defined procedures.<br>
<br>
AP<br>
<br>
<br>
On 28 Sep 2017, at 18:11, Andreas Pirklbauer <andreas_pirklbauer at <a href="http://yahoo.com" rel="noreferrer" target="_blank">yahoo.com</a> <<a href="https://lists.inf.ethz.ch/mailman/listinfo/oberon" rel="noreferrer" target="_blank">https://lists.inf.ethz.ch/<wbr>mailman/listinfo/oberon</a>><<wbr>mailto:<a href="mailto:andreas_pirklbauer">andreas_pirklbauer</a> at <a href="http://yahoo.com" rel="noreferrer" target="_blank">yahoo.com</a> <<a href="https://lists.inf.ethz.ch/mailman/listinfo/oberon" rel="noreferrer" target="_blank">https://lists.inf.ethz.ch/<wbr>mailman/listinfo/oberon</a>>>> wrote:<br>
<br>
<br>
Note that even though the Oberon language report of Oberon-07 still states that ?If a procedure P is assigned to a procedure variable of type T [...]. P must not be declared local to another procedure?, in the current implementation of Oberon-07, this restriction is not actually checked - at least not in the case when the procedure variable to which a local procedure is assigned is itself declared locally in the same scope, as in the following example:<br>
<br>
MODULE M;<br>
<br>
PROCEDURE P;<br>
VAR p: PROCEDURE;<br>
<br>
PROCEDURE Q; BEGIN END Q;<br>
<br>
BEGIN p := Q<br>
END P;<br>
END M.<br>
<br>
<br>
which compiles correctly under Oberon 2013 without an error message.<br>
<br>
AP<br>
<br>
------------------------------<wbr>------------------------------<wbr>--------------<br>
<br>
August Karlstrom fusionfile at <a href="http://gmail.com" rel="noreferrer" target="_blank">gmail.com</a> <<a href="https://lists.inf.ethz.ch/mailman/listinfo/oberon" rel="noreferrer" target="_blank">https://lists.inf.ethz.ch/<wbr>mailman/listinfo/oberon</a>><<wbr>mailto:<a href="mailto:fusionfile">fusionfile</a> at <a href="http://gmail.com" rel="noreferrer" target="_blank">gmail.com</a> <<a href="https://lists.inf.ethz.ch/mailman/listinfo/oberon" rel="noreferrer" target="_blank">https://lists.inf.ethz.ch/<wbr>mailman/listinfo/oberon</a>>> Thu Sep 18 12:14:29 CEST 2017<br>
<br>
In the latest revision of the Oberon language, access to identifiers in<br>
intermediate scopes is denied. Doesn't this imply that the restriction<br>
that only globally defined procedures can be assigned to procedure<br>
variables, is the unnecessary?<br>
<br>
-- August<br>
<br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://lists.inf.ethz.ch/pipermail/oberon/attachments/20170928/a2e7609d/attachment.html" rel="noreferrer" target="_blank">http://lists.inf.ethz.ch/<wbr>pipermail/oberon/attachments/<wbr>20170928/a2e7609d/attachment.<wbr>html</a>><br>
<br>
------------------------------<br>
<br>
Subject: Digest Footer<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" rel="noreferrer" target="_blank">https://lists.inf.ethz.ch/<wbr>mailman/listinfo/oberon</a><br>
<br>
<br>
------------------------------<br>
<br>
End of Oberon Digest, Vol 160, Issue 22<br>
******************************<wbr>*********<br>
</blockquote></div><br></div>