On Thu, Feb 5, 2009 at 1:20 AM, Nick Sabalausky <a@a.a> wrote:
> >
> > 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 ;)

Psh!  All that has to happen grammatically is that instead of using a raw semicolon to terminate statements, you have a StatementTerminator nonterminal which goes to either semicolon or non-consuming right brace.  It's trivial to implement in the compiler too.

Nick Sabalausky Wrote:
> > 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.

You can use several "_", for instance:
scala> val a = List(10,5,2,48,75,84,96,85,3,21,52)
a: List[Int] = List(10, 5, 2, 48, 75, 84, 96, 85, 3, 21, 52)

scala> val b = a reduceLeft (_ + _)
b: Int = 481

The only problem is if you want to change arg order. In this case you have to use named parameters.
scala> val b = a reduceLeft (_ - _)
b: Int = -461

scala> val b = a reduceLeft ((a,b) => b - a)
b: Int = -5

Cheers
Sylvain

"BCS" <none@anon.com> wrote in message news:a6268ff24108cb552c70a0af6c@news.digitalmars.com...
> 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)
>

I think I see what you mean. Although, that does create an inconsistency that bothers me a bit, because then some functions with trailing delegate params could be called with block syntax and others couldn't. And then the ones that can be called that way have a restriction on overloading and the ones that can't, don't have that restriction. Just seems messy to me.

Maybe instead of requiring anything in the declaration, any use of the block statement style could be required to include a paramater list (and disallowing block statement style for varargs):

void foo(int a) {/*stuff*/}
void foo(int a, void dg(void)) {/*stuff*/}

// Ok
foo(5, { writefln("hi"); } );

// Ok, calls foo(int)
foo(5);
{ writefln("hi"); }

// Illegal (because of [1]) *even* if the
//    "foo(int)" overload doesn't exist
foo(5)
{ writefln("hi"); }

// Ok, calls foo(int, void delegate(void))
foo(5)
(void)
{ writefln("hi"); }

// Illegal, because of [2]
foo(5);
(void)
{ writefln("hi"); }

// [1]: Already Illegal:
//    (However, this would become ambiguous with [3],
//    but that could be solved by block-statement-style
//    being disallowed for varargs)
writefln("hi")
{ writefln("hi"); }

// [2]: Already Illegal? (Or is it a "verb-less"
//     delegate literal expression statement?):
(int a)
{ writefln("hi"); }

// [3]
writefln("hi", {writefln("hi");} );


This way, it's impossible to take valid code, add or remove a semicolon, and still have valid code (which I think was your main concern?).

Reply to Nick,

> This way, it's impossible to take valid code, add or remove a
> semicolon, and still have valid code (which I think was your main
> concern?).
> 

I think that way can be made even stronger my making the delegate/block need a trailing ';' (it's a function call after all) where a bare block statement does not.

hsyl20 wrote:
> Nick Sabalausky Wrote:
>>> 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.
>
> You can use several "_", for instance:
> scala>  val a = List(10,5,2,48,75,84,96,85,3,21,52)
> a: List[Int] = List(10, 5, 2, 48, 75, 84, 96, 85, 3, 21, 52)
>
> scala>  val b = a reduceLeft (_ + _)
> b: Int = 481
>
> The only problem is if you want to change arg order. In this case you have to use named parameters.
> scala>  val b = a reduceLeft (_ - _)
> b: Int = -461
>
> scala>  val b = a reduceLeft ((a,b) =>  b - a)
> b: Int = -5
>
> Cheers
> Sylvain

this seems counter-intuitive to me. Nemerle uses this syntax for currying which seems to me a much better meaning to this syntax.
for example ( using D like syntax):

int func (string a, char b, int c) { ... }
auto a = func( "hello", _, 8);

the above is syntax sugar for:

auto a = int(char b) { return func("hello", b, 8); };

BCS wrote:
> 
> Why use this:
> 
> "func(someInt) { |a,b| return a+b; };"
> 
> when you can reuse syntax and get this for the same amount of typeing
> 
> "func(someInt) (a,b){ return a+b; };"
> 
> 

While I know the compiler could (should) know the difference easily enough, my eyes want to parse that as a chained call followed bizarrely by a naked block, rather than a block.

That said, I've always found blocks to be one of Ruby's niftiest features (I do a fair bit of Ruby hackage on the side), and would love to see something like it in D2.

-- Chris Nicholson-Sauls

Reply to Yigal,

> Personally I prefer to have syntax for "blocks" like Ruby/smalltalk.
> given the following example function:
> int func(int a, delegate int(int) dg) { .. }
> // call func with [something in this spirit is my favorite]:
> func(someInt) { | int a, int b | return a+b; };
> 

how about require that the block arg in the called function name the args

> int func(int a, delegate int(int val, int thing) dg) { .. }

and then pull in those names implicitly

> func(someInt) { return val+thing; };

This would have implication in overloading and what not but it would be syntactically clean.

BCS wrote:
> Reply to Yigal,
> 
>> Personally I prefer to have syntax for "blocks" like Ruby/smalltalk.
>> given the following example function:
>> int func(int a, delegate int(int) dg) { .. }
>> // call func with [something in this spirit is my favorite]:
>> func(someInt) { | int a, int b | return a+b; };
>>
> 
> how about require that the block arg in the called function name the args
> 
>> int func(int a, delegate int(int val, int thing) dg) { .. }
> 
> and then pull in those names implicitly
> 
>> func(someInt) { return val+thing; };
> 
> This would have implication in overloading and what not but it would be syntactically clean.

Ew, no. Aside from the technical issues, this distances the names from the use thereof (i.e. they'd likely be in separate files)

Robert Fraser wrote:
> BCS wrote:
>> Reply to Yigal,
>>
>>> Personally I prefer to have syntax for "blocks" like Ruby/smalltalk.
>>> given the following example function:
>>> int func(int a, delegate int(int) dg) { .. }
>>> // call func with [something in this spirit is my favorite]:
>>> func(someInt) { | int a, int b | return a+b; };
>>>
>>
>> how about require that the block arg in the called function name the args
>>
>>> int func(int a, delegate int(int val, int thing) dg) { .. }
>>
>> and then pull in those names implicitly
>>
>>> func(someInt) { return val+thing; };
>>
>> This would have implication in overloading and what not but it would be syntactically clean.
> 
> Ew, no. Aside from the technical issues, this distances the names from the use thereof (i.e. they'd likely be in separate files)

While I fundamentally agree, it could also be nice to /allow/ the names in the decleration, as they may be useful for documentation.

-- Chris Nicholson-Sauls