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] > >