Intent

[btanksley@hifn.com]

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

>> >I
>> >had brought
>> >up the issue of optimizing Joy programs; there had to be an
>> >intermediate
>> >interpretation of the Joy program before it can be optimized.  The
>> >"labels" approach described above is exactly that.  I do admit that
>> >there could be a method of optimization, maybe one that uses code
>> >pattern mappings, to optimize without an intermediate stage.

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

>> OTOH, with your system there IS an
>> intermediate form; unless I miss my guess, you're converting 
>> this stuff into
>> a set of tables containing IDs, and doing lookups on those tables.

>DBOS has 3 stages:  ObjectCode (source code), MSM (system
>representation), and compiled code.  These are the same three as Joy
>would have.  Maybe Joy replaces compiled code with a VM.

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.  I'm interested in adding another form,
"quotations", which will consist of an ordered list of pointers to function
descriptions; this will allow certain optimizations to take place.  None of
these optimizations are part of what you'd describe as the compiler, though;
they're all user-level code.

>> >This is a different type of problem than just renaming, or
>> >changing parameter order.

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

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.

>Kyle Lahnakoski                                  Arcavia Software Ltd.

-Billy