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