Re: Is the compiler supposed to accept this?
On Thursday, 11 July 2013 at 04:59:14 UTC, Kenji Hara wrote: I filed the website bug in bugzilla, and posted pull request. http://d.puremagic.com/issues/show_bug.cgi?id=10605 https://github.com/D-Programming-Language/dlang.org/pull/351 Kenji Hara http://msalvarez1.edublogs.org/files/2010/01/rock_rule2.jpg
Re: Is the compiler supposed to accept this?
There are severel comments in the part of the dmd front end that
show the syntax that the parser is looking for. Here's a listing:
// function type (parameters) { statements... }
// delegate type (parameters) { statements... }
// function (parameters) { statements... }
// delegate (parameters) { statements... }
// function { statements... }
// delegate { statements... }
// (parameters) { statements... }
// { statements... }
// identifier = expression
Based on the fact that function (parameters) = expression
isn't written out like the others, I'm going to file an
accepts-valid bug for this.
Re: Is the compiler supposed to accept this?
On 07/10/2013 07:47 PM, Brian Schott wrote:
There are severel comments in the part of the dmd front end that show
the syntax that the parser is looking for. Here's a listing:
// function type (parameters) { statements... }
// delegate type (parameters) { statements... }
// function (parameters) { statements... }
// delegate (parameters) { statements... }
// function { statements... }
// delegate { statements... }
// (parameters) { statements... }
// { statements... }
// identifier = expression
Based on the fact that function (parameters) = expression isn't
written out like the others, I'm going to file an accepts-valid bug for
this.
Accepts-valid is not a bug.
Re: Is the compiler supposed to accept this?
On Wednesday, 10 July 2013 at 18:17:07 UTC, Timon Gehr wrote: Accepts-valid is not a bug. I think you know what I meant. :-)
Re: Is the compiler supposed to accept this?
On 07/10/2013 08:47 PM, Brian Schott wrote: On Wednesday, 10 July 2013 at 18:17:07 UTC, Timon Gehr wrote: Accepts-valid is not a bug. I think you know what I meant. :-) Well, I am going to guess you meant accepts-invalid, though I'd prefer if you didn't. :o)
Re: Is the compiler supposed to accept this?
On 07/10/2013 07:47 PM, Brian Schott wrote:
There are severel comments in the part of the dmd front end that show
the syntax that the parser is looking for. Here's a listing:
// function type (parameters) { statements... }
// delegate type (parameters) { statements... }
// function (parameters) { statements... }
// delegate (parameters) { statements... }
// function { statements... }
// delegate { statements... }
// (parameters) { statements... }
// { statements... }
// identifier = expression
Based on the fact that function (parameters) = expression isn't
written out like the others,
You mean, like some others.
I'm going to file an [...] bug for this.
// (parameters) = expression ?
In any case, please consider that it actually makes no sense to restrict
the expressiveness of the type signature based on how the function body
is specified. (Why on earth should one have to use the { return
expression; } syntax just in order to be able to assert that no context
pointer is required?)
The documentation is in error here.
Re: Is the compiler supposed to accept this?
On Wednesday, 10 July 2013 at 21:16:30 UTC, Timon Gehr wrote:
// (parameters) = expression ?
In any case, please consider that it actually makes no sense to
restrict the expressiveness of the type signature based on how
the function body is specified. (Why on earth should one have
to use the { return expression; } syntax just in order to be
able to assert that no context pointer is required?)
The documentation is in error here.
(parameters) = expression is mentioned in the source and I
agree it's valid. I must have forgotton to copy-paste it.
I don't agree that function(parameters) = expression is valid
though. Can any of the DMD devs clear up if this is intended?
Re: Is the compiler supposed to accept this?
On 07/10/2013 02:32 PM, Brian Schott wrote: On Wednesday, 10 July 2013 at 21:16:30 UTC, Timon Gehr wrote: The documentation is in error here. (parameters) = expression is mentioned in the source and I agree it's valid. I must have forgotton to copy-paste it. I don't agree that function(parameters) = expression is valid though. Can any of the DMD devs clear up if this is intended? According to spec function(parameters) = expression is not valid. http://dlang.org/expression.html Lambda: Identifier = AssignExpression ParameterAttributes = AssignExpression Neither of those allow 'function' or 'delegate' keyword. However, I agree with Timon Gehr that the spec should be changed to match the current behavior. Ali
Re: Is the compiler supposed to accept this?
On 07/10/2013 11:32 PM, Brian Schott wrote:
On Wednesday, 10 July 2013 at 21:16:30 UTC, Timon Gehr wrote:
// (parameters) = expression ?
In any case, please consider that it actually makes no sense to
restrict the expressiveness of the type signature based on how the
function body is specified. (Why on earth should one have to use the {
return expression; } syntax just in order to be able to assert that no
context pointer is required?)
The documentation is in error here.
(parameters) = expression is mentioned in the source and I agree it's
valid. I must have forgotton to copy-paste it.
I don't agree that function(parameters) = expression is valid though.
Yes, you said that. What I do not understand is why. I think common
sense would mandate that it should be valid syntax.
Can any of the DMD devs clear up if this is intended?
This is the relevant pull:
https://github.com/D-Programming-Language/dmd/commit/675898721c04d0bf155a85abf986eae99c37c0dc
Re: Is the compiler supposed to accept this?
On Wednesday, 10 July 2013 at 21:33:00 UTC, Brian Schott wrote:
On Wednesday, 10 July 2013 at 21:16:30 UTC, Timon Gehr wrote:
// (parameters) = expression ?
In any case, please consider that it actually makes no sense
to restrict the expressiveness of the type signature based on
how the function body is specified. (Why on earth should one
have to use the { return expression; } syntax just in order to
be able to assert that no context pointer is required?)
The documentation is in error here.
(parameters) = expression is mentioned in the source and I
agree it's valid. I must have forgotton to copy-paste it.
I don't agree that function(parameters) = expression is
valid though. Can any of the DMD devs clear up if this is
intended?
I don't see how DMD implementation matters here. This is language
design issue.
Re: Is the compiler supposed to accept this?
This is accepts-valid behavior. function(parameters) = expr means the combination of: 1. specifying context pointer is not necessary 2. lambda syntax (parameters) = expr I think website documentation has a bug. Kenji Hara 2013/7/10 Brian Schott briancsch...@gmail.com While finishing up work on my parser and grammar specification I found this in container.d: return equal!(function(Elem a, Elem b) = !_less(a,b) !_less(b,a)) (thisRange, thatRange); It seems to be some strange hybrid of the function literal syntax and the lambda syntax. It's not documented anywhere (surprise!) and I'm not sure if I should support it or file an accepts-invalid bug against DMD.
Re: Is the compiler supposed to accept this?
I filed the website bug in bugzilla, and posted pull request. http://d.puremagic.com/issues/show_bug.cgi?id=10605 https://github.com/D-Programming-Language/dlang.org/pull/351 Kenji Hara 2013/7/11 Kenji Hara k.hara...@gmail.com This is accepts-valid behavior. function(parameters) = expr means the combination of: 1. specifying context pointer is not necessary 2. lambda syntax (parameters) = expr I think website documentation has a bug. Kenji Hara 2013/7/10 Brian Schott briancsch...@gmail.com While finishing up work on my parser and grammar specification I found this in container.d: return equal!(function(Elem a, Elem b) = !_less(a,b) !_less(b,a)) (thisRange, thatRange); It seems to be some strange hybrid of the function literal syntax and the lambda syntax. It's not documented anywhere (surprise!) and I'm not sure if I should support it or file an accepts-invalid bug against DMD.
Re: Is the compiler supposed to accept this?
On 07/10/2013 01:24 AM, Brian Schott wrote:
While finishing up work on my parser and grammar specification I found
this in container.d:
return equal!(function(Elem a, Elem b) = !_less(a,b) !_less(b,a))
(thisRange, thatRange);
It seems to be some strange hybrid of the function literal syntax and
the lambda syntax.
=... is supposed to be just a shorthand for { return ...; }
It's not documented anywhere (surprise!) and I'm not
sure if I should support it or file an accepts-invalid bug against DMD.
I'd say support it and file a bug against the documentation.
