Re: [stack] An Overlooked Paradigm in Functional Programming

Can someone add value to my query/idea that 'perhaps cat-like is
effective/productive
in using pre-existing functions'. I'm only interested in productivety
increases, which
IMO come mostly by managing complexity ie. reducing the cognative
load; that's why
I found <the German-uni article> appropriate. Pity that THAT blog
needs a pasword.

Perhaps   http://concatenative.org/wiki/view/Staapl
is talking about 'layered' system/s: like cat-like using pre-existing functions;
but at this stage of life, I'm not interested in 'playing cross word puzzles',
which seems the motivation of many contributors here.


On 2/1/10, William Tanksley, Jr <[email protected]> wrote:
> chris glur <[email protected]> wrote:
>
>> > That's a lousy excuse for refusing to accept an answer to
>> > your problem. Just because you did no research doesn't mean
>> > there's no answer.
>> We seem to have lost each other completely ?
>> The author defined the factorial function in one short line of near
>> english;
>> and then gave the multi-step joy interpretation.
>>
>
> You're talking about Manfred's Joy paper posted at
> http://www.latrobe.edu.au/philosophy/phimvt/joy/j02maf.html. Manfred's paper
> wasn't trying to express factorial in the simplest manner possible, nor in
> the best way to express the English; rather, it's a "tour de force", to use
> the author's own words about the program you quoted, intended only to show
> the most primitive breakdown of the program's operation for tutorial
> purposes. It's much like reading a .NET CIL dump and concluding that C# is
> not suitable for programming in-the-large.
>
> Manfred himself explains this immediately after the section you quote: "Of
> course this program is a *tour de force*, it is ugly and inefficient. With
> more suitable combinators much crisper and more efficient programs can be
> written." He suggests using "primrec", as Nowak did, to produce the program
> "[1] [*] primrec"; he also explains how high-level concepts would increase
> the actual efficiency of the program by reducing the amount of data moving
> and copying.
>
> Yet you take that out of context to "prove" that all concatenative programs
> are messy and nasty, when in fact all you've proven is that low-level
> operations are low-level.
>
> Since my aim is to REDUCE mental load, it's irrelevant WHAT the finer
>> considerations of his joy-translation may be, because I don't want
>> to transform conceptual simplicity into complexity.
>>
>
> That doesn't make sense. The reason he wrote the program dictates why it's
> messy and low-level -- because he wanted to expose the low-level details of
> the implementation.
>
>> Your specific goal *seems* to be to program in a low-level
>> > non-concatenative language and a high-level concatenative
>> > language. Since that goal is reversed from anyone else's I've
>> > ever met, I'm mildly interested -- I like contrarian thinking
>> > (that's why I'm studying concatenative languages).
>> I'll give a real-life example:
>> Since all I want is [each]: (3499, /usr/bin/mc) pair, I merely pass it
>> [NB the use of "it" to lambda-like eliminate IDs] through filters which:
>>
>
> You ARE aware that lambda creates IDs, right? It doesn't eliminate them.
>
> So there are 3 'library available' BIG functions:
>> = lsof  [list open files]
>> = grep "/mc" [ but show only lines with "/mc"]
>> = cut <something> [but show only the wanted part of the lines]
>>  I don't WANT to know how these, no doubt complex, functions work.
>> They are constructed by a 'proper language' - as you call "low level".
>> And the the cat-like just does:
>> lsof | grep "/mc" | cut <as required>
>>
>
> That's usually called a "compositional" language, in existing terminology.
> There's nothing particularly concatenative about it; compositional pipe
> languages usually support only one pipe at a time, whereas a concatenative
> language has as many data streams as you want to push on the stack.
> Concatenative languages also don't use an operator to denote composition,
> preferring the syntax of juxtaposition (and hence making concatenation map
> to composition, whence the name 'concatenative').
>
>
>> So altho' cat-like is no good for the real heavy-lifting, it's good
>> to chain/pipe existing functions together to do the hi-level tasks.
>
>
> Compositional languages are typically not used to build complex features, as
> you say; but concatenative languages _are_.
>
> == Chris Glur.
>
>
> -Wm
>
>
> [Non-text portions of this message have been removed]
>
>