Oberon in Python, ala Pyrex but instant compile?

[Brad Clements]

Well, of course Oberon is strict in a draconian way. Isn't that supposed to
keep you from pointer-munging yourself into a crash?

I can't help that most of the existing Oberon code was written by students!
;-)

Surely it must have some redeeming value, otherwise why is it still around
teasing the rest of us?

--
Novell DeveloperNet Sysop #5

_
"Janto Dreijer" <janto_d at hotmail.com> wrote in message
news:f9068f8e.0205220358.19eb1094 at posting.google.com...
> "Brad Clements" <bkc at Murkworks.com> wrote in message
news:<3ce11bc3_4 at goliath.newsgroups.com>...
>
> > Brainstorming..
>
> >
>
> > Pyrex looks very nice. I'm wondering if it'd be possible to use an
Oberon-2
>
> > compiler as the backend instead of GCC.
>
> >
>
> > The idea being that Oberon-2, on some (most?) OS's allows for very fast
>
> > dynamic compilation and loading. The Oberon compiler could be a Python
>
> > module that dynamically loads Pyrex "modules" and recompiles on the fly
as
>
> > needed.
>
> >
>
> > I realize that dynamic loading is part of Oberon System, not really the
>
> > Oberon compiler itself.
>
> >
>
> > But I wondering if this is too crazy an idea or not. Have something like
>
> > Pyrex write Oberon code, run it through an Oberon compiler and
dynamically
>
> > load the resulting module.
>
> >
>
> > Oberon is much smaller than GCC and runs just about anywhere.
>
> >
>
> > Crazy idea, or waste of time, or both?
>
> >
>
> > --
>
> > Novell DeveloperNet Sysop #5
>
> >
>
>
> I know this is an old post, but I feel that Oberon programmers need
> all the help they can get without being made fun of :-) If I remember
> correctly you also asked about running python ON oberon, in a previous
> post.
>
> I believe I have some authority on this subject (or at least "will")
> as we have just been given the taks of writing an interpreter for a
> butchered version of python as a CS project. It has already taken me
> 8h just to write the scanner/tokeniser. That's extremely long for the
> ammount of work involved. Most of the time was spent struggling with
> oberon's absence of a string type, incomplete (and faulty!) oo
> implementation and the oberon compiler(!) crashing with legal code.
>
> Oberon's extremely strict and archaic design makes a complete and
> bug-free interpreter almost impossible.
>
> I could keep on ranting (just ask) about oberon's flaws and why such a
> fork would actually waste a lot of development time that could have
> been used for jyhton or cpython, but I'm sure that just browsing
> oberon's internal libraries would dissuade even the most naive coder.
> :-)
>
> BTW If any of my fellow classmates post their versions I will kill
> them <0.0001 wink>




-----------== Posted via Newsfeed.Com - Uncensored Usenet News ==----------
   http://www.newsfeed.com       The #1 Newsgroup Service in the World!
-----= Over 100,000 Newsgroups - Unlimited Fast Downloads - 19 Servers =-----