[Oberon] Trivialising formality considered harmful

[John Drake]

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

> John Drake wrote:
> > 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).

Now that you mention it, I vaguely remember this.
I have no experience with MinGW but could try 
that out.  Were you able to get the VisualOberon
library working with it?
 
> 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 would choose the one that did what I needed.
We have to be carefull not to put too much stock 
in the Oakwood document.  It's not the 
equivalent of "ANSI-C" but rather a set 
of recommendations.  Here's what one the the 
people who were there had to say:

http://groups.google.com/group/comp.lang.oberon/browse_frm/thread/e2aa296ee0922af6/122e3eabf576c658?q=Oakwood+purpose&rnum=2#122e3eabf576c658
================================================
It may be helpful to clarify the purpose of 
the Oakwood Guidelines.  They came out of a 
meeting of about 30 compiler developers, 
vendors  and users in June '93. The idea was 
to gather language clarifications, 
proposed extensions and implementation 
recommendations with the aim of reducing 
unneccessary differences between Oberon 
compiler products on the market.  The meeting 
and discussions ran for 2 days followed by a 
day of consolidation by a small group, 
including several ETH people.  The guidelines 
report was written as a summary of the meeting 
and incidentally includes a recommendation for 
a set of library modules that are compatible 
with the ETH books and the ETH Oberon System,
they can also be implemented on any other 
system. These modules are not based in any 
way on the ISO Modula-2 library modules.
The contents of the guidelines were reviewed 
several times by ETH before publication.
The Oakwood Guidelines are published by the 
BCS and RTA in the Modular Mag, which is the 
journal of the Modular Languages Group
of the BCS. 

Brian Kirk 
==============================================

Now, I think Mr. Kirk's assertion that the
library recommendations were "not based in 
any way on the ISO Modula-2 library modules"
is not 100% accurate.  Clearly module Strings 
came directly from the Modula-2 libraries.  
Still this illustrates the point that the 
Oakwood libraries were never codified as 
the "end all be all" of standard libraries.  
Trying to "force" compiler writers after 
the fact to use the Oakwood version of 
Strings or Files just isn't going to happen.  
(In, Out and XYPlane were already pretty much
uniform anyway).  

Sure, you can write your own compiler from
scratch if you wish and make it 100% 
Oakwood compliant down to every recommended
library and extension.  If that's what
you want to do, I wish you luck.  But
I'm more interested in moving forward
a set of portable libraries that people
can use with the Oberon-2 compilers that
already exist.  That means acknowledging
the fact that names like "Files" and
"Strings" are typically already taken.

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

If there was an ANSI/ISO Oberon committee
it could make such a declaration.  But there
isn't one.

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

Changing the Oakwood guidelines isn't such a bad
idea.  That would be easier than trying to get
all of the compiler writers to change.

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

And hence we end up with the situation we have
now thanks to everyone trying to fix the 
"confusion". ;)  Seriously, from the early
days you were able to use Oberon with Linux and
other versions of Unix.  I used to use the Oberon
operating system on top of Solaris all of the
time.  I could use a telnet Window inside of
Oberon to to issue Unix commands, and then 
save all of the commands and output easily
as an Oberon Text.  It was like EMACS on
steroids.  

But people thought the only way you could get
others to use Oberon was to seperate it from
it's system.  That's fine and dandy, but
you have to consider what gets lost.  For
instance I remember in the early days some
people would argue that you didn't need a
String library because you had module "Texts".
Well, that's fine and good until you go to
a "command line" version of Oberon that
doesn't include module Texts (for obvious
reasons) but you wrote your program to take
advantage of something that's no longer there.

So the challenge to day is to build up a
library set that various Oberon programs
working with various compilers and/or systems
can find usefull.  I guess I'm not as 
concerned about other people's perceptions
of Oberon as I am with what I can do with
it.  I have the belief that "If you build
it, they will come."  There's functionality
that we don't have across all Oberon 
compilers that we should have.  
 
> > 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

Thanks!  I'll work on an RFC for the idea.

Regards,

John M. Drake

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