February 2018 - Oberon - mailman3.inf.ethz.ch

A CASE quiz
by Chris Burrows 17 Feb '18

17 Feb '18

I have attached two copies of a CASE statement which implements part of the Soundex algorithm. Assume that both compile OK but both have at least one identical logical error which you may not have noticed if I hadn't warned you. Which version do you think would be more effective in flushing out the error if the programmer was not aware of his mistake? I put my money on the one without the ELSE . Regards, Chris Burrows CFB Software http://www.astrobe.com/RISC5

4 7

Intermediate scopes in Oberon-07
by Andreas Pirklbauer 17 Feb '18

17 Feb '18

Note that an experimental implementation that a. allows the *declaration* of local constants, types, variables b. disallows *access* to intermediate constants, types, variables is at: http://github.com/andreaspirklbauer/Oberon-no-access-to-intermediate-objects I provide it *only* for discussion purposes. I would prefer eliminating local procedures altogether (as it would eliminate the very questions of whether one should allow declaring or accessing them). But if local procedures are here to stay (it looks like it), then I want to at least treat *all* intermediate objects in the same, consistent way.

2 1

Re: [Oberon] A CASE quiz
by Josef Templ 17 Feb '18

17 Feb '18

Sorry, but for me this example is not convincing. If you want to catch this kind of programming errors as early as possible, you should not allow any gaps at all but flag this as a compile time error. Unfortunately, this may turn out to be inconvenient in other examples. In addition, what if the programmer forgets to include the minimum or maximum label? It is not possible to catch all kinds of programming errors at compile time. If you leave it to run-time checks, there is not much difference between the versions. SoundEx is typically used for a fuzzy search, i.e. searching for something 'similar'. On an embedded target it may actually be better to have a poorly working SoundEx function than a trap. But this is of course SoundEx specific and debatable. To summarize, I would not draw any general conclusions from this single constructed example. - Josef

1 0

CASE without ELSE
by Andreas Pirklbauer 17 Feb '18

17 Feb '18

> The increase in size of the compiler sources is about 250 lines > of code, i.e. an increase of 7%. It is a non-trivial addition. That’s pretty significant relative to the size of the Oberon compiler (in other languages it would be considered negligible) > Compiles are typically about 10% faster after implementing > the PO2013 Oberon compiler scanner function ORS.Get as > a CASE statement. In other compilers a 10% speedup would be quite noticeable (one coffee less to grab during compilation), but not in Oberon where compilation already is near-instantaneous. PS: I believe this is the only place in the Oberon system where one would see a measurable performance gain (here 10%) speedup (correct me if I’m wrong)

2 1

CASE without ELSE
by Andreas Pirklbauer 16 Feb '18

16 Feb '18

> My interpretation of what might have happened is this: > In Oberon07 the numeric CASE had been dropped, but later > it has been reintroduced but the ELSE has been forgotten. That’s one possibility. Another possibility would be that it was dropped but the grammar was not fully restricted to the non-numerical case, i.e. only the ELSE was removed but not the fact that that case expression can an integer. Either way, we now have a language spec that contains the numerical case, but an implementation that doesn’t. > To me, a numeric CASE without an ELSE is pointless. Agreed. It was the absence of the ELSE clause and the fact that the numeric case hadn’t been implemented in PO2013 for ~5 years now that caused me to believe that the intended main use of the CASE statement is with records and pointer types (i.e. to check extension levels), where the ELSE clause is indeed not needed, since it is implicit if the base type appears as the last case. > My conclusion so far is: If the numeric CASE is not > implemented but only specified, it should not be > taken literally. Extensions levels are (internally) also numbers of course ;-)

2 1

CASE without ELSE
by Andreas Pirklbauer 16 Feb '18

16 Feb '18

> I know that the code below can not be compiled as ORP.Mod did not > implement the numerical case (yet) but it is valid Oberon-07 code. > Jörg Is it possible that the reason why the numeric case is not (yet?) implemented is that it will eventually be eliminated from the language? After all, in PO2013 all CASE statements where the type of the case expression is integer or char have been replaced with cascaded IF’s.

1 0

CASE without ELSE
by Josef Templ 15 Feb '18

15 Feb '18

Hi everybody, recently I noticed that there is no ELSE clause in the CASE statement of the latest Oberon language version. Has this been removed intentionally or accidentally? Or is there something new instead of it? If it has been removed intentionally: Is there a significant simplification in the compiler or a speedup at runtime? On the other side, it puts some burden onto the programmer to work around it. As an example: I tried to implement a simple command interpreter that reads a character from a serial line (connected to a keyboard) and executes a related procedure in an embedded target. The natural language construct, I thought, would be a CASE for that kind of problem. Pressing an invalid key could be ignored easily by the ELSE clause of the CASE. - Josef

6 10

CASE without ELSE
by Andreas Pirklbauer 15 Feb '18

15 Feb '18

> Hi everybody, > > recently I noticed that there is no ELSE clause in the CASE statement of > the latest Oberon language version. > Has this been removed intentionally or accidentally? Or is there something > new instead of it? > > ... > > - Josef Josef, 1. The numeric case, i.e. where the type T of the case expression (case variable) is of type INTEGER or CHAR, is not actually implemented in Oberon 2013. As a consequence, one now needs to use e.g. an IF statement instead. 2. Only the case where the type T of the case expression (case variable) is a RECORD or POINTER type is implemented in Oberon 2013. In this case, the case labels must be extensions of T. This is typically used in installed handler procedures in the Oberon viewer system - which now seems to have become the intended main use of CASE. Now one can why there is no ELSE clause: If the type T of the case expression is a RECORD or POINTER type, the ELSE can always be simulated by simply specifying the *base* type of T as the *last* element in the case list. .. as in MenuViewers.Handle: CASE M OF Oberon.InputMsg: ... | Oberon.ControlMsg: ... | Oberon.CopyMsg: ... | Display.FrameMsg: .. (*this is in fact the ELSE clause*) END One just needs to get the order right: extended types first, base type last (if one placed the base type at the beginning of the list, it would always evaluate to TRUE even if M were an extension of T) Andreas

1 0

Project Oberon / RISC-V Linux
by Peter Matthias 14 Feb '18

14 Feb '18

Hi all, for those who are interested, a working (except traps) RISC-V version is available at http://oberon.wikidot.com . Regards, Peter

1 0

Intermediate scopes in Oberon-07
by Andreas Pirklbauer 11 Feb '18

11 Feb '18

> Wirth tries very hard to avoid so called "type explosion”. > Therefore, he rather declares a single record with very > generally usable fields than a hierarchy of record types. > And fewer type declaration in total also means fewer local ones. For the compiler, the rationale for the decision to use such multi-purpose fields is explained in ch 12.3.1 on p.29 of: www.inf.ethz.ch/personal/wirth/ProjectOberon/PO.Applications.pdf <http://www.inf.ethz.ch/personal/wirth/ProjectOberon/PO.Applications.pdf> But at least for the compiler, there is another reason for using the rather compressed representation using multi-purpose fields: to minimize memory usage! For example, the length of record type ORB.Object is 56 bytes, to which procedure NEW will add 8 bytes (for the type tag and the mark field) for a total of 64 bytes. If one adds even a single field to this one record, memory usage would double to 128 bytes for *each* allocated heap record (it’s how heap blocks are implemented in PO2013: 32, 64, 128, n*256). Given that even for small modules there are typically hundreds of identifiers in the symbol table (mainly because of imports), it’s easy to increase heap usage by a few hundred KB, depending on the size of the modules being compiled. And THAT makes a big difference on a machine with only 1 MB of memory (as used by PO2013) and a heap size of 415KB. I once did a small experiment and found that it can easily break the compiler on more than one occasion. BUT: Such implementation considerations - which in addition are completely irrelevant on machines with larger memories - don’t belong to a discussion about programming styles. But historically, such considerations were important - as everyone who has worked on machines such as the PDP-11 will remember :-)

1 0