[racket] Liitin screencast tutorial

> > 2. Have you developed portions of Liitin in Liitin? I assume you have
> > read the 1999 paper on 'revenge of the son of the Lisp machine'. Perhaps
> > you could just start with a 'demo' on how to develop something
> like it in
> > Liitin.
> >
> > In a way one should re-do the entire code base of Racket in Liitin
> > to really test-drive it. I could imagine huge gains, once it is
> > polished and stable and ready for the world
> >
> > -- Matthias

I'm not sure if this qualifies as the type of demo you were thinking, but...

Instead of pretending that we could do such stunt, I wonder if Liitin could
today provide the means to do it for someone who has the required skills. As
mentioned, it is important that we keep some kind of common "seed" system
for all Liitin objects. Think about it like a robot just sent to Mars. You
know that you could have done better but you are stuck with the hardware and
the ROM BIOS to ensure that it will always boot alive. Other that that, you
can do anything with data (read: Liitin objects).

You want to access all existing objects as they are, but then you would like
to make an improved, RAM version of the BIOS. In practice, you could try the
following approach:

Any Liitin account would do fine, instead of some root access to the back
stage. Say, the namespace could be racket:   Now, duplicate all of ROM
objects (Racket 5.1) into Liitin objects.

E.g.
racket:lambda

(named-lambda (lambda...
  )))

racket:apply

(named-lambda (apply...
  )))

and so on. As soon as there is need to change something, you would do it the
way shown in the tutorial. That is, change the code and "Save update".

The functions that refer to ROM primitives continue to work as normal, but
if you have chosen instead to use these new functions, they would
dynamically use the RAM versions.

This way you wouldn't restict any approach, and in fact you could combine
them freely. And it would be up to the object caller to choose which to use
and when. Or you could benchmark them against each other, test if they
always return the same values etc.

corporates, institutes or similar accounts can choose the namespace more
freely, but are otherwise like individual accounts (pseudo accounts?).
Instead of many persons logging into one namespace, there could be one
"librarian" to coordinate the Liitin objects. For example, racket:lambda
could be directed to a trusted person's another Liitin object as follows:

racket:lambda

(named-lambda (lambda args)
   (userx:lambda args))

Or something similar.

What do you think, is this something you were after and could it possibly
work this simple?

br, jukka