View mode: basic / threaded / horizontal-split · Log in · Help
April 27, 2008
Re: Automatic Foreach
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
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
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
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
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
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
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
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
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
1 2 3 4
Top | Discussion index | About this forum | D home