🚀 go-pugleaf

In article <8527@megaron.arizona.edu>, gudeman@arizona.edu (David Gudeman) writes:
> In article  <2594@ficc.uu.net> peter@ficc.uu.net (Peter da Silva) writes:
> >I mentioned in the previous message that I couldn't think of any dataflow
> >languages, off the top of my head. Of course I should be given a good swift
> >kick for forgetting Icon here...

> Ahem.  I hate to nit-pick, but my understanding of dataflow languages
> is that they are non-procedural languages based on something similar
> to circuit diagrams.

The multiple-result feature of Icon is a non-procedural dataflow capability
built on top of the procedural kernel. It's very well integrated, so it's
easy to ignore, but it's really an amazing capability.

> (sort of like Lisp with more readable syntax and Prolog's backtracking
> mechanism).

Not really that much like Lisp, but it's definitely got a lot in common
with Prolog. Where it differs from prolog is that the data stream is
built explicitly by a procedure rather then implied by the database.

> No doubt Mr. da Silva was thinking of some other language.

Nope. And we don't need to be so formal... you can call me Peter. Just
not "Pete".
-- 
Peter da Silva, Xenix Support, Ferranti International Controls Corporation.
Work: uunet.uu.net!ficc!peter, peter@ficc.uu.net, +1 713 274 5180.   `-_-'
Home: bigtex!texbell!sugar!peter, peter@sugar.uu.net.                 'U`
Opinions may not represent the policies of FICC or the Xenix Support group.