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