Joe Gottman wrote:
On the other hand, this being Perl, I do believe it should be easy to
specify the concurrent case. I think that a forall keyword (and a
givenall keyword corresponding to given) would be a good idea.
These would not be quite parallel to for and given because there
would
On Jan 4, 2008 9:18 AM, Jonathan Lang [EMAIL PROTECTED] wrote:
Joe Gottman wrote:
On the other hand, this being Perl, I do believe it should be easy to
specify the concurrent case. I think that a forall keyword (and a
givenall keyword corresponding to given) would be a good idea.
Luke Palmer wrote:
forall was about concurrency, not order of evaluation. There is a difference
between running in an arbitrary order serially and running in parallel.
for %bag {
.say;
}
If the bag had elements hello, world, I think printing:
helworld
lo
Would
Am I the only one having bad flashbacks to Occam, here? (Transputing Will
Change Everything!)
My $0.02, FWIW:
Concurrency is surprising. Humans don't think that way. And programs
aren't written that way - any program represented as a byte stream is
inherently sequential in nature.
Where the
Mark J. Reed wrote:
Am I the only one having bad flashbacks to Occam, here? (Transputing Will
Change Everything!)
My $0.02, FWIW:
Concurrency is surprising. Humans don't think that way. And programs
aren't written that way - any program represented as a byte stream is
inherently sequential
I disagree with the idea that humans don't think concurrently (though
more often they think in terms of data dependencies).
I think this is more analogous to event based programming rather than parallel
programming. Event based and parallel based have some similarities but the
are
I (impersonally) believe that hyper context is the right solution to
this because context can propagate to where it needs to dynamically.
As for the fact that it's not the default list context for for,
that could easily be changed with a pragma. Maybe that could even
be the default someday, but
Joe Gottman schreef:
if code that should be processed concurrently
is instead processed sequentially, the results will be correct
Not if parallel sampling of happening stuffs is involved. All of your
thousands of temperature sensors in your nuclear factory, all running
the same code, should
Larry Wall wrote:
It's really, really easy to misdesign a computer language by
overemphasizing one particular design dimension to the detriment
of others.
I agree that adding a parallel forall (and similar statements) via a
pragma will be easy if the appropriate underlying machinery is
On Fri, Jan 04, 2008 at 01:13:11PM -0800, Dave Whipp wrote:
From that
perspective, it's unfortunate a Cfor loop always iterates arrays in the
order of their indices.
But it doesn't, in hyper context. In Perl 6, Cfor and Cmap are
really the same thing, and both respond to hyper context.
As
Dave Whipp wrote:
No, you're not the only person thinking Occam ... though I should point
out that none of my suggestions are par blocks -- a par block made
every statement within the block execute in parallel with the other
statements in that block (much like a Verilog fork/join pair).
No;
Larry Wall wrote:
I (impersonally) believe that hyper context is the right solution to
this because context can propagate to where it needs to dynamically.
As for the fact that it's not the default list context for for,
that could easily be changed with a pragma. Maybe that could even
be the
Larry Wall wrote:
my hope is that we can delegate locking entirely to the innards of
the implementation and never mention it at all on the language level.
Hmm, sounds to me analogous to hoping that type inference will avoid the
need to expose type-annotations at the language level
13 matches
Mail list logo
