Re: [stack] An Overlooked Paradigm in Functional Programming

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]