An Overlooked Paradigm in Functional Programming
John Nowak — 2010-01-29 04:07:15
chris glur — 2010-01-30 21:18:15
I think/hope denkspuren.blogspot approaches from the human cognition angle,
because that's where productivety increases will come from.
I'm pushing my topic in here, while I've got a connection to the cat-list,
because the Chinese [or rain] has screwed my gmail [which is tied to the
cat-list]
=== joy in the BIG ===
The following extract from joy-docos is informative and fun:======
Consider the following recursive definition and use of the
factorial function in a (fantasy) functional language:
LET factorial(n) = if n = 0 then 1 else n * factorial(n - 1)
----------------> So this 1-lines natural-code is obfiscated to joy's ...
This is the program:
1 5
2 [ [pop 0 =]
3 [pop pop 1]
4 [ [dup 1 -] dip
5 dip i
6 * ]
7 ifte ]
8 dup i
============== end of joy-docos extract==========
But really, it's intolerable to have to do stack-shuffling,
when the computer/compiler should be doing that for me.
The absurdity of MANUALLY translating the 1-line pseudocode
to joy, when a simple/immediate algol-like compilation is
available tells much?
OTOH joy-like seems appropriate at the higher-level: using
routines/utilities/functions which have been programmed in
'proper' language/s where the compiler has done the
stack-shuffling.
IMO an example of a good task for joy-like-capabilities
is "list the file-IDs and lines of all the files newer than
n days, in this dir-tree which contain string <string>".
'Linux-pipes' lists the files [but not the lines] by:
find ./ -ctime -<n> -exec grep -l "<string>" {} \;
where apparently:
find ./ -ctime -3
would give a list of fileID's of files younger than 3 days.
and then
grep -l "<string>" {}
lists [by filtering] only the ones containing "<string>".
From a joy-perspective -- AFAICS the first step maps:
stack/pair(tree-path, daysCount) -> stack/tuple(FileSet/list)
and then the next stage does:
stack/tuple(FileSet/list, <string>) -> stack/tuple(FileSet/list).
AFAICS this task fits naturally into a data-flow-via-stacks
type of process. So joy-like is very appropriate?
But I'm thinking that the lower level utilities should
NOT be joy-like.
What ideas/documentation exist on using a joy-like
language which would call functions from a library?
===================
Is it viable to make a joy framework to handle the basic
control-structures of: IfThenElse, WhileDo; where you'd
just fill-in the eg.: predicate, ThenStmt, ElseStmt; for
the IfThenElse, and be able to concentrate on the
data-structures that are being manipulated and passed through
the various stages?
Or perhaps there's no advantage of going via joy?
Unix-via-piping is a powerfull labour saver, even though the utilities
are a patchwork, rather than a formally designed structure like joy.
So I'm wondering what could happen if the 'library of utilities' was
designed formally to match [in a unified consistent way] the joy-like
superstructure controller.
I'd like to see a cost-benefit-analysis of the attributes of joy-like:--
+ formal code manipulation could possibly lead to [auto] verification of specs.
- manual stack shuffling needed == BIG minus!!
+ can do higher-order functions like lisp/scheme, with a potentially more
natural syntax.
? <fill in>
?<fill in>
== Chris Glur.
On 1/29/10, John Nowak <john@...> wrote:
> Paper:
> http://mitarbeiter.hs-heilbronn.de/~herzberg/Publications/ICSOFT.2009.pdf
>
> See also:
> http://denkspuren.blogspot.com/2010/01/factor-heilbronn-university.html
>
>
John Nowak — 2010-01-30 23:13:10
On Jan 30, 2010, at 4:18 PM, chris glur wrote:
> The following extract from joy-docos is informative and fun:======
> Consider the following recursive definition and use of the
> factorial function in a (fantasy) functional language:
> LET factorial(n) = if n = 0 then 1 else n * factorial(n - 1)
> ----------------> So this 1-lines natural-code is obfiscated to
> joy's ...
> This is the program:
> 1 5
> 2 [ [pop 0 =]
> 3 [pop pop 1]
> 4 [ [dup 1 -] dip
> 5 dip i
> 6 * ]
> 7 ifte ]
> 8 dup i
>
> 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:
fact = [zero?] [pop 1] [dup 1 - fact *] ifte
Or, alternatively, I'd rather write:
fact = [zero?] [pop 1] [[] [1 -] bi fact *] ifte
There's only one "shuffle" word in the entire thing; 'pop'. 'bi' makes
it explicit that you're deriving two values from one value given the
identity function and the predecessor function. The rest are the same
things you'd see in the mathematical definition.
What concatenative languages do you let you do well is write an
efficient iterative version without meaningless names for accumulator
variables:
fact = dup [1 - dup 1 >] [[*] keep] while pop
But, more likely, you're just using the proper combinator anyway:
fact = [1] [*] primrec
Or, in a more Haskell-like style:
fact = 1 enum-to-from 1 [*] fold
Or:
fact = 1 enum-to-from product
-jn
John Nowak — 2010-01-30 23:37:52
On Jan 30, 2010, at 6:13 PM, John Nowak wrote:
> Or, alternatively, I'd rather write:
>
> fact = [zero?] [pop 1] [[] [1 -] bi fact *] ifte
For what it's worth, this is essentially identical to the FP version:
fact = zero? -> ~1; * . <id, fact . pred>
The only real difference is that constant (~) is used instead of pop
and that it's made explicit that 'fact' is applied only to the result
of 'pred'. The latter is an advantage, although it's one that goes
away when the stack-based version is written out visually (which is
something I'll be harassing you all with soon enough).
You can do the same thing in Haskell of course:
bi f g x = (f x, g x)
ifte c f g x = if c x then f x else g x
pred = flip (-) 1
fact = ifte ((==) 0) (const 1) (uncurry (*) . bi id (fact . pred))
... but it's not amazingly pretty.
- jn
William Tanksley, Jr — 2010-01-31 01:06:32
John Nowak <
john@...> wrote:
> of 'pred'. The latter is an advantage, although it's one that goes
> away when the stack-based version is written out visually (which is
> something I'll be harassing you all with soon enough).
>
Ah! This sounds promising.
- jn
-Wm
[Non-text portions of this message have been removed]
chris glur — 2010-01-31 08:28:59
> 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.
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' !
On 1/31/10, William Tanksley, Jr <wtanksleyjr@...> wrote:
> John Nowak <john@...> wrote:
>
>> of 'pred'. The latter is an advantage, although it's one that goes
>> away when the stack-based version is written out visually (which is
>> something I'll be harassing you all with soon enough).
>>
>
> Ah! This sounds promising.
>
> - jn
>
>
> -Wm
>
>
> [Non-text portions of this message have been removed]
>
>
William Tanksley, Jr — 2010-01-31 19:09:35
chris glur <
crglur@...> 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]
chris glur — 2010-02-01 13:31:30
> 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 <wtanksleyjr@...> wrote:
> chris glur <crglur@...> 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]
>
>
chris glur — 2010-02-01 13:33:38
> 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 <wtanksleyjr@...> wrote:
> chris glur <crglur@...> 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]
>
>
William Tanksley, Jr — 2010-02-01 15:09:01
chris glur <
crglur@...> 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]
chris glur — 2010-02-02 04:02:00
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 <wtanksleyjr@...> wrote:
> chris glur <crglur@...> 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]
>
>
William Tanksley, Jr — 2010-02-02 05:04:21
chris glur <
crglur@...> wrote:
> Can someone add value to my query/idea that 'perhaps cat-like is
> effective/productive in using pre-existing functions'.
I haven't seemed to be able to add the value you're looking for, so good
luck. I hope you come up with some interesting ideas.
I'm only interested in productivety increases, which
> IMO come mostly by managing complexity ie. reducing the cognative
> load;
If productivity truly is your main goal, you might consider being a little
more open to other possible factors contributing to productivity. For
example, the things that make a large team productive are not the things
that make a single person productive. This is why Java is so successful with
huge websites, and so unpleasant for personal projects. Anyone can slap
together a website for Python; but to merely get started with Java requires
you to choose between many competing frameworks for a million little parts
of the language, all of which have a million little configuration choices --
a large team has a specialist for each area, so the team can do the best
possible thing... the one person can't possibly figure out the best thing,
and will usually just pull some boilerplate code off the web.
Aside from the question of whether there are other ways to increase
productivity, the ways in which one manages complexity also matter. Compare
the solution in Java to the solution in Ruby -- and then look at Arc's
theory. (Arc's theory is that productivity is directly related to the
shortness of the natural solution in the language.)
Figuring out what's actually going on to cause productivity is a hard, hard
question... I hope you contribute to answering it someday.
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.
>
Playing with puzzles is sometimes useful, if the puzzles have never been
solved. We all have a part to play, if we're willing to do the work to play
it.
-Wm
[Non-text portions of this message have been removed]