<html><head></head><body><div style="color:#000; background-color:#fff; font-family:verdana, helvetica, sans-serif;font-size:13px"><div id="yui_3_16_0_ym19_1_1506774581149_6370" dir="ltr"><span id="yui_3_16_0_ym19_1_1506774581149_6369">I have found this thread of discussion to be immensely interesting, as I use Oberon to do embedded work for much of what I do. I have focused on the well sorted OP2 compiler for much of this, and also use M2 (programmed in an Oberon-like subset) for many things.</span></div><div id="yui_3_16_0_ym19_1_1506774581149_6128" dir="ltr"><span><br></span></div><div id="yui_3_16_0_ym19_1_1506774581149_6368" dir="ltr"><span id="yui_3_16_0_ym19_1_1506774581149_6367">The changes being discussed (and those that have already been made) in PO, or 07 (e.g., any follow-on dialect to Oberon that is post OP-2 in this millennium) are in many cases welcome, as they clarify and simplify. </span></div><div id="yui_3_16_0_ym19_1_1506774581149_6377" dir="ltr"><span><br></span></div><div id="yui_3_16_0_ym19_1_1506774581149_6182" dir="ltr"><span id="yui_3_16_0_ym19_1_1506774581149_6181">But they do confound. The confound our previous thinking and experience in language use (remember, there are practitioners lurking in this list who rely on a high degree of familiarity and experience with a given language definition and its implementation to ensure reliable work products). </span></div><div id="yui_3_16_0_ym19_1_1506774581149_6211" dir="ltr"><span><br></span></div><div id="yui_3_16_0_ym19_1_1506774581149_6235" dir="ltr"><span id="yui_3_16_0_ym19_1_1506774581149_6234">But perhaps most importantly, the changes are most dramatic in their impact on code bases. Many of the changes made in PO/07 are of the type that cannot be machine translated, in the sense of a source to source translator. They require the practitioner to perform code redesign in order to adopt the latest compilers. LOOP, RETURN fall into this category. The local procedure situation is another. </span></div><div id="yui_3_16_0_ym19_1_1506774581149_6408" dir="ltr"><span><br></span></div><div id="yui_3_16_0_ym19_1_1506774581149_6407" dir="ltr"><span id="yui_3_16_0_ym19_1_1506774581149_6479">Then, there are the many more minor, but tedious to adopt changes of bit op functions and their names, and the like.</span></div><div id="yui_3_16_0_ym19_1_1506774581149_6299" dir="ltr"><span><br></span></div><div id="yui_3_16_0_ym19_1_1506774581149_6243" dir="ltr"><span id="yui_3_16_0_ym19_1_1506774581149_6242">To adopt these later variants in Oberon is quite a task, if you must convert an existing, active code base to adopt the new language. And, this base works only until the *next* decision to simplify or streamline the language further. </span></div><div dir="ltr"><span><br></span></div><div id="yui_3_16_0_ym19_1_1506774581149_6434" dir="ltr"><span id="yui_3_16_0_ym19_1_1506774581149_6433">Another reason I like OP2: it is more than capable, but more than this, it is static in its definition and predictable in its behavior. I can depend on what it does, and how it does it. Moreover, I can enforce that the compiler DOES NOT change, and avoid a compiler manufacturer's next release of its tool set, and the problems THAT engenders. This reason alone is enough to adopt (one of) the Oberon dialects being discussed in this list, and locking in on it.</span></div><div id="yui_3_16_0_ym19_1_1506774581149_6298" dir="ltr"><span><br></span></div><div id="yui_3_16_0_ym19_1_1506774581149_6283" dir="ltr"><span id="yui_3_16_0_ym19_1_1506774581149_6282">I am not exercising a right of contrarianism, here; rather, I do very much appreciate the laser-like intensity and clarity with which Wirth has gone after these many details. It certainly makes the teaching of language design and implementation much more focused and on point. But practitioners, who build code bases and who must maintain the painfully worked-out, stable behaviors of these code bases most certainly DO NOT want to have to open them back up, and redesign (and then, worst of all, retest and confirm, on all platforms, in all environments, that the changes are stable and correct), with no other benefit than language compatibility. In other words, to be compelled to have to do work that adds no value to the functional performance of this code base. This is the bane of those who operate in the commercial realm. It is the main reason I maintain a close eye on these subsequent language developments, but also why I am extremely careful in committing a new project to these developments.</span></div><div id="yui_3_16_0_ym19_1_1506774581149_6578" dir="ltr"><div id="yui_3_16_0_ym19_1_1506774581149_6547" dir="ltr"><span id="yui_3_16_0_ym19_1_1506774581149_6548"><br></span></div><div id="yui_3_16_0_ym19_1_1506774581149_6287" dir="ltr"><span><br></span></div><span>-M</span><div></div> <div class="qtdSeparateBR"><br><br></div><div class="yahoo_quoted" style="display: block;"> <div style="font-family: verdana, helvetica, sans-serif; font-size: 13px;"> <div style="font-family: HelveticaNeue, Helvetica Neue, Helvetica, Arial, Lucida Grande, sans-serif; font-size: 16px;"> <div dir="ltr"><font face="Arial" size="2"> On Saturday, September 30, 2017 6:00 AM, "oberon-request@lists.inf.ethz.ch" <oberon-request@lists.inf.ethz.ch> wrote:<br></font></div> <br><br> <div class="y_msg_container"><div dir="ltr">Send Oberon mailing list submissions to<br></div><div dir="ltr"> <a href="mailto:oberon@lists.inf.ethz.ch" ymailto="mailto:oberon@lists.inf.ethz.ch">oberon@lists.inf.ethz.ch</a><br></div><div dir="ltr"><br></div><div dir="ltr">To subscribe or unsubscribe via the World Wide Web, visit<br></div><div dir="ltr"> <a href="https://lists.inf.ethz.ch/mailman/listinfo/oberon" target="_blank">https://lists.inf.ethz.ch/mailman/listinfo/oberon</a><br></div><div dir="ltr">or, via email, send a message with subject or body 'help' to<br></div><div dir="ltr"> <a href="mailto:oberon-request@lists.inf.ethz.ch" ymailto="mailto:oberon-request@lists.inf.ethz.ch">oberon-request@lists.inf.ethz.ch</a><br></div><div dir="ltr"><br></div><div dir="ltr">You can reach the person managing the list at<br></div><div dir="ltr"> <a href="mailto:oberon-owner@lists.inf.ethz.ch" ymailto="mailto:oberon-owner@lists.inf.ethz.ch">oberon-owner@lists.inf.ethz.ch</a><br></div><div dir="ltr"><br></div><div dir="ltr">When replying, please edit your Subject line so it is more specific<br></div><div dir="ltr">than "Re: Contents of Oberon digest..."<br></div><div dir="ltr"><br></div><div dir="ltr"><br></div><div dir="ltr">Today's Topics:<br></div><div dir="ltr"><br></div><div dir="ltr"> 1. Re: Procedure variables and local procedures (Skulski, Wojciech)<br></div><div dir="ltr"> 2. Re: Procedure variables and local procedures (Chris Burrows)<br></div><div dir="ltr"> 3. Re: Procedure variables and local procedures (Chris Burrows)<br></div><div dir="ltr"> 4. Re: Procedure variables and local procedures (Skulski, Wojciech)<br></div><div dir="ltr"> 5. Re: Procedure variables and local procedures (Skulski, Wojciech)<br></div><div dir="ltr"> 6. Re: Procedure variables and local procedures (J?rg)<br></div><div dir="ltr"> 7. Re: Procedure variables and local procedures (chris)<br></div><div dir="ltr"><br></div><div dir="ltr"><br></div><div dir="ltr">----------------------------------------------------------------------<br></div><div dir="ltr"><br></div><div dir="ltr">Message: 1<br></div><div dir="ltr">Date: Sat, 30 Sep 2017 01:18:50 +0000<br></div><div dir="ltr">From: "Skulski, Wojciech" <<a href="mailto:skulski@pas.rochester.edu" ymailto="mailto:skulski@pas.rochester.edu">skulski@pas.rochester.edu</a>><br></div><div dir="ltr">To: ETH Oberon and related systems <<a href="mailto:oberon@lists.inf.ethz.ch" ymailto="mailto:oberon@lists.inf.ethz.ch">oberon@lists.inf.ethz.ch</a>><br></div><div dir="ltr">Subject: Re: [Oberon] Procedure variables and local procedures<br></div><div dir="ltr">Message-ID:<br></div><div dir="ltr"> <<a href="mailto:DM5PR0701MB3672FBF0990DD0769421BE0FFF7F0@DM5PR0701MB3672.namprd07.prod.outlook.com" ymailto="mailto:DM5PR0701MB3672FBF0990DD0769421BE0FFF7F0@DM5PR0701MB3672.namprd07.prod.outlook.com">DM5PR0701MB3672FBF0990DD0769421BE0FFF7F0@DM5PR0701MB3672.namprd07.prod.outlook.com</a>><br></div><div dir="ltr"> <br></div><div dir="ltr">Content-Type: text/plain; charset="Windows-1252"<br></div><div dir="ltr"><br></div><div dir="ltr">Joerg:<br></div><div dir="ltr"><br></div><div dir="ltr">>Btw. another issue I see with Oberon-07 ist the removal of dynamic<br></div><div dir="ltr">> arrays. I cannot imagine how to write for example a string library or<br></div><div dir="ltr">> something like that without.<br></div><div dir="ltr"><br></div><div dir="ltr">I do not know the string libs mentioned by Chris, but I used mathematical libs by Robert Campbell. I also wrote waveform data acquisition and corresponding graphics. All of these highly useful programs are based on something like the following, copied from my own code.<br></div><div dir="ltr"><br></div><div dir="ltr"> RArray* = POINTER TO ARRAY OF REAL;<br></div><div dir="ltr"> IArray* = POINTER TO ARRAY OF INTEGER;<br></div><div dir="ltr"><br></div><div dir="ltr">> Would you please explain ?dynamic arrays?? Do you miss the low level SYSTEM.NEW(p, n)?<br></div><div dir="ltr"><br></div><div dir="ltr">I am guessing that Chris has the above in mind. I second his opinion: without the dynamic arrays (or "open arrays") the language is crippled.<br></div><div dir="ltr"><br></div><div dir="ltr">> The modules handling dynamic structures (eg. text editor, network stack or files) <br></div><div dir="ltr">> do in principle use the same internal scheme: they use chains of blocks of fixed size.<br></div><div dir="ltr"><br></div><div dir="ltr">Perhaps it works OK if one is developing a text editor. I still remember Turbo Editor Toolbox was using a similar approach.<br></div><div dir="ltr"><br></div><div dir="ltr">Writing an algebra library using this method takes us back to FORTRAN. Here I second Chris. I too cannot imagine working in this area without dynamic arrays.<br></div><div dir="ltr"><br></div><div dir="ltr">Perhaps you guys could have a look at monumental work done by Robert? This might provide some arguments against cutting off what you consider dead wood, which is in fact crucial for some applications.<br></div><div dir="ltr"><br></div><div dir="ltr"><br></div><div dir="ltr">Thanks,<br></div><div dir="ltr">Wojtek<br></div><div dir="ltr"><br></div><div dir="ltr">------------------------------<br></div><div dir="ltr"><br></div><div dir="ltr">Message: 2<br></div><div dir="ltr">Date: Sat, 30 Sep 2017 11:55:56 +0930<br></div><div dir="ltr">From: "Chris Burrows" <<a href="mailto:chris@cfbsoftware.com" ymailto="mailto:chris@cfbsoftware.com">chris@cfbsoftware.com</a>><br></div><div dir="ltr">To: "'ETH Oberon and related systems'" <<a href="mailto:oberon@lists.inf.ethz.ch" ymailto="mailto:oberon@lists.inf.ethz.ch">oberon@lists.inf.ethz.ch</a>><br></div><div dir="ltr">Subject: Re: [Oberon] Procedure variables and local procedures<br></div><div dir="ltr">Message-ID: <001801d33993$731ca830$5955f890$@cfbsoftware.com><br></div><div dir="ltr">Content-Type: text/plain; charset="us-ascii"<br></div><div dir="ltr"><br></div><div dir="ltr">> -----Original Message-----<br></div><div dir="ltr">> From: Oberon [mailto:<a href="mailto:oberon-bounces@lists.inf.ethz.ch" ymailto="mailto:oberon-bounces@lists.inf.ethz.ch">oberon-bounces@lists.inf.ethz.ch</a>] On Behalf Of<br></div><div dir="ltr">> chris<br></div><div dir="ltr">> Sent: Saturday, 30 September 2017 4:21 AM<br></div><div dir="ltr">> To: ETH Oberon and related systems<br></div><div dir="ltr">> Subject: Re: [Oberon] Procedure variables and local procedures<br></div><div dir="ltr">> <br></div><div dir="ltr">> <br></div><div dir="ltr">> Very terse. How does it work in the reverse case.<br></div><div dir="ltr">> <br></div><div dir="ltr">> VAR b : BYTE; i : INTEGER;<br></div><div dir="ltr">> i := 1000; b := i;<br></div><div dir="ltr">> <br></div><div dir="ltr">> Does it trap for overflow?<br></div><div dir="ltr">> <br></div><div dir="ltr"><br></div><div dir="ltr">chris,<br></div><div dir="ltr"><br></div><div dir="ltr">The details of runtime traps are implementation-specific questions and do<br></div><div dir="ltr">not form part of the language design. <br></div><div dir="ltr"><br></div><div dir="ltr">Runtime overflows (INTEGER as well as BYTE) are not trapped in Project<br></div><div dir="ltr">Oberon or Astrobe Oberon. In fact the Random function exploits this<br></div><div dir="ltr">behaviour and would break if ported to a system that didn't allow you to<br></div><div dir="ltr">turn off overflow trapping. <br></div><div dir="ltr"><br></div><div dir="ltr">If you have no control over the values of the data that reach that point in<br></div><div dir="ltr">your code and you want to trap them (a more subtle scenario than your<br></div><div dir="ltr">example) you should write:<br></div><div dir="ltr"><br></div><div dir="ltr"> ASSERT(i <= 255);<br></div><div dir="ltr"> b := i;<br></div><div dir="ltr"><br></div><div dir="ltr"><br></div><div dir="ltr">Chris (Burrows, that is - I'm not talking to myself ;-))<br></div><div dir="ltr">CFB Software<br></div><div dir="ltr"><a href="http://www.astrobe.com/RISC5" target="_blank">http://www.astrobe.com/RISC5</a><br></div><div dir="ltr"><br></div><div dir="ltr"><br></div><div dir="ltr"><br></div><div dir="ltr"><br></div><div dir="ltr">------------------------------<br></div><div dir="ltr"><br></div><div dir="ltr">Message: 3<br></div><div dir="ltr">Date: Sat, 30 Sep 2017 12:12:52 +0930<br></div><div dir="ltr">From: "Chris Burrows" <<a href="mailto:chris@cfbsoftware.com" ymailto="mailto:chris@cfbsoftware.com">chris@cfbsoftware.com</a>><br></div><div dir="ltr">To: "'ETH Oberon and related systems'" <<a href="mailto:oberon@lists.inf.ethz.ch" ymailto="mailto:oberon@lists.inf.ethz.ch">oberon@lists.inf.ethz.ch</a>><br></div><div dir="ltr">Subject: Re: [Oberon] Procedure variables and local procedures<br></div><div dir="ltr">Message-ID: <001901d33995$d2dff7c0$789fe740$@cfbsoftware.com><br></div><div dir="ltr">Content-Type: text/plain; charset="us-ascii"<br></div><div dir="ltr"><br></div><div dir="ltr">> -----Original Message-----<br></div><div dir="ltr">> From: Oberon [mailto:<a href="mailto:oberon-bounces@lists.inf.ethz.ch" ymailto="mailto:oberon-bounces@lists.inf.ethz.ch">oberon-bounces@lists.inf.ethz.ch</a>] On Behalf Of<br></div><div dir="ltr">> Skulski, Wojciech<br></div><div dir="ltr">> Sent: Saturday, 30 September 2017 10:49 AM<br></div><div dir="ltr">> To: ETH Oberon and related systems<br></div><div dir="ltr">> Subject: Re: [Oberon] Procedure variables and local procedures<br></div><div dir="ltr">> <br></div><div dir="ltr">> Perhaps you guys could have a look at monumental work done by Robert?<br></div><div dir="ltr">> This might provide some arguments against cutting off what you<br></div><div dir="ltr">> consider dead wood, which is in fact crucial for some applications.<br></div><div dir="ltr">> <br></div><div dir="ltr"><br></div><div dir="ltr">I would not dream of using a hammer to drive in a fence post any more than I<br></div><div dir="ltr">would choose a sledgehammer to drive in a nail. Similarly, computer<br></div><div dir="ltr">languages are just tools - no one tool is suitable for all jobs. The more<br></div><div dir="ltr">you try to make one toll suitable for a different job the less suitable it<br></div><div dir="ltr">is for use with the job is was designed to do e.g. a short-handled<br></div><div dir="ltr">sledgehammer or a long-handled hammer.<br></div><div dir="ltr"><br></div><div dir="ltr">What's the point of making Oberon-07 like Component Pascal when you already<br></div><div dir="ltr">have Component Pascal?<br></div><div dir="ltr"><br></div><div dir="ltr">I would not dream of trying to use a 'bloated' language like Component<br></div><div dir="ltr">Pascal to program a single-tasking application for a microcontroller with 16<br></div><div dir="ltr">KB of RAM. I would also not attempt to use a 'crippled' language like<br></div><div dir="ltr">Oberon-07 to write a multi-tasking, event-driven GUI program running on a<br></div><div dir="ltr">system with 16GB of RAM.<br></div><div dir="ltr"><br></div><div dir="ltr">However, I do use the 'highly efficient' Oberon-07 to program<br></div><div dir="ltr">microcontrollers with 16 KB of RAM. I also use the 'extremely powerful'<br></div><div dir="ltr">Component Pascal to write GUI programs for a system with 16GB of RAM.<br></div><div dir="ltr"><br></div><div dir="ltr">Regards,<br></div><div dir="ltr">Chris Burrows<br></div><div dir="ltr">CFB Software<br></div><div dir="ltr"><a href="http://www.astrobe.com/" target="_blank">http://www.astrobe.com</a><br></div><div dir="ltr"> <br></div><div dir="ltr"><br></div><div dir="ltr"><br></div><div dir="ltr"><br></div><div dir="ltr">------------------------------<br></div><div dir="ltr"><br></div><div dir="ltr">Message: 4<br></div><div dir="ltr">Date: Sat, 30 Sep 2017 02:56:30 +0000<br></div><div dir="ltr">From: "Skulski, Wojciech" <<a href="mailto:skulski@pas.rochester.edu" ymailto="mailto:skulski@pas.rochester.edu">skulski@pas.rochester.edu</a>><br></div><div dir="ltr">To: "<a href="mailto:chris@cfbsoftware.com" ymailto="mailto:chris@cfbsoftware.com">chris@cfbsoftware.com</a>" <<a href="mailto:chris@cfbsoftware.com" ymailto="mailto:chris@cfbsoftware.com">chris@cfbsoftware.com</a>>, ETH Oberon and<br></div><div dir="ltr"> related systems <<a href="mailto:oberon@lists.inf.ethz.ch" ymailto="mailto:oberon@lists.inf.ethz.ch">oberon@lists.inf.ethz.ch</a>><br></div><div dir="ltr">Subject: Re: [Oberon] Procedure variables and local procedures<br></div><div dir="ltr">Message-ID:<br></div><div dir="ltr"> <<a href="mailto:DM5PR0701MB3672C300B9589480B3587BDBFF7F0@DM5PR0701MB3672.namprd07.prod.outlook.com" ymailto="mailto:DM5PR0701MB3672C300B9589480B3587BDBFF7F0@DM5PR0701MB3672.namprd07.prod.outlook.com">DM5PR0701MB3672C300B9589480B3587BDBFF7F0@DM5PR0701MB3672.namprd07.prod.outlook.com</a>><br></div><div dir="ltr"> <br></div><div dir="ltr">Content-Type: text/plain; charset="us-ascii"<br></div><div dir="ltr"><br></div><div dir="ltr">> I would not dream of trying to use a 'bloated' language like Component<br></div><div dir="ltr">> Pascal to program a single-tasking application for a microcontroller with 16<br></div><div dir="ltr">> KB of RAM. I would also not attempt to use a 'crippled' language like<br></div><div dir="ltr">> Oberon-07 to write a multi-tasking, event-driven GUI program running on a<br></div><div dir="ltr">> system with 16GB of RAM.<br></div><div dir="ltr"><br></div><div dir="ltr">Chris:<br></div><div dir="ltr"><br></div><div dir="ltr">this is a very interesting point. A few posts ago I implied that Oberon-07 looks like a microcontroller language. Frankly, I expected to get spanked. Now you are saying the same. Would ETH folks agree? Was Oberon not meant as a pinnacle of language design, capable of the most demanding tasks like writing compilers and operating systems? Will the authors feel offended by the word "microcontroller"? <br></div><div dir="ltr"><br></div><div dir="ltr">So is Oberon-07 intended to be a frugal general purpose language, or was it meant to be a minimalistic microcontroller language? I can hold to my opinions, but what were the authors' intentions?<br></div><div dir="ltr"><br></div><div dir="ltr">W<br></div><div dir="ltr"><br></div><div dir="ltr">------------------------------<br></div><div dir="ltr"><br></div><div dir="ltr">Message: 5<br></div><div dir="ltr">Date: Sat, 30 Sep 2017 03:07:10 +0000<br></div><div dir="ltr">From: "Skulski, Wojciech" <<a href="mailto:skulski@pas.rochester.edu" ymailto="mailto:skulski@pas.rochester.edu">skulski@pas.rochester.edu</a>><br></div><div dir="ltr">To: "<a href="mailto:chris@cfbsoftware.com" ymailto="mailto:chris@cfbsoftware.com">chris@cfbsoftware.com</a>" <<a href="mailto:chris@cfbsoftware.com" ymailto="mailto:chris@cfbsoftware.com">chris@cfbsoftware.com</a>>, ETH Oberon and<br></div><div dir="ltr"> related systems <<a href="mailto:oberon@lists.inf.ethz.ch" ymailto="mailto:oberon@lists.inf.ethz.ch">oberon@lists.inf.ethz.ch</a>><br></div><div dir="ltr">Subject: Re: [Oberon] Procedure variables and local procedures<br></div><div dir="ltr">Message-ID:<br></div><div dir="ltr"> <<a href="mailto:DM5PR0701MB367228D88B23D3D5F90A6B9DFF7F0@DM5PR0701MB3672.namprd07.prod.outlook.com" ymailto="mailto:DM5PR0701MB367228D88B23D3D5F90A6B9DFF7F0@DM5PR0701MB3672.namprd07.prod.outlook.com">DM5PR0701MB367228D88B23D3D5F90A6B9DFF7F0@DM5PR0701MB3672.namprd07.prod.outlook.com</a>><br></div><div dir="ltr"> <br></div><div dir="ltr">Content-Type: text/plain; charset="us-ascii"<br></div><div dir="ltr"><br></div><div dir="ltr">> Runtime overflows (INTEGER as well as BYTE) are not trapped in Project<br></div><div dir="ltr">> Oberon or Astrobe Oberon. In fact the Random function exploits this<br></div><div dir="ltr">> behaviour and would break if ported to a system that didn't allow you to<br></div><div dir="ltr">> turn off overflow trapping.<br></div><div dir="ltr"><br></div><div dir="ltr">Another good point! Overflowing is a crucial part of some digital filters in FPGAs. Without overflowing these filters would not work. <br></div><div dir="ltr"><br></div><div dir="ltr">Another, slightly less exotic example is a circular buffer design whose pointer must overflow in order to make the buffer circular. I use this design pattern all over my FPGA firmware. In a computer language one can use an IF statement or a modulo operator, but in the FPGA there is hardly place for such embellishments. Most often I just let the upper bit fall off. <br></div><div dir="ltr"><br></div><div dir="ltr">W.<br></div><div dir="ltr"><br></div><div dir="ltr">------------------------------<br></div><div dir="ltr"><br></div><div dir="ltr">Message: 6<br></div><div dir="ltr">Date: Sat, 30 Sep 2017 09:23:10 +0200<br></div><div dir="ltr">From: J?rg <<a href="mailto:joerg.straube@iaeth.ch" ymailto="mailto:joerg.straube@iaeth.ch">joerg.straube@iaeth.ch</a>><br></div><div dir="ltr">To: ETH Oberon and related systems <<a href="mailto:oberon@lists.inf.ethz.ch" ymailto="mailto:oberon@lists.inf.ethz.ch">oberon@lists.inf.ethz.ch</a>><br></div><div dir="ltr">Subject: Re: [Oberon] Procedure variables and local procedures<br></div><div dir="ltr">Message-ID: <<a href="mailto:66D4EA77-43ED-4830-BCAC-880D2F868A09@iaeth.ch" ymailto="mailto:66D4EA77-43ED-4830-BCAC-880D2F868A09@iaeth.ch">66D4EA77-43ED-4830-BCAC-880D2F868A09@iaeth.ch</a>><br></div><div dir="ltr">Content-Type: text/plain; charset=utf-8<br></div><div dir="ltr"><br></div><div dir="ltr">Wojtek<br></div><div dir="ltr"><br></div><div dir="ltr">> I am guessing that Chris has the above in mind. I second his opinion: without the dynamic arrays (or "open arrays") the language is crippled.<br></div><div dir="ltr"><br></div><div dir="ltr">Oberon-07 has open arrays.<br></div><div dir="ltr">Open arrays are formal parameters whose length is not known at compile time.<br></div><div dir="ltr"><br></div><div dir="ltr">Here an example in Oberon-07:<br></div><div dir="ltr"><br></div><div dir="ltr"> PROCEDURE Max(v: ARRAY OF REAL): REAL; (* ?v? is an open array *)<br></div><div dir="ltr"> VAR i: INTEGER; max: REAL;<br></div><div dir="ltr"> BEGIN<br></div><div dir="ltr"> max := v[0];<br></div><div dir="ltr"> FOR i := 1 TO LEN(v)-1 DO IF v[i]>max THEN max := v[i] END END<br></div><div dir="ltr"> RETURN max END Max;<br></div><div dir="ltr"><br></div><div dir="ltr">and use Max() with vectors of different lengths like<br></div><div dir="ltr"> v1: ARRAY 10 OF REAL;<br></div><div dir="ltr"> v2: ARRAY 88 OF REAL;<br></div><div dir="ltr"><br></div><div dir="ltr">If you would like to write a library operating on two dimensional matrices, you can do so in Oberon-07. It is left as an exercise how to implement<br></div><div dir="ltr"><br></div><div dir="ltr"> MODULE Matrix;<br></div><div dir="ltr"> TYPE<br></div><div dir="ltr"> Matrix* = POINTER TO MatrixDesc;<br></div><div dir="ltr"> MatrixDesc = RECORD<br></div><div dir="ltr"> m*: PROCEDURE (i, j: INTEGER): REAL (* m(i, j) returns an elem of the matrix *)<br></div><div dir="ltr"> END;<br></div><div dir="ltr"> PROCEDURE Allocate*(m: Matrix; dim1, dim2: INTEGER);<br></div><div dir="ltr"> PROCEDURE Initialize*(m: Matrix; f: Files.File);<br></div><div dir="ltr"> PROCEDURE EigenValue*(m: Matrix): REAL;<br></div><div dir="ltr"> END Matrix.<br></div><div dir="ltr"><br></div><div dir="ltr">As all this is possible in Oberon-07, I was wondering what dynamic arrays are.<br></div><div dir="ltr"><br></div><div dir="ltr">br<br></div><div dir="ltr">J?rg<br></div><div dir="ltr"> <br></div><div dir="ltr"><br></div><div dir="ltr"><br></div><div dir="ltr">------------------------------<br></div><div dir="ltr"><br></div><div dir="ltr">Message: 7<br></div><div dir="ltr">Date: Sat, 30 Sep 2017 11:56:41 +0200<br></div><div dir="ltr">From: chris <<a href="mailto:chris@gcjd.org" ymailto="mailto:chris@gcjd.org">chris@gcjd.org</a>><br></div><div dir="ltr">To: ETH Oberon and related systems <<a href="mailto:oberon@lists.inf.ethz.ch" ymailto="mailto:oberon@lists.inf.ethz.ch">oberon@lists.inf.ethz.ch</a>><br></div><div dir="ltr">Subject: Re: [Oberon] Procedure variables and local procedures<br></div><div dir="ltr">Message-ID: <<a href="mailto:20170930115641240305.32164927@gcjd.org" ymailto="mailto:20170930115641240305.32164927@gcjd.org">20170930115641240305.32164927@gcjd.org</a>><br></div><div dir="ltr">Content-Type: text/plain; charset=iso-8859-13<br></div><div dir="ltr"><br></div><div dir="ltr">On Sat, 30 Sep 2017 02:33:16 +0200, J?rg wrote:<br></div><div dir="ltr">>> VAR b : BYTE; i : INTEGER;<br></div><div dir="ltr">>> i := 1000; b := i;<br></div><div dir="ltr">>> <br></div><div dir="ltr">>> Does it trap for overflow?<br></div><div dir="ltr">> <br></div><div dir="ltr">> The compiler does not generate a trap. It moves the lowest byte of i <br></div><div dir="ltr">> to b. See first IF in ORG.Store.<br></div><div dir="ltr"><br></div><div dir="ltr">Well, that is considered good style? In my opinion this kind of low <br></div><div dir="ltr">level action should not be in the base language. If it's defined to be <br></div><div dir="ltr">"least significant byte" that would be a bit better, but this could <br></div><div dir="ltr">result in some surprise on different hardware.<br></div><div dir="ltr"><br></div><div dir="ltr">Leaving this undefined in the language report makes the type BYTE an <br></div><div dir="ltr">unusable feature for portable programs.<br></div><div dir="ltr"><br></div><div dir="ltr">> Would you please explain ?dynamic arrays?? Do you miss the low level <br></div><div dir="ltr">> SYSTEM.NEW(p, n)?<br></div><div dir="ltr"><br></div><div dir="ltr">I mean things like:<br></div><div dir="ltr"><br></div><div dir="ltr">TYPE<br></div><div dir="ltr"> CharPtr = POINTER TO ARRAY OF CHAR;<br></div><div dir="ltr">VAR<br></div><div dir="ltr"> p : CharPtr;<br></div><div dir="ltr">BEGIN<br></div><div dir="ltr"> NEW(p, 1234);<br></div><div dir="ltr"><br></div><div dir="ltr">There is nothing low level here. That is a widely used feature in ETH <br></div><div dir="ltr">Oberon (System 3) or whatever you call it today. What is wrong with <br></div><div dir="ltr">this? Even if I had to write a string librarary for UTF8 I would use <br></div><div dir="ltr">this feature for the buffers internally and not linked list of fixed <br></div><div dir="ltr">(compile time determined) sized pieces.<br></div><div dir="ltr"><br></div><div dir="ltr">Greeting, chris<br></div><div dir="ltr"><br></div><div dir="ltr"><br></div><div dir="ltr"><br></div><div dir="ltr">------------------------------<br></div><div dir="ltr"><br></div><div dir="ltr">Subject: Digest Footer<br></div><div dir="ltr"><br></div><div dir="ltr">--<br></div><div dir="ltr"><a href="mailto:Oberon@lists.inf.ethz.ch" ymailto="mailto:Oberon@lists.inf.ethz.ch">Oberon@lists.inf.ethz.ch</a> mailing list for ETH Oberon and related systems<br></div><div dir="ltr"><a href="https://lists.inf.ethz.ch/mailman/listinfo/oberon" target="_blank">https://lists.inf.ethz.ch/mailman/listinfo/oberon</a><br></div><div dir="ltr"><br></div><div dir="ltr"><br></div><div dir="ltr">------------------------------<br></div><div dir="ltr"><br></div><div dir="ltr">End of Oberon Digest, Vol 160, Issue 26<br></div><div dir="ltr">***************************************<br></div><br><br></div> </div> </div> </div></div></body></html>