Intent

[Kyle Lahnakoski]

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.

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.

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


>>> 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.  The developer can declare the parameters in any order,
similarly the user can call in any order.

EG declaring a function (pseudo code):

	public void MyFunction(String_Class Name, Integer_Class Age);

is equivalent to

	public void MyFunction(Integer_Class Age, String_Class Name);

Much like set theory {a, b} = {b, a}, the DBOS can only construct order
in a way similar to the formal construction of ordered sets
(coordinates): (a, b) = {{a, b}, b}.  
	
Maybe you are mentioning something more subtle.


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





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