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

[Kyle Lahnakoski]

btanksley@hifn.com wrote:

> >The parameters do have meaning.
> 
> This is an assumption you make because you're used to applicative languages.
> Get rid of the assumption, get rid of the parameters, and you're rid of
> _most_ of the meaning as well.  When there's no meaning, there's no need to
> have extra information to describe that meaning, either.  A clean, costless
> optimization.

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

One of the objectives of Tunes is to be reflective.  Joy does not appear
to have this property (YET?).  My concern is about Joy being able to
achieve this end.  How does Joy refer to data, for example MyFunction? 
I could imagine a library would hold the MyFunction definition, but that
"holding" is currently done by the interpreter, and not Joy.

Maybe I have it all wrong and Joy is just the functional (excuse the
wording) model that is used in a larger reflective system: Joy has not
intention to be managing libraries.



> >To summarize, from an optimizing perspective both types of 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.  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. 

Here is the factorization piece: 
> Also true, but less relevant.  Joy code can have as much redundancy, just in
> different places.  The usual way to make your code have enough redundancy is
> to factor it well; this, in turn, makes the definitions very short and calls
> very frequent.  And making calls frequent is the ideal recipie to bring an
> applicative language to its knees, since a new call frame has to be
> allocated for each call.  (A concatenative program literally only has to
> push a return address and jump for a call.)


> I'm not saying that your idea is bad -- although I think you haven't
> considered some serious problems with it.  I'm just saying that it isn't as
> superior to mine as you're claiming.  Consider that I, just like you, have
> been educated almost entirely in applicative languages, but unlike you, I've
> also studied concatenative languages.  I have a little more information on
> which to base my choices.

I would like to hear more about my problems.  I am running out of
arguments on Joy, or I lost the main point.  :-)  Have you read the web
page, and what little documentation, I have on the DBOS?

http://www.arcavia.com/rd/dbc-html/index.html

Thank you for any criticism you may offer.



> Not an immense amount more info, of course.  Concatenative languages have
> only recently been properly studied, so I _am_ taking a risk by following
> them.  From what I've seen, though, and from the practical results achieved
> in Forth, I'm quite confident in that risk.

Best of luck.  I like the theory, it feels like Pure Math.  






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