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

[Kyle Lahnakoski]

btanksley@hifn.com wrote:

> >I think we mean reflective in two different ways.  I will make the
> >distinction between reflective, and totally reflective.  I was using
> >'reflective' in my previous posts to mean totally reflective.  Totally
> >reflective means that every structure used to support the system is
> >modeled by that system.  Joy does not appear totally reflective because
> >it does not consider its own interpreter.
> 
> That's certainly true in the current implementation, but consider that Joy
> can be trivially written in Joy -- after that, reflection can be extended to
> the entire runtime.  The only thing which cannot be reflected on (without
> direct source code manipulation) is the virtual machine -- this is why I'm
> using something similar to the Forth VM, which is extremely simple.
> 
> >Now, don't get me wrong, I am
> >not saying that DBOS is totally reflective, but I plan for it to be
> >eventually.  From what you said below: I now believe my impression of
> >Joy is that it does not plan to be totally reflective, but
> >just a single part of a larger, totally reflective, system.
> 
> I don't think that true total reflection is possible.  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.

MMMmm.   Yes, even my definition of totally reflective was bad.  I was
trying to embody the thought that you are expressing: "I also don't
think that DBOS can be more reflective than my language":  Two totally
reflective systems need not be completely reflective, but they are
equivalent.

MMMMmm.  You speak of VM, but DBOS not seem to have one.  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.  You are right on the point that DBOS is larger
than all the reflective systems I have seen so far, I did that for my
own clarity.



> No; a static Joy optimiser IS a static procedural optimiser with meta
> information.  It doesn't have access to any dynamic information.  Mind you,
> I plan to impliment several static optimisers which will be used by a
> dynamic optimizer.
> 
> >It would be great
> >if the optimization perspective of a LLL was already solved;
> >it would be of no concern to the system that uses it.
> 
> I don't understand what you mean here.  How can you solve a perspective?

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. 



> >Because of the use of "reflective" I thought Joy was going to be a
> >totally reflective system.  I see now that your designing the
> >language.
> 
> Sort of.  I'm designing the system more than the language -- the language is
> utterly trivial.  It's nothing more than a sequence of space-delimited
> words.

OK, I was a little mixed up on who was who.


Thanks


-- 
----------------------------------------------------------------------
Kyle Lahnakoski                                  Arcavia Software Ltd.
(416) 892-7784                                 http://www.arcavia.com