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


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

 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  



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
next sibling 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 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 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 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=


n the

 editor is in D mode, the underlying text will still be foo!(bar). (This
 doesn't affect D at all, only its display in Emacs.)

 Also, we're going to try using ! for single argument syntax, as in:

 foo!bar  is same as   foo!(bar)
 foo!10   is same as   foo!(10)

 etc. 0 arguments or more than 1 argument or arguments that are more than =


one

 token long will still require !( ). We'll see how that works. I think it
 looks rather nice.


So with these two things, in Emacs you'll see
Foo!bar in some places and Foo=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 reply "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
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.


 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 :).



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


Right, but D template syntax and meaning are way easier to grasp. And
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.


Ok. Let's try the lonesome !.
Oct 11 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 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
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
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 "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?


  No.


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


  The compiler doesn't accept colored text either, but that doesn't  
 impair the usefulness of an editor that displays it that way.


 Because you can't type color, but you can type « and ».


«...» is not a valid template syntax, only !(...) is supported.
Honestly, I don't understand why Andrei is ashamed of !(), refrains from  
using/seeing it and tries to replace visual with some sugar, but this all  
is is suspicious and alerting. The syntax didn't make a way into the  
language so uou should get used to it and put up with it.

This reminds me of some people who were coming from Pascal and using

#define DO
#define BEGIN {
#define END }

macros for the code to be more similar to their previous experience.

This is a bad sign, especially if it comes from one of the language  
developers.
Oct 12 2008
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?


  No.


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


  The compiler doesn't accept colored text either, but that doesn't 
 impair the usefulness of an editor that displays it that way.


 Because you can't type color, but you can type « and ».


 
 «...» is not a valid template syntax, only !(...) is supported.


Yes I know. But if Andrei's going to write an emacs module (or whatever) 
that displays !(...) as «...» I think the shown characters « and » 
themselves should be supported as well.

Otherwise, just drop this confusing visual-only feature.


 Honestly, I don't understand why Andrei is ashamed of !(), refrains from 
 using/seeing it and tries to replace visual with some sugar, but this 
 all is is suspicious and alerting. The syntax didn't make a way into the 
 language so uou should get used to it and put up with it.
 
 This reminds me of some people who were coming from Pascal and using
 
 #define DO
 #define BEGIN {
 #define END }
 
 macros for the code to be more similar to their previous experience.
 
 This is a bad sign, especially if it comes from one of the language 
 developers.


At least you can still use DO, BEGIN, END when you #define them. But now 
you can't even use what you see («...»). I say it's more evil. :)
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?


  No.


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


  The compiler doesn't accept colored text either, but that doesn't 
 impair the usefulness of an editor that displays it that way.


 Because you can't type color, but you can type « and ».


 «...» is not a valid template syntax, only !(...) is supported.


 
 Yes I know. But if Andrei's going to write an emacs module (or whatever) 
 that displays !(...) as «...» I think the shown characters « and » 
 themselves should be supported as well.
 
 Otherwise, just drop this confusing visual-only feature.


Please understand how your suggestion to drop the visual-only feature 
concerns only the use of an editor. There is no feature to talk about 
even. Essentially by "dropping the feature" you are telling me how my 
editor's screen must look like.


 Honestly, I don't understand why Andrei is ashamed of !(), refrains 
 from using/seeing it and tries to replace visual with some sugar, but 
 this all is is suspicious and alerting. The syntax didn't make a way 
 into the language so uou should get used to it and put up with it.

 This reminds me of some people who were coming from Pascal and using

 #define DO
 #define BEGIN {
 #define END }

 macros for the code to be more similar to their previous experience.

 This is a bad sign, especially if it comes from one of the language 
 developers.


 
 At least you can still use DO, BEGIN, END when you #define them. But now 
 you can't even use what you see («...»). I say it's more evil. :)


Code folding hides entire sections of code. They are nonetheless passed 
to the compiler. Is that evil?


Andrei
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?


  No.


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


  The compiler doesn't accept colored text either, but that doesn't 
 impair the usefulness of an editor that displays it that way.


 Because you can't type color, but you can type « and ».


 «...» is not a valid template syntax, only !(...) is supported.


 Yes I know. But if Andrei's going to write an emacs module (or 
 whatever) that displays !(...) as «...» I think the shown characters « 
 and » themselves should be supported as well.

 Otherwise, just drop this confusing visual-only feature.


 
 Please understand how your suggestion to drop the visual-only feature 
 concerns only the use of an editor. There is no feature to talk about 
 even. Essentially by "dropping the feature" you are telling me how my 
 editor's screen must look like.
 


Maybe I used the wrong wording. I mean the "feature" that replaces 
!(...) to «...» in "your" emacs module.

Since Walter made an announcement here I'll expect you'll release it 
publicly, and since this is from the official developers' team I'd 
expect this would be the de facto module for emacs. That means your 
module will not just affect your editor, but all emacs users' editors.


 Honestly, I don't understand why Andrei is ashamed of !(), refrains 
 from using/seeing it and tries to replace visual with some sugar, but 
 this all is is suspicious and alerting. The syntax didn't make a way 
 into the language so uou should get used to it and put up with it.

 This reminds me of some people who were coming from Pascal and using

 #define DO
 #define BEGIN {
 #define END }

 macros for the code to be more similar to their previous experience.

 This is a bad sign, especially if it comes from one of the language 
 developers.


 At least you can still use DO, BEGIN, END when you #define them. But 
 now you can't even use what you see («...»). I say it's more evil. :)


 
 Code folding hides entire sections of code. They are nonetheless passed 
 to the compiler. Is that evil?
 
 
 Andrei


But code folding is not turned on by default, and there is a clear 
visual indication (e.g. +/- on the side) that there is something more.

+/- 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:
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 next 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 reply "Bent Rasmussen" <IncredibleShrinkingSphere Gmail.com> writes:
That's looking very nice. Esp. the boolean expressions!

- Bent
Oct 18 2008
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 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 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=






mpiler?

=20
 No.
=20

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


=20
 The compiler doesn't accept colored text either, but that doesn't impai=




r=20

 the usefulness of an editor that displays it that way.


=20
 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?


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


 
 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?


 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 .


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


around the '> >' issue and allow '>>'.

a) It works for C++0x so it can be made to work for D using the same rules. 

work around the ambiguities with the right-shift operator.

/ 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 


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.



 work around the '> >' issue and allow '>>'.
 
 a) It works for C++0x so it can be made to work for D using the same 

 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 



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 


 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.



 work around the '> >' issue and allow '>>'.

 a) It works for C++0x so it can be made to work for D using the same 

 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 



 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 

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 


 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.
 


 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 

 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 



 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 

 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 


 was to disallow the comma operator between conditional predicates, 
 which I don't see as a huge issue.

 - Dave
Oct 11 2008
prev 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 

 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 

impression those aren't context-free either.


 b) Easier and more natural for D newbies who've used C++ templates 



 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 

 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 

 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 



 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 

 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 

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


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
next sibling parent reply "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.


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

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


 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.


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

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


 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

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


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

 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 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, 

 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 

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

 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 

 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 



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



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 reply Benji Smith <dlanguage benjismith.net> writes:
KennyTM~ wrote:


 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 

 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:


 work around the '> >' issue and allow '>>'.

 a) It works for C++0x so it can be made to work for D using the same 

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

 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 

 C++0x to work around the ambiguities with the right-shift operator.



less powerful.


 b) Easier and more natural for D newbies who've used C++ templates 



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 


 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



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 



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.


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 



 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.


 not true templates, they are only types, and so can only appear in very 
 restricted circumstances.



constraints *cough*). Although that is really a separate issue... Sorry, pet 
peeve. ;)
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.
 

 work around the '> >' issue and allow '>>'.





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

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 reply 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
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=






nly

 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
prev 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