[Oberon] Trivialising formality considered harmful

[John Drake]

--- 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 can't comment on POW since it's a Windows
> application and I'm using 
> Ubuntu GNU/Linux. I'm also mainly referring to the
> Oakwood libraries. 
> Basically, what I'm looking for is an actively
> developed free-standing 
> open source (preferably cross platform) command line
> Oberon-2 compiler 
> that comes with the Oakwood libraries. I want to be
> able to write 
> portable programs and I want to be able to choose
> freely between text 
> editors (presently Emacs would be my choice).

> 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.  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?)
 
> 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.

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.

That's what I do when using Strings
under ETH Oberon.

> It's perfectly OK to implement the extensions
> described in the Oakwood 
> guidelines or some other extensions, but I think a
> special compiler 
> flag/option should need to be used to compile a
> module that uses these 
> extensions, e.g. "--with-oak-extensions" or
> "--with-abc-extensions".

Well BlueBottle and Native Oberon require you to
use the "/2" extention if you have Oberon-2
specific code.  Oberon-1 code and "Active" 
Oberon code compile without a switch.
 
> Anyway, Oberon-2 is an excellent design as it is.
> Let's use it! 
> Personally I don't need additional experimental
> features. I would like 
> Oberon to be (as least) as portable as C.

I think C's "portability" is vastly overrated.
But I understand your point.  At one time
Oberon was extremely portable.  In fact it
was the most portable language/system I knew.
That's back when the original Oberon 
operating system was ported to MS-DOS,
Mac, Linux, Solaris ect.  

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.  Some people liked the language
but not the system aspect and hence you
have divergence.  On the research side 
there's the ever present need to do
"accademically interesting" work and hence
more divergence.  At this point there's
no way to put the proverbial genie back
in the bottle. (Or BlueBottle heh heh).

> That's a good idea. I've actually started doing just
> that. The 
> compiler/system dependencies are unavoidable as long
> as there are no two 
> compilers that support the Oakwood way to interface
> to C.

Well, when I was talking "System dependencies" I was
meaning "System 3 versus V4 versus OOC" rather than
"C/Pascal/whatever foreign module".  You still have
dependencies to deal with as far are foreign modules
are concerned regardless of whether there is a
standard way to call them.  For instance the "Unix"
foreign module you're calling might not be available
under Windows.

I agree it would be nice if everyone did this the
same.  Of course this statement from the Oakwood
document might have given compiler writers pause:

=============================================
The  following proposal has not been fully 
tried out however it is offered as a basis 
for discussion.
=============================================

> 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.

Regards,

John M. Drake

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