Intent

[btanksley@hifn.com]

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

>>>> Nope; the labels contribute NOTHING to optimization.  There is no
>>>> intermediate form of any kind.  

>>>Technically, you are right.  Why do you suppose programmers, 
>>>that make
>>>optimizers, desire these "labels" at an intermediate stage?

>>Do you know any programmers who have written optimisers?  
>>I've written an
>>optimiser (for Oberon) based on my study in the Dragon Book, and I'm
>>involved in the design of one for Forth.  I've studied the designs for
>>optimisers in other languages, including some very powerful ones.

>>NOT ONE of these optimisers has ever relied on any form of 
>>names.  In fact,
>>the first thing the optimiser does is get rid of the names by 
>>reducing the
>>code to a DAG (directed acyclic graph).  The trick is that 
>>combinative code
>>is written as a DAG, and concatenative code requires no 
>>special processing
>>to parse the DAG (the nodes of the DAG are placed on the 
>>stack as a natural part of compilation or execution).

>When converting a function to the DAG, the parameters of the function
>exist as nodes in the dependency tree.  The 1-1 representation may
>disappear after optimization.  When I say "label" I do no mean english
>word.

Of course; I apologise for my incorrect and misleading use of the word
'name'.

The interesting thing about concatenative languages is that there never is a
1-1 relationship, because functions don't own their parameters, so there's
no optimization needed to 'remove' it.

>I do like the trivial conversion from DAG to concatenative language.  I
>have not done an analysis of the complexity for using psets to 
>produce a DAG; I can not go further on this thread.

Well, I don't see psets as being any more complex in that sense than
ordinary parameters, and those have been fairly well studied.  I trust
therefore that modern optimization theory will works quite well for your
language.

You might also look at SlimBinaries/Juice technology; they're both very
effective formats, take a lot less space than just about anything else,
contain a LOT of useful optimization info, and are typesafe.

>>I don't know what Joy does (Joy isn't a good example), but my system
>>currently goes from text to native code, in linear time, one 
>>pass.  In other words, it has two forms.

>Are libraries stored in source code form, or native machine form?

That's a very good question.  For all intents and purposes I'm going to
store them in source code form, but I might use an abbreviated form such as
OTA or OpenFirmware (OTA is a public spec which is still in development, but
it looks very good).

>>>> Fortunately, both of those things are considered bad ideas 
>>>> -- so much so,
>>>> than in your system it's impossible for the author to change 
>>>> parameter order.

>>>I do not understand your statement.  The parameter order 
>>>never mattered
>>>in the first place, changing it has no effect.

>>Exactly.  It's impossible to change the parameter order.  You 
>>did that on
>>purpose -- you didn't want it to matter.  The reason you 
>>didn't want it to
>>matter is that it's a bad idea to fiddle with the parameter order.

>Your statement appears to indicate that you think that I am forcing a
>parameter order; the naming of parameters compensates for that order. 
>That is not so.

No, I don't think you're forcing an order.  I think you're forcing a lack of
order.  I agree with your choice.

>The developer can declare the parameters in any order,
>similarly the user can call in any order.

No, the developer _can't_ declare the parameters in any order -- he can't
impose any order on them.  They're unordered.

>>Now you seem to be unhappy that my system makes it hard to change the
>>parameter order.  The solution to that problem is simple -- 
>>don't change the parameter order.

>I am not too concerned with the ability to change parameter order.  You
>have shown many good solutions for handling those changes.  I am only
>concerned with the parameter order encoding the intent of the parameter
>values, especially when order is implementation dependent.  

Well, I have to admit that this _is_ a worthy concern, and you express it
very well.  I don't think it will have much effect on real code, though,
because real code in these languages doesn't use lots of parameters.  This
is a good thing, even though I admit that it is caused by a difficulty in
the language model.  I believe that this minor language model difficulty is
more than made up for by the clarity of the language model otherwise.

I've also demonstrated some stack-tagging solutions which neatly solve this
problem without requiring special treatment of parameters (they label
dataflow, not function parameters).

>Kyle Lahnakoski                                  Arcavia Software Ltd.

-Billy