On 4/10/07, Stewart Stremler <[EMAIL PROTECTED]> wrote:
Java makes it easy to compose streams -- you can basically wrap a stream
with another stream that transforms it in some way, and then chain
together the transformations.  Smalltalk is even more flexible (you
iterate through a list by reading from it as if it were a stream).

I'm sure that many other languages have similiar features.

> Or am I just not getting this?

I am not sure I'm getting it either. I await enlightenment.

Well I only glanced at it at the time so I also await enlightenment.
But I did find the description of such languages here interesting:

http://en.wikipedia.org/wiki/Dataflow_language
"This distinction may seem minor, but the paradigm shift is fairly
dramatic, and allows dataflow languages to be spread out across
multicore, multiprocessor systems for free."


On 4/10/07, Barry Gershenfeld <[EMAIL PROTECTED]> wrote:
I remember a guy talking about a (language or an idea) in which the basic
data element was a queue.  Each function would have a queue passed to it as
an input and it would output its results as another queue.   They guy's name
was LaQuey and this was 20 years ago.

But I guess you could construct that sort of thing using any language that
allowed you to pass pointers as arguments (meaning almost all of them), so
no revelation here.

You can achieve the same things as LISP, Python, etc. in C by
implementing a library and/or interpreter, but it's not really the
same effect. Baking capabilities into a language puts programmers who
use that language on the same page and also influences how they think
about problems. It may also influence other things, like to what
degree the compiler and/or runtime can validate or parallelize (or
something else) your code.

I don't know if I'll find that web site again or not. But I was happy
to find that Wiki page which links to several other sites.

Thanks everyone for the help.


-Chuck

--
[email protected]
http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-lpsg

Reply via email to