Mon, 10 Apr 2000 15:16:08 -0700
From: Kyle Lahnakoski [mailto:email@example.com]
>>>> Nope; the labels contribute NOTHING to optimization. There is no
>>>> intermediate form of any kind.
>>>Technically, you are right. Why do you suppose programmers,
>>>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
>>code to a DAG (directed acyclic graph). The trick is that
>>is written as a DAG, and concatenative code requires no
>>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
Of course; I apologise for my incorrect and misleading use of the word
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
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
>>>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.