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

[Kyle Lahnakoski]

btanksley@hifn.com wrote:

> >I will try to make my point clearer.  I keep mentioning "structures" to
> >model the "function" call.  You appear to be content with the
> >implementation of the function defining its interface (the parameters
> >expected in the stack).
> 
> Essentially, yes.  In other words, the intent of the code goes hand-in-hand
> with its implementation.
> 
> (Technically, BTW, you're being too loose in saying that the implementation
> controls the interface -- actually, the order of usage controls the
> interface.  Implementation is nearly irrelevant.)

Thank you.


 
> >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.  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 know what you mean by reflective when you say Joy is.  I have to think
about it more to clear up my thoughts.



> I'm assuming that by "reflective" you're meaning "smart enough to change its
> own code", not merely "able to change its own code", since Joy meets the
> second definition already.
> 
> >Joy has not intention to be managing libraries.
> 
> Non sequitur?  Confusion?  Managing libraries is a simple task which
> requires no reflection at all (at most introspection).

To manage a library the system must have meta information on what a
library is.  Only this meta information will make the system "smart
enough to change its
own code".



> >> >code can be
> >> >optimized equivalently.  But my issue is that Joy
> >> >optimization may not
> >> >be easy, actually quite difficult, maybe impossible because
> >> >the intent
> >> >is hidden in the code.
> 
> >> It's actually not.  You clipped my discussion of
> >> factorization, probably
> >> because it made no sense to you.  Just as factorization
> >> makes little sense
> >> in an applicative language, so also parameter specification
> >> makes no sense
> >> in a concatenative language.
> 
> >Maybe I do not understand "factorization".  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?


> A simple/trivial example of this is given in Leo Brodie's classic "Starting
> Forth" book:
> 
> : CYCLE  POWER ON STARTUP AGITATOR ON WATER ON TILL-FULL WATER OFF AGITATOR
> OFF DRAIN ON SPIN ON TILL-EMPTY SPIN OFF BUZZ POWER OFF ;
> 
> >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.  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 do not know enough about
lambda calculus and concatenative languages to say if such a static
optimizer can exist.  I only meant to say I doubt it, and I can't back
up my doubt.



> 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. 
Actually it makes me happy to see someone develop the language design
from the "opposite" (Church-Turing) perspective.



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