Re^25: Why is the execution order of subexpressions undefined?

Would you agree that Perl could only implicitly parallelise functions, methods or tied variables if they appear in the same statement?
No. If you want to make a version of perl that works like that, fine. But that certainly doesn't need to be the case.
Comment on Re^25: Why is the execution order of subexpressions undefined?

Replies are listed 'Best First'.
Re^26: Why is the execution order of subexpressions undefined? by BrowserUk (Patriarch) on Apr 18, 2005 at 21:39 UTC
It does, if the concurrency is to be transparent. Yes, you can add extra syntax and mutexes that allow the programmer to indicate that two or more separate statements may be overlapped--but why if you can do it without? Extra syntax introduces extra level of lexical scoping--possible closures. I looked at this a few days ago. What happens when two threads attempt to access the same closure passed in from a level above them? Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error. Lingua non convalesco, consenesco et abolesco. Rule 1 has a caveat! -- Who broke the cabal?	[reply]

Replies are listed 'Best First'.

Re^26: Why is the execution order of subexpressions undefined?
by BrowserUk (Patriarch) on Apr 18, 2005 at 21:39 UTC

It does, if the concurrency is to be transparent. Yes, you can add extra syntax and mutexes that allow the programmer to indicate that two or more separate statements may be overlapped--but why if you can do it without?

Extra syntax introduces extra level of lexical scoping--possible closures. I looked at this a few days ago. What happens when two threads attempt to access the same closure passed in from a level above them?

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

Lingua non convalesco, consenesco et abolesco.

Rule 1 has a caveat! -- Who broke the cabal?

[reply]