October 07, 2008 Re: shouting versus dotting | ||||
---|---|---|---|---|
| ||||
Posted in reply to KennyTM~ | 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 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Benji Smith | 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 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Jarrett Billingsley | 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 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Andrei Alexandrescu | 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 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Andrei Alexandrescu | 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 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Don | 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 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Don | 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 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Benji Smith | 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 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Aarti_pl | 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 | ||||
---|---|---|---|---|
| ||||
Posted in reply to KennyTM~ | 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
|
Copyright © 1999-2021 by the D Language Foundation