[Oberon] Trivialising formality considered harmful

[August Karlstrom]

John Drake wrote:
> 
> --- August Karlstrom <fusionfive at comhem.se> wrote:
> 
> 
>>Common mathematical functions (with long traditions)
>>are about the only 
>>acceptable exception I can think of. I wonder if the
>>math function 
>>"dilemma" alone made the Java designers go with
>>camel case (as opposed 
>>to Pascal case) for methods. On the other hand, the
>>more I think about 
>>it, there is really nothing wrong with e.g. ArcSinH
>>(or even ASinH), 
>>it's more a question of what you are used to.
> 
> 
> I think the Java case decision has more to do with
> being "C-like" than anything else.

I'm not so sure about that. When it comes to methods Java uses long 
spelled out names with separated words (by capitalization). The original 
C tradition regarding functions is to use short abbreviated names in 
lowercase with no hint about the individual words (no underscores).

>>The Oakwood modules were removed from OOC a couple
>>of releases ago. OOC 
>>uses the names "Strings", "Files" etc. but these
>>modules are more or 
>>less incompatible with the Oakwood modules.
>>Confusion encouraged. ;-)
> 
> 
> Hmmm...then their web manual is out of sync 
> with their release.  

Yes, and very much so.

> I've in the opposite 
> boat as you and can't comment much about OOC
> because I'm pretty much stuck in a Windows
> world.  (Wondering what it would take to
> run OOC under Cygwin?)

I have successfully installed OOC under Windows with MinGW (instructions 
by Stewart Greenhill are included in the OOC package).

>>Here is how I see it:
>>
>>There is a standard for the Oberon-2 language,
>>namely the reports "The 
>>Programming Language Oberon-2 (March 1995 ed.)" and
>>"The Oakwood 
>>Guidelines for Oberon-2 Compiler Developers". The
>>Oakwood guidelines and 
>>in particular the Oakwood libraries may not be
>>perfect, but they allow 
>>developers and students to write portable programs.
>>If a compiler writer 
>>who develops an Oberon-2 compiler called "ABC" wants
>>to include some 
>>fancier versions of the basic modules, the natural
>>names for those are 
>>"AbcStrings", "AbcFiles" and so on. The Oakwood
>>modules shall not be 
>>renamed. If they are the portability is lost. I
>>think I'm really stating 
>>the obvious here.
> 
> 
> The problem with that idea is that you
> can't enforce it.  Perhaps the Oakwood 
> folks should have named their modules
> "OakFiles, OakStrings" ect to begin with.
> Also one should consider the fact that there
> were already compilers in existence with
> libraries named "Files" and "Strings" ect
> before the Oakwood recommendations were
> made.  So even if implementers WANTED to
> go along with this, they'd have to risk
> breaking compatibility with already existing
> code.

I think the standard modules should use the short names. Without 
background information, if you were to choose between two modules: Files 
and OakFiles, which one would you guess is the standard module for 
dealing with files? Probably the former.

I'm sure there were libraries named "string" and "time" etc. in 
existence when the ANSI/ISO C specification was released. Sometimes we 
need to start afresh. Moreover, thanks to the excellent design of 
Oberon, the find/replace operation of module names in client modules can 
easily be automated.

> Thankfully there's an easy work around.
> Simply name Oakwood compliant modules
> "OakFiles" ect, then change the name
> on import.
> 
> IMPORT
>    Files := OakFiles;
> 
> That way if someone has written a module 
> that expects an Oakwood compatible "Files"
> module they can still do so without 
> A) having to change their code and B) 
> running into a conflict with a library
> that came with there compiler/system.

This requires that the Oakwood libraries are always prefixed with Oak. 
In that case the Oakwood guidelines need to be changed. If the Oakwood 
libraries are named according to the guidelines

    IMPORT Files := OakFiles;

needs to be changed to

    IMPORT Files;

> The challenge for Oberon's portability is that
> it's more than just a language.  Oberon is
> at once a language, an operating system,
> a development enviornment, and a research
> project.  

I think this "confusion" is the main reason why Oberon has not become a 
mainstream language. Some people may think that they have to use the 
Oberon OS to use the Oberon language. The Oberon OS is nice, but it's 
obvious that it can never become a mainstream OS that replaces Linux or 
Windows. Moreover, there seems to be a common misconception that Oberon 
with its heritage from Pascal is a restricted language only useful for 
educational purposes.

>>But anyway, 
>>that will only solve the problem for myself. I want
>>to be able to 
>>recommend the Oberon programming language to others
>>and I want them to 
>>be able (or even encourage them) to write portable
>>programs.
> 
> 
> I guess I should have been clearer.  We need an
> Internet based repository of portable libraries.
> We need both source portability and interface
> portability modules.  An example of a source
> portability module would be Strings since that
> doesn't require any low level or "foreign" calls.
> And interface portable example would be Files,
> since such an implementation requires either
> low level calls.  In such cases we could have
> multiple reference implementations (as many
> as necessary to cover all systems.)  Some 
> modules might not have complete system coverage 
> from the start, but people could add modules with
> the same interface over time.

Excellent idea. I'm in. :-)


August