Re: [stack] An Overlooked Paradigm in Functional Programming

chris glur <[email protected]> Mon, 1 Feb 2010 15:31:30 +0200
Newsgroups gmane.comp.lang.concatenative
Message-ID <[email protected]>
> 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.
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.
For all I know his joy-translation may have error/s, but that's
irrelevant. I merely pasted it to show how he's transformed simplicity
into complexity.

> 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:
for part of a task, I needed the list of pid/S with the open file
'on mc'.
An existing function called lsof shows a zillion lines, typically:-
mc    3499    root  txt    REG    3,14   519624    375343 /usr/bin/mc

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:
1. show only the lines which have "/mc"
2 show only the part of the lines with the 2nd field [the 3499] and the
  last field.

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>

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.

== Chris Glur.


On 1/31/10, William Tanksley, Jr <[email protected]> wrote:
> chris glur <[email protected]> wrote:
>
>> > The absurdity of MANUALLY translating the 1-line pseudocode
>> > to joy, when a simple/immediate algol-like compilation is
>> > available tells much?
>> ]That's not even a remotely fair translation as it's not recursive like
>> ]the example. The straight-forward recursive function is as such:
>> I MIGHT analyse your code in the future, but:
>> I merely PASTED the joy-author's ample 1-line pseudocode and HIS
>>  joy version.
>>
>
> 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.
>
> I won't follow your NEW argument about Haskell etc. on the going
>> nowhere [because it's fun] journey. Can't someone answer MY question/s?
>> I've got a specific goal and am NOT just playing 'look ma no hands' !
>
>
> 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).
>
> It so happens that there's plenty of solutions to your specific problem,
> even though they don't match your specific question.
>
> -Wm
>
>
> [Non-text portions of this message have been removed]
>
>