[Oberon] IMPORT Modules: why does order matter?

[Till Oliver Knoll]

Am 03.03.19 um 11:38 schrieb Chris Burrows:
>> -----Original Message-----
>> From: Oberon [mailto:oberon-bounces at lists.inf.ethz.ch] On Behalf Of
>> Till Oliver Knoll
>> Sent: Sunday, 3 March 2019 7:31 PM
>> To: oberon at lists.inf.ethz.ch
>> Subject: Re: [Oberon] IMPORT Modules: why does order matter?
>>
>> But still: the times that I keep adding a "superfluous" ; at the end
>> of the "last statement" (and where the compiler is furiously bitching
>> at me with a short "no end" compiler error) also far exceed the
>> number that I'd wish for ;)
>>
> 
> Using semicolon as a null *statement* after the last statement in a
> statement sequence *is* allowed. Pascal programmers might also be surprised
> to know that they can now include a semicolon as a null statement before an
> ELSE. What I suspect you might be trying to do is insert a semicolon before
> the END following a RETURN?
> 
> Oberon's RETURN *statement* that could be inserted anywhere in a statement
> sequence was (thankfully) eliminated in Oberon-07.

Yes, I meant exactly that. Whereas it was always possible to skip the ;
after the last statement, as e.g. in

  IF something THEN
    someStatement (* no ; here *)
  END

(and was probably even considered "good style", because the compiler
might even insert a "null statement" after the someStatement otherwise),
the compiler now really bit me after some randomly left (back in the
days) ; after the last return "statement", which is now - as you say -
newly an expression (as there is no such thing as "return statements"
anymore).

And yes, I consider return statements in the middle of (usually also too
long) functions an anti-pattern, something which I always intuitively
avoided (well, not in my "GigaDraw" student exercise ;)) during my
engineering career so far. And you usually have a hard time explaining
to your colleagues why to avoid such "bail out in the middle of nowhere"
statements.

The occasional "bail out early"-return statement might be okay, at the
very beginning of some function, as it might help increas code
readability (by avoiding an additional nesting level). But even that I
usually avoid by still going for this additional IF ... THEN nesting level.



Cheers, Oliver