Re: [stack] disallowing recursive definitions

----- Original Message ----- 
From: "Christopher Diggins" <[email protected]>
To: <[email protected]>
Sent: Saturday, March 01, 2008 2:35 PM
Subject: Re: [stack] disallowing recursive definitions


> On Sat, Mar 1, 2008 at 8:51 AM, Stevan Apter <[email protected]> wrote:
>> i'm still puzzled why authors of concatenative languages like cat and factor
>> have resisted the incorporation of array primitives into their languages.
> 
> Map, filter, fold, etc. are all part of the core Cat language. I
> consider all of these array primitives.

i haven't looked at cat's implementation of these combinators.  how
would you use map to add a matrix to a vector?  for example, suppose
you have

    1 2 3 4
    5 6 7 8

and 

    10 20 30 40

you want to add the vector to each row of the matrix.  now suppose
you have a second vector

    11 12

and you want to add each of those to each row of the matrix.  

in general, how do you map/filter/fold/zip functions which take more
than one argument?

> The Cat concept of list is
> more or less analgous to an array, but is agnostic about
> implementation details. An implementation is left to its own devices
> as to what the performance characteristics of lists are. Sorry its not
> more clear in the current documentation.
> 
>>in
>> the admittedly trivial examples below, why not write
>>
>> 1+til / applied to n generates 0..n-1, then add 1
> 
> In Cat
> 
> n [1 +] map
> 
>> or
>>
>> 1 drop til 1+ / add 1 to n, generate 0..n, then drop the first
> 
> n [1] drop
> 
>> instead of either looping or recursion?
> 
> Sure completely valid. Of course sometimes loops are fun to have
> outside of the context of a list.

sometimes they're necessary, but i can't say i have any fun writing
them.  :-)

> 
>> my sense is that programmers (and language designers) *still* do not
>> appreciate
>> the power of array programming.
> 
> Well I know that Slava (the author of Factor) does, and I'd like to
> feel that I do. Its not really fair to single us out in this.

that's true in some sense.  i should have said something like this:
given the role that simplicity and expressiveness play in the cognitive
economy of concatenative language designers, i'd expect them to be 
close students of the gains in these areas made by iverson and his
students over the last 45 years.  (yes, it really has been that long
since iverson published "a programming language.")

> 
>> here's an example i posted the other day on
>> comp.lang.functional, a general sudoku solver written in q by arthur
>> whitney.
>> for readability, i've replaced the case statement of q ($[x;y;z]) with
>> if-then-
>> else pseudocode.
>>
>> f:{if all x then enlist x else raze f each amend[x;i]each where 27=x[raze p
>> i:x find 0]find til 10]}
>>
>> note the explicit tail-recursion on 'f' in the else clause. also note that
>> this is
>> the standard algorithm used in sudoku solvers written in java, python, ruby,
>> ocaml,
>> &c. compression is achieved through the use of a handlful of array
>> primitives
>> (til, find, raze, where, all), one iterator (each), a primitive for updating
>> positions of an array (amend), and a single primitive extended from scalars
>> to
>> arrays (=).
> 
> I'll have to look more closely at this (I don't know what "til",
> "find", "raze", "where", "all", "each", and "amend" do). But it should
> be easy to implement something similar.
> 
> Nonetheless, your original point is still valid that some more array
> processing primitives would be valuable in Cat. I'll add some to the
> specification.

i'm not sure i had much of a point, beyond wanting to make a gesture of
mental irritability.  concatenative languages are lovely, but, judged on
the basis of how much code one has to write, not expressive enough to 
convince me i should use one.

> 
> - Christopher
>