"Walter Bright" wrote
> Bill Baxter wrote:
>> Changing details like the character used for this or that can make the code more or less readable though. But that doesn't really affect how difficult it is to remember how to write something.
>> I disagree with that assessment. There are aesthetics to architecture, fonts, web pages, cars, dance, clothes, etc. Break those aesthetics, and you've got something people just don't like, even if they cannot identify why.
>> Take the immutable vs invariant aesthetic. There is no technical reason to prefer one over the other. But people seem to just like immutable better.
At least one valid technical argument was raised -- invariant already has a different meaning in D1.
The other argument I remember is that you basically have to use immutable to describe what invariant means ;)
And I think the concept of templates was more difficult for me to get than the syntax.
The syntax ambiguities are somewhat of an orthoganal issue that was solved by using !() instead.
In other words, I don't think using ! without parens is going to make templates any easier to understand for newbs. It might not make it more difficult, but in my view, it's a very trivial change.
-Steve

Dave escribió:
> > "Walter Bright" <newshound1@digitalmars.com> wrote in message news:gcogl4$28ui$1@digitalmars.com...>> We seem to have reached a dead end on finding a significantly better alternative than foo!(bar).
>>>> All is not lost, though. Andrei is working on an emacs module that will parse D code and replace foo!(bar) with foo«bar» for display only when the editor is in D mode, the underlying text will still be foo!(bar). (This doesn't affect D at all, only its display in Emacs.)
>>>> Also, we're going to try using ! for single argument syntax, as in:
>>>> foo!bar is same as foo!(bar)
>> foo!10 is same as foo!(10)
>>>> etc. 0 arguments or more than 1 argument or arguments that are more than one token long will still require !( ). We'll see how that works. I think it looks rather nice.
> > I don't like it because it is not consistent and therefore could make things ugly and even harder to comprehend where clarity is needed most -- in a file full of mixed length template instantiations. It reeks of total hack to me, and I think this is opening a huge can of worms regarding the a!b!c issue. Inconsistency and things that smack of potential "corner case" are never good.
> > I hadn't seen this mentioned lately; C#, Java and now C++0x are able to work around the '> >' issue and allow '>>'.
I think that in Java and C# it's a lot easier than in D or C++, mainly because Java and C# allow only types as generic arguments.
---
Type:
Identifier [TypeArguments]{ . Identifier [TypeArguments]} {[]}
BasicType
TypeArguments:
< TypeArgument {, TypeArgument} >
TypeArgument:
Type
? [( extends |super ) Type]
---
So in your parser, if you encounter XXX<YYY<ZZZ>>, that last >> never means right shift, since ZZZ >> (something) would form an expression, not a type. So the parser can say:
if after ZZZ comes >, it closes the < of YYY. If >> comes, and we are in a nested generic, then close both < of YYY and < of XXX.
I debugged JDT's parser and here it is:
---
// when consuming a rule...
case 538 : if (DEBUG) { System.out.println("ReferenceType2 ::= ReferenceType RIGHT_SHIFT"); } //$NON-NLS-1$
consumeReferenceType2();
break;
case 544 : if (DEBUG) { System.out.println("ReferenceType3 ::= ReferenceType UNSIGNED_RIGHT_SHIFT"); } //$NON-NLS-1$
consumeReferenceType3();
break;
---
So also >>> is hard, but not that much.
Of course, that's harder than just having other symbols for <>, because you have to maintain a stack of generics so far, but it's not that hard.

KennyTM~ wrote:
> But will be compiler accept T«x» if I directly feed it into the compiler?
No.
> It's no good if what you see cannot be what you type.
The compiler doesn't accept colored text either, but that doesn't impair the usefulness of an editor that displays it that way.

Walter Bright wrote:
> KennyTM~ wrote:
>> But will be compiler accept T«x» if I directly feed it into the compiler?
> > No.
> >> It's no good if what you see cannot be what you type.
> > The compiler doesn't accept colored text either, but that doesn't impair the usefulness of an editor that displays it that way.
Because you can't type color, but you can type « and ».

On Sun, 12 Oct 2008 21:18:35 +0400, KennyTM~ <kennytm@gmail.com> wrote:
> Walter Bright wrote:
>> KennyTM~ wrote:
>>> But will be compiler accept T«x» if I directly feed it into the compiler?
>> No.
>>>>> It's no good if what you see cannot be what you type.
>> The compiler doesn't accept colored text either, but that doesn't impair the usefulness of an editor that displays it that way.
>> Because you can't type color, but you can type « and ».
«...» is not a valid template syntax, only !(...) is supported.
Honestly, I don't understand why Andrei is ashamed of !(), refrains from using/seeing it and tries to replace visual with some sugar, but this all is is suspicious and alerting. The syntax didn't make a way into the language so uou should get used to it and put up with it.
This reminds me of some people who were coming from Pascal and using
#define DO
#define BEGIN {
#define END }
macros for the code to be more similar to their previous experience.
This is a bad sign, especially if it comes from one of the language developers.

Sure you can
<red>throw</red>
;-)
"KennyTM~" <kennytm@gmail.com> skrev i meddelelsen news:gctbhb$255k$1@digitalmars.com...> Walter Bright wrote:
>> KennyTM~ wrote:
>>> But will be compiler accept T«x» if I directly feed it into the compiler?
>>>> No.
>>>>> It's no good if what you see cannot be what you type.
>>>> The compiler doesn't accept colored text either, but that doesn't impair the usefulness of an editor that displays it that way.
>> Because you can't type color, but you can type « and ».

Denis Koroskin wrote:
> On Sun, 12 Oct 2008 21:18:35 +0400, KennyTM~ <kennytm@gmail.com> wrote:
> >> Walter Bright wrote:
>>> KennyTM~ wrote:
>>>> But will be compiler accept T«x» if I directly feed it into the compiler?
>>> No.
>>>>>>> It's no good if what you see cannot be what you type.
>>> The compiler doesn't accept colored text either, but that doesn't impair the usefulness of an editor that displays it that way.
>>>> Because you can't type color, but you can type « and ».
> > «...» is not a valid template syntax, only !(...) is supported.
Yes I know. But if Andrei's going to write an emacs module (or whatever) that displays !(...) as «...» I think the shown characters « and » themselves should be supported as well.
Otherwise, just drop this confusing visual-only feature.
> Honestly, I don't understand why Andrei is ashamed of !(), refrains from using/seeing it and tries to replace visual with some sugar, but this all is is suspicious and alerting. The syntax didn't make a way into the language so uou should get used to it and put up with it.
> > This reminds me of some people who were coming from Pascal and using
> > #define DO
> #define BEGIN {
> #define END }
> > macros for the code to be more similar to their previous experience.
> > This is a bad sign, especially if it comes from one of the language developers.
At least you can still use DO, BEGIN, END when you #define them. But now you can't even use what you see («...»). I say it's more evil. :)

KennyTM~ wrote:
> Denis Koroskin wrote:
>> On Sun, 12 Oct 2008 21:18:35 +0400, KennyTM~ <kennytm@gmail.com> wrote:
>>>>> Walter Bright wrote:
>>>> KennyTM~ wrote:
>>>>> But will be compiler accept T«x» if I directly feed it into the compiler?
>>>> No.
>>>>>>>>> It's no good if what you see cannot be what you type.
>>>> The compiler doesn't accept colored text either, but that doesn't impair the usefulness of an editor that displays it that way.
>>>>>> Because you can't type color, but you can type « and ».
>>>> «...» is not a valid template syntax, only !(...) is supported.
> > Yes I know. But if Andrei's going to write an emacs module (or whatever) that displays !(...) as «...» I think the shown characters « and » themselves should be supported as well.
> > Otherwise, just drop this confusing visual-only feature.
Please understand how your suggestion to drop the visual-only feature concerns only the use of an editor. There is no feature to talk about even. Essentially by "dropping the feature" you are telling me how my editor's screen must look like.
>> Honestly, I don't understand why Andrei is ashamed of !(), refrains from using/seeing it and tries to replace visual with some sugar, but this all is is suspicious and alerting. The syntax didn't make a way into the language so uou should get used to it and put up with it.
>>>> This reminds me of some people who were coming from Pascal and using
>>>> #define DO
>> #define BEGIN {
>> #define END }
>>>> macros for the code to be more similar to their previous experience.
>>>> This is a bad sign, especially if it comes from one of the language developers.
> > At least you can still use DO, BEGIN, END when you #define them. But now you can't even use what you see («...»). I say it's more evil. :)
Code folding hides entire sections of code. They are nonetheless passed to the compiler. Is that evil?
Andrei

Andrei Alexandrescu wrote:
> KennyTM~ wrote:
>> Denis Koroskin wrote:
>>> On Sun, 12 Oct 2008 21:18:35 +0400, KennyTM~ <kennytm@gmail.com> wrote:
>>>>>>> Walter Bright wrote:
>>>>> KennyTM~ wrote:
>>>>>> But will be compiler accept T«x» if I directly feed it into the compiler?
>>>>> No.
>>>>>>>>>>> It's no good if what you see cannot be what you type.
>>>>> The compiler doesn't accept colored text either, but that doesn't impair the usefulness of an editor that displays it that way.
>>>>>>>> Because you can't type color, but you can type « and ».
>>>>>> «...» is not a valid template syntax, only !(...) is supported.
>>>> Yes I know. But if Andrei's going to write an emacs module (or whatever) that displays !(...) as «...» I think the shown characters « and » themselves should be supported as well.
>>>> Otherwise, just drop this confusing visual-only feature.
> > Please understand how your suggestion to drop the visual-only feature concerns only the use of an editor. There is no feature to talk about even. Essentially by "dropping the feature" you are telling me how my editor's screen must look like.
>
Maybe I used the wrong wording. I mean the "feature" that replaces !(...) to «...» in "your" emacs module.
Since Walter made an announcement here I'll expect you'll release it publicly, and since this is from the official developers' team I'd expect this would be the de facto module for emacs. That means your module will not just affect your editor, but all emacs users' editors.
>>> Honestly, I don't understand why Andrei is ashamed of !(), refrains from using/seeing it and tries to replace visual with some sugar, but this all is is suspicious and alerting. The syntax didn't make a way into the language so uou should get used to it and put up with it.
>>>>>> This reminds me of some people who were coming from Pascal and using
>>>>>> #define DO
>>> #define BEGIN {
>>> #define END }
>>>>>> macros for the code to be more similar to their previous experience.
>>>>>> This is a bad sign, especially if it comes from one of the language developers.
>>>> At least you can still use DO, BEGIN, END when you #define them. But now you can't even use what you see («...»). I say it's more evil. :)
> > Code folding hides entire sections of code. They are nonetheless passed to the compiler. Is that evil?
> > > Andrei
But code folding is not turned on by default, and there is a clear visual indication (e.g. +/- on the side) that there is something more.
OK there's C# #region, but again there is a clear visual indication (the +/- and the gray box) that something is inside #region.
My point is that if you just colorize « and » an average user seeing the foreign template code will not understand that the « is not actually a chevron but a !(. That will be a confusion.
It's OK if the replacement is implemented as a *non-default option*. Just like visual whitespace (I'm surprised no one challenges me with this). That means if a programmer really hates !(...) they can switch it on and change all of them into «...». With this the programmer *knows* what they're doing and confusion can be minimized.