April 27, 2008 Re: Automatic Foreach | ||||
---|---|---|---|---|
| ||||
Posted in reply to Bill Baxter | Bill Baxter wrote:
> janderson wrote:
>> Bill Baxter wrote:
>>> janderson wrote:
>>>> What do you think?
>>>
>>> I think it's already hard enough to figure out what's going to get called by something like foo(array)
>>>
>>> It could be
>>> - foo(int[] x)
>>> - foo(int[] x...)
>>> - foo(T)(T x)
>>> - foo(T)(T[] x)
>>> - foo(T...)(T x)
>>> - struct foo { static foo opCall(int[]); }
>>> - struct foo { static foo opCall(int[]...); }
>>> - struct foo { static foo opCall(T)(T x); } etc
>>> - or struct Foo with non-static opCall on instance foo
>>> - or all the same stuff on class ...
>>>
>>> So I don't think another meaning for foo(array) is really helpful.
>>>
>>> I *do* like the idea of an expression (not a statement) that has foreach-like abilities. But I think it should come with some distinguishing syntax.
>>>
>>> In Python it's just [expr(x) for x in array]
>>> Which resonates with Pythons normal loopoing:
>>> for x in array: expr(x)
>>>
>>> So direct translation of that idea to D would be
>>> [expr(x) foreach(x; array)];
>>>
>>> Seems not so terrible a syntax to me.
>>>
>>> --bb
>>
>> I think I prefer:
>>
>> foo(array[]);
>
> I think that already means call foo with a full slice of array, doesn't it? Anyway, even if it doesn't you can overload opSlice() currently so that array[] can mean anything you want it to.
>
> --bb
That's the point though. If there's already an overload available then that should be used. It allows you to come along later and write specialized behavior.
-Joel
|
April 27, 2008 Re: Automatic Foreach | ||||
---|---|---|---|---|
| ||||
Posted in reply to janderson | On 27/04/2008, janderson <askme@me.com> wrote:
> I think I prefer:
>
> foo(array[]);
The problem is that [] already has a defined meaning.
struct S
{
R opSlice() { ... }
}
S array;
foo(array[]);
should call
foo(array.opSlice());
so then you'd have to do
foo(array[][]);
to disambiguate.
Personally, I see absolutely no use for the /existing/ use of [], whereby array[] means array[0..$]. I won't feel a moment's pang of regret if this usage were dropped. That would free up [] to be redeployed for "vector operations".
|
April 27, 2008 Re: Automatic Foreach | ||||
---|---|---|---|---|
| ||||
Posted in reply to janderson | janderson wrote:
> Bill Baxter wrote:
>> janderson wrote:
>>> Bill Baxter wrote:
>>>> janderson wrote:
>>>>> What do you think?
>>>>
>>>> I think it's already hard enough to figure out what's going to get called by something like foo(array)
>>>>
>>>> It could be
>>>> - foo(int[] x)
>>>> - foo(int[] x...)
>>>> - foo(T)(T x)
>>>> - foo(T)(T[] x)
>>>> - foo(T...)(T x)
>>>> - struct foo { static foo opCall(int[]); }
>>>> - struct foo { static foo opCall(int[]...); }
>>>> - struct foo { static foo opCall(T)(T x); } etc
>>>> - or struct Foo with non-static opCall on instance foo
>>>> - or all the same stuff on class ...
>>>>
>>>> So I don't think another meaning for foo(array) is really helpful.
>>>>
>>>> I *do* like the idea of an expression (not a statement) that has foreach-like abilities. But I think it should come with some distinguishing syntax.
>>>>
>>>> In Python it's just [expr(x) for x in array]
>>>> Which resonates with Pythons normal loopoing:
>>>> for x in array: expr(x)
>>>>
>>>> So direct translation of that idea to D would be
>>>> [expr(x) foreach(x; array)];
>>>>
>>>> Seems not so terrible a syntax to me.
>>>>
>>>> --bb
>>>
>>> I think I prefer:
>>>
>>> foo(array[]);
>>
>> I think that already means call foo with a full slice of array, doesn't it? Anyway, even if it doesn't you can overload opSlice() currently so that array[] can mean anything you want it to.
>>
>> --bb
>
> That's the point though. If there's already an overload available then that should be used. It allows you to come along later and write specialized behavior.
Ok I suppose. As long as you're aware what your proposing will break existing code, which means the barrier for accepting the proposal will be a lot higher.
--bb
|
April 27, 2008 Re: Automatic Foreach | ||||
---|---|---|---|---|
| ||||
Posted in reply to janderson | On 27/04/2008, janderson <askme@me.com> wrote:
> I think I prefer:
>
> foo(array[]);
Your suggestion would still ambiguous even if [] were redeployed. Bill's wouldn't. Consider
f(a[]) + g(b[])
Do we mean
f([x foreach(x:a)]) + g([y foreach(y:b)])
or
[f(x) + g(b[i]) foreach(i,x:a)]
?
I have to say, I prefer a variation of Bill's syntax. I'd want foreach at the front, not at the back. Python tries to be more like natural language, but D wants to be more compiler-friendly (easy to parse). So I'd want
[foreach(x:a) expr(x)]
|
April 27, 2008 Re: Automatic Foreach | ||||
---|---|---|---|---|
| ||||
Posted in reply to Bill Baxter | Bill Baxter wrote:
> janderson wrote:
>> Bill Baxter wrote:
>>> janderson wrote:
>>>> Bill Baxter wrote:
>>>>> janderson wrote:
>>>>>> What do you think?
>>>>>
>>>>> I think it's already hard enough to figure out what's going to get called by something like foo(array)
>>>>>
>>>>> It could be
>>>>> - foo(int[] x)
>>>>> - foo(int[] x...)
>>>>> - foo(T)(T x)
>>>>> - foo(T)(T[] x)
>>>>> - foo(T...)(T x)
>>>>> - struct foo { static foo opCall(int[]); }
>>>>> - struct foo { static foo opCall(int[]...); }
>>>>> - struct foo { static foo opCall(T)(T x); } etc
>>>>> - or struct Foo with non-static opCall on instance foo
>>>>> - or all the same stuff on class ...
>>>>>
>>>>> So I don't think another meaning for foo(array) is really helpful.
>>>>>
>>>>> I *do* like the idea of an expression (not a statement) that has foreach-like abilities. But I think it should come with some distinguishing syntax.
>>>>>
>>>>> In Python it's just [expr(x) for x in array]
>>>>> Which resonates with Pythons normal loopoing:
>>>>> for x in array: expr(x)
>>>>>
>>>>> So direct translation of that idea to D would be
>>>>> [expr(x) foreach(x; array)];
>>>>>
>>>>> Seems not so terrible a syntax to me.
>>>>>
>>>>> --bb
>>>>
>>>> I think I prefer:
>>>>
>>>> foo(array[]);
>>>
>>> I think that already means call foo with a full slice of array, doesn't it? Anyway, even if it doesn't you can overload opSlice() currently so that array[] can mean anything you want it to.
>>>
>>> --bb
>>
>> That's the point though. If there's already an overload available then that should be used. It allows you to come along later and write specialized behavior.
>
> Ok I suppose. As long as you're aware what your proposing will break existing code, which means the barrier for accepting the proposal will be a lot higher.
>
> --bb
How?
|
April 27, 2008 Re: Automatic Foreach | ||||
---|---|---|---|---|
| ||||
Posted in reply to janderson | On 27/04/2008, janderson <askme@me.com> wrote:
> > Ok I suppose. As long as you're aware what your proposing will break
> existing code, which means the barrier for accepting the proposal will be a lot higher.
>
> How?
auto a = array1[] ~ array2[];
|
April 27, 2008 Re: Automatic Foreach | ||||
---|---|---|---|---|
| ||||
Actually, I should have said that, in general, Joel's proposal is undefined for all non-unary operations. a[] = b[] + c[] f(a[], b[], c[], d[]) etc. |
April 27, 2008 Re: Automatic Foreach | ||||
---|---|---|---|---|
| ||||
Posted in reply to Janice Caron | Janice Caron wrote:
> Actually, I should have said that, in general, Joel's proposal is
> undefined for all non-unary operations.
>
> a[] = b[] + c[]
>
> f(a[], b[], c[], d[])
>
> etc.
My proposal was to generate nested loops and base it of the order the arrays where specified. However it could just as easily be parallel for all values and require that all arrays are the same size.
-Joel
|
April 27, 2008 Re: Automatic Foreach | ||||
---|---|---|---|---|
| ||||
Posted in reply to janderson | On 27/04/2008, janderson <askme@me.com> wrote: > Janice Caron wrote: > > > Actually, I should have said that, in general, Joel's proposal is undefined for all non-unary operations. > > > > a[] = b[] + c[] > > > > f(a[], b[], c[], d[]) > > > My proposal was to generate nested loops and base it of the order the > arrays where specified. However it could just as easily be parallel for all > values and require that all arrays are the same size. I think I'd be happy with a template in std.algorithm. // a[] = b[] + c[] auto a = parallel!("a = b + c")(a,b,c); // foo(array1[], array2[], array3[], array4[]) parallel!("foo(a,b,c,d)")(array1,array2,array3,array4); Or some such. I'm sure Andrei could write that. He's a clever guy. |
April 27, 2008 Re: Automatic Foreach | ||||
---|---|---|---|---|
| ||||
Posted in reply to janderson | Have a look at the vectorization suggestion http://all-technology.com/eigenpolls/dwishlist/index.php?it=10 on the wish list. http://all-technology.com/eigenpolls/dwishlist/ janderson wrote: > I know Walter has his head stuck in Const/Invarient/Pure multithreading land at the moment. I thought I'd fire off this interesting proposal anyway. > > This is a follow up proposal/suggestion to one I sent a while back. I hope to flesh it out a bit more. > > The idea is to automatically generate for loops for arrays that are used as parameters. It will reduces type safety in one area but makes the language more expressive, particularly for templates. > > Rantional: > Half the time I create a for loop I endup encapsulating it in a > function. If D automatically created the function it would be one less > thing to worry about. If I need specialize behavior I could always > specialize the function later by providing an overload. > if you encapsulating the loop in the function you get 1 functions call and N loop-body executions but if you let d loop the function you get N function calls and N body excutions. You are adding N-1 extra function calls ! Knud |
Copyright © 1999-2021 by the D Language Foundation