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 (synchroniz
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
>
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).
On Fri, Jan 04, 2008 at 01:13:11PM -0800, Dave Whipp wrote:
> From that
> perspective, it's unfortunate a C loop always iterates arrays in the
> order of their indices.
But it doesn't, in hyper context. In Perl 6, C and C are
really the same thing, and both respond to hyper context.
> As I see
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 ther
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 n
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
> 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 fundament
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
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 s
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 defi
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 keyword (and a
> > keyword corresponding to ) would be a good idea.
> > These would n
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 keyword (and a
> keyword corresponding to ) would be a good idea.
> These would not be quite parallel to and because there
> would be some subtle differen
13 matches
Mail list logo
