> > 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 _________________________________________________ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/users
