[Oberon] Trivialising formality considered harmful
fusionfive at comhem.se
Thu Mar 16 04:15:37 CET 2006
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
>>"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
>>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
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.
> 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
> 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
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
>>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
> 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. :-)
More information about the Oberon