> In D (with dlibs) it is:
> 
> auto a = [97, 44, 67, 3, 22, 90, 1, 77, 98, 1078, 6, 64, 6, 79, 42];
> auto b = a.filter((int i){return !(i % 2);});
> 
> In Python:
> 
> a = [97, 44, 67, 3, 22, 90, 1, 77, 98, 1078, 6, 64, 6, 79, 42]
> b = [x for x in a if not(i % 2)]

In Scala :
val a = List(97, 44, 67, 3, 22, 90, 1, 77, 98, 1078, 6, 64, 6, 79, 42)
val b = a filter (_ % 2 == 0)

or val b = a filter (e => e % 2 == 0)
or val b = a filter (e : Int => e % 2 == 0)
or val b = for (e <- a if (e % 2 == 0)) yield e

The first notation "_ % 2 == 0" has no boilerplate and Scala is statically typed (unlike Python).

Cheers,
Sylvain

hsyl20:
> In Scala :
> The first notation "_ % 2 == 0" has no boilerplate and Scala is statically typed (unlike Python).

There's a subtle line between "no boilerplate" and "magic (variables)", and the Python syntax is less magic there. So thanks but no thanks.
I like the type system of Scala, but not every other thing it currently contains.
And if you want static typing take a look at ShedSkin, or RPython.

Bye,
bearophile

"hsyl20" <hsyl20@yahoo.fr> wrote in message news:gmd862$1741$1@digitalmars.com...
>> In D (with dlibs) it is:
>>
>> auto a = [97, 44, 67, 3, 22, 90, 1, 77, 98, 1078, 6, 64, 6, 79, 42];
>> auto b = a.filter((int i){return !(i % 2);});
>>
>> In Python:
>>
>> a = [97, 44, 67, 3, 22, 90, 1, 77, 98, 1078, 6, 64, 6, 79, 42]
>> b = [x for x in a if not(i % 2)]
>
> In Scala :
> val a = List(97, 44, 67, 3, 22, 90, 1, 77, 98, 1078, 6, 64, 6, 79, 42)
> val b = a filter (_ % 2 == 0)
>
> or val b = a filter (e => e % 2 == 0)
> or val b = a filter (e : Int => e % 2 == 0)
> or val b = for (e <- a if (e % 2 == 0)) yield e
>
> The first notation "_ % 2 == 0" has no boilerplate and Scala is statically typed (unlike Python).
>

I like that very much, especially since you can use either the implicit _ or a manually named var. Although I would prefer something like "a", "b", etc, (or maybe "_1", "_2",. etc) instead of "_", because "_" doesn't seem to lend itself well to multi-arg lambdas, for instance, with reduce(). I don't like *needing* to name a var when it's something trivial like in the above examples.

"BCS" <ao@pathlink.com> wrote in message news:78ccfa2d39bdc8cb54edb3210678@news.digitalmars.com...
> Reply to Bill,
>
>>> I was about to say the same thing, but I think Yigal was just mixing
>> two distinct suggestions together:
>> 1) the trailing delegates proposal (aka ruby block) and
>
> I like that
>

Then we're agreed on that part :)

>> 2) A ruby-like syntax for delegate literals : {|a,b| return a+b;}
>
> I don't like that
>

The thing I like about that is that it makes it much more clear at a glance that the "a,b" or "int a, int b" is associated with the code block (but without the problem some languages have of making it hard to distinguish from the block's body). For the sake of syntax-consistency I would be perfectly willing to allow (or even require) functions to be defined the same way:

int add { |int x, int y|
    return x+y;
}

Or:

// "func" used to disambiguate between function call and function
declaration
func add { |int <- int x, int y |
    return x+y;
}

Or maybe parens instead of pipes (this is similar to K&R C, isn't it?):

int add { (int x, int y)
    return x+y;
}

Although I'm sure any of those would be prohibitively unpopular.

>
> One #1 I'd be inclined to requier that the function be defined like
>
>> void DoIt(int delegate(int) dg...)
>
> D laready has this syntax for Typesafe Variadic Functions http://www.digitalmars.com/d/1.0/function.html
>

I'm not quite convinced either way on this. For what reasons do you think the function header should be required to indicate "this uses block syntax"? What's wrong with just saying "If the last arg a function takes is a delegate, then that delegate can optionally be specified with block syntax."?

"Nick Sabalausky" <a@a.a> wrote in message news:gmdtjl$2f4j$1@digitalmars.com...
>
> // "func" used to disambiguate between function call and function
> declaration
> func add { |int <- int x, int y |
>    return x+y;
> }
>

This one has the added benefit of making it easy to distinguish between an attribute of the function and an attribute of the function's return value (Although I guess that's not much of an issue with the current versions of D2).

On Thu, Feb 5, 2009 at 2:30 PM, Nick Sabalausky <a@a.a> wrote:
>>> 2) A ruby-like syntax for delegate literals : {|a,b| return a+b;}
>>
>> I don't like that
>>
>
> The thing I like about that is that it makes it much more clear at a glance that the "a,b" or "int a, int b" is associated with the code block (but without the problem some languages have of making it hard to distinguish from the block's body).

I agree.  Putting the args inside the { } is much more readable to me too. Even just putting the parens inside rather than outside seems an improvement.

Or how about

  { int x; int y :: return x+y; }

> Or maybe parens instead of pipes (this is similar to K&R C, isn't it?):
>
> int add { (int x, int y)
>    return x+y;
> }

K&R was like
    int add(x,y)
       int x;
       int y;
    {  return x+y }

--bb

On Thu, Feb 5, 2009 at 2:56 PM, Bill Baxter <wbaxter@gmail.com> wrote:
> On Thu, Feb 5, 2009 at 2:30 PM, Nick Sabalausky <a@a.a> wrote:
>>>> 2) A ruby-like syntax for delegate literals : {|a,b| return a+b;}
>>>
>>> I don't like that
>>>
>>
>> The thing I like about that is that it makes it much more clear at a glance that the "a,b" or "int a, int b" is associated with the code block (but without the problem some languages have of making it hard to distinguish from the block's body).
>
> I agree.  Putting the args inside the { } is much more readable to me too. Even just putting the parens inside rather than outside seems an improvement.
>
> Or how about
>
>  { int x; int y :: return x+y; }

Oh, and last semicolon of a function should be optional :-)

    { int x; int y :: return x+y }

--bb

Hello Nick,

>> One #1 I'd be inclined to requier that the function be defined like
>> 
>>> void DoIt(int delegate(int) dg...)
>>> 
>> D laready has this syntax for Typesafe Variadic Functions
>> http://www.digitalmars.com/d/1.0/function.html
>> 
> I'm not quite convinced either way on this. For what reasons do you
> think the function header should be required to indicate "this uses
> block syntax"? What's wrong with just saying "If the last arg a
> function takes is a delegate, then that delegate can optionally be
> specified with block syntax."?
> 

I have used bare block statements on occasion and a missing ';' in the wrong place would be nasty to parse. Another option for killing that problem would be to forbid overloading only on a trailing delegate so Foo(int) and Foo(int, int delegate()) would be considered ambiguous (that argues for the ... as then the rule would be to forbid overloading only on block delegates)

"Bill Baxter" <wbaxter@gmail.com> wrote in message news:mailman.651.1233813474.22690.digitalmars-d@puremagic.com...
> On Thu, Feb 5, 2009 at 2:56 PM, Bill Baxter <wbaxter@gmail.com> wrote:
>> On Thu, Feb 5, 2009 at 2:30 PM, Nick Sabalausky <a@a.a> wrote:
>>>>> 2) A ruby-like syntax for delegate literals : {|a,b| return a+b;}
>>>>
>>>> I don't like that
>>>>
>>>
>>> The thing I like about that is that it makes it much more clear at a
>>> glance
>>> that the "a,b" or "int a, int b" is associated with the code block (but
>>> without the problem some languages have of making it hard to distinguish
>>> from the block's body).
>>
>> I agree.  Putting the args inside the { } is much more readable to me
>> too.
>> Even just putting the parens inside rather than outside seems an
>> improvement.
>>
>> Or how about
>>
>>  { int x; int y :: return x+y; }

I'd be fine with that. Actually, I think I like that a little better (for a couple of reasons which I seem to be finding difficult to put into words. It's like, making a clear "split" or division in the block instead of having what looks like this thing that's just kind of floating around, and forever having those two "grouping openers" right next to each other, ie, "{ (" or "{ |" . )

But I'm not sure about replacing the commas with semicolons, unless it meant you could do:

{ int x, y :: return x+y; }

But then, I'm not sure how I feel about that either.

>
> K&R was like
>     int add(x,y)
>        int x;
>        int y;
>     {  return x+y }
>

Oh that's right, I knew it was something funky like that. (That would be a "bad redundancy". /me nods to Walter's Dobbs article.)

>
> Oh, and last semicolon of a function should be optional :-)
>
>    { int x; int y :: return x+y }
>

Now there's a language war waiting to happen ;)

On Thu, Feb 5, 2009 at 3:20 PM, Nick Sabalausky <a@a.a> wrote:
>> K&R was like
>>     int add(x,y)
>>        int x;
>>        int y;
>>     {  return x+y }
>>
>
> Oh that's right, I knew it was something funky like that. (That would be a "bad redundancy". /me nods to Walter's Dobbs article.)

Well the nice thing about it was you could do this:

     int add(x,y)
        CrazyLongTypeName x,y;
     {  return x+y }

Thereby removing some bad redundancy.

--bb