Re: [stack] An Overlooked Paradigm in Functional Programming

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 <[email protected]> wrote:
> Paper:
> http://mitarbeiter.hs-heilbronn.de/~herzberg/Publications/ICSOFT.2009.pdf
>
> See also:
> http://denkspuren.blogspot.com/2010/01/factor-heilbronn-university.html
>
>