Re: [stack] disallowing recursive definitions

----- Original Message ----- 
From: "William Tanksley, Jr" <[email protected]>
To: <[email protected]>
Sent: Saturday, March 01, 2008 5:08 PM
Subject: Re: [stack] disallowing recursive definitions


> Christopher Diggins <[email protected]> wrote:
>> 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.
> 
> It shouldn't be a puzzle... They don't understand. It's hard to get
> started learning about it.
> 
> The existing array languages are, with only two exceptions, closed
> source. (The early J interpreter was available, although I don't know
> how to get it now, and I couldn't ever figure out how to read it.) A+
> is unreservedly open source, of course, as is QNIAL. I found A+ to be
> very hard to figure out, QNIAL fairly easy.

there are several free APL interpreters available:

http://www.vector.org.uk/?area=dnld&page=content/interpreters

vector is probably the best general site for information about array
languages.  J and Q (K) are ascii.  J is free, but i agree that is
somewhat forbidding.  a freeware version of K5 has been planned, but
isn't available yet.

> 
>>  Map, filter, fold, etc. are all part of the core Cat language. I
>>  consider all of these array primitives.
> 
> I suppose they technically are. They're just a beginning, though.

yes.

> 
>> 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.
> 
> That's a pretty important point, really. It makes the difference
> between an O(n) implementation and an O(n^2) one. I'd really rather it
> be specified.

yes.  if you intend to let these datastructures bear the full weight of
"array programming" (by which i mean crafting your algorithms in such
a way that the language performs the iteration) then the implementation
had better be sharp -- at least as efficient as what the programmer can
do by explicitly iterating (and, one would hope, better.)

> 
>>  > my sense is that programmers (and language designers) *still* do not
>>  > appreciate the power of array programming.
> 
> We don't. I don't. I wish I did, but it's a steep hill to climb.

it goes in both directions.  when i'm forced to write the simplest loop,
i usually get it wrong the first time, the second time, ...  it's 
embarrassing!  the trick is to internalize the idioms, which means
learning them in the first place.  a good resource is eugene macdonell's
k "finger exercises:

http://www.kx.com/technical/contribs/eugene/kidioms.html

so-called because having them at your fingertips as idioms is where
the productivity comes from.

and a good exercise:  solve them in your favorite language.

> 
>>  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 like the implicit iteration.

me too, but getting the design right isn't easy, and if it's an after-
thought, it won't simplify things at all.

> 
>>  - Christopher
> 
> -Wm
>