www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Is the compiler supposed to accept this?

reply "Brian Schott" <briancschott gmail.com> writes:
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.
Jul 09 2013
next sibling parent Timon Gehr <timon.gehr gmx.ch> writes:
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.
Jul 09 2013
prev sibling next sibling parent reply "Brian Schott" <briancschott gmail.com> writes:
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.
Jul 10 2013
next sibling parent reply Timon Gehr <timon.gehr gmx.ch> writes:
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.
Jul 10 2013
parent Timon Gehr <timon.gehr gmx.ch> writes:
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)
Jul 10 2013
prev sibling parent reply Timon Gehr <timon.gehr gmx.ch> writes:
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.
Jul 10 2013
next sibling parent =?UTF-8?B?QWxpIMOHZWhyZWxp?= <acehreli yahoo.com> writes:
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
Jul 10 2013
prev sibling parent Timon Gehr <timon.gehr gmx.ch> writes:
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
Jul 10 2013
prev sibling next sibling parent "Brian Schott" <briancschott gmail.com> writes:
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. :-)
Jul 10 2013
prev sibling next sibling parent "Brian Schott" <briancschott gmail.com> writes:
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?
Jul 10 2013
prev sibling next sibling parent "deadalnix" <deadalnix gmail.com> writes:
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.
Jul 10 2013
prev sibling next sibling parent Kenji Hara <k.hara.pg gmail.com> writes:
--047d7bf10b4669706904e13439ea
Content-Type: text/plain; charset=UTF-8

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

--047d7bf10b4669706904e13439ea Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr">This is accepts-valid behavior.<div><br></div><div>functio= n(parameters) =3D&gt; expr</div><div><br></div><div>means the combination o= f:</div><div><br></div><div>1. specifying &quot;context pointer is not nece= ssary&quot;</div> <div>2. lambda syntax &quot;(parameters) =3D&gt; expr&quot;</div><div><br><= /div><div>I think website documentation has a bug.</div><div><br></div><div=
Kenji Hara</div><div><br></div></div><div class=3D"gmail_extra"><br><br><d=

2013/7/10 Brian Schott <span dir=3D"ltr">&lt;<a href=3D"mailto:briancschott= gmail.com" target=3D"_blank">briancschott gmail.com</a>&gt;</span><br><blo= ckquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #c= cc solid;padding-left:1ex"> While finishing up work on my parser and grammar specification I found this= in container.d:<br> <br> return equal!(function(Elem a, Elem b) =3D&gt; !_less(a,b) &amp;&amp; !_les= s(b,a))<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0(thisRange, thatRange);<br> <br> It seems to be some strange hybrid of the function literal syntax and the l= ambda syntax. It&#39;s not documented anywhere (surprise!) and I&#39;m not = sure if I should support it or file an accepts-invalid bug against DMD.<br> </blockquote></div><br></div> --047d7bf10b4669706904e13439ea--
Jul 10 2013
prev sibling next sibling parent Kenji Hara <k.hara.pg gmail.com> writes:
--f46d044287e0a1a25304e135404c
Content-Type: text/plain; charset=UTF-8

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.pg 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 <briancschott 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.


--f46d044287e0a1a25304e135404c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr">I filed the website bug in bugzilla, and posted pull reque= st.<div><br></div><div><a href=3D"http://d.puremagic.com/issues/show_bug.cg= i?id=3D10605">http://d.puremagic.com/issues/show_bug.cgi?id=3D10605</a>=C2= =A0<br></div> <div><a href=3D"https://github.com/D-Programming-Language/dlang.org/pull/35= 1">https://github.com/D-Programming-Language/dlang.org/pull/351</a>=C2=A0<b= r></div><div><br></div><div>Kenji Hara</div></div><div class=3D"gmail_extra= "><br> <br><div class=3D"gmail_quote">2013/7/11 Kenji Hara <span dir=3D"ltr">&lt;<= a href=3D"mailto:k.hara.pg gmail.com" target=3D"_blank">k.hara.pg gmail.com= </a>&gt;</span><br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 = .8ex;border-left:1px #ccc solid;padding-left:1ex"> <div dir=3D"ltr">This is accepts-valid behavior.<div><br></div><div>functio= n(parameters) =3D&gt; expr</div><div><br></div><div>means the combination o= f:</div><div><br></div><div>1. specifying &quot;context pointer is not nece= ssary&quot;</div> <div>2. lambda syntax &quot;(parameters) =3D&gt; expr&quot;</div><div><br><= /div><div>I think website documentation has a bug.</div><span class=3D"HOEn= Zb"><font color=3D"#888888"><div><br></div><div>Kenji Hara</div><div><br></= div> </font></span></div><div class=3D"HOEnZb"><div class=3D"h5"><div class=3D"g= mail_extra"><br><br><div class=3D"gmail_quote"> 2013/7/10 Brian Schott <span dir=3D"ltr">&lt;<a href=3D"mailto:briancschott= gmail.com" target=3D"_blank">briancschott gmail.com</a>&gt;</span><br><blo= ckquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #c= cc solid;padding-left:1ex"> While finishing up work on my parser and grammar specification I found this= in container.d:<br> <br> return equal!(function(Elem a, Elem b) =3D&gt; !_less(a,b) &amp;&amp; !_les= s(b,a))<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0(thisRange, thatRange);<br> <br> It seems to be some strange hybrid of the function literal syntax and the l= ambda syntax. It&#39;s not documented anywhere (surprise!) and I&#39;m not = sure if I should support it or file an accepts-invalid bug against DMD.<br> </blockquote></div><br></div> </div></div></blockquote></div><br></div> --f46d044287e0a1a25304e135404c--
Jul 10 2013
prev sibling parent "deadalnix" <deadalnix gmail.com> writes:
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
Jul 11 2013