Oberon Script. A Lightweight Compiler and Runtime System for the Web

Oberon Script. A Lightweight Compiler and Runtime System for the Web. Ralph Sommerer

Oberon Script is a scripting language and runtime system for building interactive Web Client applications. It is based on the Oberon programming language and consists of a compiler that translates Oberon Script at load-time into JavaScript code, and a small runtime system that detects and compiles script sections written in Oberon Script.

People outside our field often don't relaize just how easy it is to implement languages: This project, for example, uses a recursive descent parser, and the entire compiler is 1081 lines of Javascript code.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

See also haXe

For thoses interested, I'm working on a simular project called haXe (http://haxe.org) that is an high-level language which generates Javascript, but also Flash SWF and Neko code (Server-side VM). The compiler is written in OCaml and the distribution includes a complete Web framework.

tryruby is the latter

why the lucky stiff's "tryruby" is the latter, an AJAX doodad with Ruby on the server. It is intended to be a collaborative set of Ruby tutorials. why wrote a teeny bit more about it here.

Lisp in Javascript

A little Googling reveals a Lisp interpreter in JS.

I think it would be interesting to dynamically add features like static typing to JS via recomplication. This is kind of neat -- but Oberon??? The 90's wants its language back.

Luke Gorrie did one as well...

...which can be found Here. IIRC, the biggest problem was that JavaScript runs out of stack space real fast.

Oh, and, the language of the 50's is more than happy to keep surprising us. :-)

There's this one as well. It

There's this one as well. It includes full first class continuations, a 'just in time' compiler and a lot of r5rs.

I played around with this

I played around with this and got it working with Firefox.

I added a set-timeout! function which lets you call Scheme functions at set times via the Javascript setTimeout call. This combined with continuations could be turned into a Scheme light weight threading library that runs in the browser. Albiet slowly :)

Do the 90's want Python back as well?

Over six years ago, in December 1989, I was looking for a "hobby" programming project that would keep me occupied during the week around Christmas... I chose Python as a working title for the project...

I Dunno...

...I've been saying for over a decade that the industry has ignored Nicklaus Wirth's post-Pascal work to its detriment, assuming that the alternatives are C and C++. Project Oberon is one of the best OS/language design texts I own, if not the best.

Re: I Dunno...

Oberon was recently discussed on Lambda. In that discussion is a link to the PDF version of the book, if you don't want to fork over a $100 to Amazon.

Is there anything in particular from the book that you could highlight?

Forgot About That!

It is great that the book is available electronically.

It's been a long time since I've read it, and I'd have to dig my copy out, but the things that impressed me overall about Project Oberon were that it resurrect the idea that everything, from language to OS to applications, should be integrated instead of being treated separately, that a language could be a good "systems language" (with direct hardware access) and "safe language" (you have to declare modules "unsafe" explicitly in order to have direct hardware access) simultaneously, and that orthogonality is a good idea from top to bottom; the classic Oberon environment made essentially all operations extremely easy to visualize/leverage because the text-command system plus their three-button mouse operations led to great fluidity in code adding commands to a text, where the user could then easily execute the new command in essentially a GUI interpretation of a REPL.

But remember, I said that Wirth's post-Pascal work was ignored by industry to its detriment relative to C and C++. I still look more forward to an industrially-popular language that inherits more from O'Caml or Haskell than any member of the Pascal or C families.

Wirth

I was a big Turbo Pascal/Delphi user back in the day, and always was mildly interested in Oberon -- I remember a PC-based integrated IDE/OS version. I just don't remember there being much to distinguish it from other Pascal dialects, for instance Turbo Pascal 5.5 w/ modules and classes. Or maybe Oberon inspired these features...?

I remember Oberon as...

...being more about building an entire system from the ground up. Ambitious projects like Oberon and Modula-3 are no longer pursued. Instead, languages have tried to coexist with the operating system and stake their claims as virtual machines. Wirth's Component Pascal is an a scaled back Oberon that tries to live in the component interfac space.

What a tease...

Nice little paper but where are the 1081 lines of javascript?

(I'm pretty much a novice at this stuff...self-taught programmer making a living with business database apps, lurking on lambda for the past year or so and dipping into books like SICP. Oberon Script code sounds like just the ticket for me...)

Many more examples

We linked to many more examples that included full source code for simple interpreters and such. Luke's Scheme in JS comes to mind (it was mentioned here in the last couple of days, or search the archives) comes to mind, but there are many others. I totally agree that the only way to learn this stuff is to look at examples. The next step is to implement some simple languages yourself.

It may not be so difficult to implement a language...

... but to implement it well is another matter entirely.

Of course... (I was joking.

Of course...

(I was joking. I know I need to get that bell I promised, but after awhile my humour will grow on you)

huh?

I admit that I don't understand this. Why would you prefer a REALLY LOUD Pascal dialect to Javascript for writing browser apps? We compile Oberon in the compilers course I often TA, and it's always struck me as unremarkable and somewhat antiquated.

Then you must find C to be

Then you must find C to be antiquated. Oberon does more than C (even with the lack of unsigned types): it has a proper module system, fascist type checking, runtime NULL and array bounds checks, which literally _every_ compiler allows you to turn off at least on a module-by-module basis (if not finer-grained via source code pragmas), and proper garbage collection. It's possible to touch low-level stuff and type-cast, as long as you import the SYSTEM module.

In other words, unsafe things are made difficult and patently obvious to the code reader, while safe things are made convenient.

As far as why it is so loud, well, it's statistically rare for folks to name variables or procedures IN ALL CAPITALS. So what better choice to use for keywords? Just look at how often people bitch and moan whenever Bjarn adds _yet_ _another_ keyword to C++, which inevitably conflicts with someone's function, #define, variable, class name, etc. To my knowledge, this has NEVER occured in Oberon.

The number of keywords in the language is pretty diminutively small, too. C has more keywords, IIRC, and in any case, the whole language report is only 20 pages. It's not going to kill you, unless you _let_ it.

If this bothers you, feel free to write a macro for your editor of choice to auto-capitalize Oberon keywords. I remember that the editor for AmigaBASIC (and I believe VisualBasic as well) does this; you are free to type in any case you prefer, but the keywords are auto-capitalized. Think of it as similar to syntax coloring, or pretty printing in the absence of proper boldface.

People outside our field

People outside our field often don't realize just how easy it is to implement languages.

You can't blame them. Many (most?) people inside "our field" don't realize how easy it is to implement languages. Implementing it well, as Leon P Smith notes, is more difficult, but knocking out a prototype proof-of-concept implementation is very easy in a high-level language.

In the thread Functional single argument style object oriented programming, I was (am?) constantly thinking, why not just write a quick implementation to clarify the intended semantics and find out the feasibility of the hypothetical language. It could probably be done in about a page or two of Haskell code. I was actually considering writing a reply including an interpreter as a way to state what I thought Logan was going for.

I wasn't blaming them. If

I wasn't blaming them.

If someone is to blame, it's CS programs that make these techniques look hard and mysterious.