On Fri, 2008-01-11 at 10:34 -0800, Dave Whipp wrote:
> Matthew Walton wrote:
>
> > I wouldn't agree with that at all. I think of arrays as ordered constructs,
> > so I'd want the default iteration over my array to happen in the order of
> > the indices.
>
> I guess that depends on whether you th
Matthew Walton wrote:
I wouldn't agree with that at all. I think of arrays as ordered constructs,
so I'd want the default iteration over my array to happen in the order of
the indices.
I guess that depends on whether you think of the array as a list or as a
ram. I know that a group at microso
Springing out of the ashes (and a job where I have to write Java) for my
first post in years:
On Fri, 04 Jan 2008 13:13:11 -0800, Dave Whipp <[EMAIL PROTECTED]> wrote:
> I agree that adding a parallel "forall" (and similar statements) via a
> pragma will be easy if the appropriate underlying mach
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
Dave Whipp wrote:
I was reading Synopsis 4 with regards to multi core programming. It
seems to be infused with a bias towards non-parallel models of
computation. Concurrently appears to be an add-on feature -- whereas
we should have a mindset that explicit sequential constraints are the
add-on
Moritz Lenz wrote:
You can achieve that with the "hyper" list-op (see S02).
Also note that an optimizer is free to automatically add the "hyper"
list op if it can prove that the executed block has no side effects.
Yes, there are some places where things are better than others, which is
why I
At 5:22 PM -0800 1/2/08, Dave Whipp wrote:
I was reading Synopsis 4 with regards to multi core programming. It
seems to be infused with a bias towards non-parallel models of
computation. Concurrently appears to be an add-on feature -- whereas
we should have a mindset that explicit sequential co
Dave Whipp wrote:
> I was reading Synopsis 4 with regards to multi core programming. It
> seems to be infused with a bias towards non-parallel models of
> computation. Concurrently appears to be an add-on feature -- whereas we
> should have a mindset that explicit sequential constraints are the
I was reading Synopsis 4 with regards to multi core programming. It
seems to be infused with a bias towards non-parallel models of
computation. Concurrently appears to be an add-on feature -- whereas we
should have a mindset that explicit sequential constraints are the
add-on feature.
Two sta
21 matches
Mail list logo
