[Oberon] Trivialising formality considered harmful

[John Drake]

--- August Karlstrom <fusionfive at comhem.se> wrote:

> John Drake wrote:
> > 
> > --- easlab at absamail.co.za wrote:
> 
> [snip]
> 
> > A concrete example.  It's irritating to me
> > that the ETH Math module uses lower case for
> > the procedure names.  
> > 
> >
>
http://www.oberon.ethz.ch/ethoberon/defs/Math.Def.html
> > 
> > It's doubly irritating when one considers
> > that there was no rational reason for this.
> 
> One reason may be that these functions are commonly
> written in lower 
> case in mathematics. Moreover it feels kind of
> awkward to write e.g. 
> arcsinh (arcus sinus hyperbolicus) as ArcSinH. To
> use Arcsinh would be 
> inconsistent.

Well you make a good point.  But then that
further illustrates the difficulty of having
a hard fast "rule" for capitilization.  

> > The ETH Math module is moduled off of the
> > Modula-2 ISO math module which uses upper
> > case.  Also Math procedures are upper case
> > in the Oakwood guidelines (the one and only
> > serious attempt to standardize Oberon compliers
> > and libraries.)  
> > 
> > http://www.comp-inspirations.com/docs/oakwood.pdf
> 
> No, the Oakwood math procedures are in lower case
> for sure.

Oops, my bad.  Oberon/F (now BlackBox Component
Pascal) uses uppercase math procedures so mabye
that's how I got my wires crossed.
 
> It's ironic that despite the relative smallness and
> simplicity of Oberon 
> and the Oakwood libraries, as far as I know, there
> is *not a single* 
> freestanding Oakwood conforming Oberon(-2) compiler.
> Not even Oakwood 
> library conforming.

Hmmmm...I'm curious as to what things you think
are non compliant in a typical Oberon-2 compiler
like Pow for instance.  The extensions (like
COMPLEX) are, of course, optional.  I don't
know of a single Oberon-2 compiler that isn't
compliant with what's written in the core
part of the Oakwood document (which is
basically the Oberon-2 language report).

Most compilers/systems I've used at least
the Oakwood modules In, Out and XYPlane.  
Typically Math and MathL are also there.
Module Strings is where things get a bit
hairy.  BlackBox and Linz V4 are compliant.
ETH and Pow are not.  OOC implemented
Strings, Files, In, Out, Math and MathL.
(Basically everything except Input
and XYPlane).  I like the way they
named the modules, prefixing everything
with "Oak".

http://ooc.sourceforge.net/OOCref/OOCref_toc.html

> What the language needs is a complete Oakwood
> compliant compiler that 
> supports standard Oberon-2 and nothing else! If you
> want lots of extra 
> features you can go Java and I don't see why you
> appreciated Oberon in 
> the first place. (Here, "you" is of course a general
> "you").

Well, such a dogmatic approach doesn't even comply
with the Oakwood document. 

=================================================
The name Oberon has been trademarked by ETH in 
the context of the operating system and the 
language.  In order to respect the ETH trademark 
any compiler that does not at least implement 
ETH Oberon or Oberon-2 should not be referred to 
or named as an Oberon or Oberon-2 compiler.
When referring to features of ETH Oberon 
in documentation it is acceptable to use 
the terms Oberon or Oberon-2.  However when 
referring to any compiler specific extensions 
the term Oberon should be qualified with 
an adjective.  For example :  "XYZ Oberon-2 
supports complex numbers"
=================================================

So as a pratical example, Active Oberon is
Oberon-1 compliant, though not Oberon-2.

Anyway, rather than trying to control the
compilers (that will never happen, unless
you write your own) I see the practical
way forward as compiling a library of 
modules without compiler/system 
dependencies, or where such dependencies
have been isolated as much as possible.

For example, because I detest the ETH
Strings and Dates library, I've copied
the source over from V4 and recompiled.
Since these modules don't have any
underlying system dependencies they
can be recompiled under System 3
without any problems.  This is a project
I've thought about for years, but never
undertook.  I (kind of) abandoned the
idea as I saw further divergence among
the compilers themselves.  (Active
Oberon for instance being the current
focus at ETH.)  But in retrospect I
think such a project is still usefull.
For one thing there's still a lot of
Oberon-2 work going on out there.  For
another compilers like AO are still
Oberon-1 compliant, and there's a lot
of room for Oberon-1 libraries.  (All
of the Oakwood modules are really 
Oberon-1 for example.)

> > FAR more irritating to me are the ETH modules
> > Strings and Dates.  While they got the cases
> > right, they got the functionality wrong IMO.
> > I started to include what I don't like about
> > them in this reply, but I realized that would
> > make it too long. ;)  I'll put that in a 
> > seperate post.
> 
> Please, do! The only oddities I have noticed are the
> procedures In.Open 
> and Out.Open. On mainstream operating systems the IN
> and OUT streams are 
> always open.

I'll go ahead and mention a couple of irritants in
module the ETH module Strings.  There's no "Extract"
procedure as specified in the Oakwood document.
So there's no way to pull out substrings.  Also
Module Strings includes things that it shouldn't
like "StrToDate".  The problem with that is that
makes Strings have to import Dates.  Since Strings
is included in the kernel, that means Dates also
has to be in the kernel.  It would make more since
to have the formatting of Dates in module Dates
rather than in module Strings.
 
> [Chris Glur said:]
> >>The only way to advance is to delegate the initial
> >>decisions [eg. the
> >>syntax of identifiers- uppercase..start-char
> >>...etc.] to agreed rules,
> >>to free-up mental creativety for REAL decisions.  
> 
> I agree 100 percent.

So then what happens with things like Math.arcsinh?
If this is a compiler decision then there's no
choice but to make it Math.ArcSinH.  It doesn't
bother me either way (all lower case, or
capitalized), but I think a compiler enforced
convention would in general cause as many problems
as it "fixed".

> > And yet every other programming language on the
> > planet has people making all sorts of creative
> > "REAL" decisions without resorting to
> > artificially forcing a case convention.
> 
> I don't see anything artificial about it. If I want
> to use a library 
> that has its own conventions, I have to waste time
> and study those 
> conventions and if my client module uses libraries
> with different 
> conventions the program text will be inconsistent
> (and look ugly as 
> well). 

How much time is really "wasted"?  To use a 
library you still have to look up the definitions
REGARDLESS of whether or not there is a compiler
enforced caps convention.  You have to know the
correct spelling of the procedure as well as the
types of all of the arguments and the return
type.  For me it takes no extra time to notice
whether or not something is capitalized.  As
for what's "ugly" that's a matter of taste.
After all you brought up a reason why someone
might want lowercase math functions, even 
though I didn't think of that.  But the only
way someone could do that and have a compiler
enforced standard is if they made all function
names be LOWER case.  (Which flies in the face
of all Oberon tradition).  I think it's good
to have conventions.  I prefer to write my 
code that way.  But I also prefer compiler
simplicity and flexibility.  Maybe 
capitilzation conventions could be built
into an enhanced editor.  For instance there
are already editors that can do things like
"bold keywords".  Then if someone is not 
following a convention because they're being
"lazy" the convention will be forced on them,
but if they have a "reason" for deviating, they
still have the choice.

Regards,

John M. Drake



__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com