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

[btanksley@hifn.com]

From: Kyle Lahnakoski [mailto:kyle@arcavia.com]

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

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

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

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

What do you mean?  "Joy" is an abstract concept (even as a programming
language); it couldn't possibly hold anything.  _Something_ has to do the
job of holding the function, and that something is usually the runtime (to
which you refer specifically as the "interpreter").

>Maybe I have it all wrong and Joy is just the functional (excuse the
>wording) model that is used in a larger reflective system:

That's pretty much essential: I first specify the language and data format,
including tools to manipulate the data format; later I can build an expert
system which uses those tools.

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

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.

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.

There are optimizers for concatentative languages, though, and they tend to
do quite well.  One thing that's useful for them is the explicit ordering
implied by the stack: parameters which are about to be used are kept close
to the top of the stack.  Since EVERY machine with speed problems is
resource-constrained, this gives the optimiser a way to work with the
programmer to find a way to allocate the resources most efficiently.

>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

I did, just before you sent this; I'm very impressed.  No, I don't think
your language design is any better than mine; however, I do think you're on
the right track for building a system.  Historically, the most successful
languages have actually been application frameworks, not languages; as such,
they were very strong on the most important part of any application, the
database.  You've got that part nailed.

Note that in most of them the language part pretty much sucked (COBOL), but
that didn't hinder them.

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

That's one thing that cracks me up about it -- the inventor of Forth is a
total pragmatic.  He doesn't care in the slightest for theory.  And here we
are, coming up with a Pure Math based on his invention.

>Kyle Lahnakoski                                  Arcavia Software Ltd.

-Billy