On Thursday, 15 March 2012 at 17:05:00 UTC, Andrei Alexandrescu
wrote:
On 3/15/12 11:30 AM, Manu wrote:
On 15 March 2012 17:32, Andrei Alexandrescu
<seewebsiteforem...@erdani.org
<mailto:seewebsiteforem...@erdani.org>>
wrote:
One note - the code is really ingenious, but I still prefer
swap()
in this case. It's more concise and does less work in the
general case.
swap(a[i + k], a[j + j]);
only computes the indexing once (in source, too).
It all still feels to me like a generally ugly hack around the
original
example:
a,b = b,a;
It's a function call. Why is a function call a ugly hack?
It's also more verbose. Compare
swap(a[i + k], a[i + j]);
with
a[i + k], a[i + j] = a[i + j], a[i + k];
I mean one could even easily miss a typo in there.
There's also semantic issues to be defined. What is the order
of evaluation in
f(), g() = h(), k();
?
All of this adds dead weight to the language. We shouldn't
reach to new syntax for every single little thing.
Andrei
even if swap is preferable here (IMO the syntax improvement here
is negligible) it is still a special case. In the general case
Ruby allows e.g:
a, b, c, d = b, d, a, c
How would you do this with swap?
The order of evaluation is an orthogonal issue to the syntax.
The compiler calculates n functions to produce n values so we
could leave the order undefined.
Some FP languages define order of evaluation (e.g. left to right)
but IMO this is more suitable for older PCs with serial execution
(single processor). It's worth considering for current and future
multi/many-core PCs to instead evaluate the tuple concurrently.
or perhaps provide both options, e.g.
f(), g() // left to right
@parallel f(), g() // separate tasks/threads
Or perhaps even switch the default to make the parallel order the
default and mark the former with a @serial annotation.
