🚀 go-pugleaf

Peter da Silva writes:
 [little peter/paul dialog about making assignments unique, ending:
>OK, I still don't follow what the point is. Why avoid assignments,
>and how do you do things like state machines or stepping through a
>list?]

Umm.. I like the Peter/Paul style, but my name starts with an 'R'
(other than that, pronounced like Paul).

(1) The point is not to avoid assignments.  The point is to be able to
see the program all at once.  (Mentally, if not physically).

(2) I generally don't need to make state machines.  When I do, I try
to represent the machine as a single data object (the machine state)
which is mapped by a simple function from one state to another.
Another thing is that usually, I'll want a history of the machine, so
each state is stored in a separate location.  In functional
programming, there is a significant difference between initialization
and re-assignment.

(3) I generally don't need to step through lists.  Generally, this is
done for me automatically by primitives.  Most of the time, I consider
the stepping process trivia (especially when the primitive simulates
parallel execution, as   1 1 0 0 and 1 0 1 0   yields: 1 0 0 0).

Pure functions are much easier to validate than dirty code, for the
same kind of reasons that static code is easier to validate than
self-modifying code.

Again, the point is not to prohibit re-defining of some value, the
point is to use simpler techniques where possible.  And, again, the
advantages are in development and debugging times.

When you're used to it, C statements like
    for (j=0; j<max ; j++) { list[j] = f(list[j], j); }
seem pretty simple.  However, they aren't much faster than
    new = (type *) malloc( ... );
    for (j=0; j<max ; j++) { new[j] = f(list[j], j); }
    free(list);

Why the extra hassle?  Because now you can abort in the middle, if you
hit an error, or whatever.  Also, your new type doesn't have to be the
same as the old type.  (Though keeping track of types is even more
overhead in a language like C).  If you're in a debugging environment,
you could easily change the argument array, and restart.

Thus, I could write the above loop as 
    new =. f (list ; i. # list)
where i. # creates a little array of indices.  Or, even simpler, I
could write 
   new =. f (list)
since f has full access to all the details of its argument (type,
dimensions, etc.)  This is vaugely like the argc, argv convention of
unix, but not so specialized for file names and option switches.

   Yes, there is overhead.  Usually, for arrays smaller than 16
elements it is significantly smaller to go with a statically typed
language.  On larger data objects, the type checking and array bounds
checking vanish in the noise.  (The exact crossover depends on the
function being used, the architecture of the machine you are on, and
that sort of thing.)

   There is also storage overhead, but that isn't always significant.
The efficiencies of scale are suprisingly similar to the benefits you
get from a compiler.  Except with a compiler you can get lots of
speed-up by adding more code.  Here, the speedup comes in simplifying
the code and going with more data.

   In fact, since C makes it so awkward to dynamically allocate result
arrays, people often go to various tree structures when it would be
more efficient to store the results as a flat array.

   For some things, you NEED to get down to a low level, and be able
to do things in a serial fashion, or just modify one little piece of a
tree.  Most of the time, you can provide that functionality in some
primitive, and get on with solving the big problems.

   Enough time is spent re-inventing the wheel as it is.

>Paul> [refering to descriptive comments as type declarations]
>Peter>But wouldn't it be nice if the language understood those declarations?
>Paul> Then they'd be code.  
>That's the point.

Would you settle for a language which provided no special syntax for
comments (i.e. where comments are just pieces of data that you throw
into the program)?

Raul Rockwell