View mode: basic / threaded / horizontal-split · Log in · Help
October 10, 2008
Re: Template instantiation syntax
Andrei Alexandrescu wrote:
> Walter exaggerated when he said that "I'm working on" an emacs solution.
> I only said "I'm pretty sure it can be done". :o)

I have faith in you <g>
October 10, 2008
Re: Template instantiation syntax
Jason House wrote:
> Is it ok to chain!nested!templates?  Gramatically, it's unambiguous.

No. The problem is, which is it?

a!b!c can be a!(b!c) or a!(b)!(c)

Andrei argued that it should be the former, as that is much more useful. 
The problem is,

a!b!c

should be equivalent to:

a!(b)!(c)

which is then equivalent to:

a!(b!(c))

which makes no sense, because what does:

a!(b,c)!(d)

mean then? It becomes a morass of special cases with no comprehensible 
rules to guide us. So, we gave up, and decided to make a!b!c illegal for 
now.
October 11, 2008
Re: Template instantiation syntax
Walter Bright:
>Most template instantiations are one simple argument.

Probably my code is more general than the average code written in D, so it often contains complex templates, so the statistics for my code may be unusual. From a short survey in my code, it seems about 30-40% of template instantiations have one argument.


> Why not?

- Because it's a special case, so it adds complexity to the language. More complexity has to be justified before being added.
- It has a corner case, that is the nesting of template instantiations. And I don't know if there are other corner cases.
- Often I have code like:
if (!IsAA!(Sometype)) ...
that will became:
if (!IsAA!Sometype) ...
The first ! is a negation, and the second is a template instantiation. Maybe it's not ambiguous for the parser, but for my eye it requires a moment to tell their semantics apart. While the Name!(...) is somehow parsed as a single gestalt by my eyes, so I don't mismatch it for a negation much. This may be just a personal thing.
- It save little space, just 2 characters (), and they are easy to type, unlike on some keyboards characters like {} and especially ~, that requires ALT+126 to me.
- The current syntax works :-)
- I think there are currently more important things to work on for you :-)
- So for me it's like the ability of removing the () at the end of function calls, it introduces ambiguities for the user without giving back much good. So instead of seeing the () removed from some template instantiations, I'd like to see the () put back as compulsive in function calls :-) And I think there are 5+ persons around here that agree with me on this.


> That would seriously damage the compiler's ability to identify, 
> diagnose, and recover from syntax errors correctly.

I presume Scala uses other tricks so solve such problem, then, because it has optional semicolons.
Anyway, I am not a designer of a very complex language, so if you say so I trust you :-) Even if sometimes I disagree with your opinions, I have high regard for your capabilities and work :-)

Bye,
bearophile
October 11, 2008
Re: Template instantiation syntax
"bearophile" <bearophileHUGS@lycos.com> wrote in message 
news:gcordd$2tdi$1@digitalmars.com...
> Walter Bright:
>>Most template instantiations are one simple argument.
>
> Probably my code is more general than the average code written in D, so it 
> often contains complex templates, so the statistics for my code may be 
> unusual. From a short survey in my code, it seems about 30-40% of template 
> instantiations have one argument.
>
>
>> Why not?
>
> - Because it's a special case, so it adds complexity to the language. More 
> complexity has to be justified before being added.
> - It has a corner case, that is the nesting of template instantiations. 
> And I don't know if there are other corner cases.
> - Often I have code like:
> if (!IsAA!(Sometype)) ...
> that will became:
> if (!IsAA!Sometype) ...
> The first ! is a negation, and the second is a template instantiation. 
> Maybe it's not ambiguous for the parser, but for my eye it requires a 
> moment to tell their semantics apart. While the Name!(...) is somehow 
> parsed as a single gestalt by my eyes, so I don't mismatch it for a 
> negation much. This may be just a personal thing.

It might be better to use some symbol that is not actually in use. The @ 
suggestion seems to be a better choice for cases like this were first look 
might be ambiguous.

if( !IsAA@( Sometype ) ) ...
if( !IsAA@Sometype ) ...

At least for me it looks pretty readable and easy to understand.


> - It save little space, just 2 characters (), and they are easy to type, 
> unlike on some keyboards characters like {} and especially ~, that 
> requires ALT+126 to me.
> - The current syntax works :-)
> - I think there are currently more important things to work on for you :-)
> - So for me it's like the ability of removing the () at the end of 
> function calls, it introduces ambiguities for the user without giving back 
> much good. So instead of seeing the () removed from some template 
> instantiations, I'd like to see the () put back as compulsive in function 
> calls :-) And I think there are 5+ persons around here that agree with me 
> on this.
>
>
>> That would seriously damage the compiler's ability to identify,
>> diagnose, and recover from syntax errors correctly.
>
> I presume Scala uses other tricks so solve such problem, then, because it 
> has optional semicolons.
> Anyway, I am not a designer of a very complex language, so if you say so I 
> trust you :-) Even if sometimes I disagree with your opinions, I have high 
> regard for your capabilities and work :-)
>
> Bye,
> bearophile
October 11, 2008
Re: Template instantiation syntax
"Walter Bright" wrote
> Jason House wrote:
>> Is it ok to chain!nested!templates?  Gramatically, it's unambiguous.
>
> No. The problem is, which is it?
>
> a!b!c can be a!(b!c) or a!(b)!(c)
>
> Andrei argued that it should be the former, as that is much more useful. 
> The problem is,
>
> a!b!c
>
> should be equivalent to:
>
> a!(b)!(c)
>
> which is then equivalent to:
>
> a!(b!(c))
>
> which makes no sense, because what does:
>
> a!(b,c)!(d)
>
> mean then? It becomes a morass of special cases with no comprehensible 
> rules to guide us. So, we gave up, and decided to make a!b!c illegal for 
> now.

a!(b)!(c) makes no sense.  Does (a!(b))!(c) make any sense?

Can a template be aliased to a template symbol that still needs parameters? 
I didn't think it could.

For instance, can you do something like:

class C(T) {}

template D(T)
{
  alias C D;
}

Would that even compile?  (don't have dmd handy)

-Steve
October 11, 2008
Re: Template instantiation syntax
Walter Bright Wrote:

> Jason House wrote:
> > Is it ok to chain!nested!templates?  Gramatically, it's unambiguous.
> 
> No. The problem is, which is it?
> 
> a!b!c can be a!(b!c) or a!(b)!(c)

I don't know of a case where the latter is legal D. All templates that I know of require a non-templated symbol name before !(). All of the cases below are invoked as X!(...) where X isn't templated. Function calls can't return partial types. 

template X(...){...}
template X(...){ T X; }
class X(...){...}
struct X(...){...}
template X(...){ class X{...} }
template X(...){ struct X{...} } 
foo X(...){...}

Did I miss a case? The only candidate I can see is template X(...){ class X(...){...} }, but I don't know if it is legal or desirable.
October 11, 2008
Re: Template instantiation syntax
Fri, 10 Oct 2008 16:39:00 -0700,
Walter Bright wrote:
> Jason House wrote:
> > Is it ok to chain!nested!templates?  Gramatically, it's unambiguous.
> 
> No. The problem is, which is it?
> 
> a!b!c can be a!(b!c) or a!(b)!(c)
> 
> Andrei argued that it should be the former, as that is much more useful. 
> The problem is,
> 
> a!b!c
> 
> should be equivalent to:
> 
> a!(b)!(c)

Why is this necessary?  If a binary ! is right-associative and of a very 
high priority then a!b!c binds correctly:

TemplateInstance:
 TemplateIdentifer !( TemplateArgumentList )
 TemplateIdentifer ! Identifier
 TemplateIdentifer ! TemplateInstance

so that even a!b!c!(x,y) works as a!(b!(c!(x,y))), but a!(b)!(c) is not 
accepted.
October 11, 2008
Re: Template instantiation syntax
On Sat, Oct 11, 2008 at 7:48 AM, Andrei Alexandrescu
<SeeWebsiteForEmail@erdani.org> wrote:
> Jason House wrote:
> Walter exaggerated when he said that "I'm working on" an emacs solution.
> I only said "I'm pretty sure it can be done". :o)

I think it should be doable too.  I feel like I've seen a mode that
did something similar before, but I can't quite recall.
There are definitely a variety of examples of distorting how text is
displayed, like folding-mode, or even the syntax colorization of
font-lock-mode.  Hexl-mode also does some trick to make each
2-character hex code act like a single character.  The input methods
for asian languages have to do a variety of funky stuff too.

Definitely seems doable.

--bb
October 11, 2008
Re: Template instantiation syntax
bearophile wrote:
> Walter Bright:
>> Most template instantiations are one simple argument.
> 
> Probably my code is more general than the average code written in D, so it often contains complex templates, so the statistics for my code may be unusual. From a short survey in my code, it seems about 30-40% of template instantiations have one argument.
> 
> 
>> Why not?
> 
> - Because it's a special case, so it adds complexity to the language. More complexity has to be justified before being added.
> - It has a corner case, that is the nesting of template instantiations. And I don't know if there are other corner cases.
> - Often I have code like:
> if (!IsAA!(Sometype)) ...
> that will became:
> if (!IsAA!Sometype) ...
> The first ! is a negation, and the second is a template instantiation. Maybe it's not ambiguous for the parser, but for my eye it requires a moment to tell their semantics apart. While the Name!(...) is somehow parsed as a single gestalt by my eyes, so I don't mismatch it for a negation much. This may be just a personal thing.
> - It save little space, just 2 characters (), and they are easy to type, unlike on some keyboards characters like {} and especially ~, that requires ALT+126 to me.
> - The current syntax works :-)
> - I think there are currently more important things to work on for you :-)
> - So for me it's like the ability of removing the () at the end of function calls, it introduces ambiguities for the user without giving back much good. So instead of seeing the () removed from some template instantiations, I'd like to see the () put back as compulsive in function calls :-) And I think there are 5+ persons around here that agree with me on this.
> 
> 
>> That would seriously damage the compiler's ability to identify, 
>> diagnose, and recover from syntax errors correctly.
> 
> I presume Scala uses other tricks so solve such problem, then, because it has optional semicolons.
> Anyway, I am not a designer of a very complex language, so if you say so I trust you :-) Even if sometimes I disagree with your opinions, I have high regard for your capabilities and work :-)
> 
> Bye,
> bearophile

I think it's funny that, in the same post, you argue against optional 
parentheses while arguing for optional semicolons.

--benji
October 11, 2008
Re: Template instantiation syntax
On Sat, Oct 11, 2008 at 6:15 AM, Walter Bright
<newshound1@digitalmars.com> wrote:
> 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.

So with these two things, in Emacs you'll see
Foo!bar in some places and Foo«bar, baz» in others?
Doesn't seem very consistent to me.

As for the emacs mode -- please make the pair of unicode chars used
settable!  Those little brackets are too hard to see.

--bb
1 2 3 4 5 6
Top | Discussion index | About this forum | D home