Lists, Tables, Psets (Was: Joy, Dolphin, ...)

[btanksley@hifn.com]

From: Kyle Lahnakoski [mailto:kyle@arcavia.com]
>btanksley@hifn.com wrote:

>> I also don't think
>> that DBOS can be more reflective than my language; the best 
>> you can do is
>> have a smaller VM.  Your inclusion of parameter names would 
>> seem to require
>> more complex VM support than my inclusion of an explicit stack, thus
>> requiring a larger VM.

>MMMMmm.  You speak of VM, but DBOS not seem to have one.

Hmm.  I've always thought that VMs weren't necessary, but so far I haven't
found a system which doesn't have one.  From what I can see of your system,
you have a huge VM.  Perhaps the very magnitude of the VM is making you
ignore its presence.

>The MSM
>(Messaging State Machine) is only a specification of functionality,
>technically, no more special than source code.  The DBOS compiles MSMs
>into executable code.

"The DBOS" contains a VM, as far as I can see.

>I will try again:  It would be great if the optimization of an LLL was
>solved; a static optimizer was a solution.  Then any system that used
>the LLL would not have to concern itself with the optimization of LLL. 

I'm still missing something critical.  Are you assuming that if the LLL
optimised itself for the native platform, the HLL could simply compile to
the LLL?  This makes sense, and is partially what I had intended; actually,
though, I was thinking that the HLL would compile to the tokenized form of
the LLL.  Same thing, I suppose.

My LLL will not have any kind of optimiser built into it (well, there is a
possibility that I'll be emitting code which handles superscalar code
generation correctly, but that's an essential, behavior-altering part of the
VM more than it's a mere optimization).  There will be an optimiser written
in it, though.

>Kyle Lahnakoski                                  Arcavia Software Ltd.

-Billy