AlFreed at ohio.net
Tue Mar 28 00:06:52 CEST 2006
Zonnon started as an experiment, i.e., Oberon for .NET.
Zonnon has been funded by Microsoft. Their intention was,
and still is, to have a compiler for Visual Studio that is in the
Pascal family of languages, and that makes maximum use of
the Common Language Runtime (CLR), which is Microsoft's
commercial implementation of the Common Language
Infrastructure (CLI) specification. The CLI specification is an
international standard for creating development and execution
environments in which languages & libraries work together
seamlessly. At least that is the design philosophy behind .NET.
So, the advantage of Zonnon is that you are able to import
modules written in any other languages, where there exists
compilers that compile down to the CLR. There are about
a dozen or so such languages right now, and will likely be
many more in the near future - Zonnon amongst them.
Why is this important for me? Because I can work on projects
with people who prefer to program in other languages, and I
in a language of the Pascal family. Also, the .NET framework
has a huge standardize library that I can make use of, thereby
minimizing the code I have to write. Novell's MONO platform
is an open-source implementation of the same international
standard that the .NET framework is based upon. MONO is
currently targeted for UNIX, Linux, Mac and Windows platforms,
which means that programs written for MONO, which should
also run in .NET, will be able to not only make use of code written
in numerous different languages, but it will also be able to
run on the major platforms of today. This is why I'm spending
the time to learn Zonnon, and to assist Eugene Zueff and others
at ETH in the debugging of their compiler. There is also the
fact that I really like the logic behind Zonnon - I like how it
makes me think when I program.
> Al et al,
> I have looked briefly at Zonnon and it became obvious to me that I
> needed to spend significant time to absorb its essence.
> (That comment says nothing about its worth, however)
> Now, I have a question for all compiler writers and language extenders.
> "What problem are you trying to solve?"
> It would be very nice if in every language report right up front was a
> section of why the "new" features are being added and what problems
> motivated the need for these new features with lots of examples and how
> the new features would simplify or solve the problems.
> Here is an example where I *think* active objects would help me but I
> don't know since the overhead in implementing with active Oberon or
> Zonnon might be greater than by some other method. I am (as a hobby)
> designing a rotary engine. I have graphically depicted it. But now I
> would actually like to put hot gas into the engine and see how it
> performs as a function of temperature, pressure, etc. I *think* one way
> to do this is to use aggregated atoms (clusters of atoms which have
> similar attributes) to approximate the 10^23 atoms in a real engine. I
> prefer to do that rather than attempting to solve the Navier-Stokes
> equation for my geometry.
> So, assuming I am using Zonnon I would have to implement an object
> (atomic cluster) that bounces off walls and other clusters. It would be
> nice if, somehow, once I implement a single object that, voila, all
> objects are implemented. The only difference between them is their
> initial conditions. But it seems to me that the overseer would need to
> be quite complex and outside the domain of each object (who do I pass
> the message to that I am 'here' and moving 'there'?). So, naively, I
> suspect that writing the code in Component Pascal or writing it in
> Zonnon might be just as difficult. The only benefit would be the
> (hidden) process handling. But Services.Action in Component Pascal can
> emulate this.
> Hence my over riding question is: what do I gain by using, say, Zonnon?
> This is a true question and not meant at all to be a put down of Zonnon
> or Active Oberon.
> Now, here is what I would really like to see in a computer language:
> Automatic implementation of mathematical theories that I write using a pen.
> I assume this is still many decades in the future.
> -Doug Danforth
> Alan Freed wrote:
> > Zonnon is as different from Oberon, as Oberon is from Modula-2.
> > The Zonnon compiler is still under development, although it is
> > functional for the vast majority of cases. True, it is currently
> > for the .NET framework, but there is a project in place where
> > it will be ported over to MONO, which will be welcomed by
> > many, myself included.
> > Also, the Zonnon language is not 'cast in stone' yet. There
> > are a few issues that remain to be formalized, for example,
> > an advanced language structure for handling arrays. This
> > will make Zonnon a very competitive language for those of
> > us who write computationally intensive code.
> > There are four separate compilation units in Zonnon: the
> > module, definition, implementation and object. Also of note,
> > objects can have bodies, like you are use to for modules.
> > This makes initialization straightforward, and is necessary
> > for active objects.
> > One can get a feeling for Zonnon from the language report,
> > which is still under development, too. However, from one
> > who has done a fair amount of programming in Zonnon, the
> > language report is no users manual, and many facets are
> > nebulous. The best way to begin to appreciate Zonnon
> > for its uniqueness is to play with it, and to study code that
> > has been written in it.
> > Give it a look at: http://www.zonnon.ethz.ch
> > Al
> >>> From: oberon-bounces at lists.inf.ethz.ch
> >>> [mailto:oberon-bounces at lists.inf.ethz.ch]On Behalf Of John Drake
> >>> Sent: Saturday, 25 March 2006 9:28 AM
> >>> To: ETH Oberon and related systems
> >>> Subject: Re: [Oberon] Just Starting With Oberon2
> >>>> 1. Is Oberon still being actively developed?
> >>> Oh. That's a LOADED question. Ok, ETH is
> >>> actively (pardon the pun) developing "Active"
> >>> Oberon AKA "BlueBottle". It's compiler is a
> >>> superset of Oberon-0. (Read it's not Oberon-2
> >>> compatible, though there are...or there at
> >>> least HAVE been ways around that.)
> >> ETH is also actively developing 'Zonnon', which, as far as I can tell,
> >> is a superset of Oberon-2. It includes active objects, and also
> >> resurrects a basic form of the Pascal Read and Write statements and the
> >> 'definition' and 'implementation' pairs and enumerated types from
> >> Modula-2.
> >> http://www.zonnon.ethz.ch/
> >> Chris Burrows
> >> CFB Software
> >> http://www.cfbsoftware.com/gpcp
> >> --
> >> Oberon at lists.inf.ethz.ch mailing list for ETH Oberon and related systems
> >> https://lists.inf.ethz.ch/mailman/listinfo/oberon
> Oberon at lists.inf.ethz.ch mailing list for ETH Oberon and related systems
Alan D. Freed, PhD AlFreed at ohio.net
Bio Sciece & Technology Alan.D.Freed at nasa.gov
NASA Glenn Research Center
Dept. Biomedical Engineering FreedA at ccf.org
The Cleveland Clinic
The opinions expressed are my own and do not reflect
those of either NASA or the Cleveland Clinic.
More information about the Oberon