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

[btanksley@hifn.com]

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

>> >One of the objectives of Tunes is to be reflective.  Joy does
>> >not appear to have this property (YET?).

>> Why do you say that?  One of Joy's strengths is how reflective it is.

>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.

But I could be wrong at any point in this reasoning; I've not applied any
formal logic to it.

>> >I would imagine
>> >factorization is a scheme to reduce redundancy in parts of a
>> >Joy program for optimization purposes.

>> Not really; it can have that effect, but it's not needed for 
>> that.  Its main
>> effect is to provide levels of knowledge; it allows the 
>> coder to first write
>> a domain-specific language using the tools of the general 
>> language, and then
>> write the application entirely in the DSL.  A complex 
>> application will have
>> many DSLs, and will quite likely implement some DSLs simply 
>> to make other DSLs easier to write.

>Oh!  Is Joy planned to be a LLL?

Joy isn't my work -- the language I'm writing is a LLL, though, yes.  I may
or may not write a high-level version of it as well; if so, the main
difference between the high level and low level versions will be that the
HLL will have complex data structures and garbage collection.  It's almost
certain that typechecking and such won't be present in the low level
language.

>> >But I had already mentioned that you may be
>> >right; Joy programs can be optimized as well as any other 
>> >program.  We
>> >can not go further in this debate unless I see some 
>> >convincing argument
>> >that Joy optimization is as good as optimizing procedural languages
>> >containing meta information.  Until then: you are right on 
>> >the point of optimization.

>> When Joy gains an optimiser, it WILL be an "optimizing 
>> procedural language
>> containing meta-information."  Therefore it's unclear how 
>> you can make such a general comparison.

>I thought your point was that static Joy optimizers can do as well as
>dynamic procedural optimizers with meta information.

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 do not know enough about
>lambda calculus and concatenative languages to say if such a static
>optimizer can exist.

The purpose of concatenative languages is to totally eliminate lambda
calculus.  LC has held back computer science for far too long, with its
dependance on named variables.

>I only meant to say I doubt it, and I can't back up my doubt.

But I would tend to say that no static optimizer can ever be as effective as
a dynamic optimizer.

>> I did, just before you sent this; I'm very impressed.  No, I 
>> don't think your language design is any better than mine;

>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.

>Actually it makes me happy to see someone develop the language design
>from the "opposite" (Church-Turing) perspective.

Grin.  I admit that this motivates me as well.  I've always hated lambda
calculus, and I was overjoyed to find out that my suspicions could be borne
about by mathematics.

>Kyle Lahnakoski                                  Arcavia Software Ltd.

-Billy