Article View: comp.lang.oberon
Article #1192Re: Language "purity" and the ETH (was: bitwise and & or in Oberon?)
From: Peter Froehlich
Date: Sun, 24 Mar 1996 16:42
Date: Sun, 24 Mar 1996 16:42
60 lines
3690 bytes
3690 bytes
Hi!
On Di 19.03.1996 around 08:13:32 ludwig@inf.ethz.ch (Stefan Ludwig) wrote
in message "Language "purity" and the ETH (was: bitwise and & or in Oberon?)":
> > There are no technical problems in implementing an Oberon compiler for
> >another system, eg. the Amiga. But you have to change the language for
> >this, sometimes even outside Oakwood-style EXTERNAL interfaces, which makes
> [...]
> You can always define interface modules in pure Oberon,
> which encapsulate the underlying system interface by accessing it via SYSTEM.
> It's possible, safe and works very well.
It's just not very efficient to pass my arguments on the stack first
just to have the interface routine stash them into registers and make a
SYSTEM call.
Oakwood should have defined that "EXTERNAL" means "_really_ far removed
from Oberon". The situation now is that for efficient interfacing we have
to extend the language but can't properly "mark" the module as unportable.
> > IMHO the ETH position still contributes to the lack of such a wave. But
> > I guess we could argue this point endlessly.
>
> What position is that? What has been true three years ago must not be true
> today.
I think the position I spoke of is pretty clear to most of us: The ETH
gives us a language and that's it. No further discussion needed.
I was going to argue about the "what was true" thing when I noticed that
you _might_ indicate that the ETH position is changing. Is that so? Is
there hope for a ETH workgroup getting together with "us out here" to work
on Oberon-3?
> Who wants what? I don't see much initiative in the industry working towards
> a standard (with or without ETH's consent). If you out there want to change
> something, get together, organize yourself, propose something, talk to the
> creators.
I work on a proposal/evaluation of language features (and you know it
:-) and would happily contribute the results to a "Standard for Oberon"
project. But I feel that someone else would have to take the lead, since I
fear noone takes "a mere student" seriously.
> It shouldn't be too difficult to standardize the language once
> and for all, incorporating the experience gained over the past 9 (nine!) years.
Who's talking about "once and for all"? A standard is needed, call it
Oberon-96 or whatever. This would by the reference for some years. But at
least I want to see it updated every 5 years or so.
> We're *using* the language and the
> system to develop applications.
I still hope that _some_ ETH involvement in such a process would happen.
It somehow makes me sad to "take away" their language.
_
By(T)e... /| _ //3000 /\ People who use Pascal for serious programming |\
Peter... \| \X/\miga \/ fall into a fatal trap. (Brian W. Kernighan) |/
Technical Details
Message-ID:
<22494A72H0006B6C1H@p.froehlich.amc.cube.net>Path:
arc1-ca.pugleaf.net!amc.cube.net!p.froehlichReferences:
<Pine.3.87.9602261044.A21326-0100000@mbox1.ufsc.br> <222F7E07H00075301H@p.froehlich.amc.cube.net> <1996Mar6.154313.1@fermi.nsrl.rochester.edu> <22406A0BH000EA602H@p.froehlich.amc.cube.net> <4ilmqs$dvr@lillian.inf.ethz.ch>Show Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!amc.cube.net!p.froehlich From: p.froehlich@amc.cube.net (Peter Froehlich) X-Newsreader: -- The Answer V3.06 Newsgroups: comp.lang.oberon Subject: Re: Language "purity" and the ETH (was: bitwise and & or in Oberon?) Date: Sun, 24 Mar 1996 17:42:10 +0100 Message-ID: <22494A72H0006B6C1H@p.froehlich.amc.cube.net> Organization: AMIGA CITY - Public Amiga-BBS, Munich, Germany References: <Pine.3.87.9602261044.A21326-0100000@mbox1.ufsc.br> <222F7E07H00075301H@p.froehlich.amc.cube.net> <1996Mar6.154313.1@fermi.nsrl.rochester.edu> <22406A0BH000EA602H@p.froehlich.amc.cube.net> <4ilmqs$dvr@lillian.inf.ethz.ch> X-Gateway: ZCONNECT ?? amc.cube.net [Z-NEWS 2.5d/AMIGA] X-REPLY-LEVEL: 1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit MIME-Version: 1.0