Re: [stack] Joy's relationship to FP + a Joy variant with combining forms

----- Original Message ----- 
From: "John Nowak" <[email protected]>
To: <[email protected]>
Sent: Saturday, May 31, 2008 2:09 PM
Subject: Re: [stack] Joy's relationship to FP + a Joy variant with combining forms


> On May 31, 2008, at 2:33 PM, Stevan Apter wrote:
>
>> i think you can trace these ideas (and limitations) to two sources:
>> (i) early APL implementations had to be squeezed into tiny memory, and
>> (ii) the implementors were mathematicians, and the generating ideas
>> behind APL were based on iverson's program for the reform and
>> regimentation
>> of mathematical notation (see his book "A Programming Language".)  APL
>> represented a series of compromises dictated by the existing
>> technology
>> and the uses envisioned by the implementors.
>
> While I'm sure this holds true for APL, what about FP? It seems no
> real concern was given to FP's efficiency, and at least with FL, the
> intended use case seems more general than that of APL's.
> Unfortunately, I've not been able to find anything by Backus
> indicating why he chose to not have first class functions. I'm sure
> the purpose is to make it easier to prove program properties, but more
> detail would be nice.

you might want to pick up a copy of this:

http://www.abebooks.com/servlet/SearchResults?an=iverson&sts=t&tn=algebra+algorithmic&x=0&y=0


>
>> fixed forms instead of HOFs is an interesting idea.  as always with
>> me,
>> the question is what loss of expressiveness (if any) will result.

it's the *net* effect i'd be interested in.  my experience is that
this cannot be predicted based on small examples.  how does expressiveness
scale as applications grow?  such measures are invariably subjective, and
consist of comparisons such as "in X i could do Y this way; in Z i have to
do ...".  over time, these comparisons accumulate, and indicate where *useful* expressiveness has been lost.  so i suppose i use 
"expressiveness" to cover
more than just how easy it is translate an algorithm into code.  without
invoking the full power of the strong sapir-whorf hypothesis i think it's
safe to say that properties of the pl contribute to the trajectory we
take through the mental search space of algorithms.  do i need to give
examples to make the case for this claim?

i know, this is a hobbyhorse of mine -- add up all the factors that make up
a real-world programming environment (and yes, there are many kinds) and then
ask:  over time, how does this language perform?  only to the extent that
formal properties of the language impinge on overall performance are my
interests engaged.  (i am repeatedly appalled by how much code java
programmers have to read and write to accomplish the simplest tasks.)

>
> The immediately obvious consequence is that you lose 'compose' and
> 'curry' as both exist to return functions as objects. This is less
> detrimental than it may seem at first. As I showed in the email that
> began this thread, implementing 'map' in terms of 'fold' makes use of
> 'compose' in the Joy-like version, but gets on fine without it in the
> combining form version.
>
> Here's another example. In Factor, 'map' requires a quotation with a
> stack effect of ( old -- new ). Sometimes though, it is nice to have a
> function 'map-with' that makes repeated use of a value on the stack
> and keeps it around after 'map-with' is finished. For example:
>
>    -- yields '8 { 5 6 7 }'
>    8 { 3 2 1 } [ - ] map-with
>
> We can define 'map-with' in Factor as such:
>
>    : map-with [ dupd ] swap compose map ;
>
> In the language I'm proposing, we'd do this instead:
>
>    map-with(F) = map(dupd F)
>
> One last example. Let's say we want a function 'make-hash-table' that
> takes a function to use for equality. It would have the type 'A [b b -
> > Bool] -> A (Hashtable b)'. To get this to work without first class
> functions, we simply make 'make-hash-table' into a combining form.
> Since the function is hidden in the Hashtable object and cannot be
> accessed in any way, there's no problem.
>
> To be clear, there absolutely would be a loss in expressiveness, and I
> don't mean to gloss over it. It's something you'd be certain to
> eventually bump into. I do think, however, that it is perhaps not as
> severe as it may initially seem.

i have the same hunch.


>
> - John
>