www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Template instantiation syntax

reply Walter Bright <newshound1 digitalmars.com> writes:
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 foobar 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.
Oct 10 2008
next sibling parent Sergey Gromov <snake.scaly gmail.com> writes:
Fri, 10 Oct 2008 14:15:12 -0700,
Walter Bright wrote:
 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'd definitely give it a try.
Oct 10 2008
prev sibling next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Walter Bright:
 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)

And what's the advantage of such special casing of the syntax? Just to remove 2 chars () that improves clarity? I am for using shorter syntaxes in D, but not in that way. If you want to reduce the length of D programs make the semicolons optional, introduce eager and lazy array comprehensions, try to introduce a lambda syntax like the C# one, etc. Bye, bearophile
Oct 10 2008
next sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
bearophile wrote:
 And what's the advantage of such special casing of the syntax? Just
 to remove 2 chars () that improves clarity?

Yes. I think small things like this can make a big difference. Most template instantiations are one simple argument.
 I am for using shorter
 syntaxes in D, but not in that way.

Why not?
 If you want to reduce the length
 of D programs make the semicolons optional,

That would seriously damage the compiler's ability to identify, diagnose, and recover from syntax errors correctly.
 introduce eager and lazy
 array comprehensions, try to introduce a lambda syntax like the C#
 one, etc.

Oct 10 2008
parent reply bearophile <bearophileHUGS lycos.com> writes:
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
Oct 10 2008
next sibling parent "Tiago Carvalho" <merlin3000 gmail.com> writes:
"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

Oct 10 2008
prev sibling parent reply Benji Smith <dlanguage benjismith.net> writes:
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
Oct 10 2008
parent reply "Bent Rasmussen" <IncredibleShrinkingSphere Gmail.com> writes:
Parentheses establish context as does semicolons, of course. Still, 
parantheses are more prominent.

I hope this drive away from parentheses, which started as a discussion of 
"shouting vs dotting", doesn't end up with the same approach for function 
call syntax.

a!b c

Let's look at that for a while, while we ponder the concept of aesthetics. 
The defense rests.

- Bent

"Benji Smith" <dlanguage benjismith.net> skrev i meddelelsen 
news:gcpf66$uup$1 digitalmars.com...
 bearophile wrote:
 Bye,
 bearophile

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

Oct 11 2008
parent Walter Bright <newshound1 digitalmars.com> writes:
Bent Rasmussen wrote:
 Parentheses establish context as does semicolons, of course. Still, 
 parantheses are more prominent.
 
 I hope this drive away from parentheses, which started as a discussion 
 of "shouting vs dotting", doesn't end up with the same approach for 
 function call syntax.
 
 a!b c
 
 Let's look at that for a while, while we ponder the concept of 
 aesthetics. The defense rests.

One could rationally extend the argument to not need parentheses for one argument function calls. But, ugh. I don't know why I hate it, but I do.
Oct 11 2008
prev sibling parent "Danny Wilson" <bluezenix gmail.com> writes:
Op Fri, 10 Oct 2008 23:29:00 +0200 schreef bearophile  
<bearophileHUGS lycos.com>:

 If you want to reduce the length of D programs make the semicolons  
 optional, introduce eager and lazy array comprehensions, try to  
 introduce a lambda syntax like the C# one, etc.

If you could reduce the length of your whining it would save me alot of reading time aswell :-)
Oct 10 2008
prev sibling next sibling parent reply Benji Smith <dlanguage benjismith.net> writes:
Walter Bright 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 foobar 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.

Quick question: is "!" an operator in this context? (Or is it something-other-than-an-operator? If so, what is it?) Is this code legal: (foo!bar)[] myArray; Thanks! --benji
Oct 10 2008
parent Walter Bright <newshound1 digitalmars.com> writes:
Benji Smith wrote:
 Quick question: is "!" an operator in this context?

Yes.
 (Or is it 
 something-other-than-an-operator? If so, what is it?)
 
 Is this code legal:
 
    (foo!bar)[] myArray;

Yes, just like: foo.bar[] myArray; is legal.
Oct 10 2008
prev sibling next sibling parent reply Jason House <jason.james.house gmail.com> writes:
Walter Bright 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 foobar 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.

Couple of comments/questions The tool!lathe syntax doesn't look visually distinct enough for me. The syntax seems nicer on the eyes. I'm not trying to push changes. () looks ugly to me, and having matching template syntax is desirable. Is it ok to chain!nested!templates? Gramatically, it's unambiguous. Will Andrei color template parameters with ! so they're easier to spot? How would they look when nested? Alternating colors should work
Oct 10 2008
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Jason House wrote:
 Walter Bright 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 foobar 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.

Couple of comments/questions The tool!lathe syntax doesn't look visually distinct enough for me. The syntax seems nicer on the eyes. I'm not trying to push changes. () looks ugly to me, and having matching template syntax is desirable.

I agree. But after all the aggravation, I learned to be happy with what I can get.
 Is it ok to chain!nested!templates?  Gramatically, it's unambiguous.

Walter gave me a black eye over it last night. I'll let him to provide the juicy details. The short version is that for now a!b!c is disallowed with extreme prejudice.
 Will Andrei color template parameters with ! so they're easier to
 spot? How would they look when nested? Alternating colors should work

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) Andrei
Oct 10 2008
parent Walter Bright <newshound1 digitalmars.com> writes:
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>
Oct 10 2008
prev sibling next sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
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.
Oct 10 2008
next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
"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
Oct 10 2008
prev sibling next sibling parent Jason House <jason.james.house gmail.com> writes:
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.
Oct 10 2008
prev sibling parent reply Sergey Gromov <snake.scaly gmail.com> writes:
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.
Oct 10 2008
parent reply Walter Bright <newshound1 digitalmars.com> writes:
Sergey Gromov wrote:
 so that even a!b!c!(x,y) works as a!(b!(c!(x,y))), but a!(b)!(c) is not 
 accepted.

I don't think it's a good idea to say that a!(b)!(c) is never allowed. It intuitively means that a!(b) is aliased to another template.
Oct 10 2008
next sibling parent Sergey Gromov <snake.scaly gmail.com> writes:
Fri, 10 Oct 2008 23:22:22 -0700,
Walter Bright wrote:
 Sergey Gromov wrote:
 so that even a!b!c!(x,y) works as a!(b!(c!(x,y))), but a!(b)!(c) is not 
 accepted.

I don't think it's a good idea to say that a!(b)!(c) is never allowed. It intuitively means that a!(b) is aliased to another template.

Ok, then I think it's a matter of specifying precedence. So that a!b!c is always a!(b!(c)) but if you want to use a!b as an alias to another one-argument template then you must write a!(b)!c. It seems like a rare use case so it's Ok to require a bit more typing.
Oct 11 2008
prev sibling parent Michel Fortin <michel.fortin michelf.com> writes:
On 2008-10-11 02:22:22 -0400, Walter Bright <newshound1 digitalmars.com> said:

 Sergey Gromov wrote:
 so that even a!b!c!(x,y) works as a!(b!(c!(x,y))), but a!(b)!(c) is not 
 accepted.

I don't think it's a good idea to say that a!(b)!(c) is never allowed. It intuitively means that a!(b) is aliased to another template.

There is a couple of those in the D/Objective-C bridge. Basically, a few function templates are defined like this: template invoke(ReturnType, char[] methodName) { ReturnType invoke(Args...)(Args args) { // call the method while wrapping all elements as necessary } } It's generally used like this: invoke!(void, "setColor")(color); The nested-template trick avoids having to write all the function's arguments types since for the inner template, arguments are deduced from the function call. But if you want to be explicit about the argument types, you can do a chained template: invoke!(void, "setColor")!(NSColor)(color); Isn't that a funny line? Now, how readable is this one: invoke!(void, "setColor")!NSColor(color); ? - - - I'd like it very much if templates such as these could work with only one argument list, such as: invoke(void, "setColor", color); It makes this example simpler to read, because now you don't have to bother about all the technicalities of what is a template parameter and what is a runtime parameter. It could probably simplify the definition too. Here is what I have in mind for the function declaration: ReturnType invoke(typename ReturnType, static char[] methodName, auto(Args...) args) { ... } -- Michel Fortin michel.fortin michelf.com http://michelf.com/
Oct 11 2008
prev sibling next sibling parent "Bill Baxter" <wbaxter gmail.com> writes:
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
Oct 10 2008
prev sibling parent Christopher Wright <dhasenan gmail.com> writes:
Jason House wrote:
 Walter Bright 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 foobar 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.

Couple of comments/questions The tool!lathe syntax doesn't look visually distinct enough for me. The syntax seems nicer on the eyes. I'm not trying to push changes. () looks ugly to me, and having matching template syntax is desirable. Is it ok to chain!nested!templates? Gramatically, it's unambiguous.

One!Two!Three -- is this One!(Two!(Three)) or One!(Two)!(Three)? You can disambiguate using the context, at least sometimes, but that adds complexity to the grammar. struct Thing (T) { static int opCall (U)() {} } template One (T) { alias Thing!(T) One; } One!Thing!int thing; // variable declaration, Thing!(Thing!(int)) struct Thing (T) { static int opCall (U)() {} } template One (T) { alias Thing!(char) One; } int i = One!Thing!int(); // Thing!(Thing!(char))!(int).opCall
Oct 11 2008
prev sibling next sibling parent BLS <nanali nospam-wanadoo.fr> writes:
Walter Bright schrieb:
 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 foobar 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.)
 

So!Smalltalk inspired :) What about st like code blocks instead of closures ? Would make code more readable then allowing ! instead of !()
 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)
 

Both valid than ?
 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.

Oct 10 2008
prev sibling next sibling parent "Bill Baxter" <wbaxter gmail.com> writes:
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=ABbar=BB for display only whe=

 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 =

 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=ABbar, baz=BB 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
Oct 10 2008
prev sibling next sibling parent reply Max Samukha <samukha voliacable.com.removethis> writes:
On Fri, 10 Oct 2008 14:15:12 -0700, 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.

I hope this insignificant issue is not taking too much of your and Andrei's time.
Oct 10 2008
parent reply Walter Bright <newshound1 digitalmars.com> writes:
Max Samukha wrote:
 I hope this insignificant issue is not taking too much of your and
 Andrei's time.

Implementing it isn't a problem. The volume of messages about it consumes the bulk of the time <g>. I don't agree that it is insignificant. A lot of programmers are put off by C++ templates, myself included. The question is, why? They shouldn't conceptually be that complicated. I think syntax is a big part of it. I just can never seem to get a mental grip on the C++ template syntax. Like makefiles, I write C++ templates by copy/paste/modify related ones. This is just wrong. If the syntax can be made more intuitive and appealing, I believe it will break down the barriers to using templates naturally. I've seen this happen for other things. Syntax matters.
Oct 10 2008
next sibling parent Max Samukha <samukha voliacable.com.removethis> writes:
On Fri, 10 Oct 2008 23:29:21 -0700, Walter Bright
<newshound1 digitalmars.com> wrote:

Max Samukha wrote:
 I hope this insignificant issue is not taking too much of your and
 Andrei's time.

Implementing it isn't a problem. The volume of messages about it consumes the bulk of the time <g>. I don't agree that it is insignificant. A lot of programmers are put off by C++ templates, myself included. The question is, why? They shouldn't conceptually be that complicated. I think syntax is a big part of it.

dropping () for single argument instances doesn't seem to make them look much better. Maybe I just got used to current syntax.
 I just can never seem to get a mental grip on the C++ template syntax. 
Like makefiles, I write C++ templates by copy/paste/modify related ones. 
This is just wrong. If the syntax can be made more intuitive and 
appealing, I believe it will break down the barriers to using templates 
naturally.

I've seen this happen for other things. Syntax matters.

Oct 11 2008
prev sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
Bill Baxter wrote:
 But it's not the << and >> that make C++ templates hard to understand.

I think it does. I could never get past the visual ambiguity with less than, and with the streams, the ambiguity with >>. But that isn't the worst of it, the C++ template definition syntax sets my teeth on edge.
  Replacing that with some other character or character sequence would
 make very little difference in how difficult they are to understand.
 It's more the lack of a straighforward equivalent for things like
 static if.

There are a lot of issues that needed improvement.
 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.
Oct 11 2008
next sibling parent reply Max Samukha <samukha voliacable.com.removethis> writes:
On Sat, 11 Oct 2008 02:57:29 -0700, Walter Bright
<newshound1 digitalmars.com> wrote:

Bill Baxter wrote:
 But it's not the << and >> that make C++ templates hard to understand.

I think it does. I could never get past the visual ambiguity with less than, and with the streams, the ambiguity with >>. But that isn't the worst of it, the C++ template definition syntax sets my teeth on edge.
  Replacing that with some other character or character sequence would
 make very little difference in how difficult they are to understand.
 It's more the lack of a straighforward equivalent for things like
 static if.

There are a lot of issues that needed improvement.
 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.

Wait a sec! Not everybody expressed his aesthetic feeling towards immutable. I don't like the double m inside immutable and prefer invariant :).
Oct 11 2008
parent KennyTM~ <kennytm gmail.com> writes:
Max Samukha wrote:
 On Sat, 11 Oct 2008 02:57:29 -0700, Walter Bright
 <newshound1 digitalmars.com> wrote:
 
 Bill Baxter wrote:
 But it's not the << and >> that make C++ templates hard to understand.

than, and with the streams, the ambiguity with >>. But that isn't the worst of it, the C++ template definition syntax sets my teeth on edge.
  Replacing that with some other character or character sequence would
 make very little difference in how difficult they are to understand.
 It's more the lack of a straighforward equivalent for things like
 static if.

 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.

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.

Wait a sec! Not everybody expressed his aesthetic feeling towards immutable. I don't like the double m inside immutable and prefer invariant :).

To put more flame in... I like the C# keywords “readonly” (meaning const now) and “const” (meaning invariant now) more. :p
Oct 11 2008
prev sibling next sibling parent KennyTM~ <kennytm gmail.com> writes:
Walter Bright wrote:
 Bill Baxter wrote:
 But it's not the << and >> that make C++ templates hard to understand.

I think it does. I could never get past the visual ambiguity with less than, and with the streams, the ambiguity with >>. But that isn't the worst of it, the C++ template definition syntax sets my teeth on edge.

I think C++'s template is hard to use because they don't have static if <g>
  Replacing that with some other character or character sequence would
 make very little difference in how difficult they are to understand.
 It's more the lack of a straighforward equivalent for things like
 static if.

There are a lot of issues that needed improvement.
 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.

Oct 11 2008
prev sibling next sibling parent Walter Bright <newshound1 digitalmars.com> writes:
Bill Baxter wrote:
 But people don't say they have to copy&paste code because the word
 "invariant" blocks their brains from remembering how to write the
 code.  If there's something hard to remember about how to write such
 code, changing the word from "invariant" to "immutable" isn't going to
 change that.  That's all I'm tryin' to say.

Ok.
Oct 11 2008
prev sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
"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
Oct 12 2008
prev sibling next sibling parent "Bent Rasmussen" <IncredibleShrinkingSphere Gmail.com> writes:
That's a great idea. A meta-syntax for the editor.

Also, foobar looks much better than any of the other suggestions.

- Bent

"Walter Bright" <newshound1 digitalmars.com> skrev i meddelelsen 
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 foobar 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. 

Oct 11 2008
prev sibling next sibling parent "Bill Baxter" <wbaxter gmail.com> writes:
On Sat, Oct 11, 2008 at 3:29 PM, Walter Bright
<newshound1 digitalmars.com> wrote:
 Max Samukha wrote:
 I hope this insignificant issue is not taking too much of your and
 Andrei's time.

Implementing it isn't a problem. The volume of messages about it consumes the bulk of the time <g>. I don't agree that it is insignificant. A lot of programmers are put off by C++ templates, myself included. The question is, why? They shouldn't conceptually be that complicated. I think syntax is a big part of it. I just can never seem to get a mental grip on the C++ template syntax. Like makefiles, I write C++ templates by copy/paste/modify related ones. This is just wrong. If the syntax can be made more intuitive and appealing, I believe it will break down the barriers to using templates naturally. I've seen this happen for other things. Syntax matters.

But it's not the << and >> that make C++ templates hard to understand. Replacing that with some other character or character sequence would make very little difference in how difficult they are to understand. It's more the lack of a straighforward equivalent for things like static if. 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. --bb
Oct 11 2008
prev sibling next sibling parent reply KennyTM~ <kennytm gmail.com> writes:
Walter Bright 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.)
 

But will be compiler accept T«x» if I directly feed it into the compiler? It's no good if what you see cannot be what you type. (« and » can be supported with a simple replacement rule “« ↦ !(” and “» ↦ )” if they appear outside a string.)
 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.

Nice.
Oct 11 2008
next sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
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.
Oct 12 2008
next sibling parent reply KennyTM~ <kennytm gmail.com> writes:
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 ».
Oct 12 2008
next sibling parent reply "Bent Rasmussen" <IncredibleShrinkingSphere Gmail.com> writes:
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 ».

Oct 12 2008
parent reply bearophile <bearophileHUGS lycos.com> writes:
Bent Rasmussen:
 Sure you can
 <red>throw</red>

D code can be contained inside HTML sources too, so that's acceptable syntax. http://www.digitalmars.com/d/1.0/html.html Bye, bearophile
Oct 12 2008
parent KennyTM~ <kennytm gmail.com> writes:
bearophile wrote:
 Bent Rasmussen:
 Sure you can
 <red>throw</red>

D code can be contained inside HTML sources too, so that's acceptable syntax. http://www.digitalmars.com/d/1.0/html.html Bye, bearophile

I got "module html html source files is deprecated html.html".
Oct 12 2008
prev sibling next sibling parent reply KennyTM~ <kennytm gmail.com> writes:
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?

 It's no good if what you see cannot be what you type.

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. :)
Oct 12 2008
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
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?

 It's no good if what you see cannot be what you type.

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
Oct 12 2008
parent reply KennyTM~ <kennytm gmail.com> writes:
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?

 It's no good if what you see cannot be what you type.

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.
Oct 12 2008
next sibling parent Derek Parnell <derek psych.ward> writes:
On Mon, 13 Oct 2008 04:06:57 +0800, KennyTM~ wrote:


 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.

But they will only see the chevrons if they are using Andrei's personal editor and setup. I never use Emacs so I'll never see the chevrons. -- Derek Parnell Melbourne, Australia skype: derek.j.parnell
Oct 12 2008
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
KennyTM~ wrote:
 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.

I understand. You basically overestimate at the same time my proficiency with emacs and the extent of my influence. Anyhow, should an emacs module with various embellishments be offered anywhere near "officially", it will not have features that are experimental or unusual turned on by default. Andrei
Oct 12 2008
parent reply KennyTM~ <kennytm gmail.com> writes:
Andrei Alexandrescu wrote:
 KennyTM~ wrote:
 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.

I understand. You basically overestimate at the same time my proficiency with emacs and the extent of my influence. Anyhow, should an emacs module with various embellishments be offered anywhere near "officially", it will not have features that are experimental or unusual turned on by default. Andrei

I see.
Oct 12 2008
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

KennyTM~ wrote:
 Andrei Alexandrescu wrote:
 KennyTM~ wrote:
 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.

I understand. You basically overestimate at the same time my proficiency with emacs and the extent of my influence. Anyhow, should an emacs module with various embellishments be offered anywhere near "officially", it will not have features that are experimental or unusual turned on by default. Andrei

I see.

Now everyone can literally see (attached). I added Unicode display for a couple more tokens. I will experiment with that look and feel for a while and see how it fares. I just told Walter even his code looks good now :o). Andrei
Oct 12 2008
next sibling parent reply Robert Fraser <fraserofthenight gmail.com> writes:
Andrei Alexandrescu wrote:
  I just told Walter even his code looks good 
 now :o).

It can replace "goto" with scenes from the Looney Toons?
Oct 13 2008
parent Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
Robert Fraser wrote:
 Andrei Alexandrescu wrote:
  I just told Walter even his code looks good now :o).

It can replace "goto" with scenes from the Looney Toons?

LOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOL Seriously, I gave a good laugh with that one ;D -- Bruno Medeiros - Software Developer, MSc. in CS/E graduate http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
Oct 14 2008
prev sibling parent "Bent Rasmussen" <IncredibleShrinkingSphere Gmail.com> writes:
That's looking very nice. Esp. the boolean expressions!

- Bent
 
Oct 18 2008
prev sibling next sibling parent reply Sergey Gromov <snake.scaly gmail.com> writes:
Mon, 13 Oct 2008 01:18:35 +0800,
KennyTM~ wrote:
 Walter Bright wrote:
 KennyTM~ wrote:
 But will be compiler accept T=ABx=BB if I directly feed it into the co=



=20
 No.
=20
 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 impai=


 the usefulness of an editor that displays it that way.

Because you can't type color, but you can type =AB and =BB.

You can type runes either. Let's use Fehu for function types and literals!
Oct 12 2008
next sibling parent KennyTM~ <kennytm gmail.com> writes:
Sergey Gromov wrote:
 Mon, 13 Oct 2008 01:18:35 +0800,
 KennyTM~ wrote:
 Walter Bright wrote:
 KennyTM~ wrote:
 But will be compiler accept T«x» if I directly feed it into the compiler?

 It's no good if what you see cannot be what you type.

the usefulness of an editor that displays it that way.


You can type runes either. Let's use Fehu for function types and literals!

I wonder if there's an emacs module for it... :p
Oct 12 2008
prev sibling parent Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
Sergey Gromov wrote:
 Mon, 13 Oct 2008 01:18:35 +0800,
 KennyTM~ wrote:
 Walter Bright wrote:
 KennyTM~ wrote:
 But will be compiler accept Tx if I directly feed it into the compiler?

 It's no good if what you see cannot be what you type.

the usefulness of an editor that displays it that way.


You can type runes either. Let's use Fehu for function types and literals!

Now that's real arcana!! There really should be a programming language that looked magic scrolls! -- Bruno Medeiros - Software Developer, MSc. in CS/E graduate http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
Oct 14 2008
prev sibling parent "Bill Baxter" <wbaxter gmail.com> writes:
On Sun, Oct 19, 2008 at 7:40 AM, Bent Rasmussen
<IncredibleShrinkingSphere gmail.com> wrote:
 That's looking very nice. Esp. the boolean expressions!

ERROR: Vote ignored for lack of context. If you're going to go to the trouble to agree to something, you might as well quote what it is that you're agreeing to. :-) --bb
Oct 18 2008
prev sibling parent "Jarrett Billingsley" <jarrett.billingsley gmail.com> writes:
On Mon, Oct 13, 2008 at 2:59 AM, Andrei Alexandrescu
<SeeWebsiteForEmail erdani.org> wrote:
 Now everyone can literally see (attached). I added Unicode display for a
 couple more tokens. I will experiment with that look and feel for a while
 and see how it fares. I just told Walter even his code looks good now :o).

That won't happen until he stops mixing tabs and spaces!
Oct 13 2008
prev sibling parent "Denis Koroskin" <2korden gmail.com> writes:
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?

 It's no good if what you see cannot be what you type.

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.
Oct 12 2008
prev sibling next sibling parent "Bill Baxter" <wbaxter gmail.com> writes:
On Sat, Oct 11, 2008 at 6:57 PM, Walter Bright
<newshound1 digitalmars.com> wrote:
 Bill Baxter wrote:
 But it's not the << and >> that make C++ templates hard to understand.

I think it does. I could never get past the visual ambiguity with less than, and with the streams, the ambiguity with >>. But that isn't the worst of it, the C++ template definition syntax sets my teeth on edge.
  Replacing that with some other character or character sequence would
 make very little difference in how difficult they are to understand.
 It's more the lack of a straighforward equivalent for things like
 static if.

There are a lot of issues that needed improvement.
 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.

Ok, I don't disagree with that, but you're changing your argument. Before you said << and >> prevented you from remembering how to do things with C++ templates. Not liking the looks of the result or finding it hard to read can be a turn-off, sure, but I don't think << and >> are what make it hard to remember how to fake a static if with C++. That's all I was objecting to.
 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.

But people don't say they have to copy&paste code because the word "invariant" blocks their brains from remembering how to write the code. If there's something hard to remember about how to write such code, changing the word from "invariant" to "immutable" isn't going to change that. That's all I'm tryin' to say. --bb
Oct 11 2008
prev sibling next sibling parent reply "Dave" <Dave_member pathlink.com> writes:
"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 foobar 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 '>>'. a) It works for C++0x so it can be made to work for D using the same rules. I also assume that C# and Java compilers use the same methods as C++0x to work around the ambiguities with the right-shift operator. b) Easier and more natural for D newbies who've used C++ templates and/or C# / Java Generics. c) There can be no D code where ">>" instead of "> >" breaks existing code like C++98 vs C++0x. d) There wouldn't be the "I hate it because it's not C++ enough" first impression for templates. e) Less typing compared to current. f) Could make definition and instantiation consistent as well: class C<T> {T val;} auto c = new C<int>; g) I'm sure the same workaround could be used for D's UShr operator '>>>'. h) Andrei will like it better because it's closer to chevrons <g> Also, as long as I'm thinking out of the box here, for D2 how about considering using a different group of symbols for bitwise shift (if for some reason the ambiguity issue is too large to work around)? Before you yell "Sacralidge!" and roll your eyes, consider that out of about 100K lines of D code in phobos, 381 have "<<|>>" and 1711 have "!(.*)". Also, '>>>' is only used 25 times in phobos and could be replaced with '>>' and a cast where it is used. Perhaps ~> (shr), ~< (shl), ~>> (ushr), ~<= (shlAssign) and ~>= (shrAssign)? Just a thought. Still there may be an issue with a<b,c>d, but again that is apparently solved in C#, Java and C++0x, and I didn't find any of that used in phobos. I think the way they solved this in C# at least was to disallow the comma operator between conditional predicates, which I don't see as a huge issue. - Dave
Oct 11 2008
next sibling parent reply KennyTM~ <kennytm gmail.com> writes:
Dave wrote:
 
 "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.

You can always use !(...); the current proposal is backward-compat. I wonder why no one complains “3 - 4 - 5” brings a huge can of worm. The problem of ! as I see is that it is not associative (a!(b!c) != (a!b)!c), so we can just define an associativity preference just like the - (left-assoc) and = (right-assoc) operators.
 I hadn't seen this mentioned lately; C#, Java and now C++0x are able to 
 work around the '> >' issue and allow '>>'.
 
 a) It works for C++0x so it can be made to work for D using the same 
 rules. I also assume that C# and Java compilers use the same methods as 
 C++0x to work around the ambiguities with the right-shift operator.

The argument against T<x> from the start is that it is more difficult to parse. It is not impossible, it is just difficult. You can blame Walter for being lazy.
 b) Easier and more natural for D newbies who've used C++ templates 
 and/or C# / Java Generics.

I agree.
 c) There can be no D code where ">>" instead of "> >" breaks existing 
 code like C++98 vs C++0x.
 d) There wouldn't be the "I hate it because it's not C++ enough" first 
 impression for templates.

I don't know if there's anyone arguing this, and I'm OK with !(...).
 e) Less typing compared to current.

Even less using the new a!b syntax.
 f) Could make definition and instantiation consistent as well:
 class C<T> {T val;}
 auto c = new C<int>;

This is an irrelevant design issue. D can be engineered to support class C!T { T val; } auto c = new C!int; as well I believe, but the current implementation uses class C(T) instead. (BTW, you've left out the “template <typename T>” line before the class C<T> statement.)
 g) I'm sure the same workaround could be used for D's UShr operator '>>>'.
 h) Andrei will like it better because it's closer to chevrons <g>

Me too «g»
 
 Also, as long as I'm thinking out of the box here, for D2 how about 
 considering using a different group of symbols for bitwise shift (if for 
 some reason the ambiguity issue is too large to work around)?
 
 Before you yell "Sacralidge!" and roll your eyes, consider that out of 
 about 100K lines of D code in phobos, 381 have "<<|>>" and  1711 have 
 "!(.*)". Also, '>>>' is only used 25 times in phobos and could be 
 replaced with '>>' and a cast where it is used.
 
 Perhaps ~> (shr), ~< (shl), ~>> (ushr), ~<= (shlAssign) and ~>= 
 (shrAssign)?
 
 Just a thought.
 
 Still there may be an issue with a<b,c>d, but again that is apparently 
 solved in C#, Java  and C++0x, and I didn't find any of that used in 
 phobos. I think the way they solved this in C# at least was to disallow 
 the comma operator between conditional predicates, which I don't see as 
 a huge issue.
 
 - Dave
 

Oct 11 2008
next sibling parent reply "Dave" <Dave_member pathlink.com> writes:
"KennyTM~" <kennytm gmail.com> wrote in message 
news:gcqnqd$161r$1 digitalmars.com...
 Dave wrote:
 "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.

You can always use !(...); the current proposal is backward-compat.

But the problem I have with it is some poor sucker maintaining someone else's code who uses the new syntax, maybe even inconsistently in the same module.
 I wonder why no one complains “3 - 4 - 5” brings a huge can of worm. The 
 problem of ! as I see is that it is not associative (a!(b!c) != (a!b)!c), 
 so we can just define an associativity preference just like the - 
 (left-assoc) and = (right-assoc) operators.

Good point, except that would mean yet more rules to remember when the current !() syntax makes it clear. This whole thing will just make D templates harder to learn, understand, use and maintain.
 I hadn't seen this mentioned lately; C#, Java and now C++0x are able to 
 work around the '> >' issue and allow '>>'.

 a) It works for C++0x so it can be made to work for D using the same 
 rules. I also assume that C# and Java compilers use the same methods as 
 C++0x to work around the ambiguities with the right-shift operator.

The argument against T<x> from the start is that it is more difficult to parse. It is not impossible, it is just difficult. You can blame Walter for being lazy.

Lazy doesn't mean to Walter what it means to the rest of us... To Walter, "lazy" is another way of saying for "I don't agree and I'd rather just do something else" <g> I just saw a post where Walter says he hates the angle brackets and that syntax matters. I agree that syntax does matter, and apparently many developers and other language designers don't have a problem with the "<>" syntax. So maybe Walter needs to bite the bullet and D should just use it. Maybe D is bucking a trend here where it shouldn't.
 b) Easier and more natural for D newbies who've used C++ templates and/or 
 C# / Java Generics.

I agree.

This is probably the biggest issue since D has to win mindshare or else what is the point of this or any other discussion.
 c) There can be no D code where ">>" instead of "> >" breaks existing 
 code like C++98 vs C++0x.
 d) There wouldn't be the "I hate it because it's not C++ enough" first 
 impression for templates.

I don't know if there's anyone arguing this, and I'm OK with !(...).
 e) Less typing compared to current.

Even less using the new a!b syntax.
 f) Could make definition and instantiation consistent as well:
 class C<T> {T val;}
 auto c = new C<int>;

This is an irrelevant design issue. D can be engineered to support class C!T { T val; } auto c = new C!int;

Even more inconsistency and duplication <g>
 as well I believe, but the current implementation uses class C(T) instead. 
 (BTW, you've left out the “template <typename T>” line before the class 
 C<T> statement.)

I don't understand... I was talking about just replacing () and !() with the <> that C++, C# and Java use, not changing anything else regarding D template syntax.
 g) I'm sure the same workaround could be used for D's UShr operator 
 '>>>'.
 h) Andrei will like it better because it's closer to chevrons <g>

Me too «g»
 Also, as long as I'm thinking out of the box here, for D2 how about 
 considering using a different group of symbols for bitwise shift (if for 
 some reason the ambiguity issue is too large to work around)?

 Before you yell "Sacralidge!" and roll your eyes, consider that out of 
 about 100K lines of D code in phobos, 381 have "<<|>>" and  1711 have 
 "!(.*)". Also, '>>>' is only used 25 times in phobos and could be 
 replaced with '>>' and a cast where it is used.

 Perhaps ~> (shr), ~< (shl), ~>> (ushr), ~<= (shlAssign) and ~>= 
 (shrAssign)?

 Just a thought.

 Still there may be an issue with a<b,c>d, but again that is apparently 
 solved in C#, Java  and C++0x, and I didn't find any of that used in 
 phobos. I think the way they solved this in C# at least was to disallow 
 the comma operator between conditional predicates, which I don't see as a 
 huge issue.

 - Dave
 


Oct 11 2008
next sibling parent KennyTM~ <kennytm gmail.com> writes:
Dave wrote:
 "KennyTM~" <kennytm gmail.com> wrote in message 
 news:gcqnqd$161r$1 digitalmars.com...
 Dave wrote:
 "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.

You can always use !(...); the current proposal is backward-compat.

But the problem I have with it is some poor sucker maintaining someone else's code who uses the new syntax, maybe even inconsistently in the same module.
 I wonder why no one complains “3 - 4 - 5” brings a huge can of worm. 
 The problem of ! as I see is that it is not associative (a!(b!c) != 
 (a!b)!c), so we can just define an associativity preference just like 
 the - (left-assoc) and = (right-assoc) operators.

Good point, except that would mean yet more rules to remember when the current !() syntax makes it clear. This whole thing will just make D templates harder to learn, understand, use and maintain.
 I hadn't seen this mentioned lately; C#, Java and now C++0x are able 
 to work around the '> >' issue and allow '>>'.

 a) It works for C++0x so it can be made to work for D using the same 
 rules. I also assume that C# and Java compilers use the same methods 
 as C++0x to work around the ambiguities with the right-shift operator.

The argument against T<x> from the start is that it is more difficult to parse. It is not impossible, it is just difficult. You can blame Walter for being lazy.

Lazy doesn't mean to Walter what it means to the rest of us... To Walter, "lazy" is another way of saying for "I don't agree and I'd rather just do something else" <g>

lol.
 I just saw a post where Walter says he hates the angle brackets and that 
 syntax matters. I agree that syntax does matter, and apparently many 
 developers and other language designers don't have a problem with the 
 "<>" syntax. So maybe Walter needs to bite the bullet and D should just 
 use it. Maybe D is bucking a trend here where it shouldn't.
 
 b) Easier and more natural for D newbies who've used C++ templates 
 and/or C# / Java Generics.

I agree.

This is probably the biggest issue since D has to win mindshare or else what is the point of this or any other discussion.
 c) There can be no D code where ">>" instead of "> >" breaks existing 
 code like C++98 vs C++0x.
 d) There wouldn't be the "I hate it because it's not C++ enough" 
 first impression for templates.

I don't know if there's anyone arguing this, and I'm OK with !(...).
 e) Less typing compared to current.

Even less using the new a!b syntax.
 f) Could make definition and instantiation consistent as well:
 class C<T> {T val;}
 auto c = new C<int>;

This is an irrelevant design issue. D can be engineered to support class C!T { T val; } auto c = new C!int;

Even more inconsistency and duplication <g>
 as well I believe, but the current implementation uses class C(T) 
 instead. (BTW, you've left out the “template <typename T>” line before 
 the class C<T> statement.)

I don't understand... I was talking about just replacing () and !() with the <> that C++, C# and Java use, not changing anything else regarding D template syntax.

I thought you argued class C(T) { T val; } auto c = new C!(int); is inconsistent because in definition you used (...) but in usage you used !(...) ?
 g) I'm sure the same workaround could be used for D's UShr operator 
 '>>>'.
 h) Andrei will like it better because it's closer to chevrons <g>

Me too «g»
 Also, as long as I'm thinking out of the box here, for D2 how about 
 considering using a different group of symbols for bitwise shift (if 
 for some reason the ambiguity issue is too large to work around)?

 Before you yell "Sacralidge!" and roll your eyes, consider that out 
 of about 100K lines of D code in phobos, 381 have "<<|>>" and  1711 
 have "!(.*)". Also, '>>>' is only used 25 times in phobos and could 
 be replaced with '>>' and a cast where it is used.

 Perhaps ~> (shr), ~< (shl), ~>> (ushr), ~<= (shlAssign) and ~>= 
 (shrAssign)?

 Just a thought.

 Still there may be an issue with a<b,c>d, but again that is 
 apparently solved in C#, Java  and C++0x, and I didn't find any of 
 that used in phobos. I think the way they solved this in C# at least 
 was to disallow the comma operator between conditional predicates, 
 which I don't see as a huge issue.

 - Dave



Oct 11 2008
prev sibling next sibling parent reply "Nick Sabalausky" <a a.a> writes:
"Dave" <Dave_member pathlink.com> wrote in message 
news:gcqrbr$1cg4$1 digitalmars.com...
 "KennyTM~" <kennytm gmail.com> wrote in message 
 news:gcqnqd$161r$1 digitalmars.com...
 Dave wrote:
 a) It works for C++0x so it can be made to work for D using the same 
 rules. I also assume that C# and Java compilers use the same methods as 
 C++0x to work around the ambiguities with the right-shift operator.

The argument against T<x> from the start is that it is more difficult to parse. It is not impossible, it is just difficult. You can blame Walter for being lazy.

Lazy doesn't mean to Walter what it means to the rest of us... To Walter, "lazy" is another way of saying for "I don't agree and I'd rather just do something else" <g> I just saw a post where Walter says he hates the angle brackets and that syntax matters. I agree that syntax does matter, and apparently many developers and other language designers don't have a problem with the "<>" syntax. So maybe Walter needs to bite the bullet and D should just use it. Maybe D is bucking a trend here where it shouldn't.

One of the original guiding principles of D is that it be easy to parse. There were a number of valid reasons for this, not just lazyness. Plus, I'm no compiler expert, but I think I rememebr hearing somewhere that overloadng <> to be usable for both comparisons and grouping would require non-context-free grammar. That would be a major increase in D's parsing complexity. C++ grammer is definately not context-free, that's why it can get away with it. Not sure about C# or Java, but I've been under the impression those aren't context-free either.
 b) Easier and more natural for D newbies who've used C++ templates 
 and/or C# / Java Generics.

I agree.

This is probably the biggest issue since D has to win mindshare or else what is the point of this or any other discussion.

I consider this a non-issue. D is a different language, it's expected that certain things are going to be different. Otherwise it would be the same damn language. I had used C++ templates before I came across D, and my entire thought on it was just "Ok, C++ uses <>, and D uses !()". Done. It's no more of an issue than switching between Java's "{}" and ";" and VB.NET's "X...end X" and "newline". D needs to win mindshare, sure, but there are better ways to do that than advertising a popular bikeshed color.
Oct 11 2008
next sibling parent reply "Dave" <Dave_member pathlink.com> writes:
"Nick Sabalausky" <a a.a> wrote in message 
news:gcqvfr$1k6i$1 digitalmars.com...
 "Dave" <Dave_member pathlink.com> wrote in message 
 news:gcqrbr$1cg4$1 digitalmars.com...
 "KennyTM~" <kennytm gmail.com> wrote in message 
 news:gcqnqd$161r$1 digitalmars.com...
 Dave wrote:
 a) It works for C++0x so it can be made to work for D using the same 
 rules. I also assume that C# and Java compilers use the same methods as 
 C++0x to work around the ambiguities with the right-shift operator.

The argument against T<x> from the start is that it is more difficult to parse. It is not impossible, it is just difficult. You can blame Walter for being lazy.

Lazy doesn't mean to Walter what it means to the rest of us... To Walter, "lazy" is another way of saying for "I don't agree and I'd rather just do something else" <g> I just saw a post where Walter says he hates the angle brackets and that syntax matters. I agree that syntax does matter, and apparently many developers and other language designers don't have a problem with the "<>" syntax. So maybe Walter needs to bite the bullet and D should just use it. Maybe D is bucking a trend here where it shouldn't.

One of the original guiding principles of D is that it be easy to parse. There were a number of valid reasons for this, not just lazyness. Plus, I'm no compiler expert, but I think I rememebr hearing somewhere that overloadng <> to be usable for both comparisons and grouping would require non-context-free grammar. That would be a major increase in D's parsing complexity. C++ grammer is definately not context-free, that's why it can get away with it. Not sure about C# or Java, but I've been under the impression those aren't context-free either.

I can see your point and to a point I think it is a valid concern. But, most users could care less about that stuff IMO. Abstraction from what a compiler does is why we use higher-level languages in the first place <g> I'd argue that it's more important to have demand for a language than to make it easy on the compiler writers and language designers but I agree there has to be a balance.
 b) Easier and more natural for D newbies who've used C++ templates 
 and/or C# / Java Generics.

I agree.

This is probably the biggest issue since D has to win mindshare or else what is the point of this or any other discussion.

I consider this a non-issue. D is a different language, it's expected that certain things are going to be different. Otherwise it would be the same damn language. I had used C++ templates before I came across D, and my entire thought on it was just "Ok, C++ uses <>, and D uses !()". Done. It's

I agree; in an earlier post I questioned any need for deviating from the current syntax. But if the concensus is that a change is needed, all I'm arguing is that it should be towards other popular C-lineage language conventions rather than further from them. There are plenty of other even more important differences (even for just templates) that make D a better language, and easier to build a compiler for, for that matter.
 no more of an issue than switching between Java's "{}" and ";" and 
 VB.NET's "X...end X" and "newline".

 D needs to win mindshare, sure, but there are better ways to do that than 
 advertising a popular bikeshed color.

For D, I see template syntax as closer to the nuclear plant than to the bikeshed in the scheme of things. Although by the amount of discussion this topic has generated, I can see your point <g>
Oct 11 2008
next sibling parent reply "Nick Sabalausky" <a a.a> writes:
"Dave" <Dave_member pathlink.com> wrote in message 
news:gcr2jc$1pn4$1 digitalmars.com...
 "Nick Sabalausky" <a a.a> wrote in message 
 news:gcqvfr$1k6i$1 digitalmars.com...
 "Dave" <Dave_member pathlink.com> wrote in message 
 news:gcqrbr$1cg4$1 digitalmars.com...
 "KennyTM~" <kennytm gmail.com> wrote in message 
 news:gcqnqd$161r$1 digitalmars.com...
 Dave wrote:
 a) It works for C++0x so it can be made to work for D using the same 
 rules. I also assume that C# and Java compilers use the same methods 
 as C++0x to work around the ambiguities with the right-shift operator.

The argument against T<x> from the start is that it is more difficult to parse. It is not impossible, it is just difficult. You can blame Walter for being lazy.

Lazy doesn't mean to Walter what it means to the rest of us... To Walter, "lazy" is another way of saying for "I don't agree and I'd rather just do something else" <g> I just saw a post where Walter says he hates the angle brackets and that syntax matters. I agree that syntax does matter, and apparently many developers and other language designers don't have a problem with the "<>" syntax. So maybe Walter needs to bite the bullet and D should just use it. Maybe D is bucking a trend here where it shouldn't.

One of the original guiding principles of D is that it be easy to parse. There were a number of valid reasons for this, not just lazyness. Plus, I'm no compiler expert, but I think I rememebr hearing somewhere that overloadng <> to be usable for both comparisons and grouping would require non-context-free grammar. That would be a major increase in D's parsing complexity. C++ grammer is definately not context-free, that's why it can get away with it. Not sure about C# or Java, but I've been under the impression those aren't context-free either.

I can see your point and to a point I think it is a valid concern. But, most users could care less about that stuff IMO. Abstraction from what a compiler does is why we use higher-level languages in the first place <g> I'd argue that it's more important to have demand for a language than to make it easy on the compiler writers and language designers but I agree there has to be a balance.

One of the motivations cited for easy parsing was pointing at C++ (and its template syntax in particular) as an example of a grammar being so complex that only major compiler vendors could realistically attempt a complete implementation, and even they had a rediculously hard time actually getting it implemented right. Point being, there are ways in which easy parsing does translate into a win for the average coder (better quality compilers in a shorter time, room for more compiler competition). But of course you're right that designing for easy parsing shouldn't be taken too far (or else we'd all be flipping switches Altair-style).
Oct 11 2008
parent reply Robert Fraser <fraserofthenight gmail.com> writes:
Nick Sabalausky wrote:
 Point being, there are ways in which easy parsing does translate into a win 
 for the average coder (better quality compilers in a shorter time, room for 
 more compiler competition). But of course you're right that designing for 
 easy parsing shouldn't be taken too far (or else we'd all be flipping 
 switches Altair-style). 

Easy parsing doesn't always just mean "easier to implement". Other advantages of a context-free grammar are faster IDEs/smart editors tools (since they don't need to keep symbol caches while parsing) and faster compile times. I think a context-free grammar is a big win all-around.
Oct 11 2008
parent reply bearophile <bearophileHUGS lycos.com> writes:
Robert Fraser:
 I think a context-free grammar is a big win all-around.

Such things have some disadvantages too, like not allowing (?) a syntax like, for example: foreach (i, x in something) {...} Instead of the current more error-prone: foreach (i, x; something) {...} Bye, bearophile
Oct 11 2008
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
bearophile wrote:
 Robert Fraser:
 I think a context-free grammar is a big win all-around.

Such things have some disadvantages too, like not allowing (?) a syntax like, for example: foreach (i, x in something) {...} Instead of the current more error-prone: foreach (i, x; something) {...}

Both can be done with a CFG. Andrei
Oct 11 2008
parent bearophile <bearophileHUGS lycos.com> writes:
Andrei Alexandrescu:
 bearophile wrote:
 foreach (i, x in something) {...}
 Instead of the current more error-prone:
 foreach (i, x; something) {...}

Both can be done with a CFG.

Recently I have explained here why the syntax (i, x; something) is error prone, and other people have told me that they agree that sometimes that syntax leads to bugs like (i, x, something) (and the error message isn't much clear). I have received an answer, maybe from Walter, that syntax (i, x in something) can't be accepted because "in" is already taken to tell the key presence inside an associative array (while not being yet usable to scan for presence of items into a normal array), so it "can't" be used inside the foreach syntax too... So probably it's not a problem of grammar, but of successive stages of the compilation. The net result for the programmer is the same, this time the D compiler is rigid and doesn't allow for a more readable/less error-prone syntax. Bye, bearophile
Oct 11 2008
prev sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Jarrett Billingsley:
 It's not "error-prone", it's "you're not used to it."  You very
 commonly fall into the fallacy that if you think something's
 bad/confusing/not what you're used to, then _everyone_ must think that
 way and therefore it _must_ change.  Sorry, that's not the way it
 works.  I haven't mistyped a foreach loop, ever.  Deal with it.

I remember that when I have discussed about this topic the first time another person has said of sharing this problem of mine with this syntax. C# foreach syntax uses the "in", and Python too uses it. Both languages are quite more used than D, are modern, and they care about their usability and readability. If I don't talk about this topic I can't know if it's a common problem, or a personal one. So even if I am wrong (and I am wrong all the time), and the current foreach syntax of D isn't bug-prone, I think the topic deserves a little discussion, so people can show who's right. Bye, bearophile
Oct 11 2008
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Bill Baxter wrote:
 On Sun, Oct 12, 2008 at 10:46 AM, bearophile <bearophileHUGS lycos.com> wrote:
 Jarrett Billingsley:
 It's not "error-prone", it's "you're not used to it."  You very
 commonly fall into the fallacy that if you think something's
 bad/confusing/not what you're used to, then _everyone_ must think that
 way and therefore it _must_ change.  Sorry, that's not the way it
 works.  I haven't mistyped a foreach loop, ever.  Deal with it.

C# foreach syntax uses the "in", and Python too uses it. Both languages are quite more used than D, are modern, and they care about their usability and readability. If I don't talk about this topic I can't know if it's a common problem, or a personal one. So even if I am wrong (and I am wrong all the time), and the current foreach syntax of D isn't bug-prone, I think the topic deserves a little discussion, so people can show who's right.

I agree with you, Bearophile. And I may be the person you remember agreeing with you before. So we may be the only two. :-) Although clearly designers of C# and Python thought it looked nicer than other possibilities, so apparently they agree too. But anyway it seems not to be an easy change to make it work in D without ruining the easy syntax parsing. So another idea for unambiguous syntax is needed. An 'of' keyword or make an in-expression or something. foreach(x of thinglist) { ... } foreach(x in(thinglist)) { ... } foreach(x (in) thinglist) { ... } But even then, the result has to be so much better than ";" that it's worth breaking backwards compatibility. I think that's a hard sell. ";" works and its not totally terrible, and it does have precedent with the semicolons in regular for loops.

I don't see any technical difficulty with allowing foreach (x in y). Andrei
Oct 11 2008
parent Derek Parnell <derek psych.ward> writes:
On Sat, 11 Oct 2008 21:07:20 -0500, Andrei Alexandrescu wrote:

 I don't see any technical difficulty with allowing foreach (x in y).

Agreed. However, to my eye, "foreach(i, x in y)" seems to read as if both 'x' and 'i' are IN 'y'. Whereas I think of "foreach(i, x; y)" as a list of variables, of which the last one is a placeholder for elements of 'y'. Maybe it's just me though ;-) -- Derek Parnell Melbourne, Australia skype: derek.j.parnell
Oct 11 2008
prev sibling next sibling parent "Jarrett Billingsley" <jarrett.billingsley gmail.com> writes:
On Sun, Oct 12, 2008 at 4:16 AM, Bill Baxter <wbaxter gmail.com> wrote:

 But even then, the result has to be so much better than ";" that it's
 worth breaking backwards compatibility.  I think that's a hard sell.
 ";" works and its not totally terrible, and it does have precedent
 with the semicolons in regular for loops.



It's no different than .() vs !() in that regard.
 Walter seems to think there is for some reason.  Maybe because of
 foreach(x in y in z) ?

It's still grammatically unambiguous. The first 'in' is interpreted as the end of the index list and the beginning of the container expression; and the second 'in' is parsed as the container expression. It looks dumb but wouldn't come up that often anyway.
Oct 11 2008
prev sibling parent reply Christopher Wright <dhasenan gmail.com> writes:
Dave wrote:
 "Nick Sabalausky" <a a.a> wrote in message 
 news:gcqvfr$1k6i$1 digitalmars.com...
 One of the original guiding principles of D is that it be easy to 
 parse. There were a number of valid reasons for this, not just lazyness.

 Plus, I'm no compiler expert, but I think I rememebr hearing somewhere 
 that overloadng <> to be usable for both comparisons and grouping 
 would require non-context-free grammar. That would be a major increase 
 in D's parsing complexity. C++ grammer is definately not context-free, 
 that's why it can get away with it. Not sure about C# or Java, but 
 I've been under the impression those aren't context-free either.

I can see your point and to a point I think it is a valid concern. But, most users could care less about that stuff IMO. Abstraction from what a compiler does is why we use higher-level languages in the first place <g>

C++ is much more popular than D, but I haven't found an IDE for it that has a significant advantage over Descent. Many users care a fair bit about IDEs -- I would, if I didn't work over ssh pretty much of the time.
Oct 11 2008
parent Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
Christopher Wright wrote:
 Dave wrote:
 "Nick Sabalausky" <a a.a> wrote in message 
 news:gcqvfr$1k6i$1 digitalmars.com...
 One of the original guiding principles of D is that it be easy to 
 parse. There were a number of valid reasons for this, not just lazyness.

 Plus, I'm no compiler expert, but I think I rememebr hearing 
 somewhere that overloadng <> to be usable for both comparisons and 
 grouping would require non-context-free grammar. That would be a 
 major increase in D's parsing complexity. C++ grammer is definately 
 not context-free, that's why it can get away with it. Not sure about 
 C# or Java, but I've been under the impression those aren't 
 context-free either.

I can see your point and to a point I think it is a valid concern. But, most users could care less about that stuff IMO. Abstraction from what a compiler does is why we use higher-level languages in the first place <g>

C++ is much more popular than D, but I haven't found an IDE for it that has a significant advantage over Descent. Many users care a fair bit about IDEs -- I would, if I didn't work over ssh pretty much of the time.

Actually, CDT seems to have advanced quite a lot in its versions 3 and 4 at least in terms of semantic features (code completion, open declaration, open type, and even refactoring). Last time I checked it, it seemed quite better than VC++ 2005 (except perhaps in the area of debugging). -- Bruno Medeiros - Software Developer, MSc. in CS/E graduate http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
Oct 16 2008
prev sibling next sibling parent "Bill Baxter" <wbaxter gmail.com> writes:
On Sun, Oct 12, 2008 at 11:07 AM, Andrei Alexandrescu
<SeeWebsiteForEmail erdani.org> wrote:
 Bill Baxter wrote:
 On Sun, Oct 12, 2008 at 10:46 AM, bearophile <bearophileHUGS lycos.com>
 wrote:
 Jarrett Billingsley:
 It's not "error-prone", it's "you're not used to it."  You very
 commonly fall into the fallacy that if you think something's
 bad/confusing/not what you're used to, then _everyone_ must think that
 way and therefore it _must_ change.  Sorry, that's not the way it
 works.  I haven't mistyped a foreach loop, ever.  Deal with it.

I remember that when I have discussed about this topic the first time another person has said of sharing this problem of mine with this syntax. C# foreach syntax uses the "in", and Python too uses it. Both languages are quite more used than D, are modern, and they care about their usability and readability. If I don't talk about this topic I can't know if it's a common problem, or a personal one. So even if I am wrong (and I am wrong all the time), and the current foreach syntax of D isn't bug-prone, I think the topic deserves a little discussion, so people can show who's right.

I agree with you, Bearophile. And I may be the person you remember agreeing with you before. So we may be the only two. :-) Although clearly designers of C# and Python thought it looked nicer than other possibilities, so apparently they agree too. But anyway it seems not to be an easy change to make it work in D without ruining the easy syntax parsing. So another idea for unambiguous syntax is needed. An 'of' keyword or make an in-expression or something. foreach(x of thinglist) { ... } foreach(x in(thinglist)) { ... } foreach(x (in) thinglist) { ... } But even then, the result has to be so much better than ";" that it's worth breaking backwards compatibility. I think that's a hard sell. ";" works and its not totally terrible, and it does have precedent with the semicolons in regular for loops.

I don't see any technical difficulty with allowing foreach (x in y).

Walter seems to think there is for some reason. Maybe because of foreach(x in y in z) ? --bb
Oct 11 2008
prev sibling parent Christopher Wright <dhasenan gmail.com> writes:
Nick Sabalausky wrote:
 "Dave" <Dave_member pathlink.com> wrote in message 
 news:gcqrbr$1cg4$1 digitalmars.com...
 "KennyTM~" <kennytm gmail.com> wrote in message 
 news:gcqnqd$161r$1 digitalmars.com...
 Dave wrote:
 a) It works for C++0x so it can be made to work for D using the same 
 rules. I also assume that C# and Java compilers use the same methods as 
 C++0x to work around the ambiguities with the right-shift operator.

parse. It is not impossible, it is just difficult. You can blame Walter for being lazy.

"lazy" is another way of saying for "I don't agree and I'd rather just do something else" <g> I just saw a post where Walter says he hates the angle brackets and that syntax matters. I agree that syntax does matter, and apparently many developers and other language designers don't have a problem with the "<>" syntax. So maybe Walter needs to bite the bullet and D should just use it. Maybe D is bucking a trend here where it shouldn't.

One of the original guiding principles of D is that it be easy to parse. There were a number of valid reasons for this, not just lazyness. Plus, I'm no compiler expert, but I think I rememebr hearing somewhere that overloadng <> to be usable for both comparisons and grouping would require non-context-free grammar. That would be a major increase in D's parsing complexity. C++ grammer is definately not context-free, that's why it can get away with it. Not sure about C# or Java, but I've been under the impression those aren't context-free either.

You can define a context-free grammar that accepts all syntactically correct C++ programs. This will accept many incorrect C++ programs, though, and you have to defer a lot of checking until the semantic phase. The same is true of D. It's a question of how much checking has to be deferred, and whether a reasonably complete AST can be created from a context-free grammar. I don't know where C++ falls.
 b) Easier and more natural for D newbies who've used C++ templates 
 and/or C# / Java Generics.


what is the point of this or any other discussion.

I consider this a non-issue. D is a different language, it's expected that certain things are going to be different. Otherwise it would be the same damn language. I had used C++ templates before I came across D, and my entire thought on it was just "Ok, C++ uses <>, and D uses !()". Done. It's no more of an issue than switching between Java's "{}" and ";" and VB.NET's "X...end X" and "newline".

Hm. VB.NET can do just about everything that C# can. I can read C# easily. It takes a significant amount of effort for me to read VB.NET.
 D needs to win mindshare, sure, but there are better ways to do that than 
 advertising a popular bikeshed color. 
 
 

Oct 11 2008
prev sibling parent "Bill Baxter" <wbaxter gmail.com> writes:
On Sun, Oct 12, 2008 at 11:02 AM, Bill Baxter <wbaxter gmail.com> wrote:
 On Sun, Oct 12, 2008 at 10:46 AM, bearophile <bearophileHUGS lycos.com> wrote:
 Jarrett Billingsley:
 It's not "error-prone", it's "you're not used to it."  You very
 commonly fall into the fallacy that if you think something's
 bad/confusing/not what you're used to, then _everyone_ must think that
 way and therefore it _must_ change.  Sorry, that's not the way it
 works.  I haven't mistyped a foreach loop, ever.  Deal with it.

I remember that when I have discussed about this topic the first time another person has said of sharing this problem of mine with this syntax. C# foreach syntax uses the "in", and Python too uses it. Both languages are quite more used than D, are modern, and they care about their usability and readability. If I don't talk about this topic I can't know if it's a common problem, or a personal one. So even if I am wrong (and I am wrong all the time), and the current foreach syntax of D isn't bug-prone, I think the topic deserves a little discussion, so people can show who's right.

I agree with you, Bearophile. And I may be the person you remember agreeing with you before. So we may be the only two. :-) Although clearly designers of C# and Python thought it looked nicer than other possibilities, so apparently they agree too. But anyway it seems not to be an easy change to make it work in D without ruining the easy syntax parsing. So another idea for unambiguous syntax is needed. An 'of' keyword or make an in-expression or something. foreach(x of thinglist) { ... } foreach(x in(thinglist)) { ... } foreach(x (in) thinglist) { ... } But even then, the result has to be so much better than ";" that it's worth breaking backwards compatibility. I think that's a hard sell. ";" works and its not totally terrible, and it does have precedent with the semicolons in regular for loops.

Another thought -- personally I don't see much value in "in" as an expression. Why can't that just be a library function? I use foreach loops about 100x more often than I use lookup with "in". --bb
Oct 11 2008
prev sibling next sibling parent reply Benji Smith <dlanguage benjismith.net> writes:
KennyTM~ wrote:
 I hadn't seen this mentioned lately; C#, Java and now C++0x are able 
 to work around the '> >' issue and allow '>>'.

 a) It works for C++0x so it can be made to work for D using the same 
 rules. I also assume that C# and Java compilers use the same methods 
 as C++0x to work around the ambiguities with the right-shift operator.


I sympathize, because I actually prefer the Foo<Bar> syntax for template declarations. But it's not a question of it being *harder* to parse, or Walter being "lazy". The only way to resolve the ambiguity in the parser would be to do semantic analysis during the lexical phase. I've worked with a few open-source Java parsers, and ">>" is always recognized as a right-shift operator during tokenization. But then, if the statement doesn't make any sense, the semantic analyzer can rewrite the token stream. (I don't know how Sun does it, but I imagine it's something like that.) As much as I like the angle-bracket template syntax, I think it's a good choice to get rid of that ambiguity. One of the best parts of the D language design is that it's lexically unambiguous, so tokenization, syntactic analysis, and semantic analysis can be completely separate from one another. --benji
Oct 11 2008
parent "Dave" <Dave_member pathlink.com> writes:
"Benji Smith" <dlanguage benjismith.net> wrote in message 
news:gcr39f$1qrm$1 digitalmars.com...
 KennyTM~ wrote:
 I hadn't seen this mentioned lately; C#, Java and now C++0x are able to 
 work around the '> >' issue and allow '>>'.

 a) It works for C++0x so it can be made to work for D using the same 
 rules. I also assume that C# and Java compilers use the same methods as 
 C++0x to work around the ambiguities with the right-shift operator.


I sympathize, because I actually prefer the Foo<Bar> syntax for template declarations.

That's the biggest reason I mentioned it, because others may prefer it and because people were discussing other alternatives that I didn't like at all. Personally I don't have any problem with the !(), and really don't see any reason to change it, at all, including the new shortened foo!bar.
 But it's not a question of it being *harder* to parse, or Walter being 
 "lazy". The only way to resolve the ambiguity in the parser would be to do 
 semantic analysis during the lexical phase.

 I've worked with a few open-source Java parsers, and ">>" is always 
 recognized as a right-shift operator during tokenization. But then, if the 
 statement doesn't make any sense, the semantic analyzer can rewrite the 
 token stream. (I don't know how Sun does it, but I imagine it's something 
 like that.)

 As much as I like the angle-bracket template syntax, I think it's a good 
 choice to get rid of that ambiguity.

My thoughts exactly when I first read: http://www.digitalmars.com/d/2.0/templates-revisited.html
 One of the best parts of the D language design is that it's lexically 
 unambiguous, so tokenization, syntactic analysis, and semantic analysis 
 can be completely separate from one another.

 --benji 

Oct 11 2008
prev sibling parent "Bill Baxter" <wbaxter gmail.com> writes:
On Sun, Oct 12, 2008 at 10:46 AM, bearophile <bearophileHUGS lycos.com> wrote:
 Jarrett Billingsley:
 It's not "error-prone", it's "you're not used to it."  You very
 commonly fall into the fallacy that if you think something's
 bad/confusing/not what you're used to, then _everyone_ must think that
 way and therefore it _must_ change.  Sorry, that's not the way it
 works.  I haven't mistyped a foreach loop, ever.  Deal with it.

I remember that when I have discussed about this topic the first time another person has said of sharing this problem of mine with this syntax. C# foreach syntax uses the "in", and Python too uses it. Both languages are quite more used than D, are modern, and they care about their usability and readability. If I don't talk about this topic I can't know if it's a common problem, or a personal one. So even if I am wrong (and I am wrong all the time), and the current foreach syntax of D isn't bug-prone, I think the topic deserves a little discussion, so people can show who's right.

I agree with you, Bearophile. And I may be the person you remember agreeing with you before. So we may be the only two. :-) Although clearly designers of C# and Python thought it looked nicer than other possibilities, so apparently they agree too. But anyway it seems not to be an easy change to make it work in D without ruining the easy syntax parsing. So another idea for unambiguous syntax is needed. An 'of' keyword or make an in-expression or something. foreach(x of thinglist) { ... } foreach(x in(thinglist)) { ... } foreach(x (in) thinglist) { ... } But even then, the result has to be so much better than ";" that it's worth breaking backwards compatibility. I think that's a hard sell. ";" works and its not totally terrible, and it does have precedent with the semicolons in regular for loops. --bb
Oct 11 2008
prev sibling next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Dave wrote:
 
 "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 foobar 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 '>>'.

It doesn't quite deserve much mentioning. C++ has had at best a Pyrrhic victory with accommodating ">>" (the cost was a keyword, a special syntax, and a few special syntax cases). Java's templates are emasculated to begin with, and ">>" makes sure they won't easily become more powerful.
 a) It works for C++0x so it can be made to work for D using the same 
 rules. I also assume that C# and Java compilers use the same methods as 
 C++0x to work around the ambiguities with the right-shift operator.

The methods are very different and that is because Java/C# generics are less powerful.
 b) Easier and more natural for D newbies who've used C++ templates 
 and/or C# / Java Generics.

Does the C++ construct a.template foo<b>(c); strike you as particularly natural? Do you know when you need to use it and when not? In all honesty, did you ever know it exists?
 c) There can be no D code where ">>" instead of "> >" breaks existing 
 code like C++98 vs C++0x.

That is incorrect.
 d) There wouldn't be the "I hate it because it's not C++ enough" first 
 impression for templates.

I think the exclamation "it's not C++ enough" usually comes with a sigh of relief.
 e) Less typing compared to current.
 f) Could make definition and instantiation consistent as well:
 class C<T> {T val;}
 auto c = new C<int>;

That comes bundled with making writing of a D parser essentially impossible.
 g) I'm sure the same workaround could be used for D's UShr operator '>>>'.

No. That will only make things another order of magnitude harder.
 h) Andrei will like it better because it's closer to chevrons <g>

Chevrons are not ">". They do pair.
 Also, as long as I'm thinking out of the box here, for D2 how about 
 considering using a different group of symbols for bitwise shift (if for 
 some reason the ambiguity issue is too large to work around)?

It would also need to use a different symbol for less-than and greater-than. But Fortran's .LT. and .GT. don't seem that enticing.
 Before you yell "Sacralidge!" and roll your eyes, consider that out of 
 about 100K lines of D code in phobos, 381 have "<<|>>" and  1711 have 
 "!(.*)". Also, '>>>' is only used 25 times in phobos and could be 
 replaced with '>>' and a cast where it is used.

I agree that '>>>' should go. The compiler can simply use the type of the operand to disambiguate signed vs. unsigned shift. I'm glad you reminded me to remind Walter of that.
 Perhaps ~> (shr), ~< (shl), ~>> (ushr), ~<= (shlAssign) and ~>= 
 (shrAssign)?

I like the shr :o).
 Just a thought.
 
 Still there may be an issue with a<b,c>d, but again that is apparently 
 solved in C#, Java  and C++0x, and I didn't find any of that used in 
 phobos. I think the way they solved this in C# at least was to disallow 
 the comma operator between conditional predicates, which I don't see as 
 a huge issue.

I think you'll find it very instructive to familiarize yourself with the ways C++, Java, and C# accommodate use of <> as brackets. Andrei
Oct 11 2008
next sibling parent bearophile <bearophileHUGS lycos.com> writes:
Andrei Alexandrescu:
 I think the exclamation "it's not C++ enough" usually comes with a sigh
 of relief.

Quote of the week, thanks for the laugh :-)
 Perhaps ~> (shr), ~< (shl), ~>> (ushr), ~<= (shlAssign) and ~>= 
 (shrAssign)?

I like the shr :o).

You know that Pascal/ObjectPascal use shr and shl as operators: x := x shl 10; But they don't have a syntax for the shlAssign/shrAssign. Bye, bearophile
Oct 11 2008
prev sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
Dave wrote:
 Still there may be an issue with a<b,c>d, but again that is apparently 
 solved in C#, Java  and C++0x,

In C++, this is resolved by looking 'a' up in the symbol table to see if it is a template or not. This means it is impossible to parse C++ without doing semantic analysis. Such means it is impossible to write *correct* C++ tools that analyze syntax, such as color syntax highlighting, without writing most of a full compiler. (In cases, such as template bodies, where the compiler cannot do semantic analysis for parsing, the language requires the 'template' keyword be inserted before the 'a'..) There are a lot of hackish ways to parse C++ 95% correctly, and these are often used in editors. But none of them do it 100% unless they are backed by a full C++ compiler. C++ pays a high price for the < >, and still fails to get the job done correctly. I don't know specifically how Java and C# do it, but their generics are not true templates, they are only types, and so can only appear in very restricted circumstances.
Oct 11 2008
parent "Nick Sabalausky" <a a.a> writes:
"Walter Bright" <newshound1 digitalmars.com> wrote in message 
news:gcr67e$20a4$1 digitalmars.com...
 Dave wrote:
 Still there may be an issue with a<b,c>d, but again that is apparently 
 solved in C#, Java  and C++0x,

In C++, this is resolved by looking 'a' up in the symbol table to see if it is a template or not. This means it is impossible to parse C++ without doing semantic analysis. Such means it is impossible to write *correct* C++ tools that analyze syntax, such as color syntax highlighting, without writing most of a full compiler. (In cases, such as template bodies, where the compiler cannot do semantic analysis for parsing, the language requires the 'template' keyword be inserted before the 'a'..) There are a lot of hackish ways to parse C++ 95% correctly, and these are often used in editors. But none of them do it 100% unless they are backed by a full C++ compiler. C++ pays a high price for the < >, and still fails to get the job done correctly. I don't know specifically how Java and C# do it, but their generics are not true templates, they are only types, and so can only appear in very restricted circumstances.

*Extremely* restricted in the case of C# (*cough* No IArithmetic or operator constraints *cough*). Although that is really a separate issue... Sorry, pet peeve. ;)
Oct 11 2008
prev sibling next sibling parent "Jarrett Billingsley" <jarrett.billingsley gmail.com> writes:
On Sun, Oct 12, 2008 at 12:44 AM, bearophile <bearophileHUGS lycos.com> wrote:
 Robert Fraser:
 I think a context-free grammar is a big win all-around.

Such things have some disadvantages too, like not allowing (?) a syntax like, for example: foreach (i, x in something) {...} Instead of the current more error-prone: foreach (i, x; something) {...}

It's not "error-prone", it's "you're not used to it." You very commonly fall into the fallacy that if you think something's bad/confusing/not what you're used to, then _everyone_ must think that way and therefore it _must_ change. Sorry, that's not the way it works. I haven't mistyped a foreach loop, ever. Deal with it.
Oct 11 2008
prev sibling parent Ary Borenszweig <ary esperanto.org.ar> writes:
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 foobar 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.
Oct 12 2008
prev sibling next sibling parent reply "Dave" <Dave_member pathlink.com> writes:
"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 foobar 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.)

So, we have one of the most prolific, important and published D template library developers using chevrons where someone opening that with any other editor would see foo!(bar) or perhaps foo!bar. And this is all encouraged by the primary language architect. Nuts! I can also see this causing issues with continuity of style, where some particular arrangement of code would look readable with chevrons and not !(), or vice-versa. When Andrei writes his articles and books, which would he use in the text? I mean Andrei can setup emacs anyway he wants, but this also smacks of something being "blessed" by the language designer. More lunacy! <g> Let's all take a deep breath any think this through a little longer... - Dave
Oct 11 2008
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Dave wrote:
 "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 foobar 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.)

So, we have one of the most prolific, important and published D template library developers using chevrons where someone opening that with any other editor would see foo!(bar) or perhaps foo!bar. And this is all encouraged by the primary language architect. Nuts!

I think there's some misunderstanding here. What exactly seems to be the problem?
 I can also see this causing issues with continuity of style, where some 
 particular arrangement of code would look readable with chevrons and not 
 !(), or vice-versa.

I think that's a very tenuous claim to make. One wouldn't write code such that it looks a certain way, but rather that it does certain things.
 When Andrei writes his articles and books, which would he use in the text?

The standard notation. The fact that I'd be using whatever editor embellishments is irrelevant, and in fact I find it a bit bizarre that you even care about that. Is my use of syntax coloring an issue as well?
 I mean Andrei can setup emacs anyway he wants, but this also smacks of 
 something being "blessed" by the language designer.
 
 More lunacy! <g>
 
 Let's all take a deep breath any think this through a little longer...

A deep breath is sure what I needed after reading your post. Andrei
Oct 11 2008
parent reply "Bent Rasmussen" <IncredibleShrinkingSphere Gmail.com> writes:
It's more appropriate to commend you for this initiative. Maybe some better 
syntax will come out of it and until then it will make the code easier on 
your eyes (and who knows how many others). The opposition smacks more of 
"syntactic conservatism" than anything else. . - Hm, what other interesting 
kinds of syntactic transformation might one do. - More use of unicode 
symbols for one thing.

In fact the days of "one language one syntax" is about to come to an end it 
would appear. This is witnessed by the massive hype surrounding 
domain-specific languages atm - perhaps spun off by Intentional Programming 
where demonstrations show radically different presentations for the same 
underlying abstract syntax.

In the XML world we see binary XML Information Set (Infoset) formalisations 
where the abstract syntax remains more or less invariant but the 
serialization syntax changes drastically. The added bonus here being, 
amongst others, that no human will be able to write this syntax by hand, 
meaning instantiations will be machine-verified - no human err, except those 
programmed into the editors, object models and serializers. Of course 
oppinions on the pros and cons of this vary much.

- Bent

"Andrei Alexandrescu" <SeeWebsiteForEmail erdani.org> skrev i meddelelsen 
news:gcr17d$1n25$1 digitalmars.com...
 Dave wrote:

 When Andrei writes his articles and books, which would he use in the 
 text?

The standard notation. The fact that I'd be using whatever editor embellishments is irrelevant, and in fact I find it a bit bizarre that you even care about that. Is my use of syntax coloring an issue as well?
 I mean Andrei can setup emacs anyway he wants, but this also smacks of 
 something being "blessed" by the language designer.

 More lunacy! <g>

 Let's all take a deep breath any think this through a little longer...

A deep breath is sure what I needed after reading your post. Andrei

Oct 11 2008
next sibling parent bearophile <bearophileHUGS lycos.com> writes:
Bent Rasmussen:
More use of unicode symbols for one thing.<

That's a very large jump for D, and I don't know if it will ever do it. But some languages have already done such scary jump, look at Fortress. Fortress code can be written both in unicode and ASCII, the ASCII code looks longer: http://en.wikipedia.org/wiki/Fortress_(programming_language) http://research.sun.com/projects/plrg/PLDITutorialSlides9Jun2006.pdf I am sure D may learn some things from Fortress, but I think adding just one or two unicode symbols to D isn't good. If you want to accept unicode, then you want more. Bye, bearophile
Oct 11 2008
prev sibling parent "Nick Sabalausky" <a a.a> writes:
"Bent Rasmussen" <IncredibleShrinkingSphere Gmail.com> wrote in message 
news:gcre4u$2dmb$1 digitalmars.com...
 In fact the days of "one language one syntax" is about to come to an end 
 it would appear. This is witnessed by the massive hype surrounding 
 domain-specific languages atm - perhaps spun off by Intentional 
 Programming where demonstrations show radically different presentations 
 for the same underlying abstract syntax.

The domain-specific language hype annoys me. Needs have grown since the days C/C++ was considered "general purpose", and C++'s changes haven't quite been able to keep up. That's a given. Formerly "general-purpose" languages like C++ just aren't really "general purpose" anymore. But I consider the "domain-specific language" movement to be purely systemic of the lack of a sufficient new general purpose language. There's still a need, and IMO a potential, for a new general purpose language. It's just too hackish to be using a completely different language for every little thing. Most people seem to look at this recent explosion of less-than-mainstream languges like D, F#, OCaml, Groovy, Python, Delight, etc., as a trend towards an increasingly-segregated language arena. I see it as the playground/sandbox that's building the groundwork for a new general purpose language. If I understand my language history right, this is similar to how languages like ALGOL, B, BCPL, Fortran, Fourth and Cobol helped pave the way for C.
Oct 11 2008
prev sibling parent reply Kyle Furlong <kylefurlong gmail.com> writes:
Walter Bright 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 foobar 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.

Is it just me or is foo!bar uglier than foo!(bar)? Maybe I'm just used to the tried and true syntax.
Oct 14 2008
next sibling parent Frank Benoit <keinfarbton googlemail.com> writes:
Kyle Furlong schrieb:
 Walter Bright 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 foobar 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.

Is it just me or is foo!bar uglier than foo!(bar)? Maybe I'm just used to the tried and true syntax.

Seconded.
Oct 14 2008
prev sibling next sibling parent Christopher Wright <dhasenan gmail.com> writes:
Kyle Furlong wrote:
 Walter Bright 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 foobar 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.

Is it just me or is foo!bar uglier than foo!(bar)? Maybe I'm just used to the tried and true syntax.

Uglier and more ambiguous.
Oct 14 2008
prev sibling parent "Bill Baxter" <wbaxter gmail.com> writes:
On Wed, Oct 15, 2008 at 5:48 AM, Frank Benoit
<keinfarbton googlemail.com> wrote:
 Kyle Furlong schrieb:
 Walter Bright 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=ABbar=BB for display o=



 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.

Is it just me or is foo!bar uglier than foo!(bar)? Maybe I'm just used to the tried and true syntax.

Seconded.

Thirded, though it does look a bit better with a monospace font. In the proportional font used by gmail, it just shrinks to way to small and hard to see. --bb
Oct 14 2008