View mode: basic / threaded / horizontal-split · Log in · Help
October 07, 2008
Re: shouting versus dotting
KennyTM~ wrote:
> Benji Smith wrote:
>> Jarrett Billingsley wrote:
>>> On Sun, Oct 5, 2008 at 8:57 PM, Chris R. Miller
>>> <lordsauronthegreat@gmail.com> wrote:
>>>> The !() syntax seems to serve only as a heads up that it's a template.
>>>> Otherwise (as far as I can tell) a simple foo(int)(bar, baaz) would 
>>>> work
>>>> just as well as foo!(int)(bar, baaz).
>>>>
>>>
>>> Unambiguous grammar, you fail it.
>>>
>>> foo(bar)(baz); // template instantiation or a chained call?
>>>
>>> This _can_ be _made_ to work, but it would mean that the parse tree
>>> would be dependent upon semantic analysis, and that just makes things
>>> slow and awful.  I.e. C++.
>>
>> I'd be happy to get rid of OpCall, which I've always found confusing 
>> and pointless.
>>
>> --benji
> 
> That's going to break a lot of struct constructors using static opCalls.

Only because structs should have had constructors from the start. Using 
opCall was always a hack around the lack of constructors on structs.

opCall is a source of numerous language ambiguities that make other 
features more difficult to implement. For example, template 
instantiation could be done with bare parentheses ("Template(args)" 
instead of "Template!(args)" or "Template{args}") if opCall was eliminated.

--benji
October 07, 2008
Re: shouting versus dotting
Benji Smith wrote:
> KennyTM~ wrote:
>> Benji Smith wrote:
>>> Jarrett Billingsley wrote:
>>>> On Sun, Oct 5, 2008 at 8:57 PM, Chris R. Miller
>>>> <lordsauronthegreat@gmail.com> wrote:
>>>>> The !() syntax seems to serve only as a heads up that it's a template.
>>>>> Otherwise (as far as I can tell) a simple foo(int)(bar, baaz) would 
>>>>> work
>>>>> just as well as foo!(int)(bar, baaz).
>>>>>
>>>>
>>>> Unambiguous grammar, you fail it.
>>>>
>>>> foo(bar)(baz); // template instantiation or a chained call?
>>>>
>>>> This _can_ be _made_ to work, but it would mean that the parse tree
>>>> would be dependent upon semantic analysis, and that just makes things
>>>> slow and awful.  I.e. C++.
>>>
>>> I'd be happy to get rid of OpCall, which I've always found confusing 
>>> and pointless.
>>>
>>> --benji
>>
>> That's going to break a lot of struct constructors using static opCalls.
> 
> Only because structs should have had constructors from the start. Using 
> opCall was always a hack around the lack of constructors on structs.
> 
> opCall is a source of numerous language ambiguities that make other 
> features more difficult to implement. For example, template 
> instantiation could be done with bare parentheses ("Template(args)" 
> instead of "Template!(args)" or "Template{args}") if opCall was eliminated.
> 
> --benji

But what about a method that returns a delegate?
October 07, 2008
Re: shouting versus dotting
Jarrett Billingsley wrote:
> On Mon, Oct 6, 2008 at 6:59 AM, Denis Koroskin <2korden@gmail.com> wrote:
> 
>> If we don't omit parenthesises, the ambiguity goes away:
>>
>> foo()(5)
>> foo(5)()
>>
> 
> No it doesn't.
> 
> Stdout("foo")("bar!").newline;

This is one of the main reasons I dislike opCall.

Combined with optional-parentheses for function invocation, opCall is a 
poison-pill that creates a lot of potential ambiguities and prevents the 
implementation of more compelling features.

--benji
October 07, 2008
Re: shouting versus dotting
Andrei Alexandrescu wrote:
> Alexander Pánek wrote:
>> Benji Smith wrote:
>>> Andrei Alexandrescu wrote:
>>>> I'd want to give it a try. How do others feel about 
>>>> Template{arguments}?
>>>
>>>
>>> At first glance, I like it better than !(), especially since it saves 
>>> a character, making nested templates much nicer:
>>>
>>>    auto map = new Map{T[], List{MyType}}();     // not too bad
>>>    auto map = new Map!(T[], List!(MyType))();   // not too good
>>>    auto map = new Map<T[], List<MyType>>();     // still my favorite
>>>
>>> It's too bad the shift operators can't be changed. Personally, I 
>>> think the angle brackets are more valuable as a matched pair of 
>>> enclosures.
>>>
>>> We could redefine the shift operators to be:
>>>
>>>    -->  RIGHT SHIFT
>>>    <--  LEFT SHIFT
>>>    -->> SIGNED RIGHT SHIFT
>>>
>>> And then the angle brackets could be coopted for templates.
>>
>> No way! :(
>> ’em pointed brackets are way too pointy. I like having parenthesis for 
>> templates.
> 
> Well another problem is we'd need to redefine the less-than and 
> greater-than operators too.
> 
> Andrei

Oh yeah. I don't know how I missed that. <smacks forehead>

--benji
October 07, 2008
Re: shouting versus dotting
Andrei Alexandrescu wrote:
> b) Template@Arg and Template@(Args)
> 
> This approach not only accepts the need for a contraption, it actually 
> leverages it by allowing you to drop the parens if you only have one 
> argument. That way "@" becomes a true operator, the template 
> instantiation operator. Note that this can be done with the current "!" 
> as well, except that Template!Arg does not look to me like anything 
> enticing.

Interesting.

   // If this is possible.......
   auto myTemplate = Template @ (1, 2, 3, uint);

   // ......shouldn't this be possible too?
   auto args = (1, 2, 3, uint);
   auto myTemplate = Template @ args;

All other binary operators can operate on either a literal or on an 
expression, and I'd expect a template instantiation operator to do the same.

What do you think?

--benji
October 07, 2008
Re: shouting versus dotting
Don wrote:
> Bill Baxter wrote:
>> On Tue, Oct 7, 2008 at 2:25 AM, superdan <super@dan.org> wrote:
>>> Bill Baxter Wrote:
>>>
>>>> On Mon, Oct 6, 2008 at 11:58 PM, Steven Schveighoffer
>>>> <schveiguy@yahoo.com> wrote:
>>>>> "Ary Borenszweig" wrote
>>>>> I still vote to keep ! as it's the easiest solution, and I never 
>>>>> have found
>>>>> it annoying ;)
>>>> Yeh, me too.
>>>>
>>>> The @ (and #) also take up too much width in a small mono-space font
>>>> like the Proggy font I use.  And so they run into the previous and
>>>> following chars making them less readable.   ! is nice and thin so it
>>>> doesn't have that problem.
>>>>
>>>> { } vs ( ) is also a fairly subtle distinction in a small font.
>>>> Usually the context and usage is different enough that that doesn't
>>>> matter.   But of course you may just tell me I should change my font
>>>> in that case.
>>> spoken like a true prodigy. yeah. change yer font.
>>
>> Well, I think it's more a matter of the size than the particular font,
>> though.  So the remedy would probably be to switch to a font that
>> takes up more screen real-estate, meaning I'll get fewer lines of D to
>> the page.
>>
>> But there *is* a difference between { and ( even with Proggy at 6x10
>> -- 2 pixels are shifted one position.  I suppose it's not any more
>> subtle than the difference between . and , which is seen everywhere.
>> I'm sure I could get used to it if it's what the D community thinks is
>> best.   Anyway I think foo{} is more readable than foo.().
>>
>>> thing is that's important. i don't mind !() much myself. like a mole 
>>> on an otherwise fine piece of ass. got used to it. but like u i also 
>>> remember in the beginning i was like, what's wrong with walt did he 
>>> run out of ideas or what.
>>>
>>> to some1 coming anew to d stuff like what!(the!(hell!())) is freakin' 
>>> weird. no two ways about it. you just keep starin' at that mole like 
>>> austin powers. if there's a way to get rid of it then whynot. helps 
>>> attract newcomerz eh.
>>
>> I thought it was bizarre till I read the justification here
>>    http://www.digitalmars.com/d/1.0/templates-revisited.html.
>> Then  I thought, OK.  Not a bad idea.  It's better than parsing
>> ambiguities, and being forced to insert spaces between punctuation to
>> avoid them.
>>
>> But I agree that as an utter newbie to D, foo{bar} would probably have
>> seemed more elegant and obvious as a template syntax than re-purposing
>> the unary NOT operator.  The newbie's response to "foo{bar} is a
>> template instantiation" would probably be "ok, sure." instead of
>> "Why??"
>>
>> Still it seems like a big bike shed issue.  And it's bizarre coming
>> from the guy who's usually the first one to call "bike shed" anytime
>> anyone else makes a suggestion to improve aesthetics.
> 
> I agree with all these. There's a lot of other things I wish Andrei were 
> working on instead.

I am, I am. Soon as Walter fixes a few bugs, I'll rewrite std.algorithm 
(and add some more to it) in terms of ranges. Map and reduce will likely 
be lazyfied. Also std.random will define ranges instead of the current 
ad-hoc interface that works but is not integrated with anything in 
particular. But bear with me; I have a paper deadline staring me in the 
face and a thesis to finish.

> I'd hope for a colossal benefit, from something which would break almost 
> all my code...

Not going to break anything, as I explained.

> (BTW Putting template parameters inside normal parens would be an 
> adequate benefit).

I agree.


Andrei
October 07, 2008
Re: shouting versus dotting
Don pisze:
> Bill Baxter wrote:
>> On Tue, Oct 7, 2008 at 2:25 AM, superdan <super@dan.org> wrote:
>>> Bill Baxter Wrote:
>>>
>>>> On Mon, Oct 6, 2008 at 11:58 PM, Steven Schveighoffer
>>>> <schveiguy@yahoo.com> wrote:
>>>>> "Ary Borenszweig" wrote
>>>>> I still vote to keep ! as it's the easiest solution, and I never 
>>>>> have found
>>>>> it annoying ;)
>>>> Yeh, me too.
>>>>
>>>> The @ (and #) also take up too much width in a small mono-space font
>>>> like the Proggy font I use.  And so they run into the previous and
>>>> following chars making them less readable.   ! is nice and thin so it
>>>> doesn't have that problem.
>>>>
>>>> { } vs ( ) is also a fairly subtle distinction in a small font.
>>>> Usually the context and usage is different enough that that doesn't
>>>> matter.   But of course you may just tell me I should change my font
>>>> in that case.
>>> spoken like a true prodigy. yeah. change yer font.
>>
>> Well, I think it's more a matter of the size than the particular font,
>> though.  So the remedy would probably be to switch to a font that
>> takes up more screen real-estate, meaning I'll get fewer lines of D to
>> the page.
>>
>> But there *is* a difference between { and ( even with Proggy at 6x10
>> -- 2 pixels are shifted one position.  I suppose it's not any more
>> subtle than the difference between . and , which is seen everywhere.
>> I'm sure I could get used to it if it's what the D community thinks is
>> best.   Anyway I think foo{} is more readable than foo.().
>>
>>> thing is that's important. i don't mind !() much myself. like a mole 
>>> on an otherwise fine piece of ass. got used to it. but like u i also 
>>> remember in the beginning i was like, what's wrong with walt did he 
>>> run out of ideas or what.
>>>
>>> to some1 coming anew to d stuff like what!(the!(hell!())) is freakin' 
>>> weird. no two ways about it. you just keep starin' at that mole like 
>>> austin powers. if there's a way to get rid of it then whynot. helps 
>>> attract newcomerz eh.
>>
>> I thought it was bizarre till I read the justification here
>>    http://www.digitalmars.com/d/1.0/templates-revisited.html.
>> Then  I thought, OK.  Not a bad idea.  It's better than parsing
>> ambiguities, and being forced to insert spaces between punctuation to
>> avoid them.
>>
>> But I agree that as an utter newbie to D, foo{bar} would probably have
>> seemed more elegant and obvious as a template syntax than re-purposing
>> the unary NOT operator.  The newbie's response to "foo{bar} is a
>> template instantiation" would probably be "ok, sure." instead of
>> "Why??"
>>
>> Still it seems like a big bike shed issue.  And it's bizarre coming
>> from the guy who's usually the first one to call "bike shed" anytime
>> anyone else makes a suggestion to improve aesthetics.
> 
> I agree with all these. There's a lot of other things I wish Andrei were 
> working on instead.
> I'd hope for a colossal benefit, from something which would break almost 
> all my code...
> 
> (BTW Putting template parameters inside normal parens would be an 
> adequate benefit).
> 
> 

Well, I want just say "I agree" to all written above by Bill, Don and 
others who like current syntax.

I wanted to write a bit more today morning but I stopped myself as I 
would probably write too much :-P

------

I would be much more happy with implementation of my proposal:
http://d.puremagic.com/issues/show_bug.cgi?id=1827

I mean here especially syntax for "is expression" for templates.

http://digitalmars.com/d/1.0/expression.html#IsExpression

As it occurred on Tango conference in talk of Rafał Bocian (who lead the 
D course for students) syntax for "is expression" and specification 
(among few other things) is especially difficult for newbies in D.

Unfortunately answer from Walter, why he didn't decide to change current 
 syntax was.... guess what? --- It doesn't look nice in code...

Bad luck, said sad pirate .(

BR
Marcin Kuszczak
(aarti_pl)
October 07, 2008
Re: shouting versus dotting
Benji Smith wrote:
> Andrei Alexandrescu wrote:
>> b) Template@Arg and Template@(Args)
>>
>> This approach not only accepts the need for a contraption, it actually 
>> leverages it by allowing you to drop the parens if you only have one 
>> argument. That way "@" becomes a true operator, the template 
>> instantiation operator. Note that this can be done with the current 
>> "!" as well, except that Template!Arg does not look to me like 
>> anything enticing.
> 
> Interesting.
> 
>    // If this is possible.......
>    auto myTemplate = Template @ (1, 2, 3, uint);
> 
>    // ......shouldn't this be possible too?
>    auto args = (1, 2, 3, uint);
>    auto myTemplate = Template @ args;
> 
> All other binary operators can operate on either a literal or on an 
> expression, and I'd expect a template instantiation operator to do the 
> same.
> 
> What do you think?

I think you will have a hard time (re)using parentheses and commas to 
define literals.

Andrei
October 07, 2008
Re: shouting versus dotting
Aarti_pl wrote:
> Don pisze:
>> Bill Baxter wrote:
>>> On Tue, Oct 7, 2008 at 2:25 AM, superdan <super@dan.org> wrote:
>>>> Bill Baxter Wrote:
>>>>
>>>>> On Mon, Oct 6, 2008 at 11:58 PM, Steven Schveighoffer
>>>>> <schveiguy@yahoo.com> wrote:
>>>>>> "Ary Borenszweig" wrote
>>>>>> I still vote to keep ! as it's the easiest solution, and I never 
>>>>>> have found
>>>>>> it annoying ;)
>>>>> Yeh, me too.
>>>>>
>>>>> The @ (and #) also take up too much width in a small mono-space font
>>>>> like the Proggy font I use.  And so they run into the previous and
>>>>> following chars making them less readable.   ! is nice and thin so it
>>>>> doesn't have that problem.
>>>>>
>>>>> { } vs ( ) is also a fairly subtle distinction in a small font.
>>>>> Usually the context and usage is different enough that that doesn't
>>>>> matter.   But of course you may just tell me I should change my font
>>>>> in that case.
>>>> spoken like a true prodigy. yeah. change yer font.
>>>
>>> Well, I think it's more a matter of the size than the particular font,
>>> though.  So the remedy would probably be to switch to a font that
>>> takes up more screen real-estate, meaning I'll get fewer lines of D to
>>> the page.
>>>
>>> But there *is* a difference between { and ( even with Proggy at 6x10
>>> -- 2 pixels are shifted one position.  I suppose it's not any more
>>> subtle than the difference between . and , which is seen everywhere.
>>> I'm sure I could get used to it if it's what the D community thinks is
>>> best.   Anyway I think foo{} is more readable than foo.().
>>>
>>>> thing is that's important. i don't mind !() much myself. like a mole 
>>>> on an otherwise fine piece of ass. got used to it. but like u i also 
>>>> remember in the beginning i was like, what's wrong with walt did he 
>>>> run out of ideas or what.
>>>>
>>>> to some1 coming anew to d stuff like what!(the!(hell!())) is 
>>>> freakin' weird. no two ways about it. you just keep starin' at that 
>>>> mole like austin powers. if there's a way to get rid of it then 
>>>> whynot. helps attract newcomerz eh.
>>>
>>> I thought it was bizarre till I read the justification here
>>>    http://www.digitalmars.com/d/1.0/templates-revisited.html.
>>> Then  I thought, OK.  Not a bad idea.  It's better than parsing
>>> ambiguities, and being forced to insert spaces between punctuation to
>>> avoid them.
>>>
>>> But I agree that as an utter newbie to D, foo{bar} would probably have
>>> seemed more elegant and obvious as a template syntax than re-purposing
>>> the unary NOT operator.  The newbie's response to "foo{bar} is a
>>> template instantiation" would probably be "ok, sure." instead of
>>> "Why??"
>>>
>>> Still it seems like a big bike shed issue.  And it's bizarre coming
>>> from the guy who's usually the first one to call "bike shed" anytime
>>> anyone else makes a suggestion to improve aesthetics.
>>
>> I agree with all these. There's a lot of other things I wish Andrei 
>> were working on instead.
>> I'd hope for a colossal benefit, from something which would break 
>> almost all my code...
>>
>> (BTW Putting template parameters inside normal parens would be an 
>> adequate benefit).
>>
>>
> 
> Well, I want just say "I agree" to all written above by Bill, Don and 
> others who like current syntax.
> 
> I wanted to write a bit more today morning but I stopped myself as I 
> would probably write too much :-P
> 
> ------
> 
> I would be much more happy with implementation of my proposal:
> http://d.puremagic.com/issues/show_bug.cgi?id=1827
> 
> I mean here especially syntax for "is expression" for templates.
> 
> http://digitalmars.com/d/1.0/expression.html#IsExpression
> 
> As it occurred on Tango conference in talk of Rafał Bocian (who lead the 
> D course for students) syntax for "is expression" and specification 
> (among few other things) is especially difficult for newbies in D.
> 
> Unfortunately answer from Walter, why he didn't decide to change current 
>  syntax was.... guess what? --- It doesn't look nice in code...
> 
> Bad luck, said sad pirate .(
> 
> BR
> Marcin Kuszczak
> (aarti_pl)

Your proposal should be reevaluated in wake of the conditional 
templates, which Walter has implemented a couple of releases ago.

Andrei
October 07, 2008
Re: shouting versus dotting
KennyTM~ wrote:
> Benji Smith wrote:
>> KennyTM~ wrote:
>>> Benji Smith wrote:
>>>> Jarrett Billingsley wrote:
>>>>> On Sun, Oct 5, 2008 at 8:57 PM, Chris R. Miller
>>>>> <lordsauronthegreat@gmail.com> wrote:
>>>>>> The !() syntax seems to serve only as a heads up that it's a 
>>>>>> template.
>>>>>> Otherwise (as far as I can tell) a simple foo(int)(bar, baaz) 
>>>>>> would work
>>>>>> just as well as foo!(int)(bar, baaz).
>>>>>>
>>>>>
>>>>> Unambiguous grammar, you fail it.
>>>>>
>>>>> foo(bar)(baz); // template instantiation or a chained call?
>>>>>
>>>>> This _can_ be _made_ to work, but it would mean that the parse tree
>>>>> would be dependent upon semantic analysis, and that just makes things
>>>>> slow and awful.  I.e. C++.
>>>>
>>>> I'd be happy to get rid of OpCall, which I've always found confusing 
>>>> and pointless.
>>>>
>>>> --benji
>>>
>>> That's going to break a lot of struct constructors using static opCalls.
>>
>> Only because structs should have had constructors from the start. 
>> Using opCall was always a hack around the lack of constructors on 
>> structs.
>>
>> opCall is a source of numerous language ambiguities that make other 
>> features more difficult to implement. For example, template 
>> instantiation could be done with bare parentheses ("Template(args)" 
>> instead of "Template!(args)" or "Template{args}") if opCall was 
>> eliminated.
>>
>> --benji
> 
> But what about a method that returns a delegate?

Damn. You win.

Hmmmmmm... I still hate opCall, though :)

--benji
17 18 19 20 21 22 23 24
Top | Discussion index | About this forum | D home