Geoffrey Alan Washburn <[EMAIL PROTECTED]> writes:
> Scala can do much better still because it has first-class functions and
> algebraic data types ("case classes").
Comments on http://lambda-the-ultimate.org/node/view/1136 include links to
Scala http://scala.epfl.ch/examples/files/simpleInterpr
--- Shae Matijs Erisson <[EMAIL PROTECTED]> wrote:
> Geoffrey Alan Washburn <[EMAIL PROTECTED]> writes:
>
> There's also Oleg's
> http://okmij.org/ftp/Computation/monadic-shell.html
> "at the level of UNIX programming, all i/o can be regarded monadic."
Interesting. I had been thinking about I/O
> Maybe this is a different topic, but exploring concurrency in Haskell
> is definitely on my "to do" list, but this is really a bit of a puzzle.
> One thing I've been thinking lately is that in functional programming
> the process is really the wrong abstraction (computation is reduction,
> not a
Bulat Ziganshin:
for pure functional computations concurrency is just one of
IMPLEMENTATION mechanisms, and it doesn't appear in abstractions
DEFINITIONS
Well, there are formal aspects of the specification of concurrency as well.
Do you claim that no language has the right to demand *abstract
Hello Greg,
Saturday, November 26, 2005, 8:25:38 PM, you wrote:
GW> Maybe this is a different topic, but exploring concurrency in Haskell
GW> is definitely on my "to do" list, but this is really a bit of a puzzle.
GW> One thing I've been thinking lately is that in functional programming
GW> the p
Hello jerzy,
Sunday, November 27, 2005, 3:49:07 PM, you wrote:
>> for pure functional computations concurrency is just one of
>> IMPLEMENTATION mechanisms, and it doesn't appear in abstractions
>> DEFINITIONS
jkiuf> Well, there are formal aspects of the specification of concurrency as
well.
jk
--- Bulat Ziganshin <[EMAIL PROTECTED]> wrote:
> Hello Greg,
>
> for pure functional computations concurrency is just one of
> IMPLEMENTATION mechanisms, and it doesn't appear in abstractions
> DEFINITIONS
>
I suppose it depends a bit on the question you're asking. A
multiprocessor, considered
(I'm going to do a lazy permute on your stream of consciousness; hope it
terminates :-).
I think the Rubicon here is the step from one to many -- one
function/procedure to many, one thread to many, one processor to
many, ... . Our favorite pure functions are like the Hoare triples and
Dijkstra we
On Nov 27, 2005, at 2:36 PM, Bill Wood wrote:
(I'm going to do a lazy permute on your stream of consciousness;
hope it
terminates :-).
I think the Rubicon here is the step from one to many -- one
function/procedure to many, one thread to many, one processor to
many, ... . Our favorite pure
