On 04/05/2010 21:19, Andrei Alexandrescu wrote:
Walter Bright wrote:
Don wrote:
Walter Bright wrote:
Don wrote:
There are several compiler bugs relating to array operations, and
almost all relate to this issue. I'd like to fix them, but I need
to know which way it is supposed to work.
The [
On 05/09/2010 04:21 PM, bearophile wrote:
Pelle:
Please, no. :)
Just require @property for assignment-is-a-call code.
Special cases are bd. They are usually not special enough.
Experience shows me that implicit operations or untidy semantics often leads to
big troubles, even when you don
Pelle:
> Please, no. :)
> Just require @property for assignment-is-a-call code.
Special cases are bd. They are usually not special enough.
Experience shows me that implicit operations or untidy semantics often leads to
big troubles, even when you don't see such troubles at first.
The obliga
On 05/04/2010 10:19 PM, Andrei Alexandrescu wrote:
In the same vein, probably it's time to bite the bullet and require
@property for parens-less function calls.
Andrei
Please, no. :)
Just require @property for assignment-is-a-call code.
//requires @property
foo.x = 3;
//does not require @pr
bearophile wrote:
Johan Granberg:
I think it is an
acceptable tradeof that the people that need optimal speed write there code
in a more uncompressed formm using manual loops or wathewer. Then the cases
not on the criitical path of the program can be written more compactly
using a slightly slowe
Johan Granberg:
> I think it is an
> acceptable tradeof that the people that need optimal speed write there code
> in a more uncompressed formm using manual loops or wathewer. Then the cases
> not on the criitical path of the program can be written more compactly
> using a slightly slower but much
Robert Jacques Wrote:
> On Fri, 07 May 2010 09:52:46 -0400, Robert Jacques
> wrote:
> > Given that y[] is really syntactic sugar y[0..$], one option would be to
> > bite the bullet an make [] a dedicated array op/vectorize operator. This
> > would pave the way for using array ops with user
On Fri, 07 May 2010 13:18:04 -0400, Kagamin wrote:
Michel Fortin Wrote:
There is some elegance to that solution since it chooses the right
solution for the problem at hand. If you assign the result to a
temporary array as above, it's probably because you'll need it
somewhere else and thus you
On Fri, 07 May 2010 11:44:18 -0400, Steven Schveighoffer
wrote:
On Fri, 07 May 2010 11:18:37 -0400, Robert Jacques
wrote:
On Fri, 07 May 2010 11:11:47 -0400, Steven Schveighoffer
wrote:
As I've said before, I think a possible compromise to this is to allow
paren-less function calls
Kagamin wrote:
> Johan Granberg Wrote:
>
>> There is another use for array ops as well, that is to create a nice
>> syntax for doing the same operation over all elements in an array. Matlab
>> is doing this in a very nice way and it is far from all uses that
>> requiers optimal speed.
>
> I actu
Michel Fortin Wrote:
> There is some elegance to that solution since it chooses the right
> solution for the problem at hand. If you assign the result to a
> temporary array as above, it's probably because you'll need it
> somewhere else and thus you really need to keep the temporary around.
>
Johan Granberg Wrote:
> There is another use for array ops as well, that is to create a nice syntax
> for doing the same operation over all elements in an array. Matlab is doing
> this in a very nice way and it is far from all uses that requiers optimal
> speed.
I actually saw butthurt about mat
On Fri, 07 May 2010 11:18:37 -0400, Robert Jacques
wrote:
On Fri, 07 May 2010 11:11:47 -0400, Steven Schveighoffer
wrote:
As I've said before, I think a possible compromise to this is to allow
paren-less function calls when the return type is void. These
functions cannot be misinterp
On Fri, 07 May 2010 11:11:47 -0400, Steven Schveighoffer
wrote:
On Fri, 07 May 2010 10:08:22 -0400, Robert Jacques
wrote:
On Tue, 04 May 2010 16:19:09 -0400, Andrei Alexandrescu
wrote:
Walter Bright wrote:
Don wrote:
Walter Bright wrote:
Don wrote:
There are several compiler bugs
On Fri, 07 May 2010 09:52:46 -0400, Robert Jacques
wrote:
Given that y[] is really syntactic sugar y[0..$], one option would be to
bite the bullet an make [] a dedicated array op/vectorize operator. This
would pave the way for using array ops with user defined types (e.g.
matrices and rang
On Fri, 07 May 2010 10:08:22 -0400, Robert Jacques
wrote:
On Tue, 04 May 2010 16:19:09 -0400, Andrei Alexandrescu
wrote:
Walter Bright wrote:
Don wrote:
Walter Bright wrote:
Don wrote:
There are several compiler bugs relating to array operations, and
almost all relate to this issue.
On 2010-05-07 09:52:46 -0400, "Robert Jacques" said:
On Fri, 07 May 2010 07:51:11 -0400, Michel Fortin
wrote:
On 2010-05-07 01:34:39 -0400, "Robert Jacques" said:
And then there's the ambiguous case:
x[] = foo(y[]);
Which is an example of x[] = y; vs x[] = y[]; problem.
True. The pro
On Tue, 04 May 2010 16:19:09 -0400, Andrei Alexandrescu
wrote:
Walter Bright wrote:
Don wrote:
Walter Bright wrote:
Don wrote:
There are several compiler bugs relating to array operations, and
almost all relate to this issue. I'd like to fix them, but I need to
know which way it is sup
On Fri, 07 May 2010 07:51:11 -0400, Michel Fortin
wrote:
On 2010-05-07 01:34:39 -0400, "Robert Jacques" said:
On Fri, 07 May 2010 00:13:04 -0400, Jason House
wrote:
Robert Jacques Wrote:
given
real foo(real value) {...}
and
real[] foo(real[] value) {...}
what should happen with the f
On 2010-05-07 01:34:39 -0400, "Robert Jacques" said:
On Fri, 07 May 2010 00:13:04 -0400, Jason House
wrote:
Robert Jacques Wrote:
given
real foo(real value) {...}
and
real[] foo(real[] value) {...}
what should happen with the follow line of code:
x[] = foo(y[]) + z[];
That can be interp
On Fri, 07 May 2010 00:13:04 -0400, Jason House
wrote:
Robert Jacques Wrote:
given
real foo(real value) {...}
and
real[] foo(real[] value) {...}
what should happen with the follow line of code:
x[] = foo(y[]) + z[];
That can be interpreted in either of the following ways:
foreach(i) x[i]
Robert Jacques Wrote:
> On Thu, 06 May 2010 22:46:42 -0400, Michel Fortin
> wrote:
>
> > On 2010-05-06 21:48:09 -0400, "Robert Jacques" said:
> >
> >> On Thu, 06 May 2010 20:57:07 -0400, Michel Fortin
> >> wrote:
> >>
> >>> On 2010-05-06 19:02:03 -0400, Jason House
> >>> said:
> >>>
>
On Thu, 06 May 2010 22:46:42 -0400, Michel Fortin
wrote:
On 2010-05-06 21:48:09 -0400, "Robert Jacques" said:
On Thu, 06 May 2010 20:57:07 -0400, Michel Fortin
wrote:
On 2010-05-06 19:02:03 -0400, Jason House
said:
Don Wrote:
x[] = sin(y[]);
I strongly favor the first synta
On 2010-05-06 22:46:42 -0400, Michel Fortin said:
That said, I'd expect the compiler to call sin(y) only once, so it'd be
more like that:
auto sinY = sin(y);
for(int i = 0; i < x.length; i++) {
x[i] = sinY[i];
}
And I'd expect that because in the expr
On 2010-05-06 21:48:09 -0400, "Robert Jacques" said:
On Thu, 06 May 2010 20:57:07 -0400, Michel Fortin
wrote:
On 2010-05-06 19:02:03 -0400, Jason House said:
Don Wrote:
x[] = sin(y[]);
I strongly favor the first syntax since it matches how I'd write it in
a for loop.
i.e. I'd re
On Thu, 06 May 2010 20:57:07 -0400, Michel Fortin
wrote:
On 2010-05-06 19:02:03 -0400, Jason House
said:
Don Wrote:
x[] = sin(y[]);
I strongly favor the first syntax since it matches how I'd write it in
a for loop.
i.e. I'd replace [] with [i].
This is the best way to see array
On 2010-05-06 19:02:03 -0400, Jason House said:
Don Wrote:
x[] = sin(y[]);
I strongly favor the first syntax since it matches how I'd write it in
a for loop.
i.e. I'd replace [] with [i].
This is the best way to see array operations I've read up to now:
replace [] with [i], i being th
On Thu, 06 May 2010 19:02:03 -0400, Jason House
wrote:
Don Wrote:
Walter Bright wrote:
> Don wrote:
>> Walter Bright wrote:
>>> Don wrote:
There are several compiler bugs relating to array operations, and
almost all relate to this issue. I'd like to fix them, but I need
to
Don Wrote:
> Walter Bright wrote:
> > Don wrote:
> >> Walter Bright wrote:
> >>> Don wrote:
> There are several compiler bugs relating to array operations, and
> almost all relate to this issue. I'd like to fix them, but I need to
> know which way it is supposed to work.
> >>>
> >
Robert Jacques:
> Do you have some specific examples in mind?
I have tons of specific examples in mind :-)
I have written some things here, and I'd like to write one more time about this:
http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=87311
http://www.digita
On Thu, 06 May 2010 16:54:48 -0400, bearophile
wrote:
Johan Granberg:
Matlab is doing
this in a very nice way and it is far from all uses that requiers
optimal
speed.
Some parts of the Chapel language are exceptionally well designed, and
deserve to be stolen. For numerical computations
On Thu, 06 May 2010 16:48:30 -0400, Don wrote:
Robert Jacques wrote:
On Thu, 06 May 2010 14:40:17 -0400, bearophile
wrote:
Kagamin:
Since sin's result is not an array,<
I am not sure, but I presume here Don was talking about a dispatch of
the sin to all items of an array, so its result
Johan Granberg:
> Matlab is doing
> this in a very nice way and it is far from all uses that requiers optimal
> speed.
Some parts of the Chapel language are exceptionally well designed, and deserve
to be stolen. For numerical computations it looks far better than Fortress.
Bye,
bearophile
Robert Jacques wrote:
On Thu, 06 May 2010 14:40:17 -0400, bearophile
wrote:
Kagamin:
Since sin's result is not an array,<
I am not sure, but I presume here Don was talking about a dispatch of
the sin to all items of an array, so its result is another (new or
mutated in place) array.
Bye,
Robert Jacques wrote:
> On Thu, 06 May 2010 14:40:17 -0400, bearophile
> wrote:
>> Kagamin:
>>> Since sin's result is not an array,<
>>
>> I am not sure, but I presume here Don was talking about a dispatch of
>> the sin to all items of an array, so its result is another (new or
>> mutated in plac
On Thu, 06 May 2010 14:40:17 -0400, bearophile
wrote:
Kagamin:
Since sin's result is not an array,<
I am not sure, but I presume here Don was talking about a dispatch of
the sin to all items of an array, so its result is another (new or
mutated in place) array.
Bye,
bearophile
That
Kagamin:
>Since sin's result is not an array,<
I am not sure, but I presume here Don was talking about a dispatch of the sin
to all items of an array, so its result is another (new or mutated in place)
array.
Bye,
bearophile
Don Wrote:
> Two questions. (1) What happens with functions? For example:
> x[] = sin(y[]);
> OR
> x[] = sin(y[])[];
>
Array op is effectively a statement-wide operation (it can be even deemed as a
statement itself), braces are the hint which arrays are iterated. Since sin's
result is not an ar
On 05/05/10 08:19, Andrei Alexandrescu wrote:
In the same vein, probably it's time to bite the bullet and require
@property for parens-less function calls.
Andrei
Agreed. Is there any word on rewriting things like `fooInstance.prop +=
3` for @properties?
Walter Bright wrote:
Don wrote:
Walter Bright wrote:
Don wrote:
There are several compiler bugs relating to array operations, and
almost all relate to this issue. I'd like to fix them, but I need to
know which way it is supposed to work.
The [] should be required. I worry that otherwise the
Walter Bright wrote:
Don wrote:
Walter Bright wrote:
Don wrote:
There are several compiler bugs relating to array operations, and
almost all relate to this issue. I'd like to fix them, but I need to
know which way it is supposed to work.
The [] should be required. I worry that otherwise the
Don wrote:
Walter Bright wrote:
Don wrote:
There are several compiler bugs relating to array operations, and
almost all relate to this issue. I'd like to fix them, but I need to
know which way it is supposed to work.
The [] should be required. I worry that otherwise there will be
ambiguous
int[3] x, y;
x[] = y * 2; // should work, but currently fails
Don't know if this would cause any compiler problems but y could also be a
scalar value.
So requiring the [] would at least be unambiguous to the programmer.
Hmm, maybe if you have two variables named very similarly and you mistyp
Walter Bright wrote:
Don wrote:
There are several compiler bugs relating to array operations, and
almost all relate to this issue. I'd like to fix them, but I need to
know which way it is supposed to work.
The [] should be required. I worry that otherwise there will be
ambiguous cases that w
Don wrote:
There are several compiler bugs relating to array operations, and almost
all relate to this issue. I'd like to fix them, but I need to know which
way it is supposed to work.
The [] should be required. I worry that otherwise there will be ambiguous cases
that will cause trouble.
According to my reading of the spec, array operations only require []
after the lvalue, not after any of the rvalues. So this should work:
int[3] x, y;
x[] = y * 2; // should work, but currently fails
But in DMD at present, array operations only work if you write [] after
_every_ array.
x[] =
46 matches
Mail list logo
