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

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".

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

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)]

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?

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[];

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.

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

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.

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