www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - foo!(bar) ==> foo{bar}

reply Walter Bright <newshound1 digitalmars.com> writes:
The foo.(bar) syntax seems to be sinking. The foo{bar} seems to be the 
most practical alternative. So, how about putting it in the next D2 
release on a trial basis, so people can try it out and see how it looks?
Oct 06 2008
next sibling parent KennyTM~ <kennytm gmail.com> writes:
Walter Bright wrote:

 The foo.(bar) syntax seems to be sinking. The foo{bar} seems to be the 
 most practical alternative. So, how about putting it in the next D2 
 release on a trial basis, so people can try it out and see how it looks?


yes yes yes!

(oh, i mean, yes yes yes{} <g> )
Oct 06 2008
prev sibling next sibling parent reply "Jarrett Billingsley" <jarrett.billingsley gmail.com> writes:
On Mon, Oct 6, 2008 at 3:52 PM, Walter Bright
<newshound1 digitalmars.com> wrote:

 The foo.(bar) syntax seems to be sinking. The foo{bar} seems to be the most
 practical alternative. So, how about putting it in the next D2 release on a
 trial basis, so people can try it out and see how it looks?


I guess it's OK but I still don't see why anything has to change.
There are much bigger fish to fry.
Oct 06 2008
parent reply Leandro Lucarella <llucax gmail.com> writes:
Jarrett Billingsley, el  6 de octubre a las 16:04 me escribiste:

 On Mon, Oct 6, 2008 at 3:52 PM, Walter Bright
 <newshound1 digitalmars.com> wrote:

 The foo.(bar) syntax seems to be sinking. The foo{bar} seems to be the most
 practical alternative. So, how about putting it in the next D2 release on a
 trial basis, so people can try it out and see how it looks?


 
 I guess it's OK but I still don't see why anything has to change.
 There are much bigger fish to fry.


Amen!

-- 
Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/
----------------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------------
Fitter, happier, more productive, comfortable, not drinking too much,
regular exercise at the gym (3 days a week),
getting on better with your associate employee contemporaries,
Oct 07 2008
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Leandro Lucarella wrote:

 Jarrett Billingsley, el  6 de octubre a las 16:04 me escribiste:

 On Mon, Oct 6, 2008 at 3:52 PM, Walter Bright
 <newshound1 digitalmars.com> wrote:

 The foo.(bar) syntax seems to be sinking. The foo{bar} seems to be the most
 practical alternative. So, how about putting it in the next D2 release on a
 trial basis, so people can try it out and see how it looks?


 I guess it's OK but I still don't see why anything has to change.
 There are much bigger fish to fry.


 
 Amen!


New/potential users are big fish. There has been quite a bit of opinion 
that the Slashed-Eye Sad Guy is offputting at least at first.

Andrei
Oct 07 2008
next sibling parent reply "Jarrett Billingsley" <jarrett.billingsley gmail.com> writes:
On Tue, Oct 7, 2008 at 11:38 AM, Andrei Alexandrescu
<SeeWebsiteForEmail erdani.org> wrote:

 Leandro Lucarella wrote:

 Jarrett Billingsley, el  6 de octubre a las 16:04 me escribiste:

 On Mon, Oct 6, 2008 at 3:52 PM, Walter Bright
 <newshound1 digitalmars.com> wrote:

 The foo.(bar) syntax seems to be sinking. The foo{bar} seems to be the
 most
 practical alternative. So, how about putting it in the next D2 release
 on a
 trial basis, so people can try it out and see how it looks?


 I guess it's OK but I still don't see why anything has to change.
 There are much bigger fish to fry.


 Amen!


 New/potential users are big fish. There has been quite a bit of opinion that
 the Slashed-Eye Sad Guy is offputting at least at first.


And I suppose it's the _emotionally damaging_ appearance of !() that's
putting them off, not the tens/hundreds of poorly-specified
often-buggy template and compile-time features.  Right.

Wait -- in your initial statement, you didn't even mention new users.
You had some cute anecdote about waking up and realizing that all the
template shouting was making you sad or something.  So who exactly is
this "feature" aimed at?
Oct 07 2008
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Jarrett Billingsley wrote:

 On Tue, Oct 7, 2008 at 11:38 AM, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org> wrote:

 Leandro Lucarella wrote:

 Jarrett Billingsley, el  6 de octubre a las 16:04 me escribiste:

 On Mon, Oct 6, 2008 at 3:52 PM, Walter Bright
 <newshound1 digitalmars.com> wrote:

 The foo.(bar) syntax seems to be sinking. The foo{bar} seems to be the
 most
 practical alternative. So, how about putting it in the next D2 release
 on a
 trial basis, so people can try it out and see how it looks?


 I guess it's OK but I still don't see why anything has to change.
 There are much bigger fish to fry.


 Amen!


 New/potential users are big fish. There has been quite a bit of opinion that
 the Slashed-Eye Sad Guy is offputting at least at first.


 
 And I suppose it's the _emotionally damaging_ appearance of !() that's
 putting them off, not the tens/hundreds of poorly-specified
 often-buggy template and compile-time features.  Right.


Well there's work being on both. Again, this particular nit does not 
require a lot of implementation work.


 Wait -- in your initial statement, you didn't even mention new users.
 You had some cute anecdote about waking up and realizing that all the
 template shouting was making you sad or something.  So who exactly is
 this "feature" aimed at?


I didn't, but I also didn't claim that new users were my motivator all 
along.


Andrei
Oct 07 2008
prev sibling next sibling parent reply "Jarrett Billingsley" <jarrett.billingsley gmail.com> writes:
On Tue, Oct 7, 2008 at 12:28 PM, Jarrett Billingsley
<jarrett.billingsley gmail.com> wrote:


 Wait -- in your initial statement, you didn't even mention new users.
 You had some cute anecdote about waking up and realizing that all the
 template shouting was making you sad or something.  So who exactly is
 this "feature" aimed at?


Nevermind, I retract at least this part.  But the first part still stands.
Oct 07 2008
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Jarrett Billingsley wrote:

 On Tue, Oct 7, 2008 at 12:28 PM, Jarrett Billingsley
 <jarrett.billingsley gmail.com> wrote:
 

 Wait -- in your initial statement, you didn't even mention new users.
 You had some cute anecdote about waking up and realizing that all the
 template shouting was making you sad or something.  So who exactly is
 this "feature" aimed at?


 
 Nevermind, I retract at least this part.  But the first part still stands.


Thank you. I, too, wanted to add "And why the inquisitive attitude?" to 
my post, and then changed my mind :o).

Andrei
Oct 07 2008
prev sibling next sibling parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
"Andrei Alexandrescu" wrote

 Leandro Lucarella wrote:

 Jarrett Billingsley, el  6 de octubre a las 16:04 me escribiste:

 On Mon, Oct 6, 2008 at 3:52 PM, Walter Bright
 <newshound1 digitalmars.com> wrote:

 The foo.(bar) syntax seems to be sinking. The foo{bar} seems to be the 
 most
 practical alternative. So, how about putting it in the next D2 release 
 on a
 trial basis, so people can try it out and see how it looks?


 I guess it's OK but I still don't see why anything has to change.
 There are much bigger fish to fry.


 Amen!


 New/potential users are big fish. There has been quite a bit of opinion 
 that the Slashed-Eye Sad Guy is offputting at least at first.


You might be misinterpreting how people on this NG have responded.  Here is 
my anecdote (or at least what I can remember) when I first encountered D 
templates.

I'm reading through the spec, and I get to templates, and they are specified 
with !().  My first reaction is, well that's dumb, why buck the trend?  C++, 

totally understand it.  From that point on, !() looks sooo much better to me 
than <>.  Never once did I not like the choice of !, it was all just a 
knee-jerk reaction to why Walter didn't choose something that looks the same 
as C++, especially when there are so many cases of him copying C++ syntax. 
It could have been  () or {} and I still would have reacted the same.

My expectation for a new user to D is:


initial reaction I had.  Then, depending on their personality, they get 
defensively angry or say, 'oh yeah, that makes a lot of sense!' and are done 
with it.  I'm guessing the latter would be more common.

2. They have no background in templates, and they say 'What's a template?'

Now, change the template syntax to {} or  () or whatever (clearly not <>, as 
there are technical problems with it):


this different?  Why make things different than C++ or whatever since 
everything else looks like C++?', then they read the explanation and either 
get defensively angry, or grasp the reasoning and move on.  Again, guessing 
the latter will be more common.

2. They have no background in templates, and they say 'What's a template?'

Bottom line, I believe it matters not in the least what syntax is used. 
Templates are a hard concept to grasp to those who have never used them, 
regardless of the syntax.

Just my view.  Note I can't speak for others that said they were put off by 
the !() syntax, but at least that's how I interpreted what they meant.

-Steve
Oct 07 2008
next sibling parent reply Ary Borenszweig <ary esperanto.org.ar> writes:
Steven Schveighoffer wrote:

 "Andrei Alexandrescu" wrote

 Leandro Lucarella wrote:

 Jarrett Billingsley, el  6 de octubre a las 16:04 me escribiste:

 On Mon, Oct 6, 2008 at 3:52 PM, Walter Bright
 <newshound1 digitalmars.com> wrote:

 The foo.(bar) syntax seems to be sinking. The foo{bar} seems to be the 
 most
 practical alternative. So, how about putting it in the next D2 release 
 on a
 trial basis, so people can try it out and see how it looks?


 I guess it's OK but I still don't see why anything has to change.
 There are much bigger fish to fry.


 Amen!


 New/potential users are big fish. There has been quite a bit of opinion 
 that the Slashed-Eye Sad Guy is offputting at least at first.


 
 You might be misinterpreting how people on this NG have responded.  Here is 
 my anecdote (or at least what I can remember) when I first encountered D 
 templates.
 
 I'm reading through the spec, and I get to templates, and they are specified 
 with !().  My first reaction is, well that's dumb, why buck the trend?  C++, 

 totally understand it.  From that point on, !() looks sooo much better to me 
 than <>.  Never once did I not like the choice of !, it was all just a 
 knee-jerk reaction to why Walter didn't choose something that looks the same 
 as C++, especially when there are so many cases of him copying C++ syntax. 
 It could have been  () or {} and I still would have reacted the same.


Now that you mention it, making template syntax be !() or {} makes it 
harder to port C++ code to D. I wonder why this isn't a big deal, but 
keeping "int[3]*[5] x;"-like declarations is a must... :-(


 
 My expectation for a new user to D is:
 

 initial reaction I had.  Then, depending on their personality, they get 
 defensively angry or say, 'oh yeah, that makes a lot of sense!' and are done 
 with it.  I'm guessing the latter would be more common.


The latter is what happened to me. But the !() syntax hurts my eyes, 
maybe because of what Andrei said about words and exclamations.
Oct 07 2008
parent reply Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
Ary Borenszweig wrote:

 Now that you mention it, making template syntax be !() or {} makes it 
 harder to port C++ code to D. I wonder why this isn't a big deal, but 
 keeping "int[3]*[5] x;"-like declarations is a must... :-(
 


Didn't you mean the C-style declarations (ie, "int (*x[5])[3];") ?

-- 
Bruno Medeiros - Software Developer, MSc. in CS/E graduate
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
Oct 14 2008
parent Ary Borenszweig <ary esperanto.org.ar> writes:
Bruno Medeiros wrote:

 Ary Borenszweig wrote:

 Now that you mention it, making template syntax be !() or {} makes it 
 harder to port C++ code to D. I wonder why this isn't a big deal, but 
 keeping "int[3]*[5] x;"-like declarations is a must... :-(


 
 Didn't you mean the C-style declarations (ie, "int (*x[5])[3];") ?
 


Yes, that.
Oct 14 2008
prev sibling next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Steven Schveighoffer wrote:

 "Andrei Alexandrescu" wrote

 Leandro Lucarella wrote:

 Jarrett Billingsley, el  6 de octubre a las 16:04 me escribiste:

 On Mon, Oct 6, 2008 at 3:52 PM, Walter Bright
 <newshound1 digitalmars.com> wrote:

 The foo.(bar) syntax seems to be sinking. The foo{bar} seems to be the 
 most
 practical alternative. So, how about putting it in the next D2 release 
 on a
 trial basis, so people can try it out and see how it looks?


 I guess it's OK but I still don't see why anything has to change.
 There are much bigger fish to fry.


 Amen!


 New/potential users are big fish. There has been quite a bit of opinion 
 that the Slashed-Eye Sad Guy is offputting at least at first.


 
 You might be misinterpreting how people on this NG have responded.


At least for me, I was well aware of the issues with the angle brackets, 
but when I saw foo!(bar) I was like: "ew, that's the best he could come 
up with?!?"

Andrei
Oct 07 2008
prev sibling next sibling parent reply Vincent Richomme <forumer smartmobili.com> writes:
Steven Schveighoffer a crit :

 "Andrei Alexandrescu" wrote

 Leandro Lucarella wrote:

 Jarrett Billingsley, el  6 de octubre a las 16:04 me escribiste:

 On Mon, Oct 6, 2008 at 3:52 PM, Walter Bright
 <newshound1 digitalmars.com> wrote:

 The foo.(bar) syntax seems to be sinking. The foo{bar} seems to be the 
 most
 practical alternative. So, how about putting it in the next D2 release 
 on a
 trial basis, so people can try it out and see how it looks?


 I guess it's OK but I still don't see why anything has to change.
 There are much bigger fish to fry.


 Amen!


 New/potential users are big fish. There has been quite a bit of opinion 
 that the Slashed-Eye Sad Guy is offputting at least at first.


 
 You might be misinterpreting how people on this NG have responded.  Here is 
 my anecdote (or at least what I can remember) when I first encountered D 
 templates.
 
 I'm reading through the spec, and I get to templates, and they are specified 
 with !().  My first reaction is, well that's dumb, why buck the trend?  C++, 

 totally understand it.  From that point on, !() looks sooo much better to me 
 than <>.  Never once did I not like the choice of !, it was all just a 
 knee-jerk reaction to why Walter didn't choose something that looks the same 
 as C++, especially when there are so many cases of him copying C++ syntax. 
 It could have been  () or {} and I still would have reacted the same.
 
 My expectation for a new user to D is:
 

 initial reaction I had.  Then, depending on their personality, they get 
 defensively angry or say, 'oh yeah, that makes a lot of sense!' and are done 
 with it.  I'm guessing the latter would be more common.
 


I agree I was shocked by the syntax at first glance ... and it still 
very difficult to read D templates. Hope I will get used to it ;-)
But if you ask lots of developpers what is the meaning of this symbol I 
am quite sure they will never imagine it could be related to templates.



 2. They have no background in templates, and they say 'What's a template?'
 
 Now, change the template syntax to {} or  () or whatever (clearly not <>, as 
 there are technical problems with it):
 

 this different?  Why make things different than C++ or whatever since 
 everything else looks like C++?', then they read the explanation and either 
 get defensively angry, or grasp the reasoning and move on.  Again, guessing 
 the latter will be more common.
 
 2. They have no background in templates, and they say 'What's a template?'
 
 Bottom line, I believe it matters not in the least what syntax is used. 
 Templates are a hard concept to grasp to those who have never used them, 
 regardless of the syntax.
 
 Just my view.  Note I can't speak for others that said they were put off by 
 the !() syntax, but at least that's how I interpreted what they meant.
 
 -Steve
Oct 07 2008
parent reply Tomas Lindquist Olsen <tomas famolsen.dk> writes:
Vincent Richomme wrote:

 Steven Schveighoffer a crit :


 initial reaction I had.  Then, depending on their personality, they 
 get defensively angry or say, 'oh yeah, that makes a lot of sense!' 
 and are done with it.  I'm guessing the latter would be more common.


 I agree I was shocked by the syntax at first glance ... and it still 
 very difficult to read D templates. Hope I will get used to it ;-)
 But if you ask lots of developpers what is the meaning of this symbol I 
 am quite sure they will never imagine it could be related to templates.
 
 


How is curly braces different here? I think of some scope when I see them,
certainly not 
template parameters.

I too thought wth? when I first read the D spec, but coming from C++ and having
hit the issues 
with <> several times it made a lot of sense to do something else.

IMHO {} is not it!
Oct 07 2008
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Tomas Lindquist Olsen wrote:

 Vincent Richomme wrote:

 Steven Schveighoffer a crit :


 initial reaction I had.  Then, depending on their personality, they 
 get defensively angry or say, 'oh yeah, that makes a lot of sense!' 
 and are done with it.  I'm guessing the latter would be more common.


 I agree I was shocked by the syntax at first glance ... and it still 
 very difficult to read D templates. Hope I will get used to it ;-)
 But if you ask lots of developpers what is the meaning of this symbol 
 I am quite sure they will never imagine it could be related to templates.


 
 How is curly braces different here? I think of some scope when I see 
 them, certainly not template parameters.
 
 I too thought wth? when I first read the D spec, but coming from C++ and 
 having hit the issues with <> several times it made a lot of sense to do 
 something else.
 
 IMHO {} is not it!


IMHO {} is better than .+() (where ".+" is one or more characters). I 
remember better now when I first talked to Walter about template 
instantiation. We were just talking about problems with <> and I asked, 
how do you avoid that in D? (We were in a coffee shop.) He said "Well," 
pulled a napkin and wrote the aeternal foo, followed by "!", followed by 
"(bar)". I thought and said it sucked and he gave me the "you'll get 
used to it" cookie. Had he said "Oh, I just use curly braces", I 
would've been like, "alright". There wouldn't have been a need to even 
write anything or add anything to it.

Andrei
Oct 07 2008
prev sibling next sibling parent "Nick Sabalausky" <a a.a> writes:
"Steven Schveighoffer" <schveiguy yahoo.com> wrote in message 
news:gcg4bs$kq5$1 digitalmars.com...

 "Andrei Alexandrescu" wrote

 Leandro Lucarella wrote:

 Jarrett Billingsley, el  6 de octubre a las 16:04 me escribiste:

 On Mon, Oct 6, 2008 at 3:52 PM, Walter Bright
 <newshound1 digitalmars.com> wrote:

 The foo.(bar) syntax seems to be sinking. The foo{bar} seems to be the 
 most
 practical alternative. So, how about putting it in the next D2 release 
 on a
 trial basis, so people can try it out and see how it looks?


 I guess it's OK but I still don't see why anything has to change.
 There are much bigger fish to fry.


 Amen!


 New/potential users are big fish. There has been quite a bit of opinion 
 that the Slashed-Eye Sad Guy is offputting at least at first.


 You might be misinterpreting how people on this NG have responded.  Here 
 is my anecdote (or at least what I can remember) when I first encountered 
 D templates.

 I'm reading through the spec, and I get to templates, and they are 
 specified with !().  My first reaction is, well that's dumb, why buck the 

 reasoning and I totally understand it.  From that point on, !() looks sooo 
 much better to me than <>.  Never once did I not like the choice of !, it 
 was all just a knee-jerk reaction to why Walter didn't choose something 
 that looks the same as C++, especially when there are so many cases of him 
 copying C++ syntax. It could have been  () or {} and I still would have 
 reacted the same.

 My expectation for a new user to D is:


 initial reaction I had.  Then, depending on their personality, they get 
 defensively angry or say, 'oh yeah, that makes a lot of sense!' and are 
 done with it.  I'm guessing the latter would be more common.

 2. They have no background in templates, and they say 'What's a template?'

 Now, change the template syntax to {} or  () or whatever (clearly not <>, 
 as there are technical problems with it):


 this different?  Why make things different than C++ or whatever since 
 everything else looks like C++?', then they read the explanation and 
 either get defensively angry, or grasp the reasoning and move on.  Again, 
 guessing the latter will be more common.

 2. They have no background in templates, and they say 'What's a template?'

 Bottom line, I believe it matters not in the least what syntax is used. 
 Templates are a hard concept to grasp to those who have never used them, 
 regardless of the syntax.

 Just my view.  Note I can't speak for others that said they were put off 
 by the !() syntax, but at least that's how I interpreted what they meant.

 -Steve


My only problem with "foo!()" is that I've had a hard time getting myself to 
visually associate the "!" with the "()" instead of the "foo".  Ie, I look 
at "foo!()" and I immediately think "foo!" and "()" instead of "foo" and 
"!()". That said, I really can't decide whether I think it should be changed 
to "foo{}" or whether it's just not a big enough deal to bother changing.
Oct 07 2008
prev sibling next sibling parent reply =?UTF-8?B?QWxleGFuZGVyIFDDoW5law==?= writes:
Steven Schveighoffer wrote:

 "Andrei Alexandrescu" wrote

 Leandro Lucarella wrote:

 Jarrett Billingsley, el  6 de octubre a las 16:04 me escribiste:

 On Mon, Oct 6, 2008 at 3:52 PM, Walter Bright
 <newshound1 digitalmars.com> wrote:

 The foo.(bar) syntax seems to be sinking. The foo{bar} seems to be the 
 most
 practical alternative. So, how about putting it in the next D2 release 
 on a
 trial basis, so people can try it out and see how it looks?


 I guess it's OK but I still don't see why anything has to change.
 There are much bigger fish to fry.


 Amen!


 New/potential users are big fish. There has been quite a bit of opinion 
 that the Slashed-Eye Sad Guy is offputting at least at first.


 
 You might be misinterpreting how people on this NG have responded.  Here is 
 my anecdote (or at least what I can remember) when I first encountered D 
 templates.
 
 I'm reading through the spec, and I get to templates, and they are specified 
 with !().  My first reaction is, well that's dumb, why buck the trend?  C++, 

 totally understand it.  From that point on, !() looks sooo much better to me 
 than <>.  Never once did I not like the choice of !, it was all just a 
 knee-jerk reaction to why Walter didn't choose something that looks the same 
 as C++, especially when there are so many cases of him copying C++ syntax. 
 It could have been  () or {} and I still would have reacted the same.
 
 My expectation for a new user to D is:
 

 initial reaction I had.  Then, depending on their personality, they get 
 defensively angry or say, 'oh yeah, that makes a lot of sense!' and are done 
 with it.  I'm guessing the latter would be more common.
 
 2. They have no background in templates, and they say 'What's a template?'
 
 Now, change the template syntax to {} or  () or whatever (clearly not <>, as 
 there are technical problems with it):
 

 this different?  Why make things different than C++ or whatever since 
 everything else looks like C++?', then they read the explanation and either 
 get defensively angry, or grasp the reasoning and move on.  Again, guessing 
 the latter will be more common.
 
 2. They have no background in templates, and they say 'What's a template?'
 
 Bottom line, I believe it matters not in the least what syntax is used. 
 Templates are a hard concept to grasp to those who have never used them, 
 regardless of the syntax.
 
 Just my view.  Note I can't speak for others that said they were put off by 
 the !() syntax, but at least that's how I interpreted what they meant.
 
 -Steve 
 
 


As I had no proper background in any of those languages except some C, I 
didn’t quite get what templates are in the first place. But, as I was 
kind of diving into the world of compile-time programming through D, !() 
  just always was the way it works. It’s probably just a matter of your 
background. But having no background and coming to D, reading the 
reasons for the syntax, it clearly makes sense.

I really don’t see any reason in changing it. Foo!(T) is just a template 
instantiation for me, and good at that, as it’s a unique syntax you 
don’t find anywhere else in D’s syntax, unlike {}. The other 

the latter would have been the option with the least pukage included :P).

Also just FYI, all this discussion has pretty much pushed D2 further 
away from me. I really don’t feel like using it anytime soon at all.
Oct 07 2008
parent reply "Tiago Carvalho" <merlin3000 gmail.com> writes:
Not beeing a very active template programmer I find the   version the 
easiest on the eyes (since it appears there's no technical differences from 
!() ). Both in template ( int, float ) and the single type template int 
suggested by Andre.

"Alexander Pánek" <alexander.panek brainsware.org> wrote in message 
news:gcglje$22re$1 digitalmars.com...

 Steven Schveighoffer wrote:

 "Andrei Alexandrescu" wrote

 Leandro Lucarella wrote:

 Jarrett Billingsley, el  6 de octubre a las 16:04 me escribiste:

 On Mon, Oct 6, 2008 at 3:52 PM, Walter Bright
 <newshound1 digitalmars.com> wrote:

 The foo.(bar) syntax seems to be sinking. The foo{bar} seems to be 
 the most
 practical alternative. So, how about putting it in the next D2 
 release on a
 trial basis, so people can try it out and see how it looks?


 I guess it's OK but I still don't see why anything has to change.
 There are much bigger fish to fry.


 Amen!


 New/potential users are big fish. There has been quite a bit of opinion 
 that the Slashed-Eye Sad Guy is offputting at least at first.


 You might be misinterpreting how people on this NG have responded.  Here 
 is my anecdote (or at least what I can remember) when I first encountered 
 D templates.

 I'm reading through the spec, and I get to templates, and they are 
 specified with !().  My first reaction is, well that's dumb, why buck the 

 reasoning and I totally understand it.  From that point on, !() looks 
 sooo much better to me than <>.  Never once did I not like the choice of 
 !, it was all just a knee-jerk reaction to why Walter didn't choose 
 something that looks the same as C++, especially when there are so many 
 cases of him copying C++ syntax. It could have been  () or {} and I still 
 would have reacted the same.

 My expectation for a new user to D is:


 initial reaction I had.  Then, depending on their personality, they get 
 defensively angry or say, 'oh yeah, that makes a lot of sense!' and are 
 done with it.  I'm guessing the latter would be more common.

 2. They have no background in templates, and they say 'What's a 
 template?'

 Now, change the template syntax to {} or  () or whatever (clearly not <>, 
 as there are technical problems with it):


 is this different?  Why make things different than C++ or whatever since 
 everything else looks like C++?', then they read the explanation and 
 either get defensively angry, or grasp the reasoning and move on.  Again, 
 guessing the latter will be more common.

 2. They have no background in templates, and they say 'What's a 
 template?'

 Bottom line, I believe it matters not in the least what syntax is used. 
 Templates are a hard concept to grasp to those who have never used them, 
 regardless of the syntax.

 Just my view.  Note I can't speak for others that said they were put off 
 by the !() syntax, but at least that's how I interpreted what they meant.

 -Steve


 As I had no proper background in any of those languages except some C, I 
 didn’t quite get what templates are in the first place. But, as I was kind 
 of diving into the world of compile-time programming through D, !() just 
 always was the way it works. It’s probably just a matter of your 
 background. But having no background and coming to D, reading the reasons 
 for the syntax, it clearly makes sense.

 I really don’t see any reason in changing it. Foo!(T) is just a template 
 instantiation for me, and good at that, as it’s a unique syntax you don’t 
 find anywhere else in D’s syntax, unlike {}. The other alternatives were 

 been the option with the least pukage included :P).

 Also just FYI, all this discussion has pretty much pushed D2 further away 
 from me. I really don’t feel like using it anytime soon at all.
Oct 07 2008
parent reply =?UTF-8?B?QWxleGFuZGVyIFDDoW5law==?= writes:
Top posting is bad!

Tiago Carvalho wrote:

 Not beeing a very active template programmer I find the   version the 
 easiest on the eyes (since it appears there's no technical differences 
 from !() ). Both in template ( int, float ) and the single type 
 template int suggested by Andre.


But since !() is established and used for *years* now, I don’t see a 
point in changing it, just because something else might be easier on the 
eyes for some people.
Oct 07 2008
parent reply "Tiago Carvalho" <merlin3000 gmail.com> writes:
"Alexander Pánek" <alexander.panek brainsware.org> wrote in message 
news:gcgom3$28pm$1 digitalmars.com...

 Top posting is bad!


Ups... :/


 Tiago Carvalho wrote:

 Not beeing a very active template programmer I find the   version the 
 easiest on the eyes (since it appears there's no technical differences 
 from !() ). Both in template ( int, float ) and the single type 
 template int suggested by Andre.


 But since !() is established and used for *years* now, I don’t see a point 
 in changing it, just because something else might be easier on the eyes 
 for some people.


I understand, I have been following the D development for a while now but 
still not a very active D programmer, so it's easier for me to agree with 
changes to the language.
I'm happy not to be in Walter's shoes since there's no right answer for 
this, at least not one that I can see. But since it seems there's a strong 
will to change the !() "standard"; in that case I like the  .
Oct 07 2008
parent reply =?UTF-8?B?QWxleGFuZGVyIFDDoW5law==?= writes:
Tiago Carvalho wrote:

 "Alexander Pánek" <alexander.panek brainsware.org> wrote in message 
 news:gcgom3$28pm$1 digitalmars.com...

 Top posting is bad!


 
 Ups... :/


It’s ok. ;)


 Tiago Carvalho wrote:

 Not beeing a very active template programmer I find the   version the 
 easiest on the eyes (since it appears there's no technical 
 differences from !() ). Both in template ( int, float ) and the 
 single type template int suggested by Andre.


 But since !() is established and used for *years* now, I don’t see a 
 point in changing it, just because something else might be easier on 
 the eyes for some people.


 
 I understand, I have been following the D development for a while now 
 but still not a very active D programmer, so it's easier for me to agree 
 with changes to the language.
 I'm happy not to be in Walter's shoes since there's no right answer for 
 this, at least not one that I can see. But since it seems there's a 
 strong will to change the !() "standard"; in that case I like the  .


Where did you see that strong will? Mind to introduce us?
Oct 07 2008
parent reply "Tiago Carvalho" <merlin3000 gmail.com> writes:
"Alexander Pánek" <alexander.panek brainsware.org> wrote in message 
news:gcgsgb$2g71$1 digitalmars.com...

 Tiago Carvalho wrote:

 "Alexander Pánek" <alexander.panek brainsware.org> wrote in message 
 news:gcgom3$28pm$1 digitalmars.com...

 Top posting is bad!


 Ups... :/


 It’s ok. ;)


 Tiago Carvalho wrote:

 Not beeing a very active template programmer I find the   version the 
 easiest on the eyes (since it appears there's no technical differences 
 from !() ). Both in template ( int, float ) and the single type 
 template int suggested by Andre.


 But since !() is established and used for *years* now, I don’t see a 
 point in changing it, just because something else might be easier on the 
 eyes for some people.


 I understand, I have been following the D development for a while now but 
 still not a very active D programmer, so it's easier for me to agree with 
 changes to the language.
 I'm happy not to be in Walter's shoes since there's no right answer for 
 this, at least not one that I can see. But since it seems there's a 
 strong will to change the !() "standard"; in that case I like the  .


 Where did you see that strong will? Mind to introduce us?


In the late discussions about this subject, for what I've seen most posts 
are suggestions of alternatives to !() rather than posts to keep it and the 
fact Walter is willing to try the alternatives out is a big (probably the 
biggest) step toward change.
Oct 07 2008
parent reply "Bill Baxter" <wbaxter gmail.com> writes:
On Wed, Oct 8, 2008 at 9:05 AM, Tiago Carvalho <merlin3000 gmail.com> wrote=
:

 "Alexander P=E1nek" <alexander.panek brainsware.org> wrote in message
 news:gcgsgb$2g71$1 digitalmars.com...

 Tiago Carvalho wrote:

 "Alexander P=E1nek" <alexander.panek brainsware.org> wrote in message
 news:gcgom3$28pm$1 digitalmars.com...

 Top posting is bad!


 Ups... :/


 It's ok. ;)


 Tiago Carvalho wrote:

 Not beeing a very active template programmer I find the   version the
 easiest on the eyes (since it appears there's no technical difference=










s from

 !() ). Both in template ( int, float ) and the single type template i=










nt

 suggested by Andre.


 But since !() is established and used for *years* now, I don't see a
 point in changing it, just because something else might be easier on t=








he

 eyes for some people.


 I understand, I have been following the D development for a while now b=






ut

 still not a very active D programmer, so it's easier for me to agree wi=






th

 changes to the language.
 I'm happy not to be in Walter's shoes since there's no right answer for
 this, at least not one that I can see. But since it seems there's a str=






ong

 will to change the !() "standard"; in that case I like the  .


 Where did you see that strong will? Mind to introduce us?


 In the late discussions about this subject, for what I've seen most posts
 are suggestions of alternatives to !() rather than posts to keep it and t=


he

 fact Walter is willing to try the alternatives out is a big (probably the
 biggest) step toward change.


That's purely the bike shed effect.  Everyone is capable of suggesting
a sequence of symbols to use.  Not as many are capable of making a
strong argument either way about whether it should change or not.  So
the suggestions about alternate syntax are mostly of the form "if'
it's going to change then how about this?"

Plus as you can see, if Andrei asks for something like this, Walter is
usually quick to implement it if its easy.  So many folks here assume
it's a done deal no matter what we say.  So if we can't stop the train
wreck, at least we can control the damage a little bit. :-)

--bb
Oct 07 2008
parent "Tiago Carvalho" <merlin3000 gmail.com> writes:
"Bill Baxter" <wbaxter gmail.com> wrote in message 
news:mailman.43.1223425576.3087.digitalmars-d puremagic.com...

That's purely the bike shed effect.  Everyone is capable of suggesting
a sequence of symbols to use.  Not as many are capable of making a
strong argument either way about whether it should change or not.  So
the suggestions about alternate syntax are mostly of the form "if'
it's going to change then how about this?"


As I said, I don't have a lot o experience with templates, so my hability to 
make suggestions is limited to visual improvements. In that case my 
justification is as strong as it can be, for me  () looks better than !() 
and both of them look better than {} since I automatically think of code 
blocks when I see that.
It's not so much "if' it's going to change then how about this?" it's more 
of "given the opportunity to change, I think this would be an improvement".

But as I said to Alexander it's easier for a non regular D programmer, like 
me, to agree with modifications to the sintax.


Plus as you can see, if Andrei asks for something like this, Walter is
usually quick to implement it if its easy.  So many folks here assume
it's a done deal no matter what we say.  So if we can't stop the train
wreck, at least we can control the damage a little bit. :-)

--bb
Oct 09 2008
prev sibling parent reply Sandeep K <sandeep.iitkgpMEOW gmail.com> writes:
I don't like {} at all. {} should be for function bodies, lamdbas. 

Here's a thought:
By default make all templates belong to a reserved namespace. So prefix the
namespace when you need to disambiguate. Call the namespace "T" or "template"
or ? 
T.foo(T.meow())
All templates in the current namespace say Cat get collected under Cat.T 

Might look bad but I don't think any of the other solutions look that great
either. This syntax looks a lot more uniform to functions.
Oct 07 2008
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Sandeep K wrote:

 I don't like {} at all. {} should be for function bodies, lamdbas.


     struct S { int a, b; }
     S s = { 1, 2 };


 Here's a thought: By default make all templates belong to a reserved
 namespace. So prefix the namespace when you need to disambiguate.
 Call the namespace "T" or "template" or ? T.foo(T.meow()) All
 templates in the current namespace say Cat get collected under Cat.T
 
 
 Might look bad but I don't think any of the other solutions look that
 great either. This syntax looks a lot more uniform to functions.


I hope we can find something terser.


Andrei
Oct 07 2008
parent Sandeep K <sandeep.iitkgpMEOW gmail.com> writes:
Andrei Alexandrescu Wrote:


 Sandeep K wrote:

 I don't like {} at all. {} should be for function bodies, lamdbas.


 
      struct S { int a, b; }
      S s = { 1, 2 };


:)

Isn't "T." terse enough? I felt it is more elegant than using special syntax to
disambiguate which function we are referring to. Anyways, I wouldn't know if
this would have other problems such as clashing with the template parameter in
template definitions.
Oct 07 2008
prev sibling parent Leandro Lucarella <llucax gmail.com> writes:
Andrei Alexandrescu, el  7 de octubre a las 10:38 me escribiste:

 Leandro Lucarella wrote:

Jarrett Billingsley, el  6 de octubre a las 16:04 me escribiste:

On Mon, Oct 6, 2008 at 3:52 PM, Walter Bright
<newshound1 digitalmars.com> wrote:

The foo.(bar) syntax seems to be sinking. The foo{bar} seems to be the most
practical alternative. So, how about putting it in the next D2 release on a
trial basis, so people can try it out and see how it looks?


I guess it's OK but I still don't see why anything has to change.
There are much bigger fish to fry.


Amen!


 
 New/potential users are big fish. There has been quite a bit of opinion
 that the Slashed-Eye Sad Guy is offputting at least at first.


If new users is the issues, enum shouldn't be used to define manifest
constants. That was easy to implement (this is one argument to use for
this change to be introduced), and didn't introduce a new way to do
things in D (which is why I don't think it's a good idea to add a new
syntax for template instantiation).

-- 
Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/
----------------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------------
Dale tu mano al mono, pero no el codo, dado que un mono confianzudo es
irreversible.
	-- Ricardo Vaporeso. La Reja, Agosto de 1912.
Oct 07 2008
prev sibling next sibling parent superdan <super dan.org> writes:
Walter Bright Wrote:


 The foo.(bar) syntax seems to be sinking. The foo{bar} seems to be the 
 most practical alternative. So, how about putting it in the next D2 
 release on a trial basis, so people can try it out and see how it looks?


the thot gave me a lil erection. i wanna. but take the pissed pirate off.
Oct 06 2008
prev sibling next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Walter Bright:

 The foo.(bar) syntax seems to be sinking.


The Foo{bar} syntax looks nice enough, it's a char long, and I presume q{int}
isn't a problem, but from 30 answers seems people don't see problems in the old
syntax. So it's not sinking at all.

While in the past I may have listed lots of other things that deserve
attention, and some of them seem far more important/urgent.

Bye,
bearophile
Oct 06 2008
parent reply superdan <super dan.org> writes:
bearophile Wrote:


 Walter Bright:

 The foo.(bar) syntax seems to be sinking.


 
 The Foo{bar} syntax looks nice enough, it's a char long, and I presume q{int}
isn't a problem, but from 30 answers seems people don't see problems in the old
syntax. So it's not sinking at all.


relax. he said the pissed pirate is sinking not the slashed pissed fella.

q{int} is a problem.

template q(T) { enum q = "eh"; }
writeln(q{int});

tat prints eh or int?

anyhoo every1 forgot all about tat which says how used it is. yank it walt.
perl made a huge mistake with it. i been on their boards and conferences fer
years. time and again they tried to add clean identifiers. y'know without the $
and   and % and poop. and they can't because of the q{string} and qq{string}

with a non-keyword string. it's gonna bite yer ass later. 

yank the q{} walt regardless of templates n stuff. use ${} or whatever but
never a short id. yer gonna thank yerself later.
Oct 06 2008
parent reply Ary Borenszweig <ary esperanto.org.ar> writes:
superdan escribi:

 bearophile Wrote:
 

 Walter Bright:

 The foo.(bar) syntax seems to be sinking.


 The Foo{bar} syntax looks nice enough, it's a char long, and I presume q{int}
isn't a problem, but from 30 answers seems people don't see problems in the old
syntax. So it's not sinking at all.


 
 relax. he said the pissed pirate is sinking not the slashed pissed fella.
 
 q{int} is a problem.
 
 template q(T) { enum q = "eh"; }
 writeln(q{int});
 
 tat prints eh or int?


It prints "int", of course. q{int} is already evaluated at the lexical 
pass, so the parser sees:

writeln("int");

I don't see it is such a big deal. Why would you define a template named 
q anyway? No one will be bitten by that.

Although I know it's inconsistent... it's not "nice".

But !() is about to change in D2, why not change q{}, which is also D2 only?
Oct 06 2008
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Ary Borenszweig wrote:

 superdan escribi:

 bearophile Wrote:


 Walter Bright:

 The foo.(bar) syntax seems to be sinking.


 The Foo{bar} syntax looks nice enough, it's a char long, and I 
 presume q{int} isn't a problem, but from 30 answers seems people 
 don't see problems in the old syntax. So it's not sinking at all.


 relax. he said the pissed pirate is sinking not the slashed pissed fella.

 q{int} is a problem.

 template q(T) { enum q = "eh"; }
 writeln(q{int});

 tat prints eh or int?


 
 It prints "int", of course. q{int} is already evaluated at the lexical 
 pass, so the parser sees:
 
 writeln("int");
 
 I don't see it is such a big deal. Why would you define a template named 
 q anyway? No one will be bitten by that.
 
 Although I know it's inconsistent... it's not "nice".
 
 But !() is about to change in D2, why not change q{}, which is also D2 
 only?


I agree with superdan and Ary, q{string} is a mistake. I was behind 
introducing q{}, I apologize.

Speaking of constructs starting with letter, there's also r"string". So 
far it hasn't caused problems...


Andrei
Oct 06 2008
parent "Jarrett Billingsley" <jarrett.billingsley gmail.com> writes:
On Mon, Oct 6, 2008 at 6:04 PM, Andrei Alexandrescu
<SeeWebsiteForEmail erdani.org> wrote:

 Ary Borenszweig wrote:

 superdan escribi=F3:

 bearophile Wrote:


 Walter Bright:

 The foo.(bar) syntax seems to be sinking.


 The Foo{bar} syntax looks nice enough, it's a char long, and I presume
 q{int} isn't a problem, but from 30 answers seems people don't see pro=








blems

 in the old syntax. So it's not sinking at all.


 relax. he said the pissed pirate is sinking not the slashed pissed fell=






a.

 q{int} is a problem.

 template q(T) { enum q =3D "eh"; }
 writeln(q{int});

 tat prints eh or int?


 It prints "int", of course. q{int} is already evaluated at the lexical
 pass, so the parser sees:

 writeln("int");

 I don't see it is such a big deal. Why would you define a template named=




 q

 anyway? No one will be bitten by that.

 Although I know it's inconsistent... it's not "nice".

 But !() is about to change in D2, why not change q{}, which is also D2
 only?


 I agree with superdan and Ary, q{string} is a mistake. I was behind
 introducing q{}, I apologize.


Please to not having Perl in D.  I really like the idea of token
strings, but something like ${} would probably be better.


 Speaking of constructs starting with letter, there's also r"string". So f=


ar

 it hasn't caused problems...


That's because nowhere else in the language is such a sequence of
characters interpretable as anything else :)
Oct 06 2008
prev sibling next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Walter Bright wrote:

 The foo.(bar) syntax seems to be sinking.


Wat iz it sinking about?


 The foo{bar} seems to be the 
 most practical alternative. So, how about putting it in the next D2 
 release on a trial basis, so people can try it out and see how it looks?


I'm for that too and refreshing Thunderbird every five seconds.


Andrei
Oct 06 2008
prev sibling next sibling parent reply "Nick Sabalausky" <a a.a> writes:
"Walter Bright" <newshound1 digitalmars.com> wrote in message 
news:gcdqa4$qas$1 digitalmars.com...

 The foo.(bar) syntax seems to be sinking. The foo{bar} seems to be the 
 most practical alternative. So, how about putting it in the next D2 
 release on a trial basis, so people can try it out and see how it looks?


I would like to eventually be able to have a function like this (trivial 
contrived example):

repeat(int times, void delegate() d)
{
    foreach(int i; 0..times)
        d();
}

And call it like this:

repeat(3)
{
    // Do stuff
}

Instead of needing to use the current awkwardness of:

repeat(3,
{
    // Do stuff
});

If changing "foo!(bar)" to "foo{bar}" would cause problems with that, then 
I'd be against it. Otherwise, I'd be ok with the change, provided that it 
didn't end up becoming visually confusing in terms of "Is that a big 
template parameter list, or a statement block?"
Oct 06 2008
next sibling parent reply superdan <super dan.org> writes:
Nick Sabalausky Wrote:


 "Walter Bright" <newshound1 digitalmars.com> wrote in message 
 news:gcdqa4$qas$1 digitalmars.com...

 The foo.(bar) syntax seems to be sinking. The foo{bar} seems to be the 
 most practical alternative. So, how about putting it in the next D2 
 release on a trial basis, so people can try it out and see how it looks?


 
 I would like to eventually be able to have a function like this (trivial 
 contrived example):
 
 repeat(int times, void delegate() d)
 {
     foreach(int i; 0..times)
         d();
 }
 
 And call it like this:
 
 repeat(3)
 {
     // Do stuff
 }
 
 Instead of needing to use the current awkwardness of:
 
 repeat(3,
 {
     // Do stuff
 });
 
 If changing "foo!(bar)" to "foo{bar}" would cause problems with that, then 
 I'd be against it. Otherwise, I'd be ok with the change, provided that it 
 didn't end up becoming visually confusing in terms of "Is that a big 
 template parameter list, or a statement block?" 


nagonna be a problem. it's been discussed. id { stuff }is instantiation.
id(optional stuff) { stuff } is that thing yer talkin' about.
Oct 06 2008
parent reply "Simen Kjaeraas" <simen.kjaras gmail.com> writes:
On Mon, 06 Oct 2008 23:24:01 +0200, superdan <super dan.org> wrote:


 Nick Sabalausky Wrote:


 "Walter Bright" <newshound1 digitalmars.com> wrote in message
 news:gcdqa4$qas$1 digitalmars.com...

 The foo.(bar) syntax seems to be sinking. The foo{bar} seems to be the
 most practical alternative. So, how about putting it in the next D2
 release on a trial basis, so people can try it out and see how it  


 looks?

 I would like to eventually be able to have a function like this (trivial
 contrived example):

 repeat(int times, void delegate() d)
 {
     foreach(int i; 0..times)
         d();
 }

 And call it like this:

 repeat(3)
 {
     // Do stuff
 }

 Instead of needing to use the current awkwardness of:

 repeat(3,
 {
     // Do stuff
 });

 If changing "foo!(bar)" to "foo{bar}" would cause problems with that,  
 then
 I'd be against it. Otherwise, I'd be ok with the change, provided that  
 it
 didn't end up becoming visually confusing in terms of "Is that a big
 template parameter list, or a statement block?"


 nagonna be a problem. it's been discussed. id { stuff }is instantiation.  
 id(optional stuff) { stuff } is that thing yer talkin' about.


Not necessarily. Consider

   repeat(int times = 3, void delegate() d){...}

   repeat
   {
     foo();
   }

-- 
Simen
Oct 07 2008
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Simen Kjaeraas wrote:

 On Mon, 06 Oct 2008 23:24:01 +0200, superdan <super dan.org> wrote:
 

 Nick Sabalausky Wrote:


 "Walter Bright" <newshound1 digitalmars.com> wrote in message
 news:gcdqa4$qas$1 digitalmars.com...

 The foo.(bar) syntax seems to be sinking. The foo{bar} seems to be the
 most practical alternative. So, how about putting it in the next D2
 release on a trial basis, so people can try it out and see how it 


 looks?

 I would like to eventually be able to have a function like this (trivial
 contrived example):

 repeat(int times, void delegate() d)
 {
     foreach(int i; 0..times)
         d();
 }

 And call it like this:

 repeat(3)
 {
     // Do stuff
 }

 Instead of needing to use the current awkwardness of:

 repeat(3,
 {
     // Do stuff
 });

 If changing "foo!(bar)" to "foo{bar}" would cause problems with that, 
 then
 I'd be against it. Otherwise, I'd be ok with the change, provided 
 that it
 didn't end up becoming visually confusing in terms of "Is that a big
 template parameter list, or a statement block?"


 nagonna be a problem. it's been discussed. id { stuff }is 
 instantiation. id(optional stuff) { stuff } is that thing yer talkin' 
 about.


 
 Not necessarily. Consider
 
   repeat(int times = 3, void delegate() d){...}
 
   repeat
   {
     foo();
   }
 


I think that's a corner case we shouldn't cater for. Most of the time 
you want to pass parameters into the delegate. Therefore the delegate 
will have to be somehow prefixed by a parameter declaration, which will 
syntactically disambiguate it.

Andrei
Oct 07 2008
prev sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
Nick Sabalausky wrote:

 I would like to eventually be able to have a function like this (trivial 
 contrived example):
 
 repeat(int times, void delegate() d)
 {
     foreach(int i; 0..times)
         d();
 }
 
 And call it like this:
 
 repeat(3)
 {
     // Do stuff
 }
 
 Instead of needing to use the current awkwardness of:
 
 repeat(3,
 {
     // Do stuff
 });
 
 If changing "foo!(bar)" to "foo{bar}" would cause problems with that, then 
 I'd be against it. Otherwise, I'd be ok with the change, provided that it 
 didn't end up becoming visually confusing in terms of "Is that a big 
 template parameter list, or a statement block?" 


It may be a problem, because inside a template expansion, the template 
name with no arguments represents the current instantiation.
Oct 06 2008
parent reply Don <nospam nospam.com.au> writes:
Walter Bright wrote:

 Nick Sabalausky wrote:

 I would like to eventually be able to have a function like this 
 (trivial contrived example):

 repeat(int times, void delegate() d)
 {
     foreach(int i; 0..times)
         d();
 }

 And call it like this:

 repeat(3)
 {
     // Do stuff
 }

 Instead of needing to use the current awkwardness of:

 repeat(3,
 {
     // Do stuff
 });

 If changing "foo!(bar)" to "foo{bar}" would cause problems with that, 
 then I'd be against it. Otherwise, I'd be ok with the change, provided 
 that it didn't end up becoming visually confusing in terms of "Is that 
 a big template parameter list, or a statement block?" 


 
 It may be a problem, because inside a template expansion, the template 
 name with no arguments represents the current instantiation.


Is that a behaviour which needs to be retained? After all, inside the 
template you have all of the template arguments, so you can write it out 
long-hand. (==> It's an issue of syntax sugar, not functionality). And 
I've found that you often want to have almost all of the arguments the 
same, except one or two different. ( ==> It's syntax sugar which might 
not be all that useful).
Oct 07 2008
parent reply Walter Bright <newshound1 digitalmars.com> writes:
Don wrote:

 Walter Bright wrote:

 It may be a problem, because inside a template expansion, the template 
 name with no arguments represents the current instantiation.


 
 Is that a behaviour which needs to be retained? After all, inside the 
 template you have all of the template arguments, so you can write it out 
 long-hand. (==> It's an issue of syntax sugar, not functionality). And 
 I've found that you often want to have almost all of the arguments the 
 same, except one or two different. ( ==> It's syntax sugar which might 
 not be all that useful).


I think so. This may be a deal breaker for { }.
Oct 07 2008
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Walter Bright wrote:

 Don wrote:

 Walter Bright wrote:

 It may be a problem, because inside a template expansion, the 
 template name with no arguments represents the current instantiation.


 Is that a behaviour which needs to be retained? After all, inside the 
 template you have all of the template arguments, so you can write it 
 out long-hand. (==> It's an issue of syntax sugar, not functionality). 
 And I've found that you often want to have almost all of the arguments 
 the same, except one or two different. ( ==> It's syntax sugar which 
 might not be all that useful).


 
 I think so. This may be a deal breaker for { }.


I don't understand this. Could you please explain the problem again and 
maybe illustrate with an example?

Andrei
Oct 07 2008
prev sibling next sibling parent Moritz Warning <moritzwarning web.de> writes:
On Mon, 06 Oct 2008 12:52:39 -0700, Walter Bright wrote:


 The foo.(bar) syntax seems to be sinking. The foo{bar} seems to be the
 most practical alternative. So, how about putting it in the next D2
 release on a trial basis, so people can try it out and see how it looks?


While foo{bar} is an acceptable syntax for foo!(bar),
it's only a very minor improvement if any.
Not worth the resulting hassle (rewriting code and docs).

Maybe some better syntax comes around (e.g. some clean way to move  
template parameters into the function header?).
Oct 06 2008
prev sibling next sibling parent Michel Fortin <michel.fortin michelf.com> writes:
On 2008-10-06 15:52:39 -0400, Walter Bright <newshound1 digitalmars.com> said:


 The foo.(bar) syntax seems to be sinking. The foo{bar} seems to be the 
 most practical alternative. So, how about putting it in the next D2 
 release on a trial basis, so people can try it out and see how it looks?


I'm not sure this is any improvement over "!()". The "!()" syntax at 
least uses parenthesis, drawing a parallel with function parameters. I 
think the best thing would be to allow parenthesis to be used alone, 
without "!()", finding some way around the ambiguities (maybe plainly 
disallowing them). Beside that, "!()" is still my second choice as long 
as we stay in plain ASCII territory. I haven't seen anything good 
enough to justify switching to a new syntax.

-- 
Michel Fortin
michel.fortin michelf.com
http://michelf.com/
Oct 06 2008
prev sibling next sibling parent Jason House <jason.james.house gmail.com> writes:
Walter Bright Wrote:


 The foo.(bar) syntax seems to be sinking. The foo{bar} seems to be the 
 most practical alternative. So, how about putting it in the next D2 
 release on a trial basis, so people can try it out and see how it looks?


Can we assume by you addressing  a bicycle shed coloring issue that the next
release of dmd will be soon?

Personally, I'm hoping for thread local storage and invariant(T) ==>
immutable(T). My ideal release would include druntime too :-D
Oct 07 2008
prev sibling next sibling parent reply Tomas Lindquist Olsen <tomas famolsen.dk> writes:
Walter Bright wrote:

 The foo.(bar) syntax seems to be sinking. The foo{bar} seems to be the 
 most practical alternative. So, how about putting it in the next D2 
 release on a trial basis, so people can try it out and see how it looks?


I personally think it's a bad idea.

I have a danish keyboard layout:

{ == AltGr+7
} == AltGr+0

parenthesis are easier to type, as they just use shift.
This isn't really that big a problem, I already have to do it in other places,
but this is just 
one more... I actually like the current syntax better though!

Just my 2 cents on this bikeshed color!
Oct 07 2008
next sibling parent reply Frank Benoit <keinfarbton googlemail.com> writes:
Tomas Lindquist Olsen schrieb:

 Walter Bright wrote:

 The foo.(bar) syntax seems to be sinking. The foo{bar} seems to be the
 most practical alternative. So, how about putting it in the next D2
 release on a trial basis, so people can try it out and see how it looks?


 
 I personally think it's a bad idea.
 
 I have a danish keyboard layout:
 
 { == AltGr+7
 } == AltGr+0
 
 parenthesis are easier to type, as they just use shift.
 This isn't really that big a problem, I already have to do it in other
 places, but this is just one more... I actually like the current syntax
 better though!
 
 Just my 2 cents on this bikeshed color!


Same on a german keyboard. This is why I changed all my keyboards to
US-English, because it is easier in C-like programming.
Oct 07 2008
parent reply superdan <super dan.org> writes:
Frank Benoit Wrote:


 Tomas Lindquist Olsen schrieb:

 Walter Bright wrote:

 The foo.(bar) syntax seems to be sinking. The foo{bar} seems to be the
 most practical alternative. So, how about putting it in the next D2
 release on a trial basis, so people can try it out and see how it looks?


 
 I personally think it's a bad idea.
 
 I have a danish keyboard layout:
 
 { == AltGr+7
 } == AltGr+0
 
 parenthesis are easier to type, as they just use shift.
 This isn't really that big a problem, I already have to do it in other
 places, but this is just one more... I actually like the current syntax
 better though!
 
 Just my 2 cents on this bikeshed color!


 
 Same on a german keyboard. This is why I changed all my keyboards to
 US-English, because it is easier in C-like programming.


oh yeah? on my keyboard all chars come with cedilla umlaut three accents and
the saint sign in angstrom. all at once. to type a normal char i have to press
ctrl ctrl alt alt shift fn and keep my toes curled up. and when i was lil i had
measles. and walked to school in waist deep snow. uphill both ways.
Oct 07 2008
parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
"superdan" wrote

 Frank Benoit Wrote:


 Tomas Lindquist Olsen schrieb:

 Walter Bright wrote:

 The foo.(bar) syntax seems to be sinking. The foo{bar} seems to be the
 most practical alternative. So, how about putting it in the next D2
 release on a trial basis, so people can try it out and see how it 
 looks?


 I personally think it's a bad idea.

 I have a danish keyboard layout:

 { == AltGr+7
 } == AltGr+0

 parenthesis are easier to type, as they just use shift.
 This isn't really that big a problem, I already have to do it in other
 places, but this is just one more... I actually like the current syntax
 better though!

 Just my 2 cents on this bikeshed color!


 Same on a german keyboard. This is why I changed all my keyboards to
 US-English, because it is easier in C-like programming.


 oh yeah? on my keyboard all chars come with cedilla umlaut three accents 
 and the saint sign in angstrom. all at once. to type a normal char i have 
 to press ctrl ctrl alt alt shift fn and keep my toes curled up. and when i 
 was lil i had measles. and walked to school in waist deep snow. uphill 
 both ways.


To be honest, I sort of agree with superdan.  If you are going to be 
programming, and your keyboard doesn't let you easily type '{}', it sounds 

curly braces to denote blocks of code.  I guess Danish and German keyboard 
developers aren't expecting their people to program in decent programming 
languages?

Kinda shortsighted if you ask me...

-Steve
Oct 07 2008
next sibling parent reply Frank Benoit <keinfarbton googlemail.com> writes:
Steven Schveighoffer schrieb:


 To be honest, I sort of agree with superdan.  If you are going to be 
 programming, and your keyboard doesn't let you easily type '{}', it sounds 

 curly braces to denote blocks of code.  I guess Danish and German keyboard 
 developers aren't expecting their people to program in decent programming 
 languages?
 
 Kinda shortsighted if you ask me...
 
 -Steve 
 
 


Yes, i guess they thought people want to write danish or german text.
Stupid they are :D

Switching to US keyboard was not a cheap thing, because it is really not
doable to use them mixed. So i had to change at my customers company, at
my office, at home, my notebook. Thats about 7 Keyboards. Coworkers hate
to sit at my place :)

On the other hand, writting german text now needs to type "a for , etc.
Oct 07 2008
next sibling parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
"Frank Benoit" wrote

 Steven Schveighoffer schrieb:


 To be honest, I sort of agree with superdan.  If you are going to be
 programming, and your keyboard doesn't let you easily type '{}', it 
 sounds

 use
 curly braces to denote blocks of code.  I guess Danish and German 
 keyboard
 developers aren't expecting their people to program in decent programming
 languages?

 Kinda shortsighted if you ask me...

 -Steve


 Yes, i guess they thought people want to write danish or german text.
 Stupid they are :D


What I meant was, is it not possible to dedicate some keys to type { } *and* 
allow typing german/danish text?  Is there not a way to have both?  That's 
all I was saying.  I only ever use curly braces in code,  I almost never use 
it while typing English text.  Yet there those keys are ;)  It probably was 
more of a process where those symbols were chosen *because* the keys were 
easy to find, but still, a "programmer's" german keyboard seems like a 
distinct possibility.

-Steve
Oct 07 2008
next sibling parent "Denis Koroskin" <2korden gmail.com> writes:
On Tue, 07 Oct 2008 21:19:00 +0400, Steven Schveighoffer  
<schveiguy yahoo.com> wrote:


 "Frank Benoit" wrote

 Steven Schveighoffer schrieb:


 To be honest, I sort of agree with superdan.  If you are going to be
 programming, and your keyboard doesn't let you easily type '{}', it
 sounds

 use
 curly braces to denote blocks of code.  I guess Danish and German
 keyboard
 developers aren't expecting their people to program in decent  
 programming
 languages?

 Kinda shortsighted if you ask me...

 -Steve


 Yes, i guess they thought people want to write danish or german text.
 Stupid they are :D


 What I meant was, is it not possible to dedicate some keys to type { }  
 *and*
 allow typing german/danish text?  Is there not a way to have both?   
 That's
 all I was saying.  I only ever use curly braces in code,  I almost never  
 use
 it while typing English text.  Yet there those keys are ;)  It probably  
 was
 more of a process where those symbols were chosen *because* the keys were
 easy to find, but still, a "programmer's" german keyboard seems like a
 distinct possibility.

 -Steve


Well, actually there *is* a solution (on Windows, at least). You can add  
your favorite input language with an international keyboard layout. This  
way your keyboard layout would match English (UK/US) with all the  
Danish/Spanish/German etc key avaliable through AltGr.
Oct 07 2008
prev sibling next sibling parent "Simen Kjaeraas" <simen.kjaras gmail.com> writes:
On Tue, 07 Oct 2008 19:19:00 +0200, Steven Schveighoffer  
<schveiguy yahoo.com> wrote:


 "Frank Benoit" wrote

 Steven Schveighoffer schrieb:


 To be honest, I sort of agree with superdan.  If you are going to be
 programming, and your keyboard doesn't let you easily type '{}', it
 sounds

 use
 curly braces to denote blocks of code.  I guess Danish and German
 keyboard
 developers aren't expecting their people to program in decent  
 programming
 languages?

 Kinda shortsighted if you ask me...

 -Steve


 Yes, i guess they thought people want to write danish or german text.
 Stupid they are :D


 What I meant was, is it not possible to dedicate some keys to type { }  
 *and*
 allow typing german/danish text?  Is there not a way to have both?   
 That's
 all I was saying.  I only ever use curly braces in code,  I almost never  
 use
 it while typing English text.  Yet there those keys are ;)  It probably  
 was
 more of a process where those symbols were chosen *because* the keys were
 easy to find, but still, a "programmer's" german keyboard seems like a
 distinct possibility.

 -Steve


Without using modifiers, this can't be done, for the simple reason that  
some other languages' alphabets have more letters than the english.  
Norwegian layout  has æøå in place of ';[ (and yes, we do use those weird  
symbols). However, there are other keyboard layouts available, which gives  
people the best of both worlds.

-- 
Simen
Oct 07 2008
prev sibling parent =?UTF-8?B?QWxleGFuZGVyIFDDoW5law==?= writes:
Steven Schveighoffer wrote:

 "Frank Benoit" wrote

 Steven Schveighoffer schrieb:


 To be honest, I sort of agree with superdan.  If you are going to be
 programming, and your keyboard doesn't let you easily type '{}', it 
 sounds

 use
 curly braces to denote blocks of code.  I guess Danish and German 
 keyboard
 developers aren't expecting their people to program in decent programming
 languages?

 Kinda shortsighted if you ask me...

 -Steve


 Yes, i guess they thought people want to write danish or german text.
 Stupid they are :D


 
 What I meant was, is it not possible to dedicate some keys to type { } *and* 
 allow typing german/danish text?  Is there not a way to have both?  That's 
 all I was saying.  I only ever use curly braces in code,  I almost never use 
 it while typing English text.  Yet there those keys are ;)  It probably was 
 more of a process where those symbols were chosen *because* the keys were 
 easy to find, but still, a "programmer's" german keyboard seems like a 
 distinct possibility.


I’m using a modified US layout, with ä on AltGr+a, ö on AltGr+o, ..., as 
well as typographically correct quotes for English, German and French 
(“”, „”, «»/»«), a proper apostrophe (’), a €-sign on AltGr+e,
etc. 
Works pretty well for me. Also, if anyone else is using my computer, I 
just change the layout to the German one and change it back afterwards. 
Not a big thing.
Oct 07 2008
prev sibling parent Walter Bright <newshound1 digitalmars.com> writes:
Frank Benoit wrote:

 Switching to US keyboard was not a cheap thing, because it is really not
 doable to use them mixed. So i had to change at my customers company, at
 my office, at home, my notebook. Thats about 7 Keyboards. Coworkers hate
 to sit at my place :)


C++ introduced digraphs to deal with that, but as far as I know, nobody 
ever uses them.
Oct 07 2008
prev sibling parent reply Tomas Lindquist Olsen <tomas famolsen.dk> writes:
Steven Schveighoffer wrote:

 "superdan" wrote

 Frank Benoit Wrote:


 Tomas Lindquist Olsen schrieb:

 Walter Bright wrote:

 The foo.(bar) syntax seems to be sinking. The foo{bar} seems to be the
 most practical alternative. So, how about putting it in the next D2
 release on a trial basis, so people can try it out and see how it 
 looks?


 I personally think it's a bad idea.

 I have a danish keyboard layout:

 { == AltGr+7
 } == AltGr+0

 parenthesis are easier to type, as they just use shift.
 This isn't really that big a problem, I already have to do it in other
 places, but this is just one more... I actually like the current syntax
 better though!

 Just my 2 cents on this bikeshed color!


 Same on a german keyboard. This is why I changed all my keyboards to
 US-English, because it is easier in C-like programming.


 oh yeah? on my keyboard all chars come with cedilla umlaut three accents 
 and the saint sign in angstrom. all at once. to type a normal char i have 
 to press ctrl ctrl alt alt shift fn and keep my toes curled up. and when i 
 was lil i had measles. and walked to school in waist deep snow. uphill 
 both ways.


 
 To be honest, I sort of agree with superdan.  If you are going to be 
 programming, and your keyboard doesn't let you easily type '{}', it sounds 

 curly braces to denote blocks of code.  I guess Danish and German keyboard 
 developers aren't expecting their people to program in decent programming 
 languages?
 
 Kinda shortsighted if you ask me...
 
 -Steve 
 
 


For most people those braces are never used, instead someone chose to put the
extremely common 
(in Danish) letters  there instead.

I have to write a lot of Danish and have learned to live with the layout for
coding too. I 
always write both when I have to start a new scope, then fill it out.

Still it was just a bad argument why I didn't like {} for template params. In
the end I'll use 
whatever it ends up with...

I just think it's funny that this has even come up and is getting serious
consideration. Walter 
usually don't like changing the color of his shed! And D coders are already
used to !()
Oct 07 2008
parent reply Walter Bright <newshound1 digitalmars.com> writes:
Tomas Lindquist Olsen wrote:

 I just think it's funny that this has even come up and is getting 
 serious consideration. Walter usually don't like changing the color of 
 his shed! And D coders are already used to !()


As Andrei said, I don't write a lot of templates. He does.

What I'd really like are those funky  and  quote characters. But alas, 
few keyboards have them on it. (I inserted them here by cutting and 
pasting from somewhere else, hardly very practical. I could modify my 
text editor to make it easy, but what about every other ascii text 
editor people use?)
Oct 07 2008
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Walter Bright wrote:

 Tomas Lindquist Olsen wrote:

 I just think it's funny that this has even come up and is getting 
 serious consideration. Walter usually don't like changing the color of 
 his shed! And D coders are already used to !()


 
 As Andrei said, I don't write a lot of templates. He does.
 
 What I'd really like are those funky  and  quote characters. But alas, 
 few keyboards have them on it. (I inserted them here by cutting and 
 pasting from somewhere else, hardly very practical. I could modify my 
 text editor to make it easy, but what about every other ascii text 
 editor people use?)


That's simple. I saw that at work in a nice Smalltalk environment called 
Squeak. People wrote a <- b and the IDE transformed in real time the 
"<-" into a nice arrow.

The compiler accepts both notations. That way the code looks super nice 
and (if using Template{arguments}) is also easy to enter. Plus it 
doesn't look half bad without the embellishment either.


Andrei
Oct 07 2008
next sibling parent reply Robert Fraser <fraserofthenight gmail.com> writes:
Andrei Alexandrescu wrote:

 Walter Bright wrote:

 Tomas Lindquist Olsen wrote:

 I just think it's funny that this has even come up and is getting 
 serious consideration. Walter usually don't like changing the color 
 of his shed! And D coders are already used to !()


 As Andrei said, I don't write a lot of templates. He does.

 What I'd really like are those funky  and  quote characters. But 
 alas, few keyboards have them on it. (I inserted them here by cutting 
 and pasting from somewhere else, hardly very practical. I could modify 
 my text editor to make it easy, but what about every other ascii text 
 editor people use?)


 
 That's simple. I saw that at work in a nice Smalltalk environment called 
 Squeak. People wrote a <- b and the IDE transformed in real time the 
 "<-" into a nice arrow.
 
 The compiler accepts both notations. That way the code looks super nice 
 and (if using Template{arguments}) is also easy to enter. Plus it 
 doesn't look half bad without the embellishment either.
 
 
 Andrei


So we'd be writing LinkedList<-HashMap<-int, Tuple<-char[], double->->->
That's not so bad, ackshully.
Oct 08 2008
parent KennyTM~ <kennytm gmail.com> writes:
Robert Fraser wrote:

 Andrei Alexandrescu wrote:

 Walter Bright wrote:

 Tomas Lindquist Olsen wrote:

 I just think it's funny that this has even come up and is getting 
 serious consideration. Walter usually don't like changing the color 
 of his shed! And D coders are already used to !()


 As Andrei said, I don't write a lot of templates. He does.

 What I'd really like are those funky « and » quote characters. But 
 alas, few keyboards have them on it. (I inserted them here by cutting 
 and pasting from somewhere else, hardly very practical. I could 
 modify my text editor to make it easy, but what about every other 
 ascii text editor people use?)


 That's simple. I saw that at work in a nice Smalltalk environment 
 called Squeak. People wrote a <- b and the IDE transformed in real 
 time the "<-" into a nice arrow.

 The compiler accepts both notations. That way the code looks super 
 nice and (if using Template{arguments}) is also easy to enter. Plus it 
 doesn't look half bad without the embellishment either.


 Andrei


 
 So we'd be writing LinkedList<-HashMap<-int, Tuple<-char[], double->->->
 That's not so bad, ackshully.


I think T<-1     -> is a bit confusing.

(I had suggested \<...\> somewhere in the Positive thread but {...} is 
better.)
Oct 08 2008
prev sibling parent reply Gide Nwawudu <gide btinternet.com> writes:
On Tue, 07 Oct 2008 23:12:31 -0500, Andrei Alexandrescu
<SeeWebsiteForEmail erdani.org> wrote:


Walter Bright wrote:

 Tomas Lindquist Olsen wrote:

 I just think it's funny that this has even come up and is getting 
 serious consideration. Walter usually don't like changing the color of 
 his shed! And D coders are already used to !()


 
 As Andrei said, I don't write a lot of templates. He does.
 
 What I'd really like are those funky  and  quote characters. But alas, 
 few keyboards have them on it. (I inserted them here by cutting and 
 pasting from somewhere else, hardly very practical. I could modify my 
 text editor to make it easy, but what about every other ascii text 
 editor people use?)


That's simple. I saw that at work in a nice Smalltalk environment called 
Squeak. People wrote a <- b and the IDE transformed in real time the 
"<-" into a nice arrow.

The compiler accepts both notations. That way the code looks super nice 
and (if using Template{arguments}) is also easy to enter. Plus it 
doesn't look half bad without the embellishment either.


Andrei


The current syntax '!()' and guillemets '' might be the way to go.
The good thing about guilements is they can be highlighted in a text
editor or IDE as a different colour and this makes templates stand
out, but it is shame that guilements aren't on a UK keyboard.

alias DenseMatrixnum PulType;
alias SparseRowsMatrixnum,HashSparseVector PuuType;
alias BiMapuint, Tupleuint,uint, BiMapOptions.lhDense DicType;

See it doesn't look too bad.

Gide
Oct 08 2008
parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
"Gide Nwawudu" wrote

 On Tue, 07 Oct 2008 23:12:31 -0500, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org> wrote:


Walter Bright wrote:

 Tomas Lindquist Olsen wrote:

 I just think it's funny that this has even come up and is getting
 serious consideration. Walter usually don't like changing the color of
 his shed! And D coders are already used to !()


 As Andrei said, I don't write a lot of templates. He does.

 What I'd really like are those funky  and  quote characters. But alas,
 few keyboards have them on it. (I inserted them here by cutting and
 pasting from somewhere else, hardly very practical. I could modify my
 text editor to make it easy, but what about every other ascii text
 editor people use?)


That's simple. I saw that at work in a nice Smalltalk environment called
Squeak. People wrote a <- b and the IDE transformed in real time the
"<-" into a nice arrow.

The compiler accepts both notations. That way the code looks super nice
and (if using Template{arguments}) is also easy to enter. Plus it
doesn't look half bad without the embellishment either.


Andrei


 The current syntax '!()' and guillemets '' might be the way to go.
 The good thing about guilements is they can be highlighted in a text
 editor or IDE as a different colour and this makes templates stand
 out, but it is shame that guilements aren't on a UK keyboard.

 alias DenseMatrixnum PulType;
 alias SparseRowsMatrixnum,HashSparseVector PuuType;
 alias BiMapuint, Tupleuint,uint, BiMapOptions.lhDense DicType;

 See it doesn't look too bad.


Maybe its your choice of parameter names, but this looks aboslutely awful :(

Everything runs together, looks like one big word.  I think we need a full 
height character to represent template brackets, something with a lot of 
whitespace to separate it from the other characters.

-Steve
Oct 08 2008
next sibling parent reply =?UTF-8?B?QWxleGFuZGVyIFDDoW5law==?= writes:
Steven Schveighoffer wrote:

 Everything runs together, looks like one big word.  I think we need a full 
 height character to represent template brackets, something with a lot of 
 whitespace to separate it from the other characters.


Heh... sounds like !() to me! ;)
Oct 08 2008
parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
"Alexander Pnek" wrote

 Steven Schveighoffer wrote:

 Everything runs together, looks like one big word.  I think we need a 
 full height character to represent template brackets, something with a 
 lot of whitespace to separate it from the other characters.


 Heh... sounds like !() to me! ;)


*gasp*  That's perfect!  I say we go with it ;)

-Steve
Oct 08 2008
parent reply =?UTF-8?B?QWxleGFuZGVyIFDDoW5law==?= writes:
Steven Schveighoffer wrote:

 "Alexander Pánek" wrote

 Steven Schveighoffer wrote:

 Everything runs together, looks like one big word.  I think we need a 
 full height character to represent template brackets, something with a 
 lot of whitespace to separate it from the other characters.


 Heh... sounds like !() to me! ;)


 
 *gasp*  That's perfect!  I say we go with it ;)


Has my vote, for sure!
Oct 08 2008
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Alexander Pnek wrote:

 Steven Schveighoffer wrote:

 "Alexander Pnek" wrote

 Steven Schveighoffer wrote:

 Everything runs together, looks like one big word.  I think we need 
 a full height character to represent template brackets, something 
 with a lot of whitespace to separate it from the other characters.


 Heh... sounds like !() to me! ;)


 *gasp*  That's perfect!  I say we go with it ;)


 
 Has my vote, for sure!


One possibility to make progress would be to keep !( but allow omitting 
the parens when only one argument is being passed. That way many 
instantiations will be helped. For example, in wake of the impending 
demise of complex built-ins:

Complex!double alpha;
Complex!float[] data;

That way, again, we leverage the fact that an extra symbol is needed 
instead of compulsively requiring it in addition of the parens.

One nice thing about this change is that it keeps all code as it is, 
just lifts one restriction.

How about that?


Andrei
Oct 08 2008
next sibling parent reply "Denis Koroskin" <2korden gmail.com> writes:
On Wed, 08 Oct 2008 20:00:54 +0400, Andrei Alexandrescu  
<SeeWebsiteForEmail erdani.org> wrote:


 Alexander Pánek wrote:

 Steven Schveighoffer wrote:

 "Alexander Pánek" wrote

 Steven Schveighoffer wrote:

 Everything runs together, looks like one big word.  I think we need  
 a full height character to represent template brackets, something  
 with a lot of whitespace to separate it from the other characters.


 Heh... sounds like !() to me! ;)


 *gasp*  That's perfect!  I say we go with it ;)


  Has my vote, for sure!


 One possibility to make progress would be to keep !( but allow omitting  
 the parens when only one argument is being passed. That way many  
 instantiations will be helped. For example, in wake of the impending  
 demise of complex built-ins:

 Complex!double alpha;
 Complex!float[] data;

 That way, again, we leverage the fact that an extra symbol is needed  
 instead of compulsively requiring it in addition of the parens.

 One nice thing about this change is that it keeps all code as it is,  
 just lifts one restriction.

 How about that?


 Andrei


What is Complex!float[] - Complex!(float)[] or Complex!(float[])?
Oct 08 2008
next sibling parent =?UTF-8?B?QWxleGFuZGVyIFDDoW5law==?= writes:
Denis Koroskin wrote:

 What is Complex!float[] - Complex!(float)[] or Complex!(float[])?


I dunno. Both make sense. :)

OTOH, how often do you pass an array type to a template? As far as I can 
tell, you usually just pass the base type and an array of that base type 
as argument (like Template!(char)("string")).

Thus: Complex!float[] -> Complex!(float)[]
Oct 08 2008
prev sibling next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Denis Koroskin wrote:

 On Wed, 08 Oct 2008 20:00:54 +0400, Andrei Alexandrescu 
 <SeeWebsiteForEmail erdani.org> wrote:
 

 Alexander Pnek wrote:

 Steven Schveighoffer wrote:

 "Alexander Pnek" wrote

 Steven Schveighoffer wrote:

 Everything runs together, looks like one big word.  I think we 
 need a full height character to represent template brackets, 
 something with a lot of whitespace to separate it from the other 
 characters.


 Heh... sounds like !() to me! ;)


 *gasp*  That's perfect!  I say we go with it ;)


  Has my vote, for sure!


 One possibility to make progress would be to keep !( but allow 
 omitting the parens when only one argument is being passed. That way 
 many instantiations will be helped. For example, in wake of the 
 impending demise of complex built-ins:

 Complex!double alpha;
 Complex!float[] data;

 That way, again, we leverage the fact that an extra symbol is needed 
 instead of compulsively requiring it in addition of the parens.

 One nice thing about this change is that it keeps all code as it is, 
 just lifts one restriction.

 How about that?


 Andrei


 
 What is Complex!float[] - Complex!(float)[] or Complex!(float[])?


My intent is for ! to bind the tightest.

Andrei
Oct 08 2008
parent reply Benji Smith <dlanguage benjismith.net> writes:
Andrei Alexandrescu wrote:

 Denis Koroskin wrote:

 What is Complex!float[] - Complex!(float)[] or Complex!(float[])?


 
 My intent is for ! to bind the tightest.


So, would it be legal to write it like this?

    (Complex!float)[] array;

--benji
Oct 08 2008
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Benji Smith wrote:

 Andrei Alexandrescu wrote:

 Denis Koroskin wrote:

 What is Complex!float[] - Complex!(float)[] or Complex!(float[])?


 My intent is for ! to bind the tightest.


 
 So, would it be legal to write it like this?
 
    (Complex!float)[] array;


Walter would know.

Andrei
Oct 08 2008
prev sibling parent KennyTM~ <kennytm gmail.com> writes:
Denis Koroskin wrote:

 On Wed, 08 Oct 2008 20:00:54 +0400, Andrei Alexandrescu 
 <SeeWebsiteForEmail erdani.org> wrote:
 

 Alexander Pánek wrote:

 Steven Schveighoffer wrote:

 "Alexander Pánek" wrote

 Steven Schveighoffer wrote:

 Everything runs together, looks like one big word.  I think we 
 need a full height character to represent template brackets, 
 something with a lot of whitespace to separate it from the other 
 characters.


 Heh... sounds like !() to me! ;)


 *gasp*  That's perfect!  I say we go with it ;)


  Has my vote, for sure!


 One possibility to make progress would be to keep !( but allow 
 omitting the parens when only one argument is being passed. That way 
 many instantiations will be helped. For example, in wake of the 
 impending demise of complex built-ins:

 Complex!double alpha;
 Complex!float[] data;

 That way, again, we leverage the fact that an extra symbol is needed 
 instead of compulsively requiring it in addition of the parens.

 One nice thing about this change is that it keeps all code as it is, 
 just lifts one restriction.

 How about that?


 Andrei


 
 What is Complex!float[] - Complex!(float)[] or Complex!(float[])?


What is 5+6*7 — 5+(6*7) or (5+6)*7?

I don't think this is an issue when the operator precedence is well-defined.
Oct 08 2008
prev sibling next sibling parent reply Benji Smith <dlanguage benjismith.net> writes:
Andrei Alexandrescu wrote:

 One possibility to make progress would be to keep !( but allow omitting 
 the parens when only one argument is being passed. That way many 
 instantiations will be helped. For example, in wake of the impending 
 demise of complex built-ins:
 
 Complex!double alpha;
 Complex!float[] data;


Is that an array of Complex!float, or a Complex of float-arrays?

In absence of parentheses, does the ! operator have higher precedence 
than square brackets?

Also...just thinking aloud...it occurs to me that arrays really ought to 
be templates, declared like this:

    Array!int integers;

The square-bracket declaration syntax is handy, but behind the scenes, 
is there really any difference between an array-of-a-specific-type and a 
template?

--benji
Oct 08 2008
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Benji Smith wrote:

 Andrei Alexandrescu wrote:

 One possibility to make progress would be to keep !( but allow 
 omitting the parens when only one argument is being passed. That way 
 many instantiations will be helped. For example, in wake of the 
 impending demise of complex built-ins:

 Complex!double alpha;
 Complex!float[] data;


 
 Is that an array of Complex!float, or a Complex of float-arrays?
 
 In absence of parentheses, does the ! operator have higher precedence 
 than square brackets?
 
 Also...just thinking aloud...it occurs to me that arrays really ought to 
 be templates, declared like this:
 
    Array!int integers;
 
 The square-bracket declaration syntax is handy, but behind the scenes, 
 is there really any difference between an array-of-a-specific-type and a 
 template?


No difference so far as I know. Arrays and pointers are type 
constructors taking exactly one type.

template Array(T) { alias T[] Array; }
template Pointer(T) { alias T* Pointer; }

In fact it could be argued that this notation is more uniform, as [] and 
* are postfix and must be read right to left.


Andrei
Oct 08 2008
prev sibling next sibling parent =?UTF-8?B?QWxleGFuZGVyIFDDoW5law==?= writes:
Andrei Alexandrescu wrote:

 Alexander Pánek wrote:

 Steven Schveighoffer wrote:

 "Alexander Pánek" wrote

 Steven Schveighoffer wrote:

 Everything runs together, looks like one big word.  I think we need 
 a full height character to represent template brackets, something 
 with a lot of whitespace to separate it from the other characters.


 Heh... sounds like !() to me! ;)


 *gasp*  That's perfect!  I say we go with it ;)


 Has my vote, for sure!


 
 One possibility to make progress would be to keep !( but allow omitting 
 the parens when only one argument is being passed. That way many 
 instantiations will be helped. For example, in wake of the impending 
 demise of complex built-ins:
 
 Complex!double alpha;
 Complex!float[] data;
 
 That way, again, we leverage the fact that an extra symbol is needed 
 instead of compulsively requiring it in addition of the parens.
 
 One nice thing about this change is that it keeps all code as it is, 
 just lifts one restriction.
 
 How about that?


I like that.
Oct 08 2008
prev sibling next sibling parent reply KennyTM~ <kennytm gmail.com> writes:
Andrei Alexandrescu wrote:

 Alexander Pánek wrote:

 Steven Schveighoffer wrote:

 "Alexander Pánek" wrote

 Steven Schveighoffer wrote:

 Everything runs together, looks like one big word.  I think we need 
 a full height character to represent template brackets, something 
 with a lot of whitespace to separate it from the other characters.


 Heh... sounds like !() to me! ;)


 *gasp*  That's perfect!  I say we go with it ;)


 Has my vote, for sure!


 
 One possibility to make progress would be to keep !( but allow omitting 
 the parens when only one argument is being passed. That way many 
 instantiations will be helped. For example, in wake of the impending 
 demise of complex built-ins:
 
 Complex!double alpha;
 Complex!float[] data;
 
 That way, again, we leverage the fact that an extra symbol is needed 
 instead of compulsively requiring it in addition of the parens.
 
 One nice thing about this change is that it keeps all code as it is, 
 just lifts one restriction.
 
 How about that?
 
 
 Andrei


vote++ for this.

But how do templates with no arguments be called? Is “T!” valid? If so, 
can these ambiguity be solved first? These are minor cases, though.

(1) opCall strikes again!

class T(int n = 6) {
         static int opCall (int z) {
                 writefln(z);
		return z;
         }
	static char init;
}

void main() {
	auto x = T!(4).init;
}

(2) !is

template T() {
	enum T = 3;
}

void main () {
	writeln(T!is 3);
}
Oct 08 2008
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
KennyTM~ wrote:

 Andrei Alexandrescu wrote:

 Alexander Pnek wrote:

 Steven Schveighoffer wrote:

 "Alexander Pnek" wrote

 Steven Schveighoffer wrote:

 Everything runs together, looks like one big word.  I think we 
 need a full height character to represent template brackets, 
 something with a lot of whitespace to separate it from the other 
 characters.


 Heh... sounds like !() to me! ;)


 *gasp*  That's perfect!  I say we go with it ;)


 Has my vote, for sure!


 One possibility to make progress would be to keep !( but allow 
 omitting the parens when only one argument is being passed. That way 
 many instantiations will be helped. For example, in wake of the 
 impending demise of complex built-ins:

 Complex!double alpha;
 Complex!float[] data;

 That way, again, we leverage the fact that an extra symbol is needed 
 instead of compulsively requiring it in addition of the parens.

 One nice thing about this change is that it keeps all code as it is, 
 just lifts one restriction.

 How about that?


 Andrei


 
 vote++ for this.
 
 But how do templates with no arguments be called? Is T! valid?


Offhand, that looks like it can't work, but haven't we all been wrong 
before? :o)


 If so, 
 can these ambiguity be solved first? These are minor cases, though.
 
 (1) opCall strikes again!
 
 class T(int n = 6) {
         static int opCall (int z) {
                 writefln(z);
         return z;
         }
     static char init;
 }
 
 void main() {
     auto x = T!(4).init;
 }


This is not an opCall issue. A template can alias itself to anything. 
Consider:

template A(T = int)
{
     alias foo A; // say foo is a function
}


 (2) !is
 
 template T() {
     enum T = 3;
 }
 
 void main () {
     writeln(T!is 3);
 }


This is not a problem because "is" is a keyword.


Andrei
Oct 08 2008
parent KennyTM~ <kennytm gmail.com> writes:
Andrei Alexandrescu wrote:

 KennyTM~ wrote:

 Andrei Alexandrescu wrote:

 Alexander Pánek wrote:

 Steven Schveighoffer wrote:

 "Alexander Pánek" wrote

 Steven Schveighoffer wrote:

 Everything runs together, looks like one big word.  I think we 
 need a full height character to represent template brackets, 
 something with a lot of whitespace to separate it from the other 
 characters.


 Heh... sounds like !() to me! ;)


 *gasp*  That's perfect!  I say we go with it ;)


 Has my vote, for sure!


 One possibility to make progress would be to keep !( but allow 
 omitting the parens when only one argument is being passed. That way 
 many instantiations will be helped. For example, in wake of the 
 impending demise of complex built-ins:

 Complex!double alpha;
 Complex!float[] data;

 That way, again, we leverage the fact that an extra symbol is needed 
 instead of compulsively requiring it in addition of the parens.

 One nice thing about this change is that it keeps all code as it is, 
 just lifts one restriction.

 How about that?


 Andrei


 vote++ for this.

 But how do templates with no arguments be called? Is “T!” valid?


 
 Offhand, that looks like it can't work, but haven't we all been wrong 
 before? :o)
 


I guess no. And a template having no parameters isn't really that common 
I guess? I haven't encountered one as least. I also realized if ! is a 
binary operator then it shouldn't act as a postfix operator also.

(Or maybe reserve the postfix operator ! for factorial, i.e. 5! == 120 
/joke)


 If so, can these ambiguity be solved first? These are minor cases, 
 though.

 (1) opCall strikes again!

 class T(int n = 6) {
         static int opCall (int z) {
                 writefln(z);
         return z;
         }
     static char init;
 }

 void main() {
     auto x = T!(4).init;
 }


 
 This is not an opCall issue. A template can alias itself to anything. 
 Consider:
 
 template A(T = int)
 {
     alias foo A; // say foo is a function
 }
 

 (2) !is

 template T() {
     enum T = 3;
 }

 void main () {
     writeln(T!is 3);
 }


 
 This is not a problem because "is" is a keyword.
 
 
 Andrei
Oct 08 2008
prev sibling next sibling parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
"Andrei Alexandrescu" wrote

 Alexander Pnek wrote:

 Steven Schveighoffer wrote:

 "Alexander Pnek" wrote

 Steven Schveighoffer wrote:

 Everything runs together, looks like one big word.  I think we need a 
 full height character to represent template brackets, something with a 
 lot of whitespace to separate it from the other characters.


 Heh... sounds like !() to me! ;)


 *gasp*  That's perfect!  I say we go with it ;)


 Has my vote, for sure!


 One possibility to make progress would be to keep !( but allow omitting 
 the parens when only one argument is being passed. That way many 
 instantiations will be helped. For example, in wake of the impending 
 demise of complex built-ins:

 Complex!double alpha;
 Complex!float[] data;

 That way, again, we leverage the fact that an extra symbol is needed 
 instead of compulsively requiring it in addition of the parens.

 One nice thing about this change is that it keeps all code as it is, just 
 lifts one restriction.

 How about that?


Can't say I love the way it looks, but I can't really find anything 
technically wrong with it.  Although you know my position on optional 
parentheses :)  Except here, x!y doesn't mean something in another language.

The only thing I have against it is what other people have stated about your 
Complex!float[].

It looks ambiguous, even though the precedence could be well-defined.  Some 
other odd things to think about, what do they mean?:

a!b op c

where op is + - / * ~ || && | &

struct a(int x) {...}
a!-5 b;
a!~5 b;

struct a(bool x) {...}
bool b;
a!!b c;

I don't think I'll get used to it :(

-Steve
Oct 08 2008
next sibling parent reply Sean Kelly <sean invisibleduck.org> writes:
Steven Schveighoffer wrote:

 
 struct a(bool x) {...}
 bool b;
 a!!b c;


This example is sufficient for me to recommend against the "omit parens" 
syntax.  Particularly since chained nots are legal, if pointless:

a!!!!!!b c;


 I don't think I'll get used to it :(


I'd get used to it, but I think it reduces at-a-glance clarity, which is 
a problem since the point of this is to find a syntax more appealing to 
new users.


Sean
Oct 08 2008
next sibling parent "Denis Koroskin" <2korden gmail.com> writes:
On Wed, 08 Oct 2008 21:56:57 +0400, Sean Kelly <sean invisibleduck.org>  
wrote:


 Steven Schveighoffer wrote:

  struct a(bool x) {...}
 bool b;
 a!!b c;


 This example is sufficient for me to recommend against the "omit parens"  
 syntax.  Particularly since chained nots are legal, if pointless:

 a!!!!!!b c;


 I don't think I'll get used to it :(


 I'd get used to it, but I think it reduces at-a-glance clarity, which is  
 a problem since the point of this is to find a syntax more appealing to  
 new users.


 Sean


I guess that ommiting parens is allowed but discouraged in this situation.  
You can always put them back if you think that missing them hurts clarity.
Oct 08 2008
prev sibling next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Sean Kelly wrote:

 Steven Schveighoffer wrote:

 struct a(bool x) {...}
 bool b;
 a!!b c;


 
 This example is sufficient for me to recommend against the "omit parens" 
 syntax.  Particularly since chained nots are legal, if pointless:
 
 a!!!!!!b c;


Walter suggested that a!b works only if b is a symbol.


 I don't think I'll get used to it :(


 
 I'd get used to it, but I think it reduces at-a-glance clarity, which is 
 a problem since the point of this is to find a syntax more appealing to 
 new users.


Yah.


Andrei
Oct 08 2008
prev sibling parent KennyTM~ <kennytm gmail.com> writes:
Sean Kelly wrote:

 Steven Schveighoffer wrote:

 struct a(bool x) {...}
 bool b;
 a!!b c;


 
 This example is sufficient for me to recommend against the "omit parens" 
 syntax.  Particularly since chained nots are legal, if pointless:
 
 a!!!!!!b c;
 

 I don't think I'll get used to it :(


 
 I'd get used to it, but I think it reduces at-a-glance clarity, which is 
 a problem since the point of this is to find a syntax more appealing to 
 new users.
 
 
 Sean


int a, b;
a---------b;
Oct 08 2008
prev sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Steven Schveighoffer wrote:

 "Andrei Alexandrescu" wrote

 Alexander Pnek wrote:

 Steven Schveighoffer wrote:

 "Alexander Pnek" wrote

 Steven Schveighoffer wrote:

 Everything runs together, looks like one big word.  I think we need a 
 full height character to represent template brackets, something with a 
 lot of whitespace to separate it from the other characters.


 Heh... sounds like !() to me! ;)


 *gasp*  That's perfect!  I say we go with it ;)


 Has my vote, for sure!


 One possibility to make progress would be to keep !( but allow omitting 
 the parens when only one argument is being passed. That way many 
 instantiations will be helped. For example, in wake of the impending 
 demise of complex built-ins:

 Complex!double alpha;
 Complex!float[] data;

 That way, again, we leverage the fact that an extra symbol is needed 
 instead of compulsively requiring it in addition of the parens.

 One nice thing about this change is that it keeps all code as it is, just 
 lifts one restriction.

 How about that?


 
 Can't say I love the way it looks, but I can't really find anything 
 technically wrong with it.  Although you know my position on optional 
 parentheses :)  Except here, x!y doesn't mean something in another language.


It does mean something in Visual Basic. I'm annoyed I even remembered 
that :o).


 The only thing I have against it is what other people have stated about your 
 Complex!float[].


I think this will be solved once by having ! bind tighter than all of 
today's operators, which is the way it should. One advantage is that it 
makes it easier to use a template type without incurring a large change 
in the type's syntax. For example, one issue I had while working on 
complex was that changing creal to Complex!(real) is a long trip. 
Without parens, it's easier not only for Complex but others as well.

int x;

to

Safe!int x;

or:

Widget w;

to

RefCnt!Widget w;

and so on.


 It looks ambiguous, even though the precedence could be well-defined.  Some 
 other odd things to think about, what do they mean?:
 
 a!b op c
 
 where op is + - / * ~ || && | &
 
 struct a(int x) {...}
 a!-5 b;
 a!~5 b;
 
 struct a(bool x) {...}
 bool b;
 a!!b c;
 
 I don't think I'll get used to it :(


"It'll look odd the first couple of days, then you'll get used to it." I 
seem to remember somebody said something to the same effect...


Andrei
Oct 08 2008
prev sibling parent Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
Andrei Alexandrescu wrote:

 
 One possibility to make progress would be to keep !( but allow omitting 
 the parens when only one argument is being passed. That way many 
 instantiations will be helped. For example, in wake of the impending 
 demise of complex built-ins:
 
 Complex!double alpha;
 Complex!float[] data;
 
 That way, again, we leverage the fact that an extra symbol is needed 
 instead of compulsively requiring it in addition of the parens.
 
 One nice thing about this change is that it keeps all code as it is, 
 just lifts one restriction.
 
 How about that?
 
 
 Andrei


*grrrnmhsdhmmrsrmmhsmgrrmhghhhgrhghrgg*...

Really, Andrei, what's this obsession with omitting parenthesis? Do you 
have something against them? Are you a parenthesis racist? Were you 
sexually abused as a child by parenthesis? :-O
(please take this lightly, it's not meant to be insulting or flaming :o) )

But I'm banging my head here. This issue is just like the omittable 
parenthesis for function calls: you're adding a special case whereas the 
normal syntax works fine, is more consistent (visually and otherwise) 
and likely easier to read. (yes, subjective opinion, but still...)
And just like the omittable parenthesis for function calls, this will 
add ambiguities. Just seeing the discussion springing around resolving 
those ambiguities (like adding precedences and whatnot) makes me cringe. 
Why add complexity if the normal case works fine. (I'm guessing your 
answer is that the normal is not fine - gotta save some more of them' 
characters...) I know economy of syntax is important, but Andrei, you 
seem to be taking it to Scrooge McDuck levels of economy.

Also, let me add another case, if it hasn't been mentioned before:
   Foo!Bar!Baz xpto;
is that Foo!(Bar!(Baz))? or (Foo!(Bar))!(Baz)
Yes, I know that it would be a rare occurence for both such cases to be 
semantically valid, but it's possible.


Andrei Alexandrescu wrote:

 KennyTM~ wrote:

 But how do templates with no arguments be called? Is T! valid?


 Offhand, that looks like it can't work, but haven't we all been wrong
 before? :o)


Good that it won't work. But the door is still open for this same 
feature with other symbols other than "!", so I'm still worried.


-- 
Bruno Medeiros - Software Developer, MSc. in CS/E graduate
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
Oct 14 2008
prev sibling parent reply Gide Nwawudu <gide btinternet.com> writes:
On Wed, 8 Oct 2008 11:51:23 -0400, "Steven Schveighoffer"
<schveiguy yahoo.com> wrote:


"Gide Nwawudu" wrote

 On Tue, 07 Oct 2008 23:12:31 -0500, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org> wrote:


Walter Bright wrote:

 Tomas Lindquist Olsen wrote:

 I just think it's funny that this has even come up and is getting
 serious consideration. Walter usually don't like changing the color of
 his shed! And D coders are already used to !()


 As Andrei said, I don't write a lot of templates. He does.

 What I'd really like are those funky  and  quote characters. But alas,
 few keyboards have them on it. (I inserted them here by cutting and
 pasting from somewhere else, hardly very practical. I could modify my
 text editor to make it easy, but what about every other ascii text
 editor people use?)


That's simple. I saw that at work in a nice Smalltalk environment called
Squeak. People wrote a <- b and the IDE transformed in real time the
"<-" into a nice arrow.

The compiler accepts both notations. That way the code looks super nice
and (if using Template{arguments}) is also easy to enter. Plus it
doesn't look half bad without the embellishment either.


Andrei


 The current syntax '!()' and guillemets '' might be the way to go.
 The good thing about guilements is they can be highlighted in a text
 editor or IDE as a different colour and this makes templates stand
 out, but it is shame that guilements aren't on a UK keyboard.

 alias DenseMatrixnum PulType;
 alias SparseRowsMatrixnum,HashSparseVector PuuType;
 alias BiMapuint, Tupleuint,uint, BiMapOptions.lhDense DicType;

 See it doesn't look too bad.


Maybe its your choice of parameter names, but this looks aboslutely awful :(

Everything runs together, looks like one big word.  I think we need a full 
height character to represent template brackets, something with a lot of 
whitespace to separate it from the other characters.

-Steve 


The IDE/editor highlights the guillemets in a differnet colour,
because unlike brackets, this is easily done without affecting other
expressions. It does look ok.

Gide
Oct 09 2008
parent reply KennyTM~ <kennytm gmail.com> writes:
Gide Nwawudu wrote:

 On Wed, 8 Oct 2008 11:51:23 -0400, "Steven Schveighoffer"
 <schveiguy yahoo.com> wrote:
 

 "Gide Nwawudu" wrote

 On Tue, 07 Oct 2008 23:12:31 -0500, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org> wrote:


 Walter Bright wrote:

 Tomas Lindquist Olsen wrote:

 I just think it's funny that this has even come up and is getting
 serious consideration. Walter usually don't like changing the color of
 his shed! And D coders are already used to !()


 As Andrei said, I don't write a lot of templates. He does.

 What I'd really like are those funky « and » quote characters. But alas,
 few keyboards have them on it. (I inserted them here by cutting and
 pasting from somewhere else, hardly very practical. I could modify my
 text editor to make it easy, but what about every other ascii text
 editor people use?)


 That's simple. I saw that at work in a nice Smalltalk environment called
 Squeak. People wrote a <- b and the IDE transformed in real time the
 "<-" into a nice arrow.

 The compiler accepts both notations. That way the code looks super nice
 and (if using Template{arguments}) is also easy to enter. Plus it
 doesn't look half bad without the embellishment either.


 Andrei


 The current syntax '!()' and guillemets '«»' might be the way to go.
 The good thing about guilements is they can be highlighted in a text
 editor or IDE as a different colour and this makes templates stand
 out, but it is shame that guilements aren't on a UK keyboard.

 alias DenseMatrix«num» PulType;
 alias SparseRowsMatrix«num,HashSparseVector» PuuType;
 alias BiMap«uint, Tuple«uint,uint», BiMapOptions.lhDense» DicType;

 See it doesn't look too bad.


 Maybe its your choice of parameter names, but this looks aboslutely awful :(

 Everything runs together, looks like one big word.  I think we need a full 
 height character to represent template brackets, something with a lot of 
 whitespace to separate it from the other characters.

 -Steve 


 The IDE/editor highlights the guillemets in a differnet colour,
 because unlike brackets, this is easily done without affecting other
 expressions. It does look ok.
 
 Gide


What if I want to program in notepad.exe?
Oct 09 2008
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
KennyTM~ wrote:

 Gide Nwawudu wrote:

 On Wed, 8 Oct 2008 11:51:23 -0400, "Steven Schveighoffer"
 <schveiguy yahoo.com> wrote:


 "Gide Nwawudu" wrote

 On Tue, 07 Oct 2008 23:12:31 -0500, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org> wrote:


 Walter Bright wrote:

 Tomas Lindquist Olsen wrote:

 I just think it's funny that this has even come up and is getting
 serious consideration. Walter usually don't like changing the 
 color of
 his shed! And D coders are already used to !()


 As Andrei said, I don't write a lot of templates. He does.

 What I'd really like are those funky  and  quote characters. But 
 alas,
 few keyboards have them on it. (I inserted them here by cutting and
 pasting from somewhere else, hardly very practical. I could modify my
 text editor to make it easy, but what about every other ascii text
 editor people use?)


 That's simple. I saw that at work in a nice Smalltalk environment 
 called
 Squeak. People wrote a <- b and the IDE transformed in real time the
 "<-" into a nice arrow.

 The compiler accepts both notations. That way the code looks super 
 nice
 and (if using Template{arguments}) is also easy to enter. Plus it
 doesn't look half bad without the embellishment either.


 Andrei


 The current syntax '!()' and guillemets '' might be the way to go.
 The good thing about guilements is they can be highlighted in a text
 editor or IDE as a different colour and this makes templates stand
 out, but it is shame that guilements aren't on a UK keyboard.

 alias DenseMatrixnum PulType;
 alias SparseRowsMatrixnum,HashSparseVector PuuType;
 alias BiMapuint, Tupleuint,uint, BiMapOptions.lhDense DicType;

 See it doesn't look too bad.


 Maybe its your choice of parameter names, but this looks aboslutely 
 awful :(

 Everything runs together, looks like one big word.  I think we need a 
 full height character to represent template brackets, something with 
 a lot of whitespace to separate it from the other characters.

 -Steve


 The IDE/editor highlights the guillemets in a differnet colour,
 because unlike brackets, this is easily done without affecting other
 expressions. It does look ok.

 Gide


 
 What if I want to program in notepad.exe?


No highlight of course but I was surprised that Notepad displayed the 
guillemets properly.

Andrei
Oct 09 2008
parent reply Sergey Gromov <snake.scaly gmail.com> writes:
Thu, 09 Oct 2008 07:26:39 -0500,
Andrei Alexandrescu wrote:

 KennyTM~ wrote:

 Gide Nwawudu wrote:

 The IDE/editor highlights the guillemets in a differnet colour,
 because unlike brackets, this is easily done without affecting other
 expressions. It does look ok.

 Gide


 
 What if I want to program in notepad.exe?


 
 No highlight of course but I was surprised that Notepad displayed the 
 guillemets properly.


XP Notepad has full Unicode support and can save various flavours of 
Unicode files.  Microsoft cares about their non-English speaking, non-
European customers.

As to Unicode punctuation, I wasn't able to evaluate most of the 
proposals in this NG because my news reader is not Unicode-aware and my 
code page is Russian, so I've seen most of them as question marks.
Oct 09 2008
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Sergey Gromov wrote:

 Thu, 09 Oct 2008 07:26:39 -0500,
 Andrei Alexandrescu wrote:

 KennyTM~ wrote:

 Gide Nwawudu wrote:

 The IDE/editor highlights the guillemets in a differnet colour,
 because unlike brackets, this is easily done without affecting other
 expressions. It does look ok.

 Gide


 What if I want to program in notepad.exe?


 No highlight of course but I was surprised that Notepad displayed the 
 guillemets properly.


 
 XP Notepad has full Unicode support and can save various flavours of 
 Unicode files.  Microsoft cares about their non-English speaking, non-
 European customers.
 
 As to Unicode punctuation, I wasn't able to evaluate most of the 
 proposals in this NG because my news reader is not Unicode-aware and my 
 code page is Russian, so I've seen most of them as question marks.


Speaking of which, an interesting converse approach would be if the 
editor would accept and store !() while displaying guillemets instead. 
Does anyone know how this could be done for emacs?


Andrei
Oct 09 2008
parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
"Andrei Alexandrescu" wrote

 Sergey Gromov wrote:

 Thu, 09 Oct 2008 07:26:39 -0500,
 Andrei Alexandrescu wrote:

 KennyTM~ wrote:

 Gide Nwawudu wrote:

 The IDE/editor highlights the guillemets in a differnet colour,
 because unlike brackets, this is easily done without affecting other
 expressions. It does look ok.

 Gide


 What if I want to program in notepad.exe?


 No highlight of course but I was surprised that Notepad displayed the 
 guillemets properly.


 XP Notepad has full Unicode support and can save various flavours of 
 Unicode files.  Microsoft cares about their non-English speaking, non-
 European customers.

 As to Unicode punctuation, I wasn't able to evaluate most of the 
 proposals in this NG because my news reader is not Unicode-aware and my 
 code page is Russian, so I've seen most of them as question marks.


 Speaking of which, an interesting converse approach would be if the editor 
 would accept and store !() while displaying guillemets instead. Does 
 anyone know how this could be done for emacs?


I don't know how it can be done, but I'm sure it can be, and this sounds 
like the BEST solution :)  Because then if I read your code, I don't have to 
worry about dealing with multiple template syntaxes, likewise for you.

-Steve
Oct 09 2008
prev sibling next sibling parent reply "Jarrett Billingsley" <jarrett.billingsley gmail.com> writes:
On Thu, Oct 9, 2008 at 6:38 AM, KennyTM~ <kennytm gmail.com> wrote:

 Gide Nwawudu wrote:

 On Wed, 8 Oct 2008 11:51:23 -0400, "Steven Schveighoffer"
 <schveiguy yahoo.com> wrote:


 "Gide Nwawudu" wrote

 On Tue, 07 Oct 2008 23:12:31 -0500, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org> wrote:


 Walter Bright wrote:

 Tomas Lindquist Olsen wrote:

 I just think it's funny that this has even come up and is getting
 serious consideration. Walter usually don't like changing the color
 of
 his shed! And D coders are already used to !()


 As Andrei said, I don't write a lot of templates. He does.

 What I'd really like are those funky =AB and =BB quote characters. B=












ut

 alas,
 few keyboards have them on it. (I inserted them here by cutting and
 pasting from somewhere else, hardly very practical. I could modify m=












y

 text editor to make it easy, but what about every other ascii text
 editor people use?)


 That's simple. I saw that at work in a nice Smalltalk environment
 called
 Squeak. People wrote a <- b and the IDE transformed in real time the
 "<-" into a nice arrow.

 The compiler accepts both notations. That way the code looks super ni=










ce

 and (if using Template{arguments}) is also easy to enter. Plus it
 doesn't look half bad without the embellishment either.


 Andrei


 The current syntax '!()' and guillemets '=AB=BB' might be the way to g=








o.

 The good thing about guilements is they can be highlighted in a text
 editor or IDE as a different colour and this makes templates stand
 out, but it is shame that guilements aren't on a UK keyboard.

 alias DenseMatrix=ABnum=BB PulType;
 alias SparseRowsMatrix=ABnum,HashSparseVector=BB PuuType;
 alias BiMap=ABuint, Tuple=ABuint,uint=BB, BiMapOptions.lhDense=BB DicT=








ype;

 See it doesn't look too bad.


 Maybe its your choice of parameter names, but this looks aboslutely awf=






ul

 :(

 Everything runs together, looks like one big word.  I think we need a
 full height character to represent template brackets, something with a =






lot

 of whitespace to separate it from the other characters.

 -Steve


 The IDE/editor highlights the guillemets in a differnet colour,
 because unlike brackets, this is easily done without affecting other
 expressions. It does look ok.

 Gide


 What if I want to program in notepad.exe?


Notepad has supported Unicode for years ;)
Oct 09 2008
parent KennyTM~ <kennytm gmail.com> writes:
Jarrett Billingsley wrote:

 On Thu, Oct 9, 2008 at 6:38 AM, KennyTM~ <kennytm gmail.com> wrote:

 Gide Nwawudu wrote:

 On Wed, 8 Oct 2008 11:51:23 -0400, "Steven Schveighoffer"
 <schveiguy yahoo.com> wrote:


 "Gide Nwawudu" wrote

 On Tue, 07 Oct 2008 23:12:31 -0500, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org> wrote:


 Walter Bright wrote:

 Tomas Lindquist Olsen wrote:

 I just think it's funny that this has even come up and is getting
 serious consideration. Walter usually don't like changing the color
 of
 his shed! And D coders are already used to !()


 As Andrei said, I don't write a lot of templates. He does.

 What I'd really like are those funky « and » quote characters. But
 alas,
 few keyboards have them on it. (I inserted them here by cutting and
 pasting from somewhere else, hardly very practical. I could modify my
 text editor to make it easy, but what about every other ascii text
 editor people use?)


 That's simple. I saw that at work in a nice Smalltalk environment
 called
 Squeak. People wrote a <- b and the IDE transformed in real time the
 "<-" into a nice arrow.

 The compiler accepts both notations. That way the code looks super nice
 and (if using Template{arguments}) is also easy to enter. Plus it
 doesn't look half bad without the embellishment either.


 Andrei


 The current syntax '!()' and guillemets '«»' might be the way to go.
 The good thing about guilements is they can be highlighted in a text
 editor or IDE as a different colour and this makes templates stand
 out, but it is shame that guilements aren't on a UK keyboard.

 alias DenseMatrix«num» PulType;
 alias SparseRowsMatrix«num,HashSparseVector» PuuType;
 alias BiMap«uint, Tuple«uint,uint», BiMapOptions.lhDense» DicType;

 See it doesn't look too bad.


 Maybe its your choice of parameter names, but this looks aboslutely awful
 :(

 Everything runs together, looks like one big word.  I think we need a
 full height character to represent template brackets, something with a lot
 of whitespace to separate it from the other characters.

 -Steve


 The IDE/editor highlights the guillemets in a differnet colour,
 because unlike brackets, this is easily done without affecting other
 expressions. It does look ok.

 Gide


 What if I want to program in notepad.exe?


 
 Notepad has supported Unicode for years ;)


People, I'm responding to the argument "IDE/editor highlights the 
guillemets" as a solution to "Everything runs together, looks like one 
big word.". Of course I know notepad.exe supports Unicode in WinNT. Even 
if it does not, it can still be typed without problem since « and » are 
in ISO-8859-1 (Windows 1252).
Oct 09 2008
prev sibling parent Gide Nwawudu <gide btinternet.com> writes:
On Thu, 09 Oct 2008 18:38:43 +0800, KennyTM~ <kennytm gmail.com>
wrote:


Gide Nwawudu wrote:

 On Wed, 8 Oct 2008 11:51:23 -0400, "Steven Schveighoffer"
 <schveiguy yahoo.com> wrote:
 

 "Gide Nwawudu" wrote

 On Tue, 07 Oct 2008 23:12:31 -0500, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org> wrote:


 Walter Bright wrote:

 Tomas Lindquist Olsen wrote:

 I just think it's funny that this has even come up and is getting
 serious consideration. Walter usually don't like changing the color of
 his shed! And D coders are already used to !()


 As Andrei said, I don't write a lot of templates. He does.

 What I'd really like are those funky  and  quote characters. But alas,
 few keyboards have them on it. (I inserted them here by cutting and
 pasting from somewhere else, hardly very practical. I could modify my
 text editor to make it easy, but what about every other ascii text
 editor people use?)


 That's simple. I saw that at work in a nice Smalltalk environment called
 Squeak. People wrote a <- b and the IDE transformed in real time the
 "<-" into a nice arrow.

 The compiler accepts both notations. That way the code looks super nice
 and (if using Template{arguments}) is also easy to enter. Plus it
 doesn't look half bad without the embellishment either.


 Andrei


 The current syntax '!()' and guillemets '' might be the way to go.
 The good thing about guilements is they can be highlighted in a text
 editor or IDE as a different colour and this makes templates stand
 out, but it is shame that guilements aren't on a UK keyboard.

 alias DenseMatrixnum PulType;
 alias SparseRowsMatrixnum,HashSparseVector PuuType;
 alias BiMapuint, Tupleuint,uint, BiMapOptions.lhDense DicType;

 See it doesn't look too bad.


 Maybe its your choice of parameter names, but this looks aboslutely awful :(

 Everything runs together, looks like one big word.  I think we need a full 
 height character to represent template brackets, something with a lot of 
 whitespace to separate it from the other characters.

 -Steve 


 The IDE/editor highlights the guillemets in a differnet colour,
 because unlike brackets, this is easily done without affecting other
 expressions. It does look ok.
 
 Gide


What if I want to program in notepad.exe?


Guillemets look ok using Lucida Console font and notepad supports
unicode.

Gide
Oct 09 2008
prev sibling next sibling parent reply ore-sama <spam here.lot> writes:
Walter Bright Wrote:


 What I'd really like are those funky  and  quote characters. But alas, 
 few keyboards have them on it. (I inserted them here by cutting and 
 pasting from somewhere else, hardly very practical. I could modify my 
 text editor to make it easy, but what about every other ascii text 
 editor people use?)


On windows this can be ruled out with custom keyboard layout. There was a
utility on microsoft site, that builds such a layout.
Oct 08 2008
parent reply =?UTF-8?B?QWxleGFuZGVyIFDDoW5law==?= writes:
ore-sama wrote:

 Walter Bright Wrote:
 

 What I'd really like are those funky « and » quote characters. But alas, 
 few keyboards have them on it. (I inserted them here by cutting and 
 pasting from somewhere else, hardly very practical. I could modify my 
 text editor to make it easy, but what about every other ascii text 
 editor people use?)


 
 On windows this can be ruled out with custom keyboard layout. There was a
utility on microsoft site, that builds such a layout.


You can also provide a custom keyboard layout on Linux/X11/Xorg through Xkb.
Oct 08 2008
next sibling parent reply KennyTM~ <kennytm gmail.com> writes:
Alexander Pánek wrote:

 ore-sama wrote:

 Walter Bright Wrote:


 What I'd really like are those funky « and » quote characters. But 
 alas, few keyboards have them on it. (I inserted them here by cutting 
 and pasting from somewhere else, hardly very practical. I could 
 modify my text editor to make it easy, but what about every other 
 ascii text editor people use?)


 On windows this can be ruled out with custom keyboard layout. There 
 was a utility on microsoft site, that builds such a layout.


 
 You can also provide a custom keyboard layout on Linux/X11/Xorg through 
 Xkb.


Isn't it too much asking a user to build a custom keyboard layout just 
for using the template feature?
Oct 08 2008
parent =?UTF-8?B?QWxleGFuZGVyIFDDoW5law==?= writes:
KennyTM~ wrote:

 Alexander Pánek wrote:

 ore-sama wrote:

 Walter Bright Wrote:


 What I'd really like are those funky « and » quote characters. But 
 alas, few keyboards have them on it. (I inserted them here by 
 cutting and pasting from somewhere else, hardly very practical. I 
 could modify my text editor to make it easy, but what about every 
 other ascii text editor people use?)


 On windows this can be ruled out with custom keyboard layout. There 
 was a utility on microsoft site, that builds such a layout.


 You can also provide a custom keyboard layout on Linux/X11/Xorg 
 through Xkb.


 
 Isn't it too much asking a user to build a custom keyboard layout just 
 for using the template feature?


I dunno. Probably. It’s also a wee bit much to ask for a change of 
syntax because you have an exclamation mark phobia.
Oct 08 2008
prev sibling parent "Nick Sabalausky" <a a.a> writes:
"Alexander Pnek" <alexander.panek brainsware.org> wrote in message 
news:gcikoq$c34$1 digitalmars.com...

 ore-sama wrote:

 Walter Bright Wrote:


 What I'd really like are those funky  and  quote characters. But alas, 
 few keyboards have them on it. (I inserted them here by cutting and 
 pasting from somewhere else, hardly very practical. I could modify my 
 text editor to make it easy, but what about every other ascii text 
 editor people use?)


 On windows this can be ruled out with custom keyboard layout. There was a 
 utility on microsoft site, that builds such a layout.


 You can also provide a custom keyboard layout on Linux/X11/Xorg through 
 Xkb.


Seems to me that custom keyboard layouts would defeat the point of making 
things more attractive for new people.
Oct 08 2008
prev sibling next sibling parent reply Tomas Lindquist Olsen <tomas famolsen.dk> writes:
Walter Bright wrote:

 Tomas Lindquist Olsen wrote:

 I just think it's funny that this has even come up and is getting 
 serious consideration. Walter usually don't like changing the color of 
 his shed! And D coders are already used to !()


 
 As Andrei said, I don't write a lot of templates. He does.
 
 What I'd really like are those funky  and  quote characters. But alas, 
 few keyboards have them on it. (I inserted them here by cutting and 
 pasting from somewhere else, hardly very practical. I could modify my 
 text editor to make it easy, but what about every other ascii text 
 editor people use?)


They're not printed on my keyboard but I can use AltGr+Z and AltGr+X to produce
 and  . This 
is actually a lot nicer to type than { } which requires me to move my hands a
lot more.

I think it's a real problem if some people can't produce them though...
Sometimes you just 
wanna hack a bit in some crappy console editor...
Oct 08 2008
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Tomas Lindquist Olsen wrote:

 Walter Bright wrote:

 Tomas Lindquist Olsen wrote:

 I just think it's funny that this has even come up and is getting 
 serious consideration. Walter usually don't like changing the color 
 of his shed! And D coders are already used to !()


 As Andrei said, I don't write a lot of templates. He does.

 What I'd really like are those funky  and  quote characters. But 
 alas, few keyboards have them on it. (I inserted them here by cutting 
 and pasting from somewhere else, hardly very practical. I could modify 
 my text editor to make it easy, but what about every other ascii text 
 editor people use?)


 
 They're not printed on my keyboard but I can use AltGr+Z and AltGr+X to 
 produce  and  . This is actually a lot nicer to type than { } which 
 requires me to move my hands a lot more.
 
 I think it's a real problem if some people can't produce them though... 
 Sometimes you just wanna hack a bit in some crappy console editor...


I think we can discount the chevrons as an input method. From what I see 
the display devices and fonts are well-prepared, but ASCII still rules 
on the good old keyboard.

I agree with Dave that allowing two syntaxes raises a brow. There are 
two counter-arguments to take into consideration. One is, there is a 
growing trend of improving code visuals across programming language and 
editors (syntax coloring, code folding, paren highlighting, various 
autocompletions and electric modes, error highlighting...), and to me it 
looks like transforming Foo!( into Foo upon typing is just a shade in 
that continuum. The second is that Walter mentioned repeatedly how neat 
it would be if certain math Unicode symbols could be used as infix 
operations. Experimenting a bit with Unicode symbols may be a pretty 
interesting activity.


Andrei
Oct 08 2008
parent Don <nospam nospam.com.au> writes:
Andrei Alexandrescu wrote:

 Tomas Lindquist Olsen wrote:

 Walter Bright wrote:

 Tomas Lindquist Olsen wrote:

 I just think it's funny that this has even come up and is getting 
 serious consideration. Walter usually don't like changing the color 
 of his shed! And D coders are already used to !()


 As Andrei said, I don't write a lot of templates. He does.

 What I'd really like are those funky  and  quote characters. But 
 alas, few keyboards have them on it. (I inserted them here by cutting 
 and pasting from somewhere else, hardly very practical. I could 
 modify my text editor to make it easy, but what about every other 
 ascii text editor people use?)


 They're not printed on my keyboard but I can use AltGr+Z and AltGr+X 
 to produce  and  . This is actually a lot nicer to type than { } 
 which requires me to move my hands a lot more.

 I think it's a real problem if some people can't produce them 
 though... Sometimes you just wanna hack a bit in some crappy console 
 editor...


 
 I think we can discount the chevrons as an input method. From what I see 
 the display devices and fonts are well-prepared, but ASCII still rules 
 on the good old keyboard.


I think the importance of  is a sign that the days of ASCII are 
numbered. (And the current US situation doesn't lead me to believe that 
the euro is about to decrease in importance <g>).
You just can't make an editor without support for UTF any more.


 I agree with Dave that allowing two syntaxes raises a brow. There are 
 two counter-arguments to take into consideration. One is, there is a 
 growing trend of improving code visuals across programming language and 
 editors (syntax coloring, code folding, paren highlighting, various 
 autocompletions and electric modes, error highlighting...), and to me it 
 looks like transforming Foo!( into Foo upon typing is just a shade in 
 that continuum. The second is that Walter mentioned repeatedly how neat 
 it would be if certain math Unicode symbols could be used as infix 
 operations. Experimenting a bit with Unicode symbols may be a pretty 
 interesting activity.


Since there are already many people using chinese characters as variable 
names in D code, it makes a fair bit of sense.
Oct 09 2008
prev sibling parent Christopher Wright <dhasenan gmail.com> writes:
Walter Bright wrote:

 Tomas Lindquist Olsen wrote:

 I just think it's funny that this has even come up and is getting 
 serious consideration. Walter usually don't like changing the color of 
 his shed! And D coders are already used to !()


 
 As Andrei said, I don't write a lot of templates. He does.
 
 What I'd really like are those funky  and  quote characters. But alas, 
 few keyboards have them on it. (I inserted them here by cutting and 
 pasting from somewhere else, hardly very practical. I could modify my 
 text editor to make it easy, but what about every other ascii text 
 editor people use?)


You could modify your keyboard layout instead. Chances are you only use 
one of your alt keys on a regular basis, so you could repurpose that to 
be a third-level chooser.
Oct 08 2008
prev sibling parent Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
Tomas Lindquist Olsen wrote:

 Walter Bright wrote:

 The foo.(bar) syntax seems to be sinking. The foo{bar} seems to be the 
 most practical alternative. So, how about putting it in the next D2 
 release on a trial basis, so people can try it out and see how it looks?


 
 I personally think it's a bad idea.
 
 I have a danish keyboard layout:
 
 { == AltGr+7
 } == AltGr+0
 
 parenthesis are easier to type, as they just use shift.
 This isn't really that big a problem, I already have to do it in other 
 places, but this is just one more... I actually like the current syntax 
 better though!
 
 Just my 2 cents on this bikeshed color!


Unfortunately you can't optimize for all cases (ie, all keyboard layouts).

-- 
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 Benji Smith <dlanguage benjismith.net> writes:
Walter Bright wrote:

 The foo.(bar) syntax seems to be sinking. The foo{bar} seems to be the 
 most practical alternative. So, how about putting it in the next D2 
 release on a trial basis, so people can try it out and see how it looks?


Braces for template instantiation seem okay. But would there be any 
change to template declaration syntax?

There's a conceptual symmetry between templates and functions, Both 
having declarations and invocations. Functions use parens for both 
cases, whereas templates use "()" at the declaration site and "!()" at 
the invocation site.

I think the symmetry would be ideal, if bare parens were used in all 
cases. But at least the "!()" syntax was somewhat reminiscent of the 
declaration syntax (and the function invocation syntax).

Using curlies for template instantiation breaks the symmetry pretty 
badly, unless the template declaration syntax also uses curlies.

--benji
Oct 07 2008
prev sibling next sibling parent reply ore-sama <spam here.lot> writes:
Walter Bright Wrote:


 The foo.(bar) syntax seems to be sinking. The foo{bar} seems to be the 
 most practical alternative. So, how about putting it in the next D2 
 release on a trial basis, so people can try it out and see how it looks?


How about struct initializers syntax? I don't know what are you planning to do
with it, Lars proposed to use curly braces. This can interfere (a little) with
template instantiation syntax.
Oct 07 2008
parent reply "Denis Koroskin" <2korden gmail.com> writes:
On Tue, 07 Oct 2008 20:40:15 +0400, ore-sama <spam here.lot> wrote:


 Walter Bright Wrote:


 The foo.(bar) syntax seems to be sinking. The foo{bar} seems to be the
 most practical alternative. So, how about putting it in the next D2
 release on a trial basis, so people can try it out and see how it looks?


 How about struct initializers syntax? I don't know what are you planning  
 to do with it, Lars proposed to use curly braces. This can interfere (a  
 little) with template instantiation syntax.


Yeah, dropping the q{} stuff opens the way to initialize struct using  
StructName{ ... } syntax:
http://www.digitalmars.com/pnews/read.php?server=news.digitalmars.com&group=digitalmars.D.announce&artnum=12862
Oct 07 2008
parent Tomas Lindquist Olsen <tomas famolsen.dk> writes:
Denis Koroskin wrote:

 On Tue, 07 Oct 2008 20:40:15 +0400, ore-sama <spam here.lot> wrote:
 

 Walter Bright Wrote:


 The foo.(bar) syntax seems to be sinking. The foo{bar} seems to be the
 most practical alternative. So, how about putting it in the next D2
 release on a trial basis, so people can try it out and see how it looks?


 How about struct initializers syntax? I don't know what are you 
 planning to do with it, Lars proposed to use curly braces. This can 
 interfere (a little) with template instantiation syntax.


 
 Yeah, dropping the q{} stuff opens the way to initialize struct using 
 StructName{ ... } syntax:
 http://www.digitalmars.com/pnews/read.php?server=news.digitalmars.com&group=digitalmars.D.a
nounce&artnum=12862 
 


Funny thing is the argument with conflicting with q{} was used extensively
during that 
discussion, now it's somehow become a non issue.
Oct 07 2008
prev sibling next sibling parent Kirk McDonald <kirklin.mcdonald gmail.com> writes:
Walter Bright wrote:

 The foo.(bar) syntax seems to be sinking. The foo{bar} seems to be the 
 most practical alternative. So, how about putting it in the next D2 
 release on a trial basis, so people can try it out and see how it looks?


I do not feel it is necessary to change it at all. We are purchasing a 
perceived aesthetic improvement with a jarring change, which will either 
lead to a deprecated syntax we can never get rid of; or an immensely 
inconvenient, breaking syntax change. It will be an iconic example of 
D's status as a moving target, which is a bad thing.

I have written lots of template code in D. I liked the !( syntax 
immediately, knowing the weaknesses of using <> in C++. I have never had 
the impression that my code was shouting at me. I regard this entire 
discussion as a glorious, textbook example of Parkinson's Law of 
Triviality in action:

http://en.wikipedia.org/wiki/Parkinson%27s_Law_of_Triviality

It is my vote that we do nothing. I will be immensely disappointed if 
this silliness leads to an actual change.

-- 
Kirk McDonald
Oct 07 2008
prev sibling next sibling parent reply Dee Girl <deegirl noreply.com> writes:
Walter Bright Wrote:


 The foo.(bar) syntax seems to be sinking. The foo{bar} seems to be the 
 most practical alternative. So, how about putting it in the next D2 
 release on a trial basis, so people can try it out and see how it looks?


I did not follow this group recent. School started. Sorry! I just see now and
please add my vote if possible. I start with D recent and I remember beginning.
foo!(bar) was not pleasant. Like forced convention with a bad char. And friends
I show code never like it. It is first thing they say why they do not like D.
For me foo{bar} better idea. Thank you, Dee Girl
Oct 07 2008
parent reply Walter Bright <newshound1 digitalmars.com> writes:
Dee Girl wrote:

 I did not follow this group recent. School started. Sorry! I just see
 now and please add my vote if possible. I start with D recent and I
 remember beginning. foo!(bar) was not pleasant. Like forced
 convention with a bad char. And friends I show code never like it. It
 is first thing they say why they do not like D. For me foo{bar}
 better idea. Thank you, Dee Girl


What do your friends think of { } ?
Oct 07 2008
parent reply "Denis Koroskin" <2korden gmail.com> writes:
On Wed, 08 Oct 2008 18:22:21 +0400, superdan <super dan.org> wrote:


 Walter Bright Wrote:


 Dee Girl wrote:

 I did not follow this group recent. School started. Sorry! I just see
 now and please add my vote if possible. I start with D recent and I
 remember beginning. foo!(bar) was not pleasant. Like forced
 convention with a bad char. And friends I show code never like it. It
 is first thing they say why they do not like D. For me foo{bar}
 better idea. Thank you, Dee Girl


 What do your friends think of { } ?


 School started. Every one so busy now. But I think does not matter any  
 more ^_^

 I want to make little idea. Sorry if idea mentioned before (I did not  
 read every thread). I think we can look square brackets []. Let me  
 explain why.

 Paren () is over used in C and in D. Any expression can be in (). And  
 adding () is possible in many cases. But it is not same with []. For  
 example a:(b) is ambiguous but a:[b] is not. So there are many signs  
 possible after symbol and before [. They are:



 But after symbol and before ( only few symbols possible



 Andrei had idea change ! to . before (. But if [] are chosen other ideas  
 are possible. There fore I thing [] more promising than () for template.  
 Also that is good because as I said () already over used. Thank you, Dee  
 Girl


Ahem... supergirl?
Oct 08 2008
next sibling parent reply superdan <super dan.org> writes:
Denis Koroskin Wrote:


 On Wed, 08 Oct 2008 18:22:21 +0400, superdan <super dan.org> wrote:
 

 Walter Bright Wrote:


 Dee Girl wrote:

 I did not follow this group recent. School started. Sorry! I just see
 now and please add my vote if possible. I start with D recent and I
 remember beginning. foo!(bar) was not pleasant. Like forced
 convention with a bad char. And friends I show code never like it. It
 is first thing they say why they do not like D. For me foo{bar}
 better idea. Thank you, Dee Girl


 What do your friends think of { } ?


 School started. Every one so busy now. But I think does not matter any  
 more ^_^

 I want to make little idea. Sorry if idea mentioned before (I did not  
 read every thread). I think we can look square brackets []. Let me  
 explain why.

 Paren () is over used in C and in D. Any expression can be in (). And  
 adding () is possible in many cases. But it is not same with []. For  
 example a:(b) is ambiguous but a:[b] is not. So there are many signs  
 possible after symbol and before [. They are:



 But after symbol and before ( only few symbols possible



 Andrei had idea change ! to . before (. But if [] are chosen other ideas  
 are possible. There fore I thing [] more promising than () for template.  
 Also that is good because as I said () already over used. Thank you, Dee  
 Girl


 
 Ahem... supergirl?


that cat was gonna get outta the bag sooner or later. lets say dee sometimes
uses my laptop and forgets to change the autocompleted field.
Oct 08 2008
next sibling parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
"superdan" wrote

 Denis Koroskin Wrote:


 On Wed, 08 Oct 2008 18:22:21 +0400, superdan <super dan.org> wrote:


 Walter Bright Wrote:


 Dee Girl wrote:

 I did not follow this group recent. School started. Sorry! I just 
 see
 now and please add my vote if possible. I start with D recent and I
 remember beginning. foo!(bar) was not pleasant. Like forced
 convention with a bad char. And friends I show code never like it. 
 It
 is first thing they say why they do not like D. For me foo{bar}
 better idea. Thank you, Dee Girl


 What do your friends think of { } ?


 School started. Every one so busy now. But I think does not matter any
 more ^_^

 I want to make little idea. Sorry if idea mentioned before (I did not
 read every thread). I think we can look square brackets []. Let me
 explain why.

 Paren () is over used in C and in D. Any expression can be in (). And
 adding () is possible in many cases. But it is not same with []. For
 example a:(b) is ambiguous but a:[b] is not. So there are many signs
 possible after symbol and before [. They are:



 But after symbol and before ( only few symbols possible



 Andrei had idea change ! to . before (. But if [] are chosen other 
 ideas
 are possible. There fore I thing [] more promising than () for 
 template.
 Also that is good because as I said () already over used. Thank you, 
 Dee
 Girl


 Ahem... supergirl?


 that cat was gonna get outta the bag sooner or later. lets say dee 
 sometimes uses my laptop and forgets to change the autocompleted field.


Finkle is Einhorn. Einhorn is Finkle!  Einhorn is a man!

Seriously though, pretending to be someone else isn't cool.  Actually, it's 
a little disturbing, especially the way you invented another personality for 
it.  I always wondered why Dee Girl agreed with you on everything...

So Walter, Dee Girl's, superdan's and all of Dee Girl's "friends" votes 
count as one vote, ok?

-Steve
Oct 08 2008
parent reply superdan <super dan.org> writes:
Steven Schveighoffer Wrote:


 "superdan" wrote

 Denis Koroskin Wrote:


 On Wed, 08 Oct 2008 18:22:21 +0400, superdan <super dan.org> wrote:


 Walter Bright Wrote:


 Dee Girl wrote:

 I did not follow this group recent. School started. Sorry! I just 
 see
 now and please add my vote if possible. I start with D recent and I
 remember beginning. foo!(bar) was not pleasant. Like forced
 convention with a bad char. And friends I show code never like it. 
 It
 is first thing they say why they do not like D. For me foo{bar}
 better idea. Thank you, Dee Girl


 What do your friends think of { } ?


 School started. Every one so busy now. But I think does not matter any
 more ^_^

 I want to make little idea. Sorry if idea mentioned before (I did not
 read every thread). I think we can look square brackets []. Let me
 explain why.

 Paren () is over used in C and in D. Any expression can be in (). And
 adding () is possible in many cases. But it is not same with []. For
 example a:(b) is ambiguous but a:[b] is not. So there are many signs
 possible after symbol and before [. They are:



 But after symbol and before ( only few symbols possible



 Andrei had idea change ! to . before (. But if [] are chosen other 
 ideas
 are possible. There fore I thing [] more promising than () for 
 template.
 Also that is good because as I said () already over used. Thank you, 
 Dee
 Girl


 Ahem... supergirl?


 that cat was gonna get outta the bag sooner or later. lets say dee 
 sometimes uses my laptop and forgets to change the autocompleted field.


 
 Finkle is Einhorn. Einhorn is Finkle!  Einhorn is a man!
 
 Seriously though, pretending to be someone else isn't cool.  Actually, it's 
 a little disturbing, especially the way you invented another personality for 
 it.  I always wondered why Dee Girl agreed with you on everything...
 
 So Walter, Dee Girl's, superdan's and all of Dee Girl's "friends" votes 
 count as one vote, ok?
 
 -Steve 


not datin' much are ya. piss off moron. i'm pissed enough already without an
idiot in tow. why can't people mind their privacy and others'.
Oct 08 2008
next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
"superdan" wrote

 Steven Schveighoffer Wrote:


 "superdan" wrote

 Denis Koroskin Wrote:


 On Wed, 08 Oct 2008 18:22:21 +0400, superdan <super dan.org> wrote:


 Walter Bright Wrote:


 Dee Girl wrote:

 I did not follow this group recent. School started. Sorry! I just
 see
 now and please add my vote if possible. I start with D recent and 
 I
 remember beginning. foo!(bar) was not pleasant. Like forced
 convention with a bad char. And friends I show code never like 
 it.
 It
 is first thing they say why they do not like D. For me foo{bar}
 better idea. Thank you, Dee Girl


 What do your friends think of { } ?


 School started. Every one so busy now. But I think does not matter 
 any
 more ^_^

 I want to make little idea. Sorry if idea mentioned before (I did 
 not
 read every thread). I think we can look square brackets []. Let me
 explain why.

 Paren () is over used in C and in D. Any expression can be in (). 
 And
 adding () is possible in many cases. But it is not same with []. For
 example a:(b) is ambiguous but a:[b] is not. So there are many signs
 possible after symbol and before [. They are:



 But after symbol and before ( only few symbols possible



 Andrei had idea change ! to . before (. But if [] are chosen other
 ideas
 are possible. There fore I thing [] more promising than () for
 template.
 Also that is good because as I said () already over used. Thank you,
 Dee
 Girl


 Ahem... supergirl?


 that cat was gonna get outta the bag sooner or later. lets say dee
 sometimes uses my laptop and forgets to change the autocompleted field.


 Finkle is Einhorn. Einhorn is Finkle!  Einhorn is a man!

 Seriously though, pretending to be someone else isn't cool.  Actually, 
 it's
 a little disturbing, especially the way you invented another personality 
 for
 it.  I always wondered why Dee Girl agreed with you on everything...

 So Walter, Dee Girl's, superdan's and all of Dee Girl's "friends" votes
 count as one vote, ok?

 -Steve


 not datin' much are ya. piss off moron. i'm pissed enough already without 
 an idiot in tow. why can't people mind their privacy and others'.


I said you still get a vote, what's the problem?

And no, I don't usually date figments of my imagination.

-Steve
Oct 08 2008
prev sibling parent reply "Chris R. Miller" <lordsauronthegreat gmail.com> writes:
superdan wrote:

 Steven Schveighoffer Wrote:
 

 "superdan" wrote

 Denis Koroskin Wrote:


 On Wed, 08 Oct 2008 18:22:21 +0400, superdan <super dan.org> wrote:


 Walter Bright Wrote:


 Dee Girl wrote:

 I did not follow this group recent. School started. Sorry! I just 
 see
 now and please add my vote if possible. I start with D recent and I
 remember beginning. foo!(bar) was not pleasant. Like forced
 convention with a bad char. And friends I show code never like it. 
 It
 is first thing they say why they do not like D. For me foo{bar}
 better idea. Thank you, Dee Girl


 What do your friends think of { } ?


 School started. Every one so busy now. But I think does not matter any
 more ^_^

 I want to make little idea. Sorry if idea mentioned before (I did not
 read every thread). I think we can look square brackets []. Let me
 explain why.

 Paren () is over used in C and in D. Any expression can be in (). And
 adding () is possible in many cases. But it is not same with []. For
 example a:(b) is ambiguous but a:[b] is not. So there are many signs
 possible after symbol and before [. They are:



 But after symbol and before ( only few symbols possible



 Andrei had idea change ! to . before (. But if [] are chosen other 
 ideas
 are possible. There fore I thing [] more promising than () for 
 template.
 Also that is good because as I said () already over used. Thank you, 
 Dee
 Girl


 Ahem... supergirl?


 that cat was gonna get outta the bag sooner or later. lets say dee 
 sometimes uses my laptop and forgets to change the autocompleted field.


 Finkle is Einhorn. Einhorn is Finkle!  Einhorn is a man!

 Seriously though, pretending to be someone else isn't cool.  Actually, it's 
 a little disturbing, especially the way you invented another personality for 
 it.  I always wondered why Dee Girl agreed with you on everything...

 So Walter, Dee Girl's, superdan's and all of Dee Girl's "friends" votes 
 count as one vote, ok?

 -Steve 


 
 not datin' much are ya. piss off moron. i'm pissed enough already without an
idiot in tow. why can't people mind their privacy and others'.


If you really were different people you'd have different user accounts, 
ergo a different autocomplete cache, ergo this wouldn't be happening.

And none of this "my os doesn't support fast user switching!" bull.

I have personally used fast user switching on Windows XP, Vista, Linux 
(Gnome and KDE), and Mac OS X.

Or you didn't use fast-user-switching, which just makes you an idiot.

Reading through both of your text, Dee Girl's language is different 
enough that I'd suspect you're just an idiot (via the previously stated 
logic, which is brutal and intended more as a gruff form of satirical 
humor).
Oct 08 2008
next sibling parent reply Ary Borenszweig <ary esperanto.org.ar> writes:
Chris R. Miller escribi:

 superdan wrote:

 Steven Schveighoffer Wrote:


 "superdan" wrote

 Denis Koroskin Wrote:


 On Wed, 08 Oct 2008 18:22:21 +0400, superdan <super dan.org> wrote:


 Walter Bright Wrote:


 Dee Girl wrote:

 I did not follow this group recent. School started. Sorry! I 
 just see
 now and please add my vote if possible. I start with D recent and I
 remember beginning. foo!(bar) was not pleasant. Like forced
 convention with a bad char. And friends I show code never like 
 it. It
 is first thing they say why they do not like D. For me foo{bar}
 better idea. Thank you, Dee Girl


 What do your friends think of { } ?


 School started. Every one so busy now. But I think does not matter 
 any
 more ^_^

 I want to make little idea. Sorry if idea mentioned before (I did not
 read every thread). I think we can look square brackets []. Let me
 explain why.

 Paren () is over used in C and in D. Any expression can be in (). And
 adding () is possible in many cases. But it is not same with []. For
 example a:(b) is ambiguous but a:[b] is not. So there are many signs
 possible after symbol and before [. They are:



 But after symbol and before ( only few symbols possible



 Andrei had idea change ! to . before (. But if [] are chosen other 
 ideas
 are possible. There fore I thing [] more promising than () for 
 template.
 Also that is good because as I said () already over used. Thank 
 you, Dee
 Girl


 Ahem... supergirl?


 that cat was gonna get outta the bag sooner or later. lets say dee 
 sometimes uses my laptop and forgets to change the autocompleted field.


 Finkle is Einhorn. Einhorn is Finkle!  Einhorn is a man!

 Seriously though, pretending to be someone else isn't cool.  
 Actually, it's a little disturbing, especially the way you invented 
 another personality for it.  I always wondered why Dee Girl agreed 
 with you on everything...

 So Walter, Dee Girl's, superdan's and all of Dee Girl's "friends" 
 votes count as one vote, ok?

 -Steve 


 not datin' much are ya. piss off moron. i'm pissed enough already 
 without an idiot in tow. why can't people mind their privacy and others'.


 
 If you really were different people you'd have different user accounts, 
 ergo a different autocomplete cache, ergo this wouldn't be happening.
 
 And none of this "my os doesn't support fast user switching!" bull.
 
 I have personally used fast user switching on Windows XP, Vista, Linux 
 (Gnome and KDE), and Mac OS X.
 
 Or you didn't use fast-user-switching, which just makes you an idiot.
 
 Reading through both of your text, Dee Girl's language is different 
 enough that I'd suspect you're just an idiot (via the previously stated 
 logic, which is brutal and intended more as a gruff form of satirical 
 humor).


Aawwww... But I liked Dee Girl! :-(
Oct 08 2008
parent Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
Ary Borenszweig wrote:

 Chris R. Miller escribi:

 If you really were different people you'd have different user 
 accounts, ergo a different autocomplete cache, ergo this wouldn't be 
 happening.

 And none of this "my os doesn't support fast user switching!" bull.

 I have personally used fast user switching on Windows XP, Vista, Linux 
 (Gnome and KDE), and Mac OS X.

 Or you didn't use fast-user-switching, which just makes you an idiot.

 Reading through both of your text, Dee Girl's language is different 
 enough that I'd suspect you're just an idiot (via the previously 
 stated logic, which is brutal and intended more as a gruff form of 
 satirical humor).


 
 Aawwww... But I liked Dee Girl! :-(


Damn... me too. A nerd programmer girl. That was cool. And Japanese too. ^^


-- 
Bruno Medeiros - Software Developer, MSc. in CS/E graduate
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
Oct 14 2008
prev sibling parent reply superdan <super dan.org> writes:
Chris R. Miller Wrote:


 superdan wrote:

 Steven Schveighoffer Wrote:
 

 "superdan" wrote

 Denis Koroskin Wrote:


 On Wed, 08 Oct 2008 18:22:21 +0400, superdan <super dan.org> wrote:


 Walter Bright Wrote:


 Dee Girl wrote:

 I did not follow this group recent. School started. Sorry! I just 
 see
 now and please add my vote if possible. I start with D recent and I
 remember beginning. foo!(bar) was not pleasant. Like forced
 convention with a bad char. And friends I show code never like it. 
 It
 is first thing they say why they do not like D. For me foo{bar}
 better idea. Thank you, Dee Girl


 What do your friends think of { } ?


 School started. Every one so busy now. But I think does not matter any
 more ^_^

 I want to make little idea. Sorry if idea mentioned before (I did not
 read every thread). I think we can look square brackets []. Let me
 explain why.

 Paren () is over used in C and in D. Any expression can be in (). And
 adding () is possible in many cases. But it is not same with []. For
 example a:(b) is ambiguous but a:[b] is not. So there are many signs
 possible after symbol and before [. They are:



 But after symbol and before ( only few symbols possible



 Andrei had idea change ! to . before (. But if [] are chosen other 
 ideas
 are possible. There fore I thing [] more promising than () for 
 template.
 Also that is good because as I said () already over used. Thank you, 
 Dee
 Girl


 Ahem... supergirl?


 that cat was gonna get outta the bag sooner or later. lets say dee 
 sometimes uses my laptop and forgets to change the autocompleted field.


 Finkle is Einhorn. Einhorn is Finkle!  Einhorn is a man!

 Seriously though, pretending to be someone else isn't cool.  Actually, it's 
 a little disturbing, especially the way you invented another personality for 
 it.  I always wondered why Dee Girl agreed with you on everything...

 So Walter, Dee Girl's, superdan's and all of Dee Girl's "friends" votes 
 count as one vote, ok?

 -Steve 


 
 not datin' much are ya. piss off moron. i'm pissed enough already without an
idiot in tow. why can't people mind their privacy and others'.


 
 If you really were different people you'd have different user accounts, 
 ergo a different autocomplete cache, ergo this wouldn't be happening.
 
 And none of this "my os doesn't support fast user switching!" bull.
 
 I have personally used fast user switching on Windows XP, Vista, Linux 
 (Gnome and KDE), and Mac OS X.
 
 Or you didn't use fast-user-switching, which just makes you an idiot.
 
 Reading through both of your text, Dee Girl's language is different 
 enough that I'd suspect you're just an idiot (via the previously stated 
 logic, which is brutal and intended more as a gruff form of satirical 
 humor).


think again einstein it's the other way round. i'll only say this once coz this
shit's pissing me enuff as it is. dee posted from my acct. she was in a hurry n
didn't care to switch users. or at least fix name/email. if you or anyone
thinks my fave pastime is to scam votes on this group or have multiple
personalities or wuddever i don't give a flyin' shit. but dee is embarrassed to
the moon n back because of this all fer reason that ain't yer business. she's
had enough without yer callin' her an idiot. i know u love dumpin' shit on me
coz i dumped on yer too but she ain't doin' no harm. leave her outta this.
Oct 08 2008
next sibling parent "Nick Sabalausky" <a a.a> writes:
"superdan" <super dan.org> wrote in message 
news:gcjp4i$cna$1 digitalmars.com...

 Chris R. Miller Wrote:


 superdan wrote:

 Steven Schveighoffer Wrote:


 "superdan" wrote

 Denis Koroskin Wrote:


 On Wed, 08 Oct 2008 18:22:21 +0400, superdan <super dan.org> wrote:


 Walter Bright Wrote:


 Dee Girl wrote:

 I did not follow this group recent. School started. Sorry! I just
 see
 now and please add my vote if possible. I start with D recent and 
 I
 remember beginning. foo!(bar) was not pleasant. Like forced
 convention with a bad char. And friends I show code never like 
 it.
 It
 is first thing they say why they do not like D. For me foo{bar}
 better idea. Thank you, Dee Girl


 What do your friends think of { } ?


 School started. Every one so busy now. But I think does not matter 
 any
 more ^_^

 I want to make little idea. Sorry if idea mentioned before (I did 
 not
 read every thread). I think we can look square brackets []. Let me
 explain why.

 Paren () is over used in C and in D. Any expression can be in (). 
 And
 adding () is possible in many cases. But it is not same with []. 
 For
 example a:(b) is ambiguous but a:[b] is not. So there are many 
 signs
 possible after symbol and before [. They are:



 But after symbol and before ( only few symbols possible



 Andrei had idea change ! to . before (. But if [] are chosen other
 ideas
 are possible. There fore I thing [] more promising than () for
 template.
 Also that is good because as I said () already over used. Thank 
 you,
 Dee
 Girl


 Ahem... supergirl?


 that cat was gonna get outta the bag sooner or later. lets say dee
 sometimes uses my laptop and forgets to change the autocompleted 
 field.


 Finkle is Einhorn. Einhorn is Finkle!  Einhorn is a man!

 Seriously though, pretending to be someone else isn't cool.  Actually, 
 it's
 a little disturbing, especially the way you invented another 
 personality for
 it.  I always wondered why Dee Girl agreed with you on everything...

 So Walter, Dee Girl's, superdan's and all of Dee Girl's "friends" 
 votes
 count as one vote, ok?

 -Steve


 not datin' much are ya. piss off moron. i'm pissed enough already 
 without an idiot in tow. why can't people mind their privacy and 
 others'.


 If you really were different people you'd have different user accounts,
 ergo a different autocomplete cache, ergo this wouldn't be happening.

 And none of this "my os doesn't support fast user switching!" bull.

 I have personally used fast user switching on Windows XP, Vista, Linux
 (Gnome and KDE), and Mac OS X.

 Or you didn't use fast-user-switching, which just makes you an idiot.

 Reading through both of your text, Dee Girl's language is different
 enough that I'd suspect you're just an idiot (via the previously stated
 logic, which is brutal and intended more as a gruff form of satirical
 humor).


 think again einstein it's the other way round. i'll only say this once coz 
 this shit's pissing me enuff as it is. dee posted from my acct. she was in 
 a hurry n didn't care to switch users. or at least fix name/email. if you 
 or anyone thinks my fave pastime is to scam votes on this group or have 
 multiple personalities or wuddever i don't give a flyin' shit. but dee is 
 embarrassed to the moon n back because of this all fer reason that ain't 
 yer business. she's had enough without yer callin' her an idiot. i know u 
 love dumpin' shit on me coz i dumped on yer too but she ain't doin' no 
 harm. leave her outta this.


It's hard to trust the only person on a newsgroup who tosses around things 
like "piss off moron", "wuddever i don't give a flyin' shit", "u" instead of 
"you", and never uses caps.
Oct 08 2008
prev sibling parent "Chris R. Miller" <lordsauronthegreat gmail.com> writes:
superdan wrote:

 Chris R. Miller Wrote:
 

 superdan wrote:

 Steven Schveighoffer Wrote:


 "superdan" wrote

 Denis Koroskin Wrote:


 On Wed, 08 Oct 2008 18:22:21 +0400, superdan <super dan.org> wrote:


 Walter Bright Wrote:


 Dee Girl wrote:

 I did not follow this group recent. School started. Sorry! I just 
 see
 now and please add my vote if possible. I start with D recent and I
 remember beginning. foo!(bar) was not pleasant. Like forced
 convention with a bad char. And friends I show code never like it. 
 It
 is first thing they say why they do not like D. For me foo{bar}
 better idea. Thank you, Dee Girl


 What do your friends think of { } ?


 School started. Every one so busy now. But I think does not matter any
 more ^_^

 I want to make little idea. Sorry if idea mentioned before (I did not
 read every thread). I think we can look square brackets []. Let me
 explain why.

 Paren () is over used in C and in D. Any expression can be in (). And
 adding () is possible in many cases. But it is not same with []. For
 example a:(b) is ambiguous but a:[b] is not. So there are many signs
 possible after symbol and before [. They are:



 But after symbol and before ( only few symbols possible



 Andrei had idea change ! to . before (. But if [] are chosen other 
 ideas
 are possible. There fore I thing [] more promising than () for 
 template.
 Also that is good because as I said () already over used. Thank you, 
 Dee
 Girl


 Ahem... supergirl?


 that cat was gonna get outta the bag sooner or later. lets say dee 
 sometimes uses my laptop and forgets to change the autocompleted field.


 Finkle is Einhorn. Einhorn is Finkle!  Einhorn is a man!

 Seriously though, pretending to be someone else isn't cool.  Actually, it's 
 a little disturbing, especially the way you invented another personality for 
 it.  I always wondered why Dee Girl agreed with you on everything...

 So Walter, Dee Girl's, superdan's and all of Dee Girl's "friends" votes 
 count as one vote, ok?

 -Steve 


 not datin' much are ya. piss off moron. i'm pissed enough already without an
idiot in tow. why can't people mind their privacy and others'.


 If you really were different people you'd have different user accounts, 
 ergo a different autocomplete cache, ergo this wouldn't be happening.

 And none of this "my os doesn't support fast user switching!" bull.

 I have personally used fast user switching on Windows XP, Vista, Linux 
 (Gnome and KDE), and Mac OS X.

 Or you didn't use fast-user-switching, which just makes you an idiot.

 Reading through both of your text, Dee Girl's language is different 
 enough that I'd suspect you're just an idiot (via the previously stated 
 logic, which is brutal and intended more as a gruff form of satirical 
 humor).


 
 think again einstein it's the other way round. i'll only say this once coz
this shit's pissing me enuff as it is. dee posted from my acct. she was in a
hurry n didn't care to switch users. or at least fix name/email. if you or
anyone thinks my fave pastime is to scam votes on this group or have multiple
personalities or wuddever i don't give a flyin' shit. but dee is embarrassed to
the moon n back because of this all fer reason that ain't yer business. she's
had enough without yer callin' her an idiot. i know u love dumpin' shit on me
coz i dumped on yer too but she ain't doin' no harm. leave her outta this.


I'm sorry Dee if you're feeling bad.  I was really trying to continue 
the mild banter with superdan.
Oct 10 2008
prev sibling parent Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
superdan wrote:

 Denis Koroskin Wrote:
 

 On Wed, 08 Oct 2008 18:22:21 +0400, superdan <super dan.org> wrote:


 Walter Bright Wrote:


 Dee Girl wrote:

 I did not follow this group recent. School started. Sorry! I just see
 now and please add my vote if possible. I start with D recent and I
 remember beginning. foo!(bar) was not pleasant. Like forced
 convention with a bad char. And friends I show code never like it. It
 is first thing they say why they do not like D. For me foo{bar}
 better idea. Thank you, Dee Girl


 What do your friends think of { } ?


 School started. Every one so busy now. But I think does not matter any  
 more ^_^

 I want to make little idea. Sorry if idea mentioned before (I did not  
 read every thread). I think we can look square brackets []. Let me  
 explain why.

 Paren () is over used in C and in D. Any expression can be in (). And  
 adding () is possible in many cases. But it is not same with []. For  
 example a:(b) is ambiguous but a:[b] is not. So there are many signs  
 possible after symbol and before [. They are:



 But after symbol and before ( only few symbols possible



 Andrei had idea change ! to . before (. But if [] are chosen other ideas  
 are possible. There fore I thing [] more promising than () for template.  
 Also that is good because as I said () already over used. Thank you, Dee  
 Girl


 Ahem... supergirl?


 
 that cat was gonna get outta the bag sooner or later. lets say dee sometimes
uses my laptop and forgets to change the autocompleted field.


Wasn't she in Japan? Or was she merely *from* Japan?

-- 
Bruno Medeiros - Software Developer, MSc. in CS/E graduate
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
Oct 14 2008
prev sibling parent reply Don <nospam nospam.com.au> writes:
Denis Koroskin wrote:

 On Wed, 08 Oct 2008 18:22:21 +0400, superdan <super dan.org> wrote:
 

 Walter Bright Wrote:


 Dee Girl wrote:

 I did not follow this group recent. School started. Sorry! I just see
 now and please add my vote if possible. I start with D recent and I
 remember beginning. foo!(bar) was not pleasant. Like forced
 convention with a bad char. And friends I show code never like it. It
 is first thing they say why they do not like D. For me foo{bar}
 better idea. Thank you, Dee Girl


 What do your friends think of { } ?


 School started. Every one so busy now. But I think does not matter any 
 more ^_^

 I want to make little idea. Sorry if idea mentioned before (I did not 
 read every thread). I think we can look square brackets []. Let me 
 explain why.

 Paren () is over used in C and in D. Any expression can be in (). And 
 adding () is possible in many cases. But it is not same with []. For 
 example a:(b) is ambiguous but a:[b] is not. So there are many signs 
 possible after symbol and before [. They are:






Not all of them work. Here's a few examples:

	enum { d= 3, e = 7 }
	int [] a=[1,2];
	bool c;
	auto k=[e]; // kills =
	a ~= c?[d]:[e]; // kills ?
	int [] f = c?k:[e]; // kills :
	if (f>[e]) {}   // kills <
	if (f<[e]) {}   // kills >
	auto g = (k,[d]); // kills comma
	auto h = k~[d]; // kills ~

Array ops will kill + - * / & | % ^
Suddenly the list looks pretty short.
Oct 08 2008
parent reply Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
Don wrote:

 Denis Koroskin wrote:

 On Wed, 08 Oct 2008 18:22:21 +0400, superdan <super dan.org> wrote:


 Walter Bright Wrote:


 Dee Girl wrote:

 I did not follow this group recent. School started. Sorry! I just see
 now and please add my vote if possible. I start with D recent and I
 remember beginning. foo!(bar) was not pleasant. Like forced
 convention with a bad char. And friends I show code never like it. It
 is first thing they say why they do not like D. For me foo{bar}
 better idea. Thank you, Dee Girl


 What do your friends think of { } ?


 School started. Every one so busy now. But I think does not matter 
 any more ^_^

 I want to make little idea. Sorry if idea mentioned before (I did not 
 read every thread). I think we can look square brackets []. Let me 
 explain why.

 Paren () is over used in C and in D. Any expression can be in (). And 
 adding () is possible in many cases. But it is not same with []. For 
 example a:(b) is ambiguous but a:[b] is not. So there are many signs 
 possible after symbol and before [. They are:






 
 Not all of them work. Here's a few examples:
 
     enum { d= 3, e = 7 }
     int [] a=[1,2];
     bool c;
     auto k=[e]; // kills =
     a ~= c?[d]:[e]; // kills ?
     int [] f = c?k:[e]; // kills :
     if (f>[e]) {}   // kills <
     if (f<[e]) {}   // kills >
     auto g = (k,[d]); // kills comma
     auto h = k~[d]; // kills ~
 
 Array ops will kill + - * / & | % ^
 Suddenly the list looks pretty short.




Hum, what about brackets without any prefix character at all?

   Vector[int, 2] foo;
   List[Vector[int, 2]] bar;
   int[3] a = [1, 2, 3]; // array literal here
   int[int] map;
   alias DenseMatrix[num] PulType;
   alias SparseRowsMatrix[num, HashSparseVector] PuuType;
   alias BiMap[uint, Tuple[uint, uint], BiMapOptions.lhDense] DicType;
   int var = a[2]; // array indexing here

Hum... doesn't look bad visually. In fact it seems to fit quite nice 
with how associative arrays, and even normal arrays, are declared. Hum, 
yes, I'm personally liking this a lot.

But does it have any ambiguities? Hum, can't think of any off-hand. If 
an identifier appears before a bracket list, it could either be a 
template instantiation, or an array indexation. But the syntax of both 
is the same, so it doesn't need to be distinguished in the parser.

Waddya think, was this discussed before?

-- 
Bruno Medeiros - Software Developer, MSc. in CS/E graduate
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
Oct 14 2008
next sibling parent Paul D. Anderson <paul.d.removethis.anderson comcast.andthis.net> writes:
Bruno Medeiros Wrote:


 Don wrote:

 Denis Koroskin wrote:

 On Wed, 08 Oct 2008 18:22:21 +0400, superdan <super dan.org> wrote:


 Walter Bright Wrote:


 Dee Girl wrote:

 I did not follow this group recent. School started. Sorry! I just see
 now and please add my vote if possible. I start with D recent and I
 remember beginning. foo!(bar) was not pleasant. Like forced
 convention with a bad char. And friends I show code never like it. It
 is first thing they say why they do not like D. For me foo{bar}
 better idea. Thank you, Dee Girl


 What do your friends think of { } ?


 School started. Every one so busy now. But I think does not matter 
 any more ^_^

 I want to make little idea. Sorry if idea mentioned before (I did not 
 read every thread). I think we can look square brackets []. Let me 
 explain why.

 Paren () is over used in C and in D. Any expression can be in (). And 
 adding () is possible in many cases. But it is not same with []. For 
 example a:(b) is ambiguous but a:[b] is not. So there are many signs 
 possible after symbol and before [. They are:






 
 Not all of them work. Here's a few examples:
 
     enum { d= 3, e = 7 }
     int [] a=[1,2];
     bool c;
     auto k=[e]; // kills =
     a ~= c?[d]:[e]; // kills ?
     int [] f = c?k:[e]; // kills :
     if (f>[e]) {}   // kills <
     if (f<[e]) {}   // kills >
     auto g = (k,[d]); // kills comma
     auto h = k~[d]; // kills ~
 
 Array ops will kill + - * / & | % ^
 Suddenly the list looks pretty short.



 
 
 Hum, what about brackets without any prefix character at all?
 
    Vector[int, 2] foo;
    List[Vector[int, 2]] bar;
    int[3] a = [1, 2, 3]; // array literal here
    int[int] map;
    alias DenseMatrix[num] PulType;
    alias SparseRowsMatrix[num, HashSparseVector] PuuType;
    alias BiMap[uint, Tuple[uint, uint], BiMapOptions.lhDense] DicType;
    int var = a[2]; // array indexing here
 
 Hum... doesn't look bad visually. In fact it seems to fit quite nice 
 with how associative arrays, and even normal arrays, are declared. Hum, 
 yes, I'm personally liking this a lot.
 
 But does it have any ambiguities? Hum, can't think of any off-hand. If 
 an identifier appears before a bracket list, it could either be a 
 template instantiation, or an array indexation. But the syntax of both 
 is the same, so it doesn't need to be distinguished in the parser.
 
 Waddya think, was this discussed before?
 
 -- 
 Bruno Medeiros - Software Developer, MSc. in CS/E graduate
 http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D


If we have to change the template instantiation syntax at all (and I don't
think it needs changing), I like brackets better than the plain parens.

Paul
Oct 14 2008
prev sibling next sibling parent reply "Jarrett Billingsley" <jarrett.billingsley gmail.com> writes:
On Tue, Oct 14, 2008 at 6:43 PM, Bruno Medeiros
<brunodomedeiros+spam com.gmail> wrote:

 Don wrote:

 Denis Koroskin wrote:

 On Wed, 08 Oct 2008 18:22:21 +0400, superdan <super dan.org> wrote:


 Walter Bright Wrote:


 Dee Girl wrote:

 I did not follow this group recent. School started. Sorry! I just see
 now and please add my vote if possible. I start with D recent and I
 remember beginning. foo!(bar) was not pleasant. Like forced
 convention with a bad char. And friends I show code never like it. It
 is first thing they say why they do not like D. For me foo{bar}
 better idea. Thank you, Dee Girl


 What do your friends think of { } ?


 School started. Every one so busy now. But I think does not matter any
 more ^_^

 I want to make little idea. Sorry if idea mentioned before (I did not
 read every thread). I think we can look square brackets []. Let me explain
 why.

 Paren () is over used in C and in D. Any expression can be in (). And
 adding () is possible in many cases. But it is not same with []. For example
 a:(b) is ambiguous but a:[b] is not. So there are many signs possible after
 symbol and before [. They are:






 Not all of them work. Here's a few examples:

    enum { d= 3, e = 7 }
    int [] a=[1,2];
    bool c;
    auto k=[e]; // kills =
    a ~= c?[d]:[e]; // kills ?
    int [] f = c?k:[e]; // kills :
    if (f>[e]) {}   // kills <
    if (f<[e]) {}   // kills >
    auto g = (k,[d]); // kills comma
    auto h = k~[d]; // kills ~

 Array ops will kill + - * / & | % ^
 Suddenly the list looks pretty short.




 Hum, what about brackets without any prefix character at all?

  Vector[int, 2] foo;
  List[Vector[int, 2]] bar;
  int[3] a = [1, 2, 3]; // array literal here
  int[int] map;
  alias DenseMatrix[num] PulType;
  alias SparseRowsMatrix[num, HashSparseVector] PuuType;
  alias BiMap[uint, Tuple[uint, uint], BiMapOptions.lhDense] DicType;
  int var = a[2]; // array indexing here

 Hum... doesn't look bad visually. In fact it seems to fit quite nice with
 how associative arrays, and even normal arrays, are declared. Hum, yes, I'm
 personally liking this a lot.

 But does it have any ambiguities? Hum, can't think of any off-hand. If an
 identifier appears before a bracket list, it could either be a template
 instantiation, or an array indexation. But the syntax of both is the same,
 so it doesn't need to be distinguished in the parser.

 Waddya think, was this discussed before?


Erm,

SomeClass[3] a; // template or array?
Oct 14 2008
parent reply Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
Jarrett Billingsley wrote:

 On Tue, Oct 14, 2008 at 6:43 PM, Bruno Medeiros
 <brunodomedeiros+spam com.gmail> wrote:

 Don wrote:

 Denis Koroskin wrote:

 On Wed, 08 Oct 2008 18:22:21 +0400, superdan <super dan.org> wrote:


 Walter Bright Wrote:


 Dee Girl wrote:

 I did not follow this group recent. School started. Sorry! I just see
 now and please add my vote if possible. I start with D recent and I
 remember beginning. foo!(bar) was not pleasant. Like forced
 convention with a bad char. And friends I show code never like it. It
 is first thing they say why they do not like D. For me foo{bar}
 better idea. Thank you, Dee Girl


 What do your friends think of { } ?


 School started. Every one so busy now. But I think does not matter any
 more ^_^

 I want to make little idea. Sorry if idea mentioned before (I did not
 read every thread). I think we can look square brackets []. Let me explain
 why.

 Paren () is over used in C and in D. Any expression can be in (). And
 adding () is possible in many cases. But it is not same with []. For example
 a:(b) is ambiguous but a:[b] is not. So there are many signs possible after
 symbol and before [. They are:






 Not all of them work. Here's a few examples:

    enum { d= 3, e = 7 }
    int [] a=[1,2];
    bool c;
    auto k=[e]; // kills =
    a ~= c?[d]:[e]; // kills ?
    int [] f = c?k:[e]; // kills :
    if (f>[e]) {}   // kills <
    if (f<[e]) {}   // kills >
    auto g = (k,[d]); // kills comma
    auto h = k~[d]; // kills ~

 Array ops will kill + - * / & | % ^
 Suddenly the list looks pretty short.



 Hum, what about brackets without any prefix character at all?

  Vector[int, 2] foo;
  List[Vector[int, 2]] bar;
  int[3] a = [1, 2, 3]; // array literal here
  int[int] map;
  alias DenseMatrix[num] PulType;
  alias SparseRowsMatrix[num, HashSparseVector] PuuType;
  alias BiMap[uint, Tuple[uint, uint], BiMapOptions.lhDense] DicType;
  int var = a[2]; // array indexing here

 Hum... doesn't look bad visually. In fact it seems to fit quite nice with
 how associative arrays, and even normal arrays, are declared. Hum, yes, I'm
 personally liking this a lot.

 But does it have any ambiguities? Hum, can't think of any off-hand. If an
 identifier appears before a bracket list, it could either be a template
 instantiation, or an array indexation. But the syntax of both is the same,
 so it doesn't need to be distinguished in the parser.

 Waddya think, was this discussed before?


 
 Erm,
 
 SomeClass[3] a; // template or array?


What about it? It doesn't matter for the parser to know if SomeClass is 
a template or array, it can just keep parsing. Its not like the "class A 
: B { }" where parsing would continue differently if B was a template 
instead of a type.

-- 
Bruno Medeiros - Software Developer, MSc. in CS/E graduate
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
Oct 15 2008
next sibling parent reply Don <nospam nospam.com.au> writes:
Bruno Medeiros wrote:

 Jarrett Billingsley wrote:

 On Tue, Oct 14, 2008 at 6:43 PM, Bruno Medeiros
 <brunodomedeiros+spam com.gmail> wrote:

 Don wrote:

 Denis Koroskin wrote:

 On Wed, 08 Oct 2008 18:22:21 +0400, superdan <super dan.org> wrote:


 Walter Bright Wrote:


 Dee Girl wrote:

 I did not follow this group recent. School started. Sorry! I 
 just see
 now and please add my vote if possible. I start with D recent and I
 remember beginning. foo!(bar) was not pleasant. Like forced
 convention with a bad char. And friends I show code never like 
 it. It
 is first thing they say why they do not like D. For me foo{bar}
 better idea. Thank you, Dee Girl


 What do your friends think of { } ?


 School started. Every one so busy now. But I think does not matter 
 any
 more ^_^

 I want to make little idea. Sorry if idea mentioned before (I did not
 read every thread). I think we can look square brackets []. Let me 
 explain
 why.

 Paren () is over used in C and in D. Any expression can be in (). And
 adding () is possible in many cases. But it is not same with []. 
 For example
 a:(b) is ambiguous but a:[b] is not. So there are many signs 
 possible after
 symbol and before [. They are:






 Not all of them work. Here's a few examples:

    enum { d= 3, e = 7 }
    int [] a=[1,2];
    bool c;
    auto k=[e]; // kills =
    a ~= c?[d]:[e]; // kills ?
    int [] f = c?k:[e]; // kills :
    if (f>[e]) {}   // kills <
    if (f<[e]) {}   // kills >
    auto g = (k,[d]); // kills comma
    auto h = k~[d]; // kills ~

 Array ops will kill + - * / & | % ^
 Suddenly the list looks pretty short.



 Hum, what about brackets without any prefix character at all?

  Vector[int, 2] foo;
  List[Vector[int, 2]] bar;
  int[3] a = [1, 2, 3]; // array literal here
  int[int] map;
  alias DenseMatrix[num] PulType;
  alias SparseRowsMatrix[num, HashSparseVector] PuuType;
  alias BiMap[uint, Tuple[uint, uint], BiMapOptions.lhDense] DicType;
  int var = a[2]; // array indexing here

 Hum... doesn't look bad visually. In fact it seems to fit quite nice 
 with
 how associative arrays, and even normal arrays, are declared. Hum, 
 yes, I'm
 personally liking this a lot.

 But does it have any ambiguities? Hum, can't think of any off-hand. 
 If an
 identifier appears before a bracket list, it could either be a template
 instantiation, or an array indexation. But the syntax of both is the 
 same,
 so it doesn't need to be distinguished in the parser.






Arrays allow ..
But, it would be nice if templates did too.

There _must_ be something badly wrong with this proposal, but I can't 
see what it is <g>. I agree that it looks nice.
Oct 15 2008
parent Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
Don wrote:

 Bruno Medeiros wrote:

 Jarrett Billingsley wrote:

 On Tue, Oct 14, 2008 at 6:43 PM, Bruno Medeiros
 <brunodomedeiros+spam com.gmail> wrote:

 Don wrote:

 Denis Koroskin wrote:

 On Wed, 08 Oct 2008 18:22:21 +0400, superdan <super dan.org> wrote:


 Walter Bright Wrote:


 Dee Girl wrote:

 I did not follow this group recent. School started. Sorry! I 
 just see
 now and please add my vote if possible. I start with D recent 
 and I
 remember beginning. foo!(bar) was not pleasant. Like forced
 convention with a bad char. And friends I show code never like 
 it. It
 is first thing they say why they do not like D. For me foo{bar}
 better idea. Thank you, Dee Girl


 What do your friends think of { } ?


 School started. Every one so busy now. But I think does not 
 matter any
 more ^_^

 I want to make little idea. Sorry if idea mentioned before (I did 
 not
 read every thread). I think we can look square brackets []. Let 
 me explain
 why.

 Paren () is over used in C and in D. Any expression can be in (). 
 And
 adding () is possible in many cases. But it is not same with []. 
 For example
 a:(b) is ambiguous but a:[b] is not. So there are many signs 
 possible after
 symbol and before [. They are:






 Not all of them work. Here's a few examples:

    enum { d= 3, e = 7 }
    int [] a=[1,2];
    bool c;
    auto k=[e]; // kills =
    a ~= c?[d]:[e]; // kills ?
    int [] f = c?k:[e]; // kills :
    if (f>[e]) {}   // kills <
    if (f<[e]) {}   // kills >
    auto g = (k,[d]); // kills comma
    auto h = k~[d]; // kills ~

 Array ops will kill + - * / & | % ^
 Suddenly the list looks pretty short.



 Hum, what about brackets without any prefix character at all?

  Vector[int, 2] foo;
  List[Vector[int, 2]] bar;
  int[3] a = [1, 2, 3]; // array literal here
  int[int] map;
  alias DenseMatrix[num] PulType;
  alias SparseRowsMatrix[num, HashSparseVector] PuuType;
  alias BiMap[uint, Tuple[uint, uint], BiMapOptions.lhDense] DicType;
  int var = a[2]; // array indexing here

 Hum... doesn't look bad visually. In fact it seems to fit quite nice 
 with
 how associative arrays, and even normal arrays, are declared. Hum, 
 yes, I'm
 personally liking this a lot.

 But does it have any ambiguities? Hum, can't think of any off-hand. 
 If an
 identifier appears before a bracket list, it could either be a template
 instantiation, or an array indexation. But the syntax of both is the 
 same,
 so it doesn't need to be distinguished in the parser.






 
 Arrays allow ..
 But, it would be nice if templates did too.
 
 There _must_ be something badly wrong with this proposal, but I can't 
 see what it is <g>. I agree that it looks nice.


It does feel like it's too nice to be true... :P

-- 
Bruno Medeiros - Software Developer, MSc. in CS/E graduate
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
Oct 15 2008
prev sibling parent reply Jesse Phillips <jessekphillips gmail.com> writes:
On Wed, 15 Oct 2008 11:24:46 +0100, Bruno Medeiros wrote:


 Jarrett Billingsley wrote:

 On Tue, Oct 14, 2008 at 6:43 PM, Bruno Medeiros
 <brunodomedeiros+spam com.gmail> wrote:

 Don wrote:

 Denis Koroskin wrote:

 On Wed, 08 Oct 2008 18:22:21 +0400, superdan <super dan.org> wrote:


 Walter Bright Wrote:


 Dee Girl wrote:

 I did not follow this group recent. School started. Sorry! I just
 see now and please add my vote if possible. I start with D recent
 and I remember beginning. foo!(bar) was not pleasant. Like forced
 convention with a bad char. And friends I show code never like
 it. It is first thing they say why they do not like D. For me
 foo{bar} better idea. Thank you, Dee Girl


 What do your friends think of { } ?


 School started. Every one so busy now. But I think does not matter
 any more ^_^

 I want to make little idea. Sorry if idea mentioned before (I did
 not read every thread). I think we can look square brackets []. Let
 me explain why.

 Paren () is over used in C and in D. Any expression can be in ().
 And adding () is possible in many cases. But it is not same with
 []. For example a:(b) is ambiguous but a:[b] is not. So there are
 many signs possible after symbol and before [. They are:






 Not all of them work. Here's a few examples:

    enum { d= 3, e = 7 }
    int [] a=[1,2];
    bool c;
    auto k=[e]; // kills =
    a ~= c?[d]:[e]; // kills ?
    int [] f = c?k:[e]; // kills :
    if (f>[e]) {}   // kills <
    if (f<[e]) {}   // kills >
    auto g = (k,[d]); // kills comma
    auto h = k~[d]; // kills ~

 Array ops will kill + - * / & | % ^



 Hum, what about brackets without any prefix character at all?

  Vector[int, 2] foo;
  List[Vector[int, 2]] bar;
  int[3] a = [1, 2, 3]; // array literal here int[int] map;
  alias DenseMatrix[num] PulType;
  alias SparseRowsMatrix[num, HashSparseVector] PuuType; alias
  BiMap[uint, Tuple[uint, uint], BiMapOptions.lhDense] DicType; int var
  = a[2]; // array indexing here

 Hum... doesn't look bad visually. In fact it seems to fit quite nice
 with how associative arrays, and even normal arrays, are declared.
 Hum, yes, I'm personally liking this a lot.

 But does it have any ambiguities? Hum, can't think of any off-hand. If
 an identifier appears before a bracket list, it could either be a
 template instantiation, or an array indexation. But the syntax of both
 is the same, so it doesn't need to be distinguished in the parser.

 Waddya think, was this discussed before?


 
 Erm,
 
 SomeClass[3] a; // template or array?


 
 What about it? It doesn't matter for the parser to know if SomeClass is
 a template or array, it can just keep parsing. Its not like the "class A
 : B { }" where parsing would continue differently if B was a template
 instead of a type.


Personally, it is important that I can parse it as a template or array. I 
prefer the !() syntax, it makes it incredibly easy to find creations of a 
template.
Oct 15 2008
parent reply "Bill Baxter" <wbaxter gmail.com> writes:
On Thu, Oct 16, 2008 at 12:24 AM, Jesse Phillips
<jessekphillips gmail.com> wrote:

 On Wed, 15 Oct 2008 11:24:46 +0100, Bruno Medeiros wrote:


 Jarrett Billingsley wrote:

 On Tue, Oct 14, 2008 at 6:43 PM, Bruno Medeiros
 <brunodomedeiros+spam com.gmail> wrote:

 Don wrote:

 Denis Koroskin wrote:

 On Wed, 08 Oct 2008 18:22:21 +0400, superdan <super dan.org> wrote:


 Walter Bright Wrote:


 Dee Girl wrote:

 I did not follow this group recent. School started. Sorry! I just
 see now and please add my vote if possible. I start with D recent
 and I remember beginning. foo!(bar) was not pleasant. Like forced
 convention with a bad char. And friends I show code never like
 it. It is first thing they say why they do not like D. For me
 foo{bar} better idea. Thank you, Dee Girl


 What do your friends think of { } ?


 School started. Every one so busy now. But I think does not matter
 any more ^_^

 I want to make little idea. Sorry if idea mentioned before (I did
 not read every thread). I think we can look square brackets []. Let
 me explain why.

 Paren () is over used in C and in D. Any expression can be in ().
 And adding () is possible in many cases. But it is not same with
 []. For example a:(b) is ambiguous but a:[b] is not. So there are
 many signs possible after symbol and before [. They are:






 Not all of them work. Here's a few examples:

    enum { d= 3, e = 7 }
    int [] a=[1,2];
    bool c;
    auto k=[e]; // kills =
    a ~= c?[d]:[e]; // kills ?
    int [] f = c?k:[e]; // kills :
    if (f>[e]) {}   // kills <
    if (f<[e]) {}   // kills >
    auto g = (k,[d]); // kills comma
    auto h = k~[d]; // kills ~

 Array ops will kill + - * / & | % ^



 Hum, what about brackets without any prefix character at all?

  Vector[int, 2] foo;
  List[Vector[int, 2]] bar;
  int[3] a = [1, 2, 3]; // array literal here int[int] map;
  alias DenseMatrix[num] PulType;
  alias SparseRowsMatrix[num, HashSparseVector] PuuType; alias
  BiMap[uint, Tuple[uint, uint], BiMapOptions.lhDense] DicType; int var
  = a[2]; // array indexing here

 Hum... doesn't look bad visually. In fact it seems to fit quite nice
 with how associative arrays, and even normal arrays, are declared.
 Hum, yes, I'm personally liking this a lot.

 But does it have any ambiguities? Hum, can't think of any off-hand. If
 an identifier appears before a bracket list, it could either be a
 template instantiation, or an array indexation. But the syntax of both
 is the same, so it doesn't need to be distinguished in the parser.

 Waddya think, was this discussed before?


 Erm,

 SomeClass[3] a; // template or array?


 What about it? It doesn't matter for the parser to know if SomeClass is
 a template or array, it can just keep parsing. Its not like the "class A
 : B { }" where parsing would continue differently if B was a template
 instead of a type.


 Personally, it is important that I can parse it as a template or array. I
 prefer the !() syntax, it makes it incredibly easy to find creations of a
 template.


I think you may be right.  If nothing technical against it emerges,
the human will likely be the weak link here.

More than SomeClass[3], this is the case that worries me:

   Identifier1[Identifier2]  x;

is it an AA or a templated type?

--bb
Oct 15 2008
next sibling parent reply Yigal Chripun <yigal100 gmail.com> writes:
Bill Baxter wrote:

 On Thu, Oct 16, 2008 at 12:24 AM, Jesse Phillips
 <jessekphillips gmail.com> wrote:

 On Wed, 15 Oct 2008 11:24:46 +0100, Bruno Medeiros wrote:


 Jarrett Billingsley wrote:

 On Tue, Oct 14, 2008 at 6:43 PM, Bruno Medeiros
 <brunodomedeiros+spam com.gmail> wrote:

 Don wrote:

 Denis Koroskin wrote:

 On Wed, 08 Oct 2008 18:22:21 +0400, superdan <super dan.org> wrote:


 Walter Bright Wrote:


 Dee Girl wrote:

 I did not follow this group recent. School started. Sorry! I just
 see now and please add my vote if possible. I start with D recent
 and I remember beginning. foo!(bar) was not pleasant. Like forced
 convention with a bad char. And friends I show code never like
 it. It is first thing they say why they do not like D. For me
 foo{bar} better idea. Thank you, Dee Girl


 What do your friends think of { } ?


 School started. Every one so busy now. But I think does not matter
 any more ^_^

 I want to make little idea. Sorry if idea mentioned before (I did
 not read every thread). I think we can look square brackets []. Let
 me explain why.

 Paren () is over used in C and in D. Any expression can be in ().
 And adding () is possible in many cases. But it is not same with
 []. For example a:(b) is ambiguous but a:[b] is not. So there are
 many signs possible after symbol and before [. They are:






 Not all of them work. Here's a few examples:

    enum { d= 3, e = 7 }
    int [] a=[1,2];
    bool c;
    auto k=[e]; // kills =
    a ~= c?[d]:[e]; // kills ?
    int [] f = c?k:[e]; // kills :
    if (f>[e]) {}   // kills <
    if (f<[e]) {}   // kills >
    auto g = (k,[d]); // kills comma
    auto h = k~[d]; // kills ~

 Array ops will kill + - * / & | % ^



 Hum, what about brackets without any prefix character at all?

  Vector[int, 2] foo;
  List[Vector[int, 2]] bar;
  int[3] a = [1, 2, 3]; // array literal here int[int] map;
  alias DenseMatrix[num] PulType;
  alias SparseRowsMatrix[num, HashSparseVector] PuuType; alias
  BiMap[uint, Tuple[uint, uint], BiMapOptions.lhDense] DicType; int var
  = a[2]; // array indexing here

 Hum... doesn't look bad visually. In fact it seems to fit quite nice
 with how associative arrays, and even normal arrays, are declared.
 Hum, yes, I'm personally liking this a lot.

 But does it have any ambiguities? Hum, can't think of any off-hand. If
 an identifier appears before a bracket list, it could either be a
 template instantiation, or an array indexation. But the syntax of both
 is the same, so it doesn't need to be distinguished in the parser.

 Waddya think, was this discussed before?


 Erm,

 SomeClass[3] a; // template or array?


 What about it? It doesn't matter for the parser to know if SomeClass is
 a template or array, it can just keep parsing. Its not like the "class A
 : B { }" where parsing would continue differently if B was a template
 instead of a type.


 Personally, it is important that I can parse it as a template or array. I
 prefer the !() syntax, it makes it incredibly easy to find creations of a
 template.


 
 I think you may be right.  If nothing technical against it emerges,
 the human will likely be the weak link here.
 
 More than SomeClass[3], this is the case that worries me:
 
    Identifier1[Identifier2]  x;
 
 is it an AA or a templated type?
 
 --bb


perhaps this will allow to remove AAs and arrays from the core language
and put them in the stdlib instead.
besides,there were discussions of separating arrays who own memory from
slices that don't.
Oct 15 2008
parent "Bill Baxter" <wbaxter gmail.com> writes:
On Thu, Oct 16, 2008 at 7:10 AM, Yigal Chripun <yigal100 gmail.com> wrote:


 I think you may be right.  If nothing technical against it emerges,
 the human will likely be the weak link here.

 More than SomeClass[3], this is the case that worries me:

    Identifier1[Identifier2]  x;

 is it an AA or a templated type?

 --bb


 perhaps this will allow to remove AAs and arrays from the core language
 and put them in the stdlib instead.
 besides,there were discussions of separating arrays who own memory from
 slices that don't.


You'd probably lose compile time AAs then.  And AA literals.  Not sure
how well either of those actually works right now though...  AA
literals at least are pretty limited.  Anyone know if AAs work in CTFE
right now?

--bb
Oct 15 2008
prev sibling parent reply Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
Bill Baxter wrote:

 On Thu, Oct 16, 2008 at 12:24 AM, Jesse Phillips
 <jessekphillips gmail.com> wrote:

 On Wed, 15 Oct 2008 11:24:46 +0100, Bruno Medeiros wrote:


 Jarrett Billingsley wrote:

 On Tue, Oct 14, 2008 at 6:43 PM, Bruno Medeiros
 <brunodomedeiros+spam com.gmail> wrote:

 Don wrote:

 Denis Koroskin wrote:

 On Wed, 08 Oct 2008 18:22:21 +0400, superdan <super dan.org> wrote:


 Walter Bright Wrote:


 Dee Girl wrote:

 I did not follow this group recent. School started. Sorry! I just
 see now and please add my vote if possible. I start with D recent
 and I remember beginning. foo!(bar) was not pleasant. Like forced
 convention with a bad char. And friends I show code never like
 it. It is first thing they say why they do not like D. For me
 foo{bar} better idea. Thank you, Dee Girl


 What do your friends think of { } ?


 School started. Every one so busy now. But I think does not matter
 any more ^_^

 I want to make little idea. Sorry if idea mentioned before (I did
 not read every thread). I think we can look square brackets []. Let
 me explain why.

 Paren () is over used in C and in D. Any expression can be in ().
 And adding () is possible in many cases. But it is not same with
 []. For example a:(b) is ambiguous but a:[b] is not. So there are
 many signs possible after symbol and before [. They are:






 Not all of them work. Here's a few examples:

    enum { d= 3, e = 7 }
    int [] a=[1,2];
    bool c;
    auto k=[e]; // kills =
    a ~= c?[d]:[e]; // kills ?
    int [] f = c?k:[e]; // kills :
    if (f>[e]) {}   // kills <
    if (f<[e]) {}   // kills >
    auto g = (k,[d]); // kills comma
    auto h = k~[d]; // kills ~

 Array ops will kill + - * / & | % ^



 Hum, what about brackets without any prefix character at all?

  Vector[int, 2] foo;
  List[Vector[int, 2]] bar;
  int[3] a = [1, 2, 3]; // array literal here int[int] map;
  alias DenseMatrix[num] PulType;
  alias SparseRowsMatrix[num, HashSparseVector] PuuType; alias
  BiMap[uint, Tuple[uint, uint], BiMapOptions.lhDense] DicType; int var
  = a[2]; // array indexing here

 Hum... doesn't look bad visually. In fact it seems to fit quite nice
 with how associative arrays, and even normal arrays, are declared.
 Hum, yes, I'm personally liking this a lot.

 But does it have any ambiguities? Hum, can't think of any off-hand. If
 an identifier appears before a bracket list, it could either be a
 template instantiation, or an array indexation. But the syntax of both
 is the same, so it doesn't need to be distinguished in the parser.

 Waddya think, was this discussed before?


 Erm,

 SomeClass[3] a; // template or array?


 What about it? It doesn't matter for the parser to know if SomeClass is
 a template or array, it can just keep parsing. Its not like the "class A
 : B { }" where parsing would continue differently if B was a template
 instead of a type.


 Personally, it is important that I can parse it as a template or array. I
 prefer the !() syntax, it makes it incredibly easy to find creations of a
 template.


 
 I think you may be right.  If nothing technical against it emerges,
 the human will likely be the weak link here.
 
 More than SomeClass[3], this is the case that worries me:
 
    Identifier1[Identifier2]  x;
 
 is it an AA or a templated type?
 
 --bb


True, you'd have to follow Identifier1 to find out. But that is just a 
hover of the mouse away. :)

-- 
Bruno Medeiros - Software Developer, MSc. in CS/E graduate
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
Oct 17 2008
parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
"Bruno Medeiros" wrote

 Bill Baxter wrote:

 On Thu, Oct 16, 2008 at 12:24 AM, Jesse Phillips
 <jessekphillips gmail.com> wrote:

 On Wed, 15 Oct 2008 11:24:46 +0100, Bruno Medeiros wrote:


 Jarrett Billingsley wrote:

 On Tue, Oct 14, 2008 at 6:43 PM, Bruno Medeiros
 <brunodomedeiros+spam com.gmail> wrote:

 Don wrote:

 Denis Koroskin wrote:

 On Wed, 08 Oct 2008 18:22:21 +0400, superdan <super dan.org> wrote:


 Walter Bright Wrote:


 Dee Girl wrote:

 I did not follow this group recent. School started. Sorry! I 
 just
 see now and please add my vote if possible. I start with D 
 recent
 and I remember beginning. foo!(bar) was not pleasant. Like 
 forced
 convention with a bad char. And friends I show code never like
 it. It is first thing they say why they do not like D. For me
 foo{bar} better idea. Thank you, Dee Girl


 What do your friends think of { } ?


 School started. Every one so busy now. But I think does not matter
 any more ^_^

 I want to make little idea. Sorry if idea mentioned before (I did
 not read every thread). I think we can look square brackets []. 
 Let
 me explain why.

 Paren () is over used in C and in D. Any expression can be in ().
 And adding () is possible in many cases. But it is not same with
 []. For example a:(b) is ambiguous but a:[b] is not. So there are
 many signs possible after symbol and before [. They are:






 Not all of them work. Here's a few examples:

    enum { d= 3, e = 7 }
    int [] a=[1,2];
    bool c;
    auto k=[e]; // kills =
    a ~= c?[d]:[e]; // kills ?
    int [] f = c?k:[e]; // kills :
    if (f>[e]) {}   // kills <
    if (f<[e]) {}   // kills >
    auto g = (k,[d]); // kills comma
    auto h = k~[d]; // kills ~

 Array ops will kill + - * / & | % ^



 Hum, what about brackets without any prefix character at all?

  Vector[int, 2] foo;
  List[Vector[int, 2]] bar;
  int[3] a = [1, 2, 3]; // array literal here int[int] map;
  alias DenseMatrix[num] PulType;
  alias SparseRowsMatrix[num, HashSparseVector] PuuType; alias
  BiMap[uint, Tuple[uint, uint], BiMapOptions.lhDense] DicType; int 
 var
  = a[2]; // array indexing here

 Hum... doesn't look bad visually. In fact it seems to fit quite nice
 with how associative arrays, and even normal arrays, are declared.
 Hum, yes, I'm personally liking this a lot.

 But does it have any ambiguities? Hum, can't think of any off-hand. 
 If
 an identifier appears before a bracket list, it could either be a
 template instantiation, or an array indexation. But the syntax of 
 both
 is the same, so it doesn't need to be distinguished in the parser.

 Waddya think, was this discussed before?


 Erm,

 SomeClass[3] a; // template or array?


 What about it? It doesn't matter for the parser to know if SomeClass is
 a template or array, it can just keep parsing. Its not like the "class 
 A
 : B { }" where parsing would continue differently if B was a template
 instead of a type.


 Personally, it is important that I can parse it as a template or array. 
 I
 prefer the !() syntax, it makes it incredibly easy to find creations of 
 a
 template.


 I think you may be right.  If nothing technical against it emerges,
 the human will likely be the weak link here.

 More than SomeClass[3], this is the case that worries me:

    Identifier1[Identifier2]  x;

 is it an AA or a templated type?

 --bb


 True, you'd have to follow Identifier1 to find out. But that is just a 
 hover of the mouse away. :)


Funny, when I hover my mouse over my ssh terminal into the Linux box I'm 
developing on, nothing comes up ;)

Even with a real IDE, if you have 10 declarations like this on the same 
page, you will need 10 mice to hover over all of them to understand the 
relationships ;)

I think this is really a deal killer for the bracket syntax.  Especially 
since what we have already works so well.  Note that Identifier2 is going to 
be a non-templated type regardless of whether you are declaring an AA or a 
template instance, which makes it even more ambiguous.

I can also see cases where someone thinks they are creating a template 
instance, but didn't use the right template identifier, so then the compiler 
now compiles the code as if they declared an AA.  I think Walter wrote an 
article about things like this, something in response to people requesting 
that semicolons be optional.

-Steve
Oct 17 2008
parent reply Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
Steven Schveighoffer wrote:

 "Bruno Medeiros" wrote

 Bill Baxter wrote:

 On Thu, Oct 16, 2008 at 12:24 AM, Jesse Phillips
 <jessekphillips gmail.com> wrote:

 On Wed, 15 Oct 2008 11:24:46 +0100, Bruno Medeiros wrote:


 Jarrett Billingsley wrote:

 On Tue, Oct 14, 2008 at 6:43 PM, Bruno Medeiros
 <brunodomedeiros+spam com.gmail> wrote:

 Don wrote:

 Denis Koroskin wrote:

 On Wed, 08 Oct 2008 18:22:21 +0400, superdan <super dan.org> wrote:


 Walter Bright Wrote:


 Dee Girl wrote:

 I did not follow this group recent. School started. Sorry! I 
 just
 see now and please add my vote if possible. I start with D 
 recent
 and I remember beginning. foo!(bar) was not pleasant. Like 
 forced
 convention with a bad char. And friends I show code never like
 it. It is first thing they say why they do not like D. For me
 foo{bar} better idea. Thank you, Dee Girl


 What do your friends think of { } ?


 School started. Every one so busy now. But I think does not matter
 any more ^_^

 I want to make little idea. Sorry if idea mentioned before (I did
 not read every thread). I think we can look square brackets []. 
 Let
 me explain why.

 Paren () is over used in C and in D. Any expression can be in ().
 And adding () is possible in many cases. But it is not same with
 []. For example a:(b) is ambiguous but a:[b] is not. So there are
 many signs possible after symbol and before [. They are:






 Not all of them work. Here's a few examples:

    enum { d= 3, e = 7 }
    int [] a=[1,2];
    bool c;
    auto k=[e]; // kills =
    a ~= c?[d]:[e]; // kills ?
    int [] f = c?k:[e]; // kills :
    if (f>[e]) {}   // kills <
    if (f<[e]) {}   // kills >
    auto g = (k,[d]); // kills comma
    auto h = k~[d]; // kills ~

 Array ops will kill + - * / & | % ^



 Hum, what about brackets without any prefix character at all?

  Vector[int, 2] foo;
  List[Vector[int, 2]] bar;
  int[3] a = [1, 2, 3]; // array literal here int[int] map;
  alias DenseMatrix[num] PulType;
  alias SparseRowsMatrix[num, HashSparseVector] PuuType; alias
  BiMap[uint, Tuple[uint, uint], BiMapOptions.lhDense] DicType; int 
 var
  = a[2]; // array indexing here

 Hum... doesn't look bad visually. In fact it seems to fit quite nice
 with how associative arrays, and even normal arrays, are declared.
 Hum, yes, I'm personally liking this a lot.

 But does it have any ambiguities? Hum, can't think of any off-hand. 
 If
 an identifier appears before a bracket list, it could either be a
 template instantiation, or an array indexation. But the syntax of 
 both
 is the same, so it doesn't need to be distinguished in the parser.

 Waddya think, was this discussed before?


 Erm,

 SomeClass[3] a; // template or array?


 What about it? It doesn't matter for the parser to know if SomeClass is
 a template or array, it can just keep parsing. Its not like the "class 
 A
 : B { }" where parsing would continue differently if B was a template
 instead of a type.


 Personally, it is important that I can parse it as a template or array. 
 I
 prefer the !() syntax, it makes it incredibly easy to find creations of 
 a
 template.


 I think you may be right.  If nothing technical against it emerges,
 the human will likely be the weak link here.

 More than SomeClass[3], this is the case that worries me:

    Identifier1[Identifier2]  x;

 is it an AA or a templated type?

 --bb


 True, you'd have to follow Identifier1 to find out. But that is just a 
 hover of the mouse away. :)


 
 Funny, when I hover my mouse over my ssh terminal into the Linux box I'm 
 developing on, nothing comes up ;)
 
 Even with a real IDE, if you have 10 declarations like this on the same 
 page, you will need 10 mice to hover over all of them to understand the 
 relationships ;)
 


It seems unlikely to have 10 declarations that have the same syntax so 
as to be confused with arrays. But I see your point.
I think an IDE can help further by using (semantic) highlighting: have 
the brackets for template instantiations highlighted differently, for 
example, in bold. It's not too difficult to implement, technically. (and 
it might be useful even for other template syntaxes, like the current !() )


 I think this is really a deal killer for the bracket syntax.  Especially 
 since what we have already works so well.  Note that Identifier2 is going to 
 be a non-templated type regardless of whether you are declaring an AA or a 
 template instance, which makes it even more ambiguous.
 
 I can also see cases where someone thinks they are creating a template 
 instance, but didn't use the right template identifier, so then the compiler 
 now compiles the code as if they declared an AA.  I think Walter wrote an 
 article about things like this, something in response to people requesting 
 that semicolons be optional.
 
 -Steve 
 
 


Eh, that could happen in a myriad of other situations. For example using 
one AA type instead of another type. But I don't think it's much 
significant, as the error will trivially be caught in most situations at 
compile time, when you try to use the type.

-- 
Bruno Medeiros - Software Developer, MSc. in CS/E graduate
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
Oct 18 2008
parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
"Bruno Medeiros" wrote

 Steven Schveighoffer wrote:

 Funny, when I hover my mouse over my ssh terminal into the Linux box I'm 
 developing on, nothing comes up ;)

 Even with a real IDE, if you have 10 declarations like this on the same 
 page, you will need 10 mice to hover over all of them to understand the 
 relationships ;)


 It seems unlikely to have 10 declarations that have the same syntax so as 
 to be confused with arrays. But I see your point.
 I think an IDE can help further by using (semantic) highlighting: have the 
 brackets for template instantiations highlighted differently, for example, 
 in bold. It's not too difficult to implement, technically. (and it might 
 be useful even for other template syntaxes, like the current !() )


This would never happen in my editor (vim), as it does not to semantic 
processing.  So I would be forced to get an IDE to work (which I have tried 
several now without success).

But the point behind all this is, if it takes a compiler (or at least a 
semantic processor) to figure out what the code means, what about the lowly 
code reviewer?  I don't see how this syntax is so much better than !() that 
we should make the language super-difficult for humans to understand without 
computer help...


 I think this is really a deal killer for the bracket syntax.  Especially 
 since what we have already works so well.  Note that Identifier2 is going 
 to be a non-templated type regardless of whether you are declaring an AA 
 or a template instance, which makes it even more ambiguous.

 I can also see cases where someone thinks they are creating a template 
 instance, but didn't use the right template identifier, so then the 
 compiler now compiles the code as if they declared an AA.  I think Walter 
 wrote an article about things like this, something in response to people 
 requesting that semicolons be optional.


 Eh, that could happen in a myriad of other situations. For example using 
 one AA type instead of another type. But I don't think it's much 
 significant, as the error will trivially be caught in most situations at 
 compile time, when you try to use the type.


Yes, but using the wrong type in an AA still gives you an AA.  If brackets 
are overloaded for templates, it might give you something completely 
different.  You would get confusing mesages like:

X[Y] x;

x[Y(55)] = new X(3);

error: cannot find opIndex for type X[Y]

huh??

This second level of symptom would be tough to trace back to the root 
problem.  This is why it is good to have syntax constructs have a large 
hamming distance.

While the bracket syntax is attractive, it's too close to array 
declarations.  I know Andrei has proposed declaring builtin arrays as 
Array!(X) (or in this case it would be Array[X]), but I hope that never 
happens, the current syntax for arrays is perfect, and I hope Walter agrees 
with that...

-Steve
Oct 20 2008
next sibling parent reply Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
Steven Schveighoffer wrote:

 "Bruno Medeiros" wrote

 Steven Schveighoffer wrote:

 Funny, when I hover my mouse over my ssh terminal into the Linux box I'm 
 developing on, nothing comes up ;)

 Even with a real IDE, if you have 10 declarations like this on the same 
 page, you will need 10 mice to hover over all of them to understand the 
 relationships ;)


 It seems unlikely to have 10 declarations that have the same syntax so as 
 to be confused with arrays. But I see your point.
 I think an IDE can help further by using (semantic) highlighting: have the 
 brackets for template instantiations highlighted differently, for example, 
 in bold. It's not too difficult to implement, technically. (and it might 
 be useful even for other template syntaxes, like the current !() )


 
 This would never happen in my editor (vim), as it does not to semantic 
 processing.  So I would be forced to get an IDE to work (which I have tried 
 several now without success).
 
 But the point behind all this is, if it takes a compiler (or at least a 
 semantic processor) to figure out what the code means, what about the lowly 
 code reviewer?  I don't see how this syntax is so much better than !() that 
 we should make the language super-difficult for humans to understand without 
 computer help...
 


Everything else we do with the language requires computer help: 
compiling, running, debugging, etc.. I don't see why editing should be 
any different. Why shouldn't a programming language have in 
consideration the potential productivity enhancements that tools can bring?


 I think this is really a deal killer for the bracket syntax.  Especially 
 since what we have already works so well.  Note that Identifier2 is going 
 to be a non-templated type regardless of whether you are declaring an AA 
 or a template instance, which makes it even more ambiguous.

 I can also see cases where someone thinks they are creating a template 
 instance, but didn't use the right template identifier, so then the 
 compiler now compiles the code as if they declared an AA.  I think Walter 
 wrote an article about things like this, something in response to people 
 requesting that semicolons be optional.


 Eh, that could happen in a myriad of other situations. For example using 
 one AA type instead of another type. But I don't think it's much 
 significant, as the error will trivially be caught in most situations at 
 compile time, when you try to use the type.


 
 Yes, but using the wrong type in an AA still gives you an AA.  If brackets 
 are overloaded for templates, it might give you something completely 
 different.  You would get confusing mesages like:
 
 X[Y] x;
 
 x[Y(55)] = new X(3);
 
 error: cannot find opIndex for type X[Y]
 
 huh??
 
 This second level of symptom would be tough to trace back to the root 
 problem.  This is why it is good to have syntax constructs have a large 
 hamming distance.
 


I disagree. I find that most, in not all, of compile errors are very 
easy to solve, very much more so that the runtime ones. Although in the 
particular case of DMD, some error messages are somewhat obscure or 
lacking in info, but that is more of a compiler issue than a language one.


-- 
Bruno Medeiros - Software Developer, MSc. in CS/E graduate
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
Oct 21 2008
parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
"Bruno Medeiros" wrote

 Steven Schveighoffer wrote:

 This would never happen in my editor (vim), as it does not to semantic 
 processing.  So I would be forced to get an IDE to work (which I have 
 tried several now without success).

 But the point behind all this is, if it takes a compiler (or at least a 
 semantic processor) to figure out what the code means, what about the 
 lowly code reviewer?  I don't see how this syntax is so much better than 
 !() that we should make the language super-difficult for humans to 
 understand without computer help...


 Everything else we do with the language requires computer help: compiling, 
 running, debugging, etc.. I don't see why editing should be any different. 
 Why shouldn't a programming language have in consideration the potential 
 productivity enhancements that tools can bring?


I require a computer to write code already.  I just don't want to have to 
use an IDE to *read* code.

If someone pastes a snippit of code in the NG, for example, I don't want to 
have to fire up an IDE to copy-paste the code, just to understand what it 
means.

This all would be a worthwhile discussion if we didn't already have a really 
good syntax to denote template instantiation which is already implemented, 
is unambiguous, easy to identify, and has no inherent parsing problems. 
Since the bracket syntax does not have some of those features, and it 
functionally adds nothing new, I think the current syntax wins.


 Yes, but using the wrong type in an AA still gives you an AA.  If 
 brackets are overloaded for templates, it might give you something 
 completely different.  You would get confusing mesages like:

 X[Y] x;

 x[Y(55)] = new X(3);

 error: cannot find opIndex for type X[Y]

 huh??

 This second level of symptom would be tough to trace back to the root 
 problem.  This is why it is good to have syntax constructs have a large 
 hamming distance.


 I disagree. I find that most, in not all, of compile errors are very easy 
 to solve, very much more so that the runtime ones. Although in the 
 particular case of DMD, some error messages are somewhat obscure or 
 lacking in info, but that is more of a compiler issue than a language one.


Yes, this would be a case of *not* easy to solve.  We have lots of these 
already, but I don't want to add more.

The point of large hamming distance between syntax is to make it difficult 
to accidentally write compilable code when you didn't mean to.  This is one 
of those cases.

For example, the following doesn't compile:

int i;
for(i = 0; i < 100; i++);
  writeln("%s", i);

Because the compiler is making it difficult for you to screw up.  I'm saying 
that !() has an advantage over the [] syntax because it is more difficult to 
screw up and write something you didn't mean.  The result of which is going 
to be an error not where you expect it, i.e. hard to track down.

-Steve
Oct 21 2008
parent Robert Fraser <fraserofthenight gmail.com> writes:
Steven Schveighoffer wrote:

 For example, the following doesn't compile:
 
 int i;
 for(i = 0; i < 100; i++);
   writeln("%s", i);


That has to be one of my top 5 D features. I can't tell you how many 
times that's bit me in the ass in other languages and the first time I 
ran into it in D and saw it was a compile error was magical.
Oct 21 2008
prev sibling parent reply Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
Steven Schveighoffer wrote:

 So I would be forced to get an IDE to work (which I have tried 
 several now without success).
 


Also what IDEs did you try, and what problems exactly did you encounter? 
Did you try any of the Eclipse ones, Descent or Mmrnmhrm?

-- 
Bruno Medeiros - Software Developer, MSc. in CS/E graduate
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
Oct 21 2008
parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
"Bruno Medeiros" wrote

 Steven Schveighoffer wrote:

 So I would be forced to get an IDE to work (which I have tried several 
 now without success).


 Also what IDEs did you try, and what problems exactly did you encounter? 
 Did you try any of the Eclipse ones, Descent or Mmrnmhrm?


I tried Descent and Code::Blocks.

I wanted something to try and debug programs.  But I couldn't get either of 
them to hook to dmd for compiling projects.  Descent actually has you 
configure a compiler, and can run a compilation which does absolutely 
nothing.  I found out later that it only uses the configuration from the 
compiler, it doesn't actually *use* the compiler.

Code::Blocks simply didn't work.  I gave up after about 2 hours of fiddling.

-Steve
Oct 21 2008
parent reply Ary Borenszweig <ary esperanto.org.ar> writes:
Steven Schveighoffer wrote:

 "Bruno Medeiros" wrote

 Steven Schveighoffer wrote:

 So I would be forced to get an IDE to work (which I have tried several 
 now without success).


 Also what IDEs did you try, and what problems exactly did you encounter? 
 Did you try any of the Eclipse ones, Descent or Mmrnmhrm?


 
 I tried Descent and Code::Blocks.
 
 I wanted something to try and debug programs.  But I couldn't get either of 
 them to hook to dmd for compiling projects.  Descent actually has you 
 configure a compiler, and can run a compilation which does absolutely 
 nothing.  I found out later that it only uses the configuration from the 
 compiler, it doesn't actually *use* the compiler.


Did you try this:

http://www.dsource.org/projects/descent/wiki/CompilingPrograms

The compiler configuration will be gone soon, as it isn't used for 
anything. And compiler integration, hmmm... it's taking too long, and I 
guess it's because me and Robert are way too busy/lazy lately.

But if you compile programs like it is said there, the debugger 
integration works quite well.


 
 Code::Blocks simply didn't work.  I gave up after about 2 hours of fiddling.
 
 -Steve
Oct 21 2008
parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
"Ary Borenszweig" wrote

 Steven Schveighoffer wrote:

 "Bruno Medeiros" wrote

 Steven Schveighoffer wrote:

 So I would be forced to get an IDE to work (which I have tried several 
 now without success).


 Also what IDEs did you try, and what problems exactly did you encounter? 
 Did you try any of the Eclipse ones, Descent or Mmrnmhrm?


 I tried Descent and Code::Blocks.

 I wanted something to try and debug programs.  But I couldn't get either 
 of them to hook to dmd for compiling projects.  Descent actually has you 
 configure a compiler, and can run a compilation which does absolutely 
 nothing.  I found out later that it only uses the configuration from the 
 compiler, it doesn't actually *use* the compiler.


 Did you try this:

 http://www.dsource.org/projects/descent/wiki/CompilingPrograms


Yes.  I believe I did follow those directions, but the debugger 
automatically skipped through extern(C) functions, and since I was trying to 
debug the runtime, it wasn't useful.

But I don't think the files were being compiled correctly, as the debugger 
couldn't find the source for the library code anyways.

I'm not saying that Descent is bad, I'm just saying it's too rough at the 
moment for someone like me who doesn't have patience with IDEs ;)  I'm sure 
you'll get the kinks worked out someday.  The auto-completion is really 
cool, but not worth the effort for me.  Vim's working just fine for me right 
now.


 The compiler configuration will be gone soon, as it isn't used for 
 anything.


That is good, it was very confusing ;)


 And compiler integration, hmmm... it's taking too long, and I guess it's 
 because me and Robert are way too busy/lazy lately.


I understand that.


 But if you compile programs like it is said there, the debugger 
 integration works quite well.


Have you solved being able to debug extern(C) functions?  ddbg has no 
problem debugging them.

-Steve
Oct 21 2008
parent reply Ary Borenszweig <ary esperanto.org.ar> writes:
Steven Schveighoffer escribi:

 "Ary Borenszweig" wrote

 Steven Schveighoffer wrote:

 "Bruno Medeiros" wrote

 Steven Schveighoffer wrote:

 So I would be forced to get an IDE to work (which I have tried several 
 now without success).


 Also what IDEs did you try, and what problems exactly did you encounter? 
 Did you try any of the Eclipse ones, Descent or Mmrnmhrm?


 I tried Descent and Code::Blocks.

 I wanted something to try and debug programs.  But I couldn't get either 
 of them to hook to dmd for compiling projects.  Descent actually has you 
 configure a compiler, and can run a compilation which does absolutely 
 nothing.  I found out later that it only uses the configuration from the 
 compiler, it doesn't actually *use* the compiler.


 Did you try this:

 http://www.dsource.org/projects/descent/wiki/CompilingPrograms


 
 Yes.  I believe I did follow those directions, but the debugger 
 automatically skipped through extern(C) functions, and since I was trying to 
 debug the runtime, it wasn't useful.
 
 But I don't think the files were being compiled correctly, as the debugger 
 couldn't find the source for the library code anyways.
 
 I'm not saying that Descent is bad, I'm just saying it's too rough at the 
 moment for someone like me who doesn't have patience with IDEs ;)  I'm sure 
 you'll get the kinks worked out someday.  The auto-completion is really 
 cool, but not worth the effort for me.  Vim's working just fine for me right 
 now.


And what about Mmrnmhrm?


 

 The compiler configuration will be gone soon, as it isn't used for 
 anything.


 
 That is good, it was very confusing ;)
 

 And compiler integration, hmmm... it's taking too long, and I guess it's 
 because me and Robert are way too busy/lazy lately.


 
 I understand that.
 

 But if you compile programs like it is said there, the debugger 
 integration works quite well.


 
 Have you solved being able to debug extern(C) functions?  ddbg has no 
 problem debugging them.


Yeah, I didn't have time to see it...


 
 -Steve
Oct 21 2008
next sibling parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
"Ary Borenszweig" wrote

 Steven Schveighoffer escribi:

 "Ary Borenszweig" wrote

 Steven Schveighoffer wrote:

 "Bruno Medeiros" wrote

 Steven Schveighoffer wrote:

 So I would be forced to get an IDE to work (which I have tried 
 several now without success).


 Also what IDEs did you try, and what problems exactly did you 
 encounter? Did you try any of the Eclipse ones, Descent or Mmrnmhrm?


 I tried Descent and Code::Blocks.

 I wanted something to try and debug programs.  But I couldn't get 
 either of them to hook to dmd for compiling projects.  Descent actually 
 has you configure a compiler, and can run a compilation which does 
 absolutely nothing.  I found out later that it only uses the 
 configuration from the compiler, it doesn't actually *use* the 
 compiler.


 Did you try this:

 http://www.dsource.org/projects/descent/wiki/CompilingPrograms


 Yes.  I believe I did follow those directions, but the debugger 
 automatically skipped through extern(C) functions, and since I was trying 
 to debug the runtime, it wasn't useful.

 But I don't think the files were being compiled correctly, as the 
 debugger couldn't find the source for the library code anyways.

 I'm not saying that Descent is bad, I'm just saying it's too rough at the 
 moment for someone like me who doesn't have patience with IDEs ;)  I'm 
 sure you'll get the kinks worked out someday.  The auto-completion is 
 really cool, but not worth the effort for me.  Vim's working just fine 
 for me right now.


 And what about Mmrnmhrm?


To be absolutely honest, I didn't even know what that was before about 2 
weeks ago when someone mentioned it as an IDE.  I had seen people mention 
it, but never what it was.  The name is so offputting to me that I probably 
will never use it.  Call me petty if you wish, but that's just the way it is 
;)

-Steve
Oct 21 2008
parent reply Frank Benoit <keinfarbton googlemail.com> writes:
Steven Schveighoffer schrieb:

 To be absolutely honest, I didn't even know what that was before about 2 
 weeks ago when someone mentioned it as an IDE.  I had seen people mention 
 it, but never what it was.  The name is so offputting to me that I probably 
 will never use it.  Call me petty if you wish, but that's just the way it is 
 ;)
 
 -Steve 


I also heard that saying ppl in IRC. And I did also not try it.

The name is important. For that reason just LLVMDC was renamed to LDC.
It is important ppl can remember the name and can talk about it. Both
impossible with Mmrn......
A better name, a better Homepage and Screenshots can help a lot.
Oct 21 2008
next sibling parent bearophile <bearophileHUGS lycos.com> writes:
Frank Benoit:

 Both impossible with Mmrn......
 A better name, a better Homepage and Screenshots can help a lot.


What about this name: "UhmmmThisIsBetter" ? ;-)

(It reminds me of the kind of names used by planets in novels by Douglas Adams).

Bye,
bearophile
Oct 21 2008
prev sibling parent reply Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
Frank Benoit wrote:

 Steven Schveighoffer schrieb:

 To be absolutely honest, I didn't even know what that was before about 2 
 weeks ago when someone mentioned it as an IDE.  I had seen people mention 
 it, but never what it was.  The name is so offputting to me that I probably 
 will never use it.  Call me petty if you wish, but that's just the way it is 
 ;)

 -Steve 


 
 I also heard that saying ppl in IRC. And I did also not try it.
 
 The name is important. For that reason just LLVMDC was renamed to LDC.
 It is important ppl can remember the name and can talk about it. Both
 impossible with Mmrn......
 A better name, a better Homepage and Screenshots can help a lot.
 
 


I understand about the name, but what's the problem with Mmrnmhrm's 
current homepage and screenshots?

As for the name, it's a personal touch of geek humor and homage, but 
yeah, it's silly. (although, for those newcomers that don't know yet, I 
didn't make it up, the name comes from Star Control II and is 
pronunciable: 
http://svn.dsource.org/projects/descent/downloads/mmrnmhrm.wav )

But yeah, it's not adequate for a proper product, and I would think 
about changing it if I saw that I would have significant time in the 
future to continue developing Mmrnmhrm, but unfortunately that is not 
the case :( , as I'm going back to working full-time. Makes you wish you 
had that 20% time for personal projects like Google engineers have. ~_~'

Also, if Descent were to adopt DLTK, it would pretty much obsolete 
Mmrnmhrm... *wink* *wink* :)

-- 
Bruno Medeiros - Software Developer, MSc. in CS/E graduate
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
Oct 22 2008
parent reply Ary Borenszweig <ary esperanto.org.ar> writes:
Bruno Medeiros wrote:

 Frank Benoit wrote:

 Steven Schveighoffer schrieb:

 To be absolutely honest, I didn't even know what that was before 
 about 2 weeks ago when someone mentioned it as an IDE.  I had seen 
 people mention it, but never what it was.  The name is so offputting 
 to me that I probably will never use it.  Call me petty if you wish, 
 but that's just the way it is ;)

 -Steve 


 I also heard that saying ppl in IRC. And I did also not try it.

 The name is important. For that reason just LLVMDC was renamed to LDC.
 It is important ppl can remember the name and can talk about it. Both
 impossible with Mmrn......
 A better name, a better Homepage and Screenshots can help a lot.


 
 I understand about the name, but what's the problem with Mmrnmhrm's 
 current homepage and screenshots?
 
 As for the name, it's a personal touch of geek humor and homage, but 
 yeah, it's silly. (although, for those newcomers that don't know yet, I 
 didn't make it up, the name comes from Star Control II and is 
 pronunciable: 
 http://svn.dsource.org/projects/descent/downloads/mmrnmhrm.wav )
 
 But yeah, it's not adequate for a proper product, and I would think 
 about changing it if I saw that I would have significant time in the 
 future to continue developing Mmrnmhrm, but unfortunately that is not 
 the case :( , as I'm going back to working full-time. Makes you wish you 
 had that 20% time for personal projects like Google engineers have. ~_~'
 
 Also, if Descent were to adopt DLTK, it would pretty much obsolete 
 Mmrnmhrm... *wink* *wink* :)


I'd like to do that in the future, but I don't know if DLTK can provide 
all the features that Descent provides right now. It would really 
simplify the development process, adoption of new features right from 
DLTK, and will make it easy for newcomers help making Descent.

IMP is another possibility, but the same doubt remains...
Oct 22 2008
parent reply Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
Ary Borenszweig wrote:

 
 I'd like to do that in the future, but I don't know if DLTK can provide 
 all the features that Descent provides right now. It would really 
 simplify the development process, adoption of new features right from 
 DLTK, and will make it easy for newcomers help making Descent.
 
 IMP is another possibility, but the same doubt remains...


DTLK provides most features, but yes, there are some it doesn't. For 
example there is no contribution to the Project Explorer view at all. 
(you must use DLTK's Script Explorer view instead).
But I don't see that as much of problem, because you can keep using 
parts ported from JDT to add up to the base DLTK functionality (I did 
that sometimes in Mmrnmhrm - duplicating DLTK code to override the base 
functionality), so you don't have to drop all the JDT ported code.

As for the immediate benefits that such transition would bring to 
Descent, well it depends. I was meaning to ask, how much of the indexer 
did you port from JDT? Is it working well?


-- 
Bruno Medeiros - Software Developer, MSc. in CS/E graduate
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
Oct 22 2008
parent reply Ary Borenszweig <ary esperanto.org.ar> writes:
Bruno Medeiros wrote:

 Ary Borenszweig wrote:

 I'd like to do that in the future, but I don't know if DLTK can 
 provide all the features that Descent provides right now. It would 
 really simplify the development process, adoption of new features 
 right from DLTK, and will make it easy for newcomers help making Descent.

 IMP is another possibility, but the same doubt remains...


 
 DTLK provides most features, but yes, there are some it doesn't. For 
 example there is no contribution to the Project Explorer view at all. 
 (you must use DLTK's Script Explorer view instead).
 But I don't see that as much of problem, because you can keep using 
 parts ported from JDT to add up to the base DLTK functionality (I did 
 that sometimes in Mmrnmhrm - duplicating DLTK code to override the base 
 functionality), so you don't have to drop all the JDT ported code.
 
 As for the immediate benefits that such transition would bring to 
 Descent, well it depends. I was meaning to ask, how much of the indexer 
 did you port from JDT? Is it working well?


I didn't port any of it. Well, just the necessary stuff to get the Open 
Type dialog list all types, and to make top-level declarations searches. 
But nothing that is inside methods/functions is indexes, as far as I 
know. The search for top-level declarations is working well. It is not 
exposed to users, but it is used in autocompletion and in the Open Type 
dialog.
Oct 22 2008
parent reply Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
Ary Borenszweig wrote:

 Bruno Medeiros wrote:

 Ary Borenszweig wrote:

 I'd like to do that in the future, but I don't know if DLTK can 
 provide all the features that Descent provides right now. It would 
 really simplify the development process, adoption of new features 
 right from DLTK, and will make it easy for newcomers help making 
 Descent.

 IMP is another possibility, but the same doubt remains...


 DTLK provides most features, but yes, there are some it doesn't. For 
 example there is no contribution to the Project Explorer view at all. 
 (you must use DLTK's Script Explorer view instead).
 But I don't see that as much of problem, because you can keep using 
 parts ported from JDT to add up to the base DLTK functionality (I did 
 that sometimes in Mmrnmhrm - duplicating DLTK code to override the 
 base functionality), so you don't have to drop all the JDT ported code.

 As for the immediate benefits that such transition would bring to 
 Descent, well it depends. I was meaning to ask, how much of the 
 indexer did you port from JDT? Is it working well?


 
 I didn't port any of it. Well, just the necessary stuff to get the Open 
 Type dialog list all types, and to make top-level declarations searches. 
 But nothing that is inside methods/functions is indexes, as far as I 
 know. The search for top-level declarations is working well. It is not 
 exposed to users, but it is used in autocompletion and in the Open Type 
 dialog.


Hum, I see. I guess the advantage of porting to DLTK could be considered 
"moderate" then (namely the possible new features would be 
search-for-references, and type hierarchies, as there is in Mmrnmhrm now).
It would be interesting to try an experimental branch of Descent based 
on DLTK to actually see how it would work out. I myself would be 
interested in doing that, but again, unfortunately I won't have the time  :/

-- 
Bruno Medeiros - Software Developer, MSc. in CS/E graduate
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
Oct 24 2008
parent Ary Borenszweig <ary esperanto.org.ar> writes:
Bruno Medeiros wrote:

 Ary Borenszweig wrote:

 Bruno Medeiros wrote:

 Ary Borenszweig wrote:

 I'd like to do that in the future, but I don't know if DLTK can 
 provide all the features that Descent provides right now. It would 
 really simplify the development process, adoption of new features 
 right from DLTK, and will make it easy for newcomers help making 
 Descent.

 IMP is another possibility, but the same doubt remains...


 DTLK provides most features, but yes, there are some it doesn't. For 
 example there is no contribution to the Project Explorer view at all. 
 (you must use DLTK's Script Explorer view instead).
 But I don't see that as much of problem, because you can keep using 
 parts ported from JDT to add up to the base DLTK functionality (I did 
 that sometimes in Mmrnmhrm - duplicating DLTK code to override the 
 base functionality), so you don't have to drop all the JDT ported code.

 As for the immediate benefits that such transition would bring to 
 Descent, well it depends. I was meaning to ask, how much of the 
 indexer did you port from JDT? Is it working well?


 I didn't port any of it. Well, just the necessary stuff to get the 
 Open Type dialog list all types, and to make top-level declarations 
 searches. But nothing that is inside methods/functions is indexes, as 
 far as I know. The search for top-level declarations is working well. 
 It is not exposed to users, but it is used in autocompletion and in 
 the Open Type dialog.


 
 Hum, I see. I guess the advantage of porting to DLTK could be considered 
 "moderate" then (namely the possible new features would be 
 search-for-references, and type hierarchies, as there is in Mmrnmhrm now).
 It would be interesting to try an experimental branch of Descent based 
 on DLTK to actually see how it would work out. I myself would be 
 interested in doing that, but again, unfortunately I won't have the 
 time  :/


Yeah, I'd love that too, but I won't have time either... :/
Oct 24 2008
prev sibling parent Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
Ary Borenszweig wrote:

 Steven Schveighoffer escribi:

 "Ary Borenszweig" wrote

 Steven Schveighoffer wrote:

 "Bruno Medeiros" wrote

 Steven Schveighoffer wrote:

 So I would be forced to get an IDE to work (which I have tried 
 several now without success).


 Also what IDEs did you try, and what problems exactly did you 
 encounter? Did you try any of the Eclipse ones, Descent or Mmrnmhrm?


 I tried Descent and Code::Blocks.

 I wanted something to try and debug programs.  But I couldn't get 
 either of them to hook to dmd for compiling projects.  Descent 
 actually has you configure a compiler, and can run a compilation 
 which does absolutely nothing.  I found out later that it only uses 
 the configuration from the compiler, it doesn't actually *use* the 
 compiler.


 Did you try this:

 http://www.dsource.org/projects/descent/wiki/CompilingPrograms


 Yes.  I believe I did follow those directions, but the debugger 
 automatically skipped through extern(C) functions, and since I was 
 trying to debug the runtime, it wasn't useful.

 But I don't think the files were being compiled correctly, as the 
 debugger couldn't find the source for the library code anyways.

 I'm not saying that Descent is bad, I'm just saying it's too rough at 
 the moment for someone like me who doesn't have patience with IDEs ;)  
 I'm sure you'll get the kinks worked out someday.  The auto-completion 
 is really cool, but not worth the effort for me.  Vim's working just 
 fine for me right now.


 
 And what about Mmrnmhrm?
 


If it's because of debugging, it won't be much of a difference since 
Mmrnmhrm has no debugger itself, one should use Descent's debugger in 
tandem.
Mmrnmhrm's integrated builder might help, if that was part of the 
problem, but I don't see why using an Eclipse external configuration to 
build the project in Descent would not work as well (even if it's more 
worksome to configure and keep updated).

-- 
Bruno Medeiros - Software Developer, MSc. in CS/E graduate
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
Oct 22 2008
prev sibling next sibling parent KennyTM~ <kennytm gmail.com> writes:
Bruno Medeiros wrote:

 Don wrote:

 Denis Koroskin wrote:

 On Wed, 08 Oct 2008 18:22:21 +0400, superdan <super dan.org> wrote:


 Walter Bright Wrote:


 Dee Girl wrote:

 I did not follow this group recent. School started. Sorry! I just 


 see

 now and please add my vote if possible. I start with D recent and I
 remember beginning. foo!(bar) was not pleasant. Like forced
 convention with a bad char. And friends I show code never like 


 it. It

 is first thing they say why they do not like D. For me foo{bar}
 better idea. Thank you, Dee Girl


 What do your friends think of { } ?


 School started. Every one so busy now. But I think does not matter 
 any more ^_^

 I want to make little idea. Sorry if idea mentioned before (I did 
 not read every thread). I think we can look square brackets []. Let 
 me explain why.

 Paren () is over used in C and in D. Any expression can be in (). 
 And adding () is possible in many cases. But it is not same with []. 
 For example a:(b) is ambiguous but a:[b] is not. So there are many 
 signs possible after symbol and before [. They are:






 Not all of them work. Here's a few examples:

     enum { d= 3, e = 7 }
     int [] a=[1,2];
     bool c;
     auto k=[e]; // kills =
     a ~= c?[d]:[e]; // kills ?
     int [] f = c?k:[e]; // kills :
     if (f>[e]) {}   // kills <
     if (f<[e]) {}   // kills >
     auto g = (k,[d]); // kills comma
     auto h = k~[d]; // kills ~

 Array ops will kill + - * / & | % ^
 Suddenly the list looks pretty short.



 
 
 Hum, what about brackets without any prefix character at all?
 
   Vector[int, 2] foo;
   List[Vector[int, 2]] bar;
   int[3] a = [1, 2, 3]; // array literal here
   int[int] map;
   alias DenseMatrix[num] PulType;
   alias SparseRowsMatrix[num, HashSparseVector] PuuType;
   alias BiMap[uint, Tuple[uint, uint], BiMapOptions.lhDense] DicType;
   int var = a[2]; // array indexing here
 
 Hum... doesn't look bad visually. In fact it seems to fit quite nice 
 with how associative arrays, and even normal arrays, are declared. Hum, 
 yes, I'm personally liking this a lot.
 
 But does it have any ambiguities? Hum, can't think of any off-hand. If 
 an identifier appears before a bracket list, it could either be a 
 template instantiation, or an array indexation. But the syntax of both 
 is the same, so it doesn't need to be distinguished in the parser.
 
 Waddya think, was this discussed before?
 


I feel uncomfortable with this suggestion but I can't find where's 
breaking it yet <g>
Oct 15 2008
prev sibling parent reply Jason House <jason.james.house gmail.com> writes:
Bruno Medeiros wrote:


 Don wrote:

 Denis Koroskin wrote:

 On Wed, 08 Oct 2008 18:22:21 +0400, superdan <super dan.org> wrote:


 Walter Bright Wrote:


 Dee Girl wrote:

 I did not follow this group recent. School started. Sorry! I just
 see now and please add my vote if possible. I start with D recent
 and I remember beginning. foo!(bar) was not pleasant. Like forced
 convention with a bad char. And friends I show code never like it.
 It is first thing they say why they do not like D. For me foo{bar}
 better idea. Thank you, Dee Girl


 What do your friends think of { } ?


 School started. Every one so busy now. But I think does not matter
 any more ^_^

 I want to make little idea. Sorry if idea mentioned before (I did not
 read every thread). I think we can look square brackets []. Let me
 explain why.

 Paren () is over used in C and in D. Any expression can be in (). And
 adding () is possible in many cases. But it is not same with []. For
 example a:(b) is ambiguous but a:[b] is not. So there are many signs
 possible after symbol and before [. They are:






 
 Not all of them work. Here's a few examples:
 
     enum { d= 3, e = 7 }
     int [] a=[1,2];
     bool c;
     auto k=[e]; // kills =
     a ~= c?[d]:[e]; // kills ?
     int [] f = c?k:[e]; // kills :
     if (f>[e]) {}   // kills <
     if (f<[e]) {}   // kills >
     auto g = (k,[d]); // kills comma
     auto h = k~[d]; // kills ~
 
 Array ops will kill + - * / & | % ^
 Suddenly the list looks pretty short.



 
 
 Hum, what about brackets without any prefix character at all?
 
    Vector[int, 2] foo;
    List[Vector[int, 2]] bar;
    int[3] a = [1, 2, 3]; // array literal here
    int[int] map;
    alias DenseMatrix[num] PulType;
    alias SparseRowsMatrix[num, HashSparseVector] PuuType;
    alias BiMap[uint, Tuple[uint, uint], BiMapOptions.lhDense] DicType;
    int var = a[2]; // array indexing here
 
 Hum... doesn't look bad visually. In fact it seems to fit quite nice
 with how associative arrays, and even normal arrays, are declared. Hum,
 yes, I'm personally liking this a lot.
 
 But does it have any ambiguities? Hum, can't think of any off-hand. If
 an identifier appears before a bracket list, it could either be a
 template instantiation, or an array indexation. But the syntax of both
 is the same, so it doesn't need to be distinguished in the parser.
 
 Waddya think, was this discussed before?
 



It may be easy to parse, but it isn't easy to read.

What is goban[19]?  Is it an array or a template?  I'd hate to be reading
through somebody else's code and have to decipher what things mean.
Oct 15 2008
parent reply Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
Jason House wrote:

 Bruno Medeiros wrote:
 

 Don wrote:

 Denis Koroskin wrote:

 On Wed, 08 Oct 2008 18:22:21 +0400, superdan <super dan.org> wrote:


 Walter Bright Wrote:


 Dee Girl wrote:

 I did not follow this group recent. School started. Sorry! I just
 see now and please add my vote if possible. I start with D recent
 and I remember beginning. foo!(bar) was not pleasant. Like forced
 convention with a bad char. And friends I show code never like it.
 It is first thing they say why they do not like D. For me foo{bar}
 better idea. Thank you, Dee Girl


 What do your friends think of { } ?


 School started. Every one so busy now. But I think does not matter
 any more ^_^

 I want to make little idea. Sorry if idea mentioned before (I did not
 read every thread). I think we can look square brackets []. Let me
 explain why.

 Paren () is over used in C and in D. Any expression can be in (). And
 adding () is possible in many cases. But it is not same with []. For
 example a:(b) is ambiguous but a:[b] is not. So there are many signs
 possible after symbol and before [. They are:






 Not all of them work. Here's a few examples:

     enum { d= 3, e = 7 }
     int [] a=[1,2];
     bool c;
     auto k=[e]; // kills =
     a ~= c?[d]:[e]; // kills ?
     int [] f = c?k:[e]; // kills :
     if (f>[e]) {}   // kills <
     if (f<[e]) {}   // kills >
     auto g = (k,[d]); // kills comma
     auto h = k~[d]; // kills ~

 Array ops will kill + - * / & | % ^
 Suddenly the list looks pretty short.



 Hum, what about brackets without any prefix character at all?

    Vector[int, 2] foo;
    List[Vector[int, 2]] bar;
    int[3] a = [1, 2, 3]; // array literal here
    int[int] map;
    alias DenseMatrix[num] PulType;
    alias SparseRowsMatrix[num, HashSparseVector] PuuType;
    alias BiMap[uint, Tuple[uint, uint], BiMapOptions.lhDense] DicType;
    int var = a[2]; // array indexing here

 Hum... doesn't look bad visually. In fact it seems to fit quite nice
 with how associative arrays, and even normal arrays, are declared. Hum,
 yes, I'm personally liking this a lot.

 But does it have any ambiguities? Hum, can't think of any off-hand. If
 an identifier appears before a bracket list, it could either be a
 template instantiation, or an array indexation. But the syntax of both
 is the same, so it doesn't need to be distinguished in the parser.

 Waddya think, was this discussed before?


 
 
 It may be easy to parse, but it isn't easy to read.
 
 What is goban[19]?  Is it an array or a template?  I'd hate to be reading
 through somebody else's code and have to decipher what things mean.


I give the same answer I gave to Bill:

True, you'd have to follow /goban/ to find out. But that is just a hover 
of the mouse away. :)


Just for the record, I'm also not bothered by !(), but if some people 
really find the urge to change it, I'd much rather have brackets than 
the ugly sad pirate. I say ugly because the dot is much more common than 
the '!', and for me it has a more solidified meaning of accessing 
members, so seeing it used as part of the template instantiation syntax 
looks weird.

-- 
Bruno Medeiros - Software Developer, MSc. in CS/E graduate
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
Oct 17 2008
parent reply Don <nospam nospam.com.au> writes:
Bruno Medeiros wrote:

 Jason House wrote:

 Bruno Medeiros wrote:


 Don wrote:

 Denis Koroskin wrote:

 On Wed, 08 Oct 2008 18:22:21 +0400, superdan <super dan.org> wrote:


 Walter Bright Wrote:


 Dee Girl wrote:

 I did not follow this group recent. School started. Sorry! I just
 see now and please add my vote if possible. I start with D recent
 and I remember beginning. foo!(bar) was not pleasant. Like forced
 convention with a bad char. And friends I show code never like it.
 It is first thing they say why they do not like D. For me foo{bar}
 better idea. Thank you, Dee Girl


 What do your friends think of { } ?


 School started. Every one so busy now. But I think does not matter
 any more ^_^

 I want to make little idea. Sorry if idea mentioned before (I did not
 read every thread). I think we can look square brackets []. Let me
 explain why.

 Paren () is over used in C and in D. Any expression can be in (). And
 adding () is possible in many cases. But it is not same with []. For
 example a:(b) is ambiguous but a:[b] is not. So there are many signs
 possible after symbol and before [. They are:






 Not all of them work. Here's a few examples:

     enum { d= 3, e = 7 }
     int [] a=[1,2];
     bool c;
     auto k=[e]; // kills =
     a ~= c?[d]:[e]; // kills ?
     int [] f = c?k:[e]; // kills :
     if (f>[e]) {}   // kills <
     if (f<[e]) {}   // kills >
     auto g = (k,[d]); // kills comma
     auto h = k~[d]; // kills ~

 Array ops will kill + - * / & | % ^
 Suddenly the list looks pretty short.



 Hum, what about brackets without any prefix character at all?

    Vector[int, 2] foo;
    List[Vector[int, 2]] bar;
    int[3] a = [1, 2, 3]; // array literal here
    int[int] map;
    alias DenseMatrix[num] PulType;
    alias SparseRowsMatrix[num, HashSparseVector] PuuType;
    alias BiMap[uint, Tuple[uint, uint], BiMapOptions.lhDense] DicType;
    int var = a[2]; // array indexing here

 Hum... doesn't look bad visually. In fact it seems to fit quite nice
 with how associative arrays, and even normal arrays, are declared. Hum,
 yes, I'm personally liking this a lot.

 But does it have any ambiguities? Hum, can't think of any off-hand. If
 an identifier appears before a bracket list, it could either be a
 template instantiation, or an array indexation. But the syntax of both
 is the same, so it doesn't need to be distinguished in the parser.

 Waddya think, was this discussed before?



 It may be easy to parse, but it isn't easy to read.

 What is goban[19]?  Is it an array or a template?  I'd hate to be reading
 through somebody else's code and have to decipher what things mean.


 
 I give the same answer I gave to Bill:
 
 True, you'd have to follow /goban/ to find out. But that is just a hover 
 of the mouse away. :)
 
 
 Just for the record, I'm also not bothered by !(), but if some people 
 really find the urge to change it, I'd much rather have brackets than 
 the ugly sad pirate. I say ugly because the dot is much more common than 
 the '!', and for me it has a more solidified meaning of accessing 
 members, so seeing it used as part of the template instantiation syntax 
 looks weird.
 


That's my opinion, too.

Using square brackets would certainly fit with Walter's goal of making 
templates less threatening for newcomers.
It would be pretty cool to teach a newbie:

int[] a;
int[double] b;  // this is an AA
priorityqueue[double] c; // this is a template
Oct 17 2008
next sibling parent reply Robert Fraser <fraserofthenight gmail.com> writes:
Don wrote:

 Bruno Medeiros wrote:

 Jason House wrote:

 Bruno Medeiros wrote:


 Don wrote:

 Denis Koroskin wrote:

 On Wed, 08 Oct 2008 18:22:21 +0400, superdan <super dan.org> wrote:


 Walter Bright Wrote:


 Dee Girl wrote:

 I did not follow this group recent. School started. Sorry! I just
 see now and please add my vote if possible. I start with D recent
 and I remember beginning. foo!(bar) was not pleasant. Like forced
 convention with a bad char. And friends I show code never like it.
 It is first thing they say why they do not like D. For me foo{bar}
 better idea. Thank you, Dee Girl


 What do your friends think of { } ?


 School started. Every one so busy now. But I think does not matter
 any more ^_^

 I want to make little idea. Sorry if idea mentioned before (I did 
 not
 read every thread). I think we can look square brackets []. Let me
 explain why.

 Paren () is over used in C and in D. Any expression can be in (). 
 And
 adding () is possible in many cases. But it is not same with []. For
 example a:(b) is ambiguous but a:[b] is not. So there are many signs
 possible after symbol and before [. They are:






 Not all of them work. Here's a few examples:

     enum { d= 3, e = 7 }
     int [] a=[1,2];
     bool c;
     auto k=[e]; // kills =
     a ~= c?[d]:[e]; // kills ?
     int [] f = c?k:[e]; // kills :
     if (f>[e]) {}   // kills <
     if (f<[e]) {}   // kills >
     auto g = (k,[d]); // kills comma
     auto h = k~[d]; // kills ~

 Array ops will kill + - * / & | % ^
 Suddenly the list looks pretty short.



 Hum, what about brackets without any prefix character at all?

    Vector[int, 2] foo;
    List[Vector[int, 2]] bar;
    int[3] a = [1, 2, 3]; // array literal here
    int[int] map;
    alias DenseMatrix[num] PulType;
    alias SparseRowsMatrix[num, HashSparseVector] PuuType;
    alias BiMap[uint, Tuple[uint, uint], BiMapOptions.lhDense] DicType;
    int var = a[2]; // array indexing here

 Hum... doesn't look bad visually. In fact it seems to fit quite nice
 with how associative arrays, and even normal arrays, are declared. Hum,
 yes, I'm personally liking this a lot.

 But does it have any ambiguities? Hum, can't think of any off-hand. If
 an identifier appears before a bracket list, it could either be a
 template instantiation, or an array indexation. But the syntax of both
 is the same, so it doesn't need to be distinguished in the parser.

 Waddya think, was this discussed before?



 It may be easy to parse, but it isn't easy to read.

 What is goban[19]?  Is it an array or a template?  I'd hate to be 
 reading
 through somebody else's code and have to decipher what things mean.


 I give the same answer I gave to Bill:

 True, you'd have to follow /goban/ to find out. But that is just a 
 hover of the mouse away. :)


 Just for the record, I'm also not bothered by !(), but if some people 
 really find the urge to change it, I'd much rather have brackets than 
 the ugly sad pirate. I say ugly because the dot is much more common 
 than the '!', and for me it has a more solidified meaning of accessing 
 members, so seeing it used as part of the template instantiation 
 syntax looks weird.


 That's my opinion, too.
 
 Using square brackets would certainly fit with Walter's goal of making 
 templates less threatening for newcomers.
 It would be pretty cool to teach a newbie:
 
 int[] a;
 int[double] b;  // this is an AA
 priorityqueue[double] c; // this is a template


I can't tell if you're being sarcastic here or not...
Oct 17 2008
next sibling parent reply "Bill Baxter" <wbaxter gmail.com> writes:
On Sat, Oct 18, 2008 at 6:59 AM, Robert Fraser
<fraserofthenight gmail.com> wrote:

 Don wrote:

 Bruno Medeiros wrote:

 Jason House wrote:

 Bruno Medeiros wrote:


 Don wrote:

 Denis Koroskin wrote:

 On Wed, 08 Oct 2008 18:22:21 +0400, superdan <super dan.org> wrote:


 Walter Bright Wrote:


 Dee Girl wrote:

 I did not follow this group recent. School started. Sorry! I just
 see now and please add my vote if possible. I start with D recent
 and I remember beginning. foo!(bar) was not pleasant. Like forced
 convention with a bad char. And friends I show code never like it.
 It is first thing they say why they do not like D. For me foo{bar}
 better idea. Thank you, Dee Girl


 What do your friends think of { } ?


 School started. Every one so busy now. But I think does not matter
 any more ^_^

 I want to make little idea. Sorry if idea mentioned before (I did
 not
 read every thread). I think we can look square brackets []. Let me
 explain why.

 Paren () is over used in C and in D. Any expression can be in ().
 And
 adding () is possible in many cases. But it is not same with []. For
 example a:(b) is ambiguous but a:[b] is not. So there are many signs
 possible after symbol and before [. They are:






 Not all of them work. Here's a few examples:

    enum { d= 3, e = 7 }
    int [] a=[1,2];
    bool c;
    auto k=[e]; // kills =
    a ~= c?[d]:[e]; // kills ?
    int [] f = c?k:[e]; // kills :
    if (f>[e]) {}   // kills <
    if (f<[e]) {}   // kills >
    auto g = (k,[d]); // kills comma
    auto h = k~[d]; // kills ~

 Array ops will kill + - * / & | % ^
 Suddenly the list looks pretty short.



 Hum, what about brackets without any prefix character at all?

   Vector[int, 2] foo;
   List[Vector[int, 2]] bar;
   int[3] a = [1, 2, 3]; // array literal here
   int[int] map;
   alias DenseMatrix[num] PulType;
   alias SparseRowsMatrix[num, HashSparseVector] PuuType;
   alias BiMap[uint, Tuple[uint, uint], BiMapOptions.lhDense] DicType;
   int var = a[2]; // array indexing here

 Hum... doesn't look bad visually. In fact it seems to fit quite nice
 with how associative arrays, and even normal arrays, are declared. Hum,
 yes, I'm personally liking this a lot.

 But does it have any ambiguities? Hum, can't think of any off-hand. If
 an identifier appears before a bracket list, it could either be a
 template instantiation, or an array indexation. But the syntax of both
 is the same, so it doesn't need to be distinguished in the parser.

 Waddya think, was this discussed before?



 It may be easy to parse, but it isn't easy to read.

 What is goban[19]?  Is it an array or a template?  I'd hate to be
 reading
 through somebody else's code and have to decipher what things mean.


 I give the same answer I gave to Bill:

 True, you'd have to follow /goban/ to find out. But that is just a hover
 of the mouse away. :)


 Just for the record, I'm also not bothered by !(), but if some people
 really find the urge to change it, I'd much rather have brackets than the
 ugly sad pirate. I say ugly because the dot is much more common than the
 '!', and for me it has a more solidified meaning of accessing members, so
 seeing it used as part of the template instantiation syntax looks weird.


 That's my opinion, too.

 Using square brackets would certainly fit with Walter's goal of making
 templates less threatening for newcomers.
 It would be pretty cool to teach a newbie:

 int[] a;
 int[double] b;  // this is an AA
 priorityqueue[double] c; // this is a template


 I can't tell if you're being sarcastic here or not...


I couldn't tell either.  To me sounds about as cool as having to teach
C newbies about all the different meanings of "static".

--bb
Oct 17 2008
parent KennyTM~ <kennytm gmail.com> writes:
Bill Baxter wrote:

 On Sat, Oct 18, 2008 at 6:59 AM, Robert Fraser
 <fraserofthenight gmail.com> wrote:

 Don wrote:

 Bruno Medeiros wrote:

 Jason House wrote:

 Bruno Medeiros wrote:


 Don wrote:

 Denis Koroskin wrote:

 On Wed, 08 Oct 2008 18:22:21 +0400, superdan <super dan.org> wrote:


 Walter Bright Wrote:


 Dee Girl wrote:

 I did not follow this group recent. School started. Sorry! I just
 see now and please add my vote if possible. I start with D recent
 and I remember beginning. foo!(bar) was not pleasant. Like forced
 convention with a bad char. And friends I show code never like it.
 It is first thing they say why they do not like D. For me foo{bar}
 better idea. Thank you, Dee Girl


 What do your friends think of { } ?


 School started. Every one so busy now. But I think does not matter
 any more ^_^

 I want to make little idea. Sorry if idea mentioned before (I did
 not
 read every thread). I think we can look square brackets []. Let me
 explain why.

 Paren () is over used in C and in D. Any expression can be in ().
 And
 adding () is possible in many cases. But it is not same with []. For
 example a:(b) is ambiguous but a:[b] is not. So there are many signs
 possible after symbol and before [. They are:






 Not all of them work. Here's a few examples:

    enum { d= 3, e = 7 }
    int [] a=[1,2];
    bool c;
    auto k=[e]; // kills =
    a ~= c?[d]:[e]; // kills ?
    int [] f = c?k:[e]; // kills :
    if (f>[e]) {}   // kills <
    if (f<[e]) {}   // kills >
    auto g = (k,[d]); // kills comma
    auto h = k~[d]; // kills ~

 Array ops will kill + - * / & | % ^
 Suddenly the list looks pretty short.



 Hum, what about brackets without any prefix character at all?

   Vector[int, 2] foo;
   List[Vector[int, 2]] bar;
   int[3] a = [1, 2, 3]; // array literal here
   int[int] map;
   alias DenseMatrix[num] PulType;
   alias SparseRowsMatrix[num, HashSparseVector] PuuType;
   alias BiMap[uint, Tuple[uint, uint], BiMapOptions.lhDense] DicType;
   int var = a[2]; // array indexing here

 Hum... doesn't look bad visually. In fact it seems to fit quite nice
 with how associative arrays, and even normal arrays, are declared. Hum,
 yes, I'm personally liking this a lot.

 But does it have any ambiguities? Hum, can't think of any off-hand. If
 an identifier appears before a bracket list, it could either be a
 template instantiation, or an array indexation. But the syntax of both
 is the same, so it doesn't need to be distinguished in the parser.

 Waddya think, was this discussed before?


 It may be easy to parse, but it isn't easy to read.

 What is goban[19]?  Is it an array or a template?  I'd hate to be
 reading
 through somebody else's code and have to decipher what things mean.


 I give the same answer I gave to Bill:

 True, you'd have to follow /goban/ to find out. But that is just a hover
 of the mouse away. :)


 Just for the record, I'm also not bothered by !(), but if some people
 really find the urge to change it, I'd much rather have brackets than the
 ugly sad pirate. I say ugly because the dot is much more common than the
 '!', and for me it has a more solidified meaning of accessing members, so
 seeing it used as part of the template instantiation syntax looks weird.


 That's my opinion, too.

 Using square brackets would certainly fit with Walter's goal of making
 templates less threatening for newcomers.
 It would be pretty cool to teach a newbie:

 int[] a;
 int[double] b;  // this is an AA
 priorityqueue[double] c; // this is a template


 I can't tell if you're being sarcastic here or not...


 
 I couldn't tell either.  To me sounds about as cool as having to teach
 C newbies about all the different meanings of "static".
 
 --bb


See? The syntax is so confusing that not only array & templates but even 
sarcasm can't be differentiated :). [sarcasm]

Anyway I think it's no good to modify the !() syntax without 
backward-compatibility because it is rooted in almost all D code 
already; and if both [] & !() are allowed it would just cause more 
confusion, isn't it.

I think the opposition of !() is a by-product of .() being announced.

Let's move on to some real issue...
Oct 18 2008
prev sibling parent reply Don <nospam nospam.com.au> writes:
Robert Fraser wrote:

 Don wrote:

 Bruno Medeiros wrote:

 Jason House wrote:

 Bruno Medeiros wrote:


 Don wrote:

 Denis Koroskin wrote:

 On Wed, 08 Oct 2008 18:22:21 +0400, superdan <super dan.org> wrote:


 Walter Bright Wrote:


 Dee Girl wrote:

 I did not follow this group recent. School started. Sorry! I just
 see now and please add my vote if possible. I start with D recent
 and I remember beginning. foo!(bar) was not pleasant. Like forced
 convention with a bad char. And friends I show code never like 
 it.
 It is first thing they say why they do not like D. For me 
 foo{bar}
 better idea. Thank you, Dee Girl


 What do your friends think of { } ?


 School started. Every one so busy now. But I think does not matter
 any more ^_^

 I want to make little idea. Sorry if idea mentioned before (I 
 did not
 read every thread). I think we can look square brackets []. Let me
 explain why.

 Paren () is over used in C and in D. Any expression can be in 
 (). And
 adding () is possible in many cases. But it is not same with []. 
 For
 example a:(b) is ambiguous but a:[b] is not. So there are many 
 signs
 possible after symbol and before [. They are:






 Not all of them work. Here's a few examples:

     enum { d= 3, e = 7 }
     int [] a=[1,2];
     bool c;
     auto k=[e]; // kills =
     a ~= c?[d]:[e]; // kills ?
     int [] f = c?k:[e]; // kills :
     if (f>[e]) {}   // kills <
     if (f<[e]) {}   // kills >
     auto g = (k,[d]); // kills comma
     auto h = k~[d]; // kills ~

 Array ops will kill + - * / & | % ^
 Suddenly the list looks pretty short.



 Hum, what about brackets without any prefix character at all?

    Vector[int, 2] foo;
    List[Vector[int, 2]] bar;
    int[3] a = [1, 2, 3]; // array literal here
    int[int] map;
    alias DenseMatrix[num] PulType;
    alias SparseRowsMatrix[num, HashSparseVector] PuuType;
    alias BiMap[uint, Tuple[uint, uint], BiMapOptions.lhDense] DicType;
    int var = a[2]; // array indexing here

 Hum... doesn't look bad visually. In fact it seems to fit quite nice
 with how associative arrays, and even normal arrays, are declared. 
 Hum,
 yes, I'm personally liking this a lot.

 But does it have any ambiguities? Hum, can't think of any off-hand. If
 an identifier appears before a bracket list, it could either be a
 template instantiation, or an array indexation. But the syntax of both
 is the same, so it doesn't need to be distinguished in the parser.

 Waddya think, was this discussed before?



 It may be easy to parse, but it isn't easy to read.

 What is goban[19]?  Is it an array or a template?  I'd hate to be 
 reading
 through somebody else's code and have to decipher what things mean.


 I give the same answer I gave to Bill:

 True, you'd have to follow /goban/ to find out. But that is just a 
 hover of the mouse away. :)


 Just for the record, I'm also not bothered by !(), but if some people 
 really find the urge to change it, I'd much rather have brackets than 
 the ugly sad pirate. I say ugly because the dot is much more common 
 than the '!', and for me it has a more solidified meaning of 
 accessing members, so seeing it used as part of the template 
 instantiation syntax looks weird.


 That's my opinion, too.

 Using square brackets would certainly fit with Walter's goal of making 
 templates less threatening for newcomers.
 It would be pretty cool to teach a newbie:

 int[] a;
 int[double] b;  // this is an AA
 priorityqueue[double] c; // this is a template


 
 I can't tell if you're being sarcastic here or not...


I would never intentionally use sarcasm on a group containing non-native 
English speakers.
I think there's a genuine similarity between AAs and templates, 
providing a natural teaching progression.
Oct 20 2008
parent reply Alix Pexton <alixD.TpextonNO SPAMgmailD.Tcom> writes:
Don wrote:

 Robert Fraser wrote:

 Don wrote:

 Bruno Medeiros wrote:

 Jason House wrote:

 Bruno Medeiros wrote:


 Don wrote:

 Denis Koroskin wrote:

 On Wed, 08 Oct 2008 18:22:21 +0400, superdan <super dan.org> wrote:


 Walter Bright Wrote:


 Dee Girl wrote:

 I did not follow this group recent. School started. Sorry! I 
 just
 see now and please add my vote if possible. I start with D 
 recent
 and I remember beginning. foo!(bar) was not pleasant. Like 
 forced
 convention with a bad char. And friends I show code never 
 like it.
 It is first thing they say why they do not like D. For me 
 foo{bar}
 better idea. Thank you, Dee Girl


 What do your friends think of { } ?


 School started. Every one so busy now. But I think does not matter
 any more ^_^

 I want to make little idea. Sorry if idea mentioned before (I 
 did not
 read every thread). I think we can look square brackets []. Let me
 explain why.

 Paren () is over used in C and in D. Any expression can be in 
 (). And
 adding () is possible in many cases. But it is not same with 
 []. For
 example a:(b) is ambiguous but a:[b] is not. So there are many 
 signs
 possible after symbol and before [. They are:






 Not all of them work. Here's a few examples:

     enum { d= 3, e = 7 }
     int [] a=[1,2];
     bool c;
     auto k=[e]; // kills =
     a ~= c?[d]:[e]; // kills ?
     int [] f = c?k:[e]; // kills :
     if (f>[e]) {}   // kills <
     if (f<[e]) {}   // kills >
     auto g = (k,[d]); // kills comma
     auto h = k~[d]; // kills ~

 Array ops will kill + - * / & | % ^
 Suddenly the list looks pretty short.



 Hum, what about brackets without any prefix character at all?

    Vector[int, 2] foo;
    List[Vector[int, 2]] bar;
    int[3] a = [1, 2, 3]; // array literal here
    int[int] map;
    alias DenseMatrix[num] PulType;
    alias SparseRowsMatrix[num, HashSparseVector] PuuType;
    alias BiMap[uint, Tuple[uint, uint], BiMapOptions.lhDense] 
 DicType;
    int var = a[2]; // array indexing here

 Hum... doesn't look bad visually. In fact it seems to fit quite nice
 with how associative arrays, and even normal arrays, are declared. 
 Hum,
 yes, I'm personally liking this a lot.

 But does it have any ambiguities? Hum, can't think of any 
 off-hand. If
 an identifier appears before a bracket list, it could either be a
 template instantiation, or an array indexation. But the syntax of 
 both
 is the same, so it doesn't need to be distinguished in the parser.

 Waddya think, was this discussed before?



 It may be easy to parse, but it isn't easy to read.

 What is goban[19]?  Is it an array or a template?  I'd hate to be 
 reading
 through somebody else's code and have to decipher what things mean.


 I give the same answer I gave to Bill:

 True, you'd have to follow /goban/ to find out. But that is just a 
 hover of the mouse away. :)


 Just for the record, I'm also not bothered by !(), but if some 
 people really find the urge to change it, I'd much rather have 
 brackets than the ugly sad pirate. I say ugly because the dot is 
 much more common than the '!', and for me it has a more solidified 
 meaning of accessing members, so seeing it used as part of the 
 template instantiation syntax looks weird.


 That's my opinion, too.

 Using square brackets would certainly fit with Walter's goal of 
 making templates less threatening for newcomers.
 It would be pretty cool to teach a newbie:

 int[] a;
 int[double] b;  // this is an AA
 priorityqueue[double] c; // this is a template


 I can't tell if you're being sarcastic here or not...


 
 I would never intentionally use sarcasm on a group containing non-native 
 English speakers.
 I think there's a genuine similarity between AAs and templates, 
 providing a natural teaching progression.
 


Um, b (the int[double] AA above) is a collection of ints that is indexed 
by a double. But is c a collection of priorityqueues that are indexed by 
a double? To me, that doesn't make sense, what type of data can I add to 
it? what type is used so set the priority? Further, I don't think it 
would make sense to use square-braces to invoke templates that are not 
collections, those that take multiple parameters or one that isn't a 
type. To me, it seems like this would make templates seem more 
complicated to new users.

A...
Oct 20 2008
parent reply Yigal Chripun <yigal100 gmail.com> writes:
Alix Pexton wrote:

 Don wrote:

 Robert Fraser wrote:

 Don wrote:

 Bruno Medeiros wrote:

 Jason House wrote:

 Bruno Medeiros wrote:


 Don wrote:

 Denis Koroskin wrote:

 On Wed, 08 Oct 2008 18:22:21 +0400, superdan <super dan.org>
 wrote:


 Walter Bright Wrote:


 Dee Girl wrote:

 I did not follow this group recent. School started. Sorry! I
 just
 see now and please add my vote if possible. I start with D
 recent
 and I remember beginning. foo!(bar) was not pleasant. Like
 forced
 convention with a bad char. And friends I show code never
 like it.
 It is first thing they say why they do not like D. For me
 foo{bar}
 better idea. Thank you, Dee Girl


 What do your friends think of { } ?


 School started. Every one so busy now. But I think does not
 matter
 any more ^_^

 I want to make little idea. Sorry if idea mentioned before (I
 did not
 read every thread). I think we can look square brackets [].
 Let me
 explain why.

 Paren () is over used in C and in D. Any expression can be in
 (). And
 adding () is possible in many cases. But it is not same with
 []. For
 example a:(b) is ambiguous but a:[b] is not. So there are many
 signs
 possible after symbol and before [. They are:






 Not all of them work. Here's a few examples:

     enum { d= 3, e = 7 }
     int [] a=[1,2];
     bool c;
     auto k=[e]; // kills =
     a ~= c?[d]:[e]; // kills ?
     int [] f = c?k:[e]; // kills :
     if (f>[e]) {}   // kills <
     if (f<[e]) {}   // kills >
     auto g = (k,[d]); // kills comma
     auto h = k~[d]; // kills ~

 Array ops will kill + - * / & | % ^
 Suddenly the list looks pretty short.



 Hum, what about brackets without any prefix character at all?

    Vector[int, 2] foo;
    List[Vector[int, 2]] bar;
    int[3] a = [1, 2, 3]; // array literal here
    int[int] map;
    alias DenseMatrix[num] PulType;
    alias SparseRowsMatrix[num, HashSparseVector] PuuType;
    alias BiMap[uint, Tuple[uint, uint], BiMapOptions.lhDense]
 DicType;
    int var = a[2]; // array indexing here

 Hum... doesn't look bad visually. In fact it seems to fit quite nice
 with how associative arrays, and even normal arrays, are
 declared. Hum,
 yes, I'm personally liking this a lot.

 But does it have any ambiguities? Hum, can't think of any
 off-hand. If
 an identifier appears before a bracket list, it could either be a
 template instantiation, or an array indexation. But the syntax of
 both
 is the same, so it doesn't need to be distinguished in the parser.

 Waddya think, was this discussed before?



 It may be easy to parse, but it isn't easy to read.

 What is goban[19]?  Is it an array or a template?  I'd hate to be
 reading
 through somebody else's code and have to decipher what things mean.


 I give the same answer I gave to Bill:

 True, you'd have to follow /goban/ to find out. But that is just a
 hover of the mouse away. :)


 Just for the record, I'm also not bothered by !(), but if some
 people really find the urge to change it, I'd much rather have
 brackets than the ugly sad pirate. I say ugly because the dot is
 much more common than the '!', and for me it has a more solidified
 meaning of accessing members, so seeing it used as part of the
 template instantiation syntax looks weird.


 That's my opinion, too.

 Using square brackets would certainly fit with Walter's goal of
 making templates less threatening for newcomers.
 It would be pretty cool to teach a newbie:

 int[] a;
 int[double] b;  // this is an AA
 priorityqueue[double] c; // this is a template


 I can't tell if you're being sarcastic here or not...


 I would never intentionally use sarcasm on a group containing
 non-native English speakers.
 I think there's a genuine similarity between AAs and templates,
 providing a natural teaching progression.


 
 Um, b (the int[double] AA above) is a collection of ints that is indexed
 by a double. But is c a collection of priorityqueues that are indexed by
 a double? To me, that doesn't make sense, what type of data can I add to
 it? what type is used so set the priority? Further, I don't think it
 would make sense to use square-braces to invoke templates that are not
 collections, those that take multiple parameters or one that isn't a
 type. To me, it seems like this would make templates seem more
 complicated to new users.
 
 A...


as already noted by others, Andrei wanted to write Array!(T) with a
capacity field. using that the above would hopefully evolve to:

 Array[int] a; // used to be - int[] a;
 Array[SomeType, 4, 4, 4] d; //used to be SomeType[4][4][4] d;
 AssociativeArray[int, double] b; // used to be - int[double] b;
 PriorityQueue[double] c; // this remains a template

all of the above would be templates.

Andrei is also working on Range templates, which I think generalize the
array slice feature. with that, the current use of [] with types can be
deprecated.

my personal feeling is that the above syntax would be easier for
newbies. either you use it as slicing operator which returns a range or
as template parameter list.
Oct 20 2008
parent "Bill Baxter" <wbaxter gmail.com> writes:
On Mon, Oct 20, 2008 at 7:07 PM, Yigal Chripun <yigal100 gmail.com> wrote:

 Alix Pexton wrote:

 Don wrote:

 Robert Fraser wrote:

 Don wrote:

 Bruno Medeiros wrote:

 Jason House wrote:

 Bruno Medeiros wrote:


 Don wrote:

 Denis Koroskin wrote:

 On Wed, 08 Oct 2008 18:22:21 +0400, superdan <super dan.org>
 wrote:


 Walter Bright Wrote:


 Dee Girl wrote:

 I did not follow this group recent. School started. Sorry! I
 just
 see now and please add my vote if possible. I start with D
 recent
 and I remember beginning. foo!(bar) was not pleasant. Like
 forced
 convention with a bad char. And friends I show code never
 like it.
 It is first thing they say why they do not like D. For me
 foo{bar}
 better idea. Thank you, Dee Girl


 What do your friends think of { } ?


 School started. Every one so busy now. But I think does not
 matter
 any more ^_^

 I want to make little idea. Sorry if idea mentioned before (I
 did not
 read every thread). I think we can look square brackets [].
 Let me
 explain why.

 Paren () is over used in C and in D. Any expression can be in
 (). And
 adding () is possible in many cases. But it is not same with
 []. For
 example a:(b) is ambiguous but a:[b] is not. So there are many
 signs
 possible after symbol and before [. They are:






 Not all of them work. Here's a few examples:

     enum { d= 3, e = 7 }
     int [] a=[1,2];
     bool c;
     auto k=[e]; // kills =
     a ~= c?[d]:[e]; // kills ?
     int [] f = c?k:[e]; // kills :
     if (f>[e]) {}   // kills <
     if (f<[e]) {}   // kills >
     auto g = (k,[d]); // kills comma
     auto h = k~[d]; // kills ~

 Array ops will kill + - * / & | % ^
 Suddenly the list looks pretty short.



 Hum, what about brackets without any prefix character at all?

    Vector[int, 2] foo;
    List[Vector[int, 2]] bar;
    int[3] a = [1, 2, 3]; // array literal here
    int[int] map;
    alias DenseMatrix[num] PulType;
    alias SparseRowsMatrix[num, HashSparseVector] PuuType;
    alias BiMap[uint, Tuple[uint, uint], BiMapOptions.lhDense]
 DicType;
    int var = a[2]; // array indexing here

 Hum... doesn't look bad visually. In fact it seems to fit quite nice
 with how associative arrays, and even normal arrays, are
 declared. Hum,
 yes, I'm personally liking this a lot.

 But does it have any ambiguities? Hum, can't think of any
 off-hand. If
 an identifier appears before a bracket list, it could either be a
 template instantiation, or an array indexation. But the syntax of
 both
 is the same, so it doesn't need to be distinguished in the parser.

 Waddya think, was this discussed before?



 It may be easy to parse, but it isn't easy to read.

 What is goban[19]?  Is it an array or a template?  I'd hate to be
 reading
 through somebody else's code and have to decipher what things mean.


 I give the same answer I gave to Bill:

 True, you'd have to follow /goban/ to find out. But that is just a
 hover of the mouse away. :)


 Just for the record, I'm also not bothered by !(), but if some
 people really find the urge to change it, I'd much rather have
 brackets than the ugly sad pirate. I say ugly because the dot is
 much more common than the '!', and for me it has a more solidified
 meaning of accessing members, so seeing it used as part of the
 template instantiation syntax looks weird.


 That's my opinion, too.

 Using square brackets would certainly fit with Walter's goal of
 making templates less threatening for newcomers.
 It would be pretty cool to teach a newbie:

 int[] a;
 int[double] b;  // this is an AA
 priorityqueue[double] c; // this is a template


 I can't tell if you're being sarcastic here or not...


 I would never intentionally use sarcasm on a group containing
 non-native English speakers.
 I think there's a genuine similarity between AAs and templates,
 providing a natural teaching progression.


 Um, b (the int[double] AA above) is a collection of ints that is indexed
 by a double. But is c a collection of priorityqueues that are indexed by
 a double? To me, that doesn't make sense, what type of data can I add to
 it? what type is used so set the priority? Further, I don't think it
 would make sense to use square-braces to invoke templates that are not
 collections, those that take multiple parameters or one that isn't a
 type. To me, it seems like this would make templates seem more
 complicated to new users.

 A...


 as already noted by others, Andrei wanted to write Array!(T) with a
 capacity field. using that the above would hopefully evolve to:

  Array[int] a; // used to be - int[] a;
  Array[SomeType, 4, 4, 4] d; //used to be SomeType[4][4][4] d;
  AssociativeArray[int, double] b; // used to be - int[double] b;
  PriorityQueue[double] c; // this remains a template

 all of the above would be templates.

 Andrei is also working on Range templates, which I think generalize the
 array slice feature. with that, the current use of [] with types can be
 deprecated.

 my personal feeling is that the above syntax would be easier for
 newbies. either you use it as slicing operator which returns a range or
 as template parameter list.


Don't arrays have to be built-ins to work with CTFE and various
template/tuple usages?  So if Array will gain that sort of built-in
status then Array will effectively become a new keyword in the
language.   But honestlly the two new keywords wouldn't bother me as
much as  having to type those names out all the time.

--bb
Oct 20 2008
prev sibling next sibling parent reply Benji Smith <dlanguage benjismith.net> writes:
Don wrote:

 Using square brackets would certainly fit with Walter's goal of making 
 templates less threatening for newcomers.
 It would be pretty cool to teach a newbie:
 
 int[] a;
 int[double] b;  // this is an AA
 priorityqueue[double] c; // this is a template


Actually, with Andrei's "Array" template introducing template syntax for 
arrays, I think there could be a convincing argument that all arrays 
(associative or otherwise) would benefit from a template-like declaration.

After all, a standard garden-variety array is actually very much like a 
type-specialized "sequence" container.

Templates like these could entirely replace the builtin array types, and 
I think everyone, from beginner to pro, would be comfortable with the 
syntax:

   // Maybe make the names explicit...
   auto a = DynamicArray[int];
   auto b = StaticArray[int, 3];

   // Or the name could be the same, with the template arguments
   // determining the static/dynamic implementation...
   auto c = Array[int];
   auto d = Array[int, 3];

   // Syntax between arrays, standard containers, and library
   // containers would be syntactically similar. Very nice.
   auto e = AssociativeArray[int, double];
   auto f = HashMap[int, double];
   auto g = PriorityQueue[double];

I actually think it's a very nice, totally workable idea.

--benji
Oct 17 2008
parent "Jarrett Billingsley" <jarrett.billingsley gmail.com> writes:
On Fri, Oct 17, 2008 at 7:45 PM, Benji Smith <dlanguage benjismith.net> wrote:


 Actually, with Andrei's "Array" template introducing template syntax for
 arrays, I think there could be a convincing argument that all arrays
 (associative or otherwise) would benefit from a template-like declaration.

 After all, a standard garden-variety array is actually very much like a
 type-specialized "sequence" container.

 Templates like these could entirely replace the builtin array types, and I
 think everyone, from beginner to pro, would be comfortable with the syntax:

  // Maybe make the names explicit...
  auto a = DynamicArray[int];
  auto b = StaticArray[int, 3];

  // Or the name could be the same, with the template arguments
  // determining the static/dynamic implementation...
  auto c = Array[int];
  auto d = Array[int, 3];

  // Syntax between arrays, standard containers, and library
  // containers would be syntactically similar. Very nice.
  auto e = AssociativeArray[int, double];
  auto f = HashMap[int, double];
  auto g = PriorityQueue[double];

 I actually think it's a very nice, totally workable idea.


I hate to change sides, but the more I look at this template syntax
the more I like it...
Oct 17 2008
prev sibling parent reply Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
Don wrote:

 Bruno Medeiros wrote:

 Jason House wrote:

 Bruno Medeiros wrote:


 Don wrote:

 Denis Koroskin wrote:

 On Wed, 08 Oct 2008 18:22:21 +0400, superdan <super dan.org> wrote:


 Walter Bright Wrote:


 Dee Girl wrote:

 I did not follow this group recent. School started. Sorry! I just
 see now and please add my vote if possible. I start with D recent
 and I remember beginning. foo!(bar) was not pleasant. Like forced
 convention with a bad char. And friends I show code never like it.
 It is first thing they say why they do not like D. For me foo{bar}
 better idea. Thank you, Dee Girl


 What do your friends think of { } ?


 School started. Every one so busy now. But I think does not matter
 any more ^_^

 I want to make little idea. Sorry if idea mentioned before (I did 
 not
 read every thread). I think we can look square brackets []. Let me
 explain why.

 Paren () is over used in C and in D. Any expression can be in (). 
 And
 adding () is possible in many cases. But it is not same with []. For
 example a:(b) is ambiguous but a:[b] is not. So there are many signs
 possible after symbol and before [. They are:






 Not all of them work. Here's a few examples:

     enum { d= 3, e = 7 }
     int [] a=[1,2];
     bool c;
     auto k=[e]; // kills =
     a ~= c?[d]:[e]; // kills ?
     int [] f = c?k:[e]; // kills :
     if (f>[e]) {}   // kills <
     if (f<[e]) {}   // kills >
     auto g = (k,[d]); // kills comma
     auto h = k~[d]; // kills ~

 Array ops will kill + - * / & | % ^
 Suddenly the list looks pretty short.



 Hum, what about brackets without any prefix character at all?

    Vector[int, 2] foo;
    List[Vector[int, 2]] bar;
    int[3] a = [1, 2, 3]; // array literal here
    int[int] map;
    alias DenseMatrix[num] PulType;
    alias SparseRowsMatrix[num, HashSparseVector] PuuType;
    alias BiMap[uint, Tuple[uint, uint], BiMapOptions.lhDense] DicType;
    int var = a[2]; // array indexing here

 Hum... doesn't look bad visually. In fact it seems to fit quite nice
 with how associative arrays, and even normal arrays, are declared. Hum,
 yes, I'm personally liking this a lot.

 But does it have any ambiguities? Hum, can't think of any off-hand. If
 an identifier appears before a bracket list, it could either be a
 template instantiation, or an array indexation. But the syntax of both
 is the same, so it doesn't need to be distinguished in the parser.

 Waddya think, was this discussed before?



 It may be easy to parse, but it isn't easy to read.

 What is goban[19]?  Is it an array or a template?  I'd hate to be 
 reading
 through somebody else's code and have to decipher what things mean.


 I give the same answer I gave to Bill:

 True, you'd have to follow /goban/ to find out. But that is just a 
 hover of the mouse away. :)


 Just for the record, I'm also not bothered by !(), but if some people 
 really find the urge to change it, I'd much rather have brackets than 
 the ugly sad pirate. I say ugly because the dot is much more common 
 than the '!', and for me it has a more solidified meaning of accessing 
 members, so seeing it used as part of the template instantiation 
 syntax looks weird.


 That's my opinion, too.
 
 Using square brackets would certainly fit with Walter's goal of making 
 templates less threatening for newcomers.
 It would be pretty cool to teach a newbie:
 
 int[] a;
 int[double] b;  // this is an AA
 priorityqueue[double] c; // this is a template


I wonder if Andrei or Walter have looked at this proposal, or if maybe 
has Andrei forgotten about the whole idea, now that he is using that 
Emacs chevrons tricks and whatnot.

Also one more for the record: I also find this syntax preferable to 
foo{bar}, the curly brackets syntax. Not that is matters since it is 
ambiguous, but the curlies kept looking like "code block/delegate" to me.


-- 
Bruno Medeiros - Software Developer, MSc. in CS/E graduate
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
Oct 21 2008
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Bruno Medeiros wrote:

 Don wrote:

 Bruno Medeiros wrote:

 Jason House wrote:

 Bruno Medeiros wrote:


 Don wrote:

 Denis Koroskin wrote:

 On Wed, 08 Oct 2008 18:22:21 +0400, superdan <super dan.org> wrote:


 Walter Bright Wrote:


 Dee Girl wrote:

 I did not follow this group recent. School started. Sorry! I just
 see now and please add my vote if possible. I start with D recent
 and I remember beginning. foo!(bar) was not pleasant. Like forced
 convention with a bad char. And friends I show code never like 
 it.
 It is first thing they say why they do not like D. For me 
 foo{bar}
 better idea. Thank you, Dee Girl


 What do your friends think of { } ?


 School started. Every one so busy now. But I think does not matter
 any more ^_^

 I want to make little idea. Sorry if idea mentioned before (I 
 did not
 read every thread). I think we can look square brackets []. Let me
 explain why.

 Paren () is over used in C and in D. Any expression can be in 
 (). And
 adding () is possible in many cases. But it is not same with []. 
 For
 example a:(b) is ambiguous but a:[b] is not. So there are many 
 signs
 possible after symbol and before [. They are:






 Not all of them work. Here's a few examples:

     enum { d= 3, e = 7 }
     int [] a=[1,2];
     bool c;
     auto k=[e]; // kills =
     a ~= c?[d]:[e]; // kills ?
     int [] f = c?k:[e]; // kills :
     if (f>[e]) {}   // kills <
     if (f<[e]) {}   // kills >
     auto g = (k,[d]); // kills comma
     auto h = k~[d]; // kills ~

 Array ops will kill + - * / & | % ^
 Suddenly the list looks pretty short.



 Hum, what about brackets without any prefix character at all?

    Vector[int, 2] foo;
    List[Vector[int, 2]] bar;
    int[3] a = [1, 2, 3]; // array literal here
    int[int] map;
    alias DenseMatrix[num] PulType;
    alias SparseRowsMatrix[num, HashSparseVector] PuuType;
    alias BiMap[uint, Tuple[uint, uint], BiMapOptions.lhDense] DicType;
    int var = a[2]; // array indexing here

 Hum... doesn't look bad visually. In fact it seems to fit quite nice
 with how associative arrays, and even normal arrays, are declared. 
 Hum,
 yes, I'm personally liking this a lot.

 But does it have any ambiguities? Hum, can't think of any off-hand. If
 an identifier appears before a bracket list, it could either be a
 template instantiation, or an array indexation. But the syntax of both
 is the same, so it doesn't need to be distinguished in the parser.

 Waddya think, was this discussed before?



 It may be easy to parse, but it isn't easy to read.

 What is goban[19]?  Is it an array or a template?  I'd hate to be 
 reading
 through somebody else's code and have to decipher what things mean.


 I give the same answer I gave to Bill:

 True, you'd have to follow /goban/ to find out. But that is just a 
 hover of the mouse away. :)


 Just for the record, I'm also not bothered by !(), but if some people 
 really find the urge to change it, I'd much rather have brackets than 
 the ugly sad pirate. I say ugly because the dot is much more common 
 than the '!', and for me it has a more solidified meaning of 
 accessing members, so seeing it used as part of the template 
 instantiation syntax looks weird.


 That's my opinion, too.

 Using square brackets would certainly fit with Walter's goal of making 
 templates less threatening for newcomers.
 It would be pretty cool to teach a newbie:

 int[] a;
 int[double] b;  // this is an AA
 priorityqueue[double] c; // this is a template


 
 I wonder if Andrei or Walter have looked at this proposal, or if maybe 
 has Andrei forgotten about the whole idea, now that he is using that 
 Emacs chevrons tricks and whatnot.
 
 Also one more for the record: I also find this syntax preferable to 
 foo{bar}, the curly brackets syntax. Not that is matters since it is 
 ambiguous, but the curlies kept looking like "code block/delegate" to me.


I do like it and did discuss it with Walter. It's just too ambiguous.

Andrei
Oct 21 2008
parent Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
Andrei Alexandrescu wrote:

 Bruno Medeiros wrote:

 I wonder if Andrei or Walter have looked at this proposal, or if maybe 
 has Andrei forgotten about the whole idea, now that he is using that 
 Emacs chevrons tricks and whatnot.

 Also one more for the record: I also find this syntax preferable to 
 foo{bar}, the curly brackets syntax. Not that is matters since it is 
 ambiguous, but the curlies kept looking like "code block/delegate" to me.


 
 I do like it and did discuss it with Walter. It's just too ambiguous.
 
 Andrei


 From a user perspective, or there are actual grammar ambiguities? 
(besides the range/slice operation)

-- 
Bruno Medeiros - Software Developer, MSc. in CS/E graduate
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
Oct 21 2008
prev sibling next sibling parent reply "Lionello Lunesu" <lionello lunesu.remove.com> writes:
"Walter Bright" <newshound1 digitalmars.com> wrote in message 
news:gcdqa4$qas$1 digitalmars.com...

 The foo.(bar) syntax seems to be sinking. The foo{bar} seems to be the 
 most practical alternative. So, how about putting it in the next D2 
 release on a trial basis, so people can try it out and see how it looks?


To me, using foo{bar} instead of foo!(bar) really makes no difference. In 
fact, I prefer the latter.

I think more effort should be spent on unifying template and normal code.

Partial compilation and "auto" support in the argument list might make the 
whole template syntax obsolete, since the compiler could issue a specially 
compiled version for constant argument values / argument types. Add to that 
support for "alias" template parameters in a normal argument list and we're 
on the right track:

typeof(r1) overlap(auto r1, auto r2)
 if (typeof(r1) == typeof(r2))//not really ok but it's what algorithm.d has 
now
{
//...
}

typeof(rs) filter(alias pred, auto[] rs ...)
{
//...
}

I suppose we'd also need a way to force compilation of specific 
instantiations for inclusion in precompiled libraries.

Please let me know if I'm talking BS here....

L.
Oct 07 2008
parent reply Michel Fortin <michel.fortin michelf.com> writes:
On 2008-10-07 21:13:40 -0400, "Lionello Lunesu" 
<lionello lunesu.remove.com> said:


 I think more effort should be spent on unifying template and normal code.
 
 Partial compilation and "auto" support in the argument list might make 
 the whole template syntax obsolete, since the compiler could issue a 
 specially compiled version for constant argument values / argument 
 types. Add to that support for "alias" template parameters in a normal 
 argument list and we're on the right track:
 
 typeof(r1) overlap(auto r1, auto r2)
  if (typeof(r1) == typeof(r2))//not really ok but it's what algorithm.d has now
 {
 //...
 }
 
 typeof(rs) filter(alias pred, auto[] rs ...)
 {
 //...
 }
 
 I suppose we'd also need a way to force compilation of specific 
 instantiations for inclusion in precompiled libraries.
 
 Please let me know if I'm talking BS here....


I think this is great concept... "implicit template functions"! You're 
right that it cannot be included in precompiled libraries because it 
has to be instanciated once you know the type of your arguments, but 
this hasn't stopped templates from being used up to now.

-- 
Michel Fortin
michel.fortin michelf.com
http://michelf.com/
Oct 07 2008
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Michel Fortin wrote:

 On 2008-10-07 21:13:40 -0400, "Lionello Lunesu" 
 <lionello lunesu.remove.com> said:
 

 I think more effort should be spent on unifying template and normal code.

 Partial compilation and "auto" support in the argument list might make 
 the whole template syntax obsolete, since the compiler could issue a 
 specially compiled version for constant argument values / argument 
 types. Add to that support for "alias" template parameters in a normal 
 argument list and we're on the right track:

 typeof(r1) overlap(auto r1, auto r2)
  if (typeof(r1) == typeof(r2))//not really ok but it's what 
 algorithm.d has now
 {
 //...
 }

 typeof(rs) filter(alias pred, auto[] rs ...)
 {
 //...
 }

 I suppose we'd also need a way to force compilation of specific 
 instantiations for inclusion in precompiled libraries.

 Please let me know if I'm talking BS here....


 
 I think this is great concept... "implicit template functions"! You're 
 right that it cannot be included in precompiled libraries because it has 
 to be instanciated once you know the type of your arguments, but this 
 hasn't stopped templates from being used up to now.


I, too, think it's a nice idea. Walter, Bartosz and I discussed it a 
while ago. There are some savings in the declaration part, and no loss 
because you can always say typeof(arg) to figure out what the type was. 
In general, however, with the advent of conditional templates, I suspect 
that most templates will impose restrictions on the types of their 
arguments and therefore will need their type names. On the example given:

Range overlap(Range r1, Range r2) if (isRandomAccessRange!(Range))
{
     ...
}

The signature clarifies the requirements on the type much crisper than 
the loose, vale tudo:

auto overlap(auto r1, auto r2) { ... }

which will (1) catch every call (blech) and (2) attempt to plow through 
its implementation and fail to compile with an uninformative message, 
file, and line.


Andrei
Oct 07 2008
next sibling parent reply "Denis Koroskin" <2korden gmail.com> writes:
On Wed, 08 Oct 2008 06:33:32 +0400, Andrei Alexandrescu  
<SeeWebsiteForEmail erdani.org> wrote:


 Michel Fortin wrote:

 On 2008-10-07 21:13:40 -0400, "Lionello Lunesu"  
 <lionello lunesu.remove.com> said:


 I think more effort should be spent on unifying template and normal  
 code.

 Partial compilation and "auto" support in the argument list might make  
 the whole template syntax obsolete, since the compiler could issue a  
 specially compiled version for constant argument values / argument  
 types. Add to that support for "alias" template parameters in a normal  
 argument list and we're on the right track:

 typeof(r1) overlap(auto r1, auto r2)
  if (typeof(r1) == typeof(r2))//not really ok but it's what  
 algorithm.d has now
 {
 //...
 }

 typeof(rs) filter(alias pred, auto[] rs ...)
 {
 //...
 }

 I suppose we'd also need a way to force compilation of specific  
 instantiations for inclusion in precompiled libraries.

 Please let me know if I'm talking BS here....


  I think this is great concept... "implicit template functions"! You're  
 right that it cannot be included in precompiled libraries because it  
 has to be instanciated once you know the type of your arguments, but  
 this hasn't stopped templates from being used up to now.


 I, too, think it's a nice idea. Walter, Bartosz and I discussed it a  
 while ago. There are some savings in the declaration part, and no loss  
 because you can always say typeof(arg) to figure out what the type was.  
 In general, however, with the advent of conditional templates, I suspect  
 that most templates will impose restrictions on the types of their  
 arguments and therefore will need their type names. On the example given:

 Range overlap(Range r1, Range r2) if (isRandomAccessRange!(Range))
 {
      ...
 }


Note that you didn't specify template arguments in the example above  
(intensionally or not, you missed the "(Range)" part after function name).  
It clearly says that you don't want to type that one. Also note that the  
definition above is clearly a template function definition since usual  
function lack matching mechanism (provided by 'if' part). How easy it  
would be to compiler to detect, deduce and allow dropping the template  
arguments?


 The signature clarifies the requirements on the type much crisper than  
 the loose, vale tudo:

 auto overlap(auto r1, auto r2) { ... }

 which will (1) catch every call (blech) and (2) attempt to plow through  
 its implementation and fail to compile with an uninformative message,  
 file, and line.


 Andrei
Oct 07 2008
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Denis Koroskin wrote:

 On Wed, 08 Oct 2008 06:33:32 +0400, Andrei Alexandrescu 
 <SeeWebsiteForEmail erdani.org> wrote:
 

 Michel Fortin wrote:

 On 2008-10-07 21:13:40 -0400, "Lionello Lunesu" 
 <lionello lunesu.remove.com> said:


 I think more effort should be spent on unifying template and normal 
 code.

 Partial compilation and "auto" support in the argument list might 
 make the whole template syntax obsolete, since the compiler could 
 issue a specially compiled version for constant argument values / 
 argument types. Add to that support for "alias" template parameters 
 in a normal argument list and we're on the right track:

 typeof(r1) overlap(auto r1, auto r2)
  if (typeof(r1) == typeof(r2))//not really ok but it's what 
 algorithm.d has now
 {
 //...
 }

 typeof(rs) filter(alias pred, auto[] rs ...)
 {
 //...
 }

 I suppose we'd also need a way to force compilation of specific 
 instantiations for inclusion in precompiled libraries.

 Please let me know if I'm talking BS here....


  I think this is great concept... "implicit template functions"! 
 You're right that it cannot be included in precompiled libraries 
 because it has to be instanciated once you know the type of your 
 arguments, but this hasn't stopped templates from being used up to now.


 I, too, think it's a nice idea. Walter, Bartosz and I discussed it a 
 while ago. There are some savings in the declaration part, and no loss 
 because you can always say typeof(arg) to figure out what the type 
 was. In general, however, with the advent of conditional templates, I 
 suspect that most templates will impose restrictions on the types of 
 their arguments and therefore will need their type names. On the 
 example given:

 Range overlap(Range r1, Range r2) if (isRandomAccessRange!(Range))
 {
      ...
 }


 
 Note that you didn't specify template arguments in the example above 
 (intensionally or not, you missed the "(Range)" part after function 
 name). It clearly says that you don't want to type that one.


Hehe. Damn. I did mean to type it.

As much as I don't want to type it, I have to. Otherwise the poor 
compiler can't know whether I meant to introduce Range or use a 
previously-defined Range.


 Also note 
 that the definition above is clearly a template function definition 
 since usual function lack matching mechanism (provided by 'if' part). 
 How easy it would be to compiler to detect, deduce and allow dropping 
 the template arguments?


Unfeasibly easy. Consider:

void foo(Bar bar, Baz baz) if (is(Bar : Baz)) { ... }

Now you tell me: which of Bar, Baz, or both is introduced, and which is 
to be looked up, if any?


Andrei
Oct 07 2008
prev sibling next sibling parent reply "Lionello Lunesu" <lionello lunesu.remove.com> writes:
"Andrei Alexandrescu" <SeeWebsiteForEmail erdani.org> wrote in message 
news:gch67k$1jl$1 digitalmars.com...

 Range overlap(Range r1, Range r2) if (isRandomAccessRange!(Range))
 {
     ...
 }

 The signature clarifies the requirements on the type much crisper than the 
 loose, vale tudo:

 auto overlap(auto r1, auto r2) { ... }

 which will (1) catch every call (blech) and (2) attempt to plow through 
 its implementation and fail to compile with an uninformative message, 
 file, and line.


But this would do the same and, in fact, is more correct:

typeof(r1) overlap(auto r1, auto r2)
  if (isRandomAccessRange!(typeof(r1)) && isRandomAccessRange!(typeof(r2)))
{
    ...
}

The only thing the original (Range)(Range r1, Range r2) syntax adds, then,
is an implicit "if (typeof(r1) == typeof(r2))" constraint. If this
constraint is used often, that syntax can be retained, but would solely
affect the declaration of the template.

L.
Oct 07 2008
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Lionello Lunesu wrote:

 
 "Andrei Alexandrescu" <SeeWebsiteForEmail erdani.org> wrote in message 
 news:gch67k$1jl$1 digitalmars.com...

 Range overlap(Range r1, Range r2) if (isRandomAccessRange!(Range))
 {
     ...
 }

 The signature clarifies the requirements on the type much crisper than 
 the loose, vale tudo:

 auto overlap(auto r1, auto r2) { ... }

 which will (1) catch every call (blech) and (2) attempt to plow 
 through its implementation and fail to compile with an uninformative 
 message, file, and line.


 
 But this would do the same and, in fact, is more correct:
 
 typeof(r1) overlap(auto r1, auto r2)
  if (isRandomAccessRange!(typeof(r1)) && isRandomAccessRange!(typeof(r2)))
 {
    ...
 }
 
 The only thing the original (Range)(Range r1, Range r2) syntax adds, then,
 is an implicit "if (typeof(r1) == typeof(r2))" constraint. If this
 constraint is used often, that syntax can be retained, but would solely
 affect the declaration of the template.


Hmmmmmmm... there are multiple issues to discuss here.

One is, you want to compare ranges of different types. I agree that 
that's more general, e.g. a range could iterate const stuff and the 
other mutable stuff. But then which of the two range types do you 
return? You'd need some extra type pushups for that. But it's doable.

The other is more trivial: auto was supposed to save some typing, but 
the abundant typeof's in the signature considerably reduce that 
advantage. IMHO auto is useful when types are NOT restricted, and as far 
as I understand things now, future only has less of those.


Andrei
Oct 07 2008
parent "Lionello Lunesu" <lionello lunesu.remove.com> writes:
"Andrei Alexandrescu" <SeeWebsiteForEmail erdani.org> wrote in message 
news:gchhfa$nsj$2 digitalmars.com...

 Lionello Lunesu wrote:

 "Andrei Alexandrescu" <SeeWebsiteForEmail erdani.org> wrote in message 
 news:gch67k$1jl$1 digitalmars.com...

 Range overlap(Range r1, Range r2) if (isRandomAccessRange!(Range))
 {
     ...
 }

 The signature clarifies the requirements on the type much crisper than 
 the loose, vale tudo:

 auto overlap(auto r1, auto r2) { ... }

 which will (1) catch every call (blech) and (2) attempt to plow through 
 its implementation and fail to compile with an uninformative message, 
 file, and line.


 But this would do the same and, in fact, is more correct:

 typeof(r1) overlap(auto r1, auto r2)
  if (isRandomAccessRange!(typeof(r1)) && 
 isRandomAccessRange!(typeof(r2)))
 {
    ...
 }

 The only thing the original (Range)(Range r1, Range r2) syntax adds, 
 then,
 is an implicit "if (typeof(r1) == typeof(r2))" constraint. If this
 constraint is used often, that syntax can be retained, but would solely
 affect the declaration of the template.


 Hmmmmmmm... there are multiple issues to discuss here.

 One is, you want to compare ranges of different types. I agree that that's 
 more general, e.g. a range could iterate const stuff and the other mutable 
 stuff. But then which of the two range types do you return? You'd need 
 some extra type pushups for that. But it's doable.


True, but that has nothing to do with the current topic. Even 'old-style' 
templates would have that problem. I should have sticked to typeof==typeof 
for the analogy.


 The other is more trivial: auto was supposed to save some typing, but the 
 abundant typeof's in the signature considerably reduce that advantage. 
 IMHO auto is useful when types are NOT restricted, and as far as I 
 understand things now, future only has less of those.


Right. And suddenly I realise that I've been wrong: I was discussing the 
template declaration, but !() only applies to its usage. Whether the 
template uses overlap(Range)(Range r1, Range r2) or (auto r1, auto r2) is 
irrelevant.

So what we'd need is for the caller to be able to specify some additional 
constraints. Can this be done by passing the constraints in the normal 
argument list?

auto result = overlap(r1,r2);//let the compiler figure it out
auto result = overlap(Array,r1,r2);//instantiate using Array

...I guess not..

L.
Oct 08 2008
prev sibling parent Michel Fortin <michel.fortin michelf.com> writes:
On 2008-10-07 22:33:32 -0400, Andrei Alexandrescu 
<SeeWebsiteForEmail erdani.org> said:


 I, too, think it's a nice idea. Walter, Bartosz and I discussed it a 
 while ago. There are some savings in the declaration part, and no loss 
 because you can always say typeof(arg) to figure out what the type was. 
 In general, however, with the advent of conditional templates, I 
 suspect that most templates will impose restrictions on the types of 
 their arguments and therefore will need their type names. On the 
 example given:
 
 Range overlap(Range r1, Range r2) if (isRandomAccessRange!(Range))
 {
      ...
 }
 
 The signature clarifies the requirements on the type much crisper than 
 the loose, vale tudo:
 
 auto overlap(auto r1, auto r2) { ... }
 
 which will (1) catch every call (blech) and (2) attempt to plow through 
 its implementation and fail to compile with an uninformative message, 
 file, and line.


But, couldn't we extend auto to define named types (just like templates 
do)? Something such as:

	Range overlap(auto(Range) r1, Range r2) { ... }

Perhaps you could do this too:

	T[] foo(auto(T)[] r1, T[] r2) { ... }

-- 
Michel Fortin
michel.fortin michelf.com
http://michelf.com/
Oct 08 2008
prev sibling next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Walter discovered a showstopper for the curls.

class A : B
{
}


Andrei
Oct 08 2008
next sibling parent reply "Denis Koroskin" <2korden gmail.com> writes:
On Wed, 08 Oct 2008 16:21:02 +0400, Andrei Alexandrescu  
<SeeWebsiteForEmail erdani.org> wrote:


 Walter discovered a showstopper for the curls.

 class A : B
 {
 }


 Andrei


This is sad .(

So, what are we left with now? Does everything stay as is or are we still  
looking   alternatives?
Oct 08 2008
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Denis Koroskin wrote:

 On Wed, 08 Oct 2008 16:21:02 +0400, Andrei Alexandrescu 
 <SeeWebsiteForEmail erdani.org> wrote:
 

 Walter discovered a showstopper for the curls.

 class A : B
 {
 }


 Andrei


 
 This is sad .(
 
 So, what are we left with now? Does everything stay as is or are we 
 still looking   alternatives?


I hope we will find a good notation after all. I hope people's patience 
hasn't worn thin. One thing that I noticed in the recent discussion was 
that quite a few people, even among supporters of the status quo, 
admitted that the !() syntax feels a bit odd at least in the beginning.

Andrei
Oct 08 2008
next sibling parent reply Max Samukha <samukha voliacable.com.removethis> writes:
On Wed, 08 Oct 2008 07:34:56 -0500, Andrei Alexandrescu
<SeeWebsiteForEmail erdani.org> wrote:


Denis Koroskin wrote:

 On Wed, 08 Oct 2008 16:21:02 +0400, Andrei Alexandrescu 
 <SeeWebsiteForEmail erdani.org> wrote:
 

 Walter discovered a showstopper for the curls.

 class A : B
 {
 }


 Andrei


 
 This is sad .(
 
 So, what are we left with now? Does everything stay as is or are we 
 still looking   alternatives?


I hope we will find a good notation after all. I hope people's patience 
hasn't worn thin. One thing that I noticed in the recent discussion was 
that quite a few people, even among supporters of the status quo, 
admitted that the !() syntax feels a bit odd at least in the beginning.

Andrei


I'm glad curls didn't get there. If I saw them in the beginning, my
first reaction would probably have been: "Why block delimiters for
template parameters? It's even odder than !(". 

After staring for some time at templated code written by you and other
people, I feel like joining !( supporters. It doesn't shout at me any
louder than != or unary !. There needs to be a space after ! for it to
shout properly. Nesting is rare and alleviated by aliases.
Oct 08 2008
parent reply superdan <super dan.org> writes:
Max Samukha Wrote:


 On Wed, 08 Oct 2008 07:34:56 -0500, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org> wrote:
 

Denis Koroskin wrote:

 On Wed, 08 Oct 2008 16:21:02 +0400, Andrei Alexandrescu 
 <SeeWebsiteForEmail erdani.org> wrote:
 

 Walter discovered a showstopper for the curls.

 class A : B
 {
 }


 Andrei


 
 This is sad .(
 
 So, what are we left with now? Does everything stay as is or are we 
 still looking   alternatives?


I hope we will find a good notation after all. I hope people's patience 
hasn't worn thin. One thing that I noticed in the recent discussion was 
that quite a few people, even among supporters of the status quo, 
admitted that the !() syntax feels a bit odd at least in the beginning.

Andrei


 
 I'm glad curls didn't get there. If I saw them in the beginning, my
 first reaction would probably have been: "Why block delimiters for
 template parameters? It's even odder than !(". 


how the heck. since like forever there's been three kinds of parens () [] and
{}. they pair n all. choosing one for template args is anyone's first guess.
but !( i bet you couldn't see comin' if it bit yer nose. 


 After staring for some time at templated code written by you and other
 people, I feel like joining !( supporters. It doesn't shout at me any
 louder than != or unary !. There needs to be a space after ! for it to
 shout properly. Nesting is rare and alleviated by aliases.


really!(how'd ya figure?) besides i often write code like

sort!
    ((string a, string b) { ... })
    (array);

pisses me off.
Oct 08 2008
next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
"superdan" wrote

 Max Samukha Wrote:


 On Wed, 08 Oct 2008 07:34:56 -0500, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org> wrote:


Denis Koroskin wrote:

 On Wed, 08 Oct 2008 16:21:02 +0400, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org> wrote:


 Walter discovered a showstopper for the curls.

 class A : B
 {
 }


 Andrei


 This is sad .(

 So, what are we left with now? Does everything stay as is or are we
 still looking   alternatives?


I hope we will find a good notation after all. I hope people's patience
hasn't worn thin. One thing that I noticed in the recent discussion was
that quite a few people, even among supporters of the status quo,
admitted that the !() syntax feels a bit odd at least in the beginning.

Andrei


 I'm glad curls didn't get there. If I saw them in the beginning, my
 first reaction would probably have been: "Why block delimiters for
 template parameters? It's even odder than !(".


 how the heck. since like forever there's been three kinds of parens () [] 
 and {}. they pair n all. choosing one for template args is anyone's first 
 guess. but !( i bet you couldn't see comin' if it bit yer nose.


 After staring for some time at templated code written by you and other
 people, I feel like joining !( supporters. It doesn't shout at me any
 louder than != or unary !. There needs to be a space after ! for it to
 shout properly. Nesting is rare and alleviated by aliases.


 really!(how'd ya figure?) besides i often write code like

 sort!
    ((string a, string b) { ... })
    (array);

 pisses me off.


What about:

sort!(

or

sort
     !(

i.e. keep the ! with the (, it's not as bad.

-Steve
Oct 08 2008
prev sibling parent Max Samukha <samukha voliacable.com.removethis> writes:
On Wed, 08 Oct 2008 10:06:29 -0400, superdan <super dan.org> wrote:


Max Samukha Wrote:

 I'm glad curls didn't get there. If I saw them in the beginning, my
 first reaction would probably have been: "Why block delimiters for
 template parameters? It's even odder than !(". 


how the heck. since like forever there's been three kinds of parens () [] and
{}. they pair n all. choosing one for template args is anyone's first guess.
but !( i bet you couldn't see comin' if it bit yer nose. 


You are right about parens, though I don't completely understand the
"but !( i bet you couldn't see comin' if it bit yer nose." part. 


 After staring for some time at templated code written by you and other
 people, I feel like joining !( supporters. It doesn't shout at me any
 louder than != or unary !. There needs to be a space after ! for it to
 shout properly. Nesting is rare and alleviated by aliases.


really!(how'd ya figure?)


from the looks of std.traits/algorithm/functional/etc. and my
templated code. maybe it's not indicative at all.


 besides i often write code like



sort!
    ((string a, string b) { ... })
    (array);

pisses me off.


I usually stick ( to !. Something like:

sort!((string a, string b) {
    ...
    })
    (array);

or use a nested function instead of function literal.
Oct 08 2008
prev sibling next sibling parent superdan <super dan.org> writes:
Andrei Alexandrescu Wrote:


 Denis Koroskin wrote:

 On Wed, 08 Oct 2008 16:21:02 +0400, Andrei Alexandrescu 
 <SeeWebsiteForEmail erdani.org> wrote:
 

 Walter discovered a showstopper for the curls.

 class A : B
 {
 }


 Andrei


 
 This is sad .(
 
 So, what are we left with now? Does everything stay as is or are we 
 still looking   alternatives?


 
 I hope we will find a good notation after all. I hope people's patience 
 hasn't worn thin. One thing that I noticed in the recent discussion was 
 that quite a few people, even among supporters of the status quo, 
 admitted that the !() syntax feels a bit odd at least in the beginning.
 
 Andrei


thin? mine's thicker than ever. no pun intended. let's face it there ain't
gonna ever be a fan club for foo!(bar). after this i know getting rid of that
crap is not off limits. chick let the bra go already. lose patience my ass.
high time to be persuasive now.

and dood. cut the effin' whining. you're in the pole position however yer got
there. if anyone else here asked to change !() nobody would've given a flyin'
intercourse. so enjoy it or whatever. at least spare me the whining.
Oct 08 2008
prev sibling parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
"Andrei Alexandrescu" wrote

 Denis Koroskin wrote:

 On Wed, 08 Oct 2008 16:21:02 +0400, Andrei Alexandrescu 
 <SeeWebsiteForEmail erdani.org> wrote:


 Walter discovered a showstopper for the curls.

 class A : B
 {
 }


 Andrei


 This is sad .(

 So, what are we left with now? Does everything stay as is or are we still 
 looking   alternatives?


 I hope we will find a good notation after all. I hope people's patience 
 hasn't worn thin. One thing that I noticed in the recent discussion was 
 that quite a few people, even among supporters of the status quo, admitted 
 that the !() syntax feels a bit odd at least in the beginning.


As much as I felt odd about it in the beginning, I now feel that !() is the 
best solution.  Simply because it works how we want and is already 
implemented.

I'm actually kinda glad that {} doesn't work because I'd rather leave 
everything the way it is ;)

P.S. I'm a little shocked that it took this long to see that obvious 
counter-case :P

-Steve
Oct 08 2008
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Steven Schveighoffer wrote:

 "Andrei Alexandrescu" wrote

 Denis Koroskin wrote:

 On Wed, 08 Oct 2008 16:21:02 +0400, Andrei Alexandrescu 
 <SeeWebsiteForEmail erdani.org> wrote:


 Walter discovered a showstopper for the curls.

 class A : B
 {
 }


 Andrei


 This is sad .(

 So, what are we left with now? Does everything stay as is or are we still 
 looking   alternatives?


 I hope we will find a good notation after all. I hope people's patience 
 hasn't worn thin. One thing that I noticed in the recent discussion was 
 that quite a few people, even among supporters of the status quo, admitted 
 that the !() syntax feels a bit odd at least in the beginning.


 
 As much as I felt odd about it in the beginning, I now feel that !() is the 
 best solution.  Simply because it works how we want and is already 
 implemented.
 
 I'm actually kinda glad that {} doesn't work because I'd rather leave 
 everything the way it is ;)
 
 P.S. I'm a little shocked that it took this long to see that obvious 
 counter-case :P


A humbling lesson indeed. Walter was actually implementing it when he
discovered the problem.

Andrei
Oct 08 2008
prev sibling next sibling parent KennyTM~ <kennytm gmail.com> writes:
Andrei Alexandrescu wrote:

 Walter discovered a showstopper for the curls.
 
 class A : B
 {
 }
 
 
 Andrei


Too bad. I guess I'll support a!b then. IMO a b looks worse than a!b.
Oct 08 2008
prev sibling next sibling parent reply "Aziz K." <aziz.kerim gmail.com> writes:
On Wed, 08 Oct 2008 14:21:02 +0200, Andrei Alexandrescu  
<SeeWebsiteForEmail erdani.org> wrote:


 Walter discovered a showstopper for the curls.

 class A : B
 {
 }


 Andrei


How about if we leave the current syntax as it is and introduce an  
alternative syntax using Unicode mathematical letters?
Here's a template function using the Unicode angle brackets "〈〉":

template ToString〈ulong U〉
{
     static if (U < 10)
	const char[] ToString = "" ~ cast(char)(U + '0');
     else
	const char[] ToString = ToString〈U / 10〉 ~ ToString〈U % 10〉;
}

The advantages:

*) Programmers can still use the normal ASCII template instantiation  
syntax.
*) The new syntax doesn't create any grammar ambiguities.
*) More potential converts from the C++ world.

The disadvantages:

*) Using the angle brackets would require some effort, although smart  
editors could alleviate this problem if it detects that an identifier is a  
template or if you specify a macro that turns <- into 〈 and -> into 〉.
*) Practically any font I tried in kwrite/kate didn't render the angle  
brackets at all and instead showed a rectangular box. Interestingly enough  
a few other special Unicode mathematical characters are rendered correctly.

Here is a nice page of all mathematical Unicode characters:  
http://tlt.its.psu.edu/suggestions/international/bylanguage/mathchart.html
Oct 08 2008
next sibling parent KennyTM~ <kennytm gmail.com> writes:
Aziz K. wrote:

 On Wed, 08 Oct 2008 14:21:02 +0200, Andrei Alexandrescu 
 <SeeWebsiteForEmail erdani.org> wrote:
 

 Walter discovered a showstopper for the curls.

 class A : B
 {
 }


 Andrei


 
 How about if we leave the current syntax as it is and introduce an 
 alternative syntax using Unicode mathematical letters?
 Here's a template function using the Unicode angle brackets "〈〉":
 
 template ToString〈ulong U〉
 {
     static if (U < 10)
     const char[] ToString = "" ~ cast(char)(U + '0');
     else
     const char[] ToString = ToString〈U / 10〉 ~ ToString〈U % 10〉;
 }
 
 The advantages:
 
 *) Programmers can still use the normal ASCII template instantiation 
 syntax.
 *) The new syntax doesn't create any grammar ambiguities.
 *) More potential converts from the C++ world.
 
 The disadvantages:
 
 *) Using the angle brackets would require some effort, although smart 
 editors could alleviate this problem if it detects that an identifier is 
 a template or if you specify a macro that turns <- into 〈 and -> into 〉.
 *) Practically any font I tried in kwrite/kate didn't render the angle 
 brackets at all and instead showed a rectangular box. Interestingly 
 enough a few other special Unicode mathematical characters are rendered 
 correctly.
 
 Here is a nice page of all mathematical Unicode characters: 
 http://tlt.its.psu.edu/suggestions/international/bylanguage/mathchart.html


What about «XXX», as it is in ISO-8859-1 and I can type them with 
Option+\ and Option+Shift+|. Oh poor Windows users you've to type with 
Alt+171 and Alt+187.

I think characters outside the ASCII range shouldn't be considered 
unless there are no ASCII solutions left. We can still consider:

  a!(b)
  a (b)
Oct 08 2008
prev sibling parent reply "Denis Koroskin" <2korden gmail.com> writes:
On Wed, 08 Oct 2008 18:09:52 +0400, Aziz K. <aziz.kerim gmail.com> wrote:


 On Wed, 08 Oct 2008 14:21:02 +0200, Andrei Alexandrescu  
 <SeeWebsiteForEmail erdani.org> wrote:


 Walter discovered a showstopper for the curls.

 class A : B
 {
 }


 Andrei


 How about if we leave the current syntax as it is and introduce an  
 alternative syntax using Unicode mathematical letters?
 Here's a template function using the Unicode angle brackets "〈〉":

 template ToString〈ulong U〉
 {
      static if (U < 10)
 	const char[] ToString = "" ~ cast(char)(U + '0');
      else
 	const char[] ToString = ToString〈U / 10〉 ~ ToString〈U % 10〉;
 }

 The advantages:

 *) Programmers can still use the normal ASCII template instantiation  
 syntax.
 *) The new syntax doesn't create any grammar ambiguities.
 *) More potential converts from the C++ world.

 The disadvantages:

 *) Using the angle brackets would require some effort, although smart  
 editors could alleviate this problem if it detects that an identifier is  
 a template or if you specify a macro that turns <- into 〈 and -> into 〉.
 *) Practically any font I tried in kwrite/kate didn't render the angle  
 brackets at all and instead showed a rectangular box. Interestingly  
 enough a few other special Unicode mathematical characters are rendered  
 correctly.

 Here is a nice page of all mathematical Unicode characters:  
 http://tlt.its.psu.edu/suggestions/international/bylanguage/mathchart.html


There are also ‹ and ›, that are much cutier than yours!
They also have a benefit that most of the fonts I've checked do support  
them *and* you can type them using Alt+0139 and Alt+0155 hotkeys (i.e. no  
copy-paste or special keyboard layouts needed) :)

template reduce(F...)
{
     NxNHelper!(F).For!(Args).Result reduce(Args...)(Args args)
     {
         alias NxNHelper!(F).For!(Args) Aux;
         ...
     }
}

now becomes:

template reduce(F...)
{
     NxNHelper‹F›.For‹Args›.Result reduce(Args...)(Args args)
     {
         alias NxNHelper‹F›.For‹Args› Aux;
         ...
     }
}

P.S. Hotkeys may be different on your system, check the Character Map  
utility that comes with Windows for right hotkeys. Their codes are U+2039  
and U+203A.
Oct 08 2008
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Denis Koroskin wrote:

 On Wed, 08 Oct 2008 18:09:52 +0400, Aziz K. <aziz.kerim gmail.com> wrote:
 

 On Wed, 08 Oct 2008 14:21:02 +0200, Andrei Alexandrescu 
 <SeeWebsiteForEmail erdani.org> wrote:


 Walter discovered a showstopper for the curls.

 class A : B
 {
 }


 Andrei


 How about if we leave the current syntax as it is and introduce an 
 alternative syntax using Unicode mathematical letters?
 Here's a template function using the Unicode angle brackets "〈〉":

 template ToString〈ulong U〉
 {
      static if (U < 10)
     const char[] ToString = "" ~ cast(char)(U + '0');
      else
     const char[] ToString = ToString〈U / 10〉 ~ ToString〈U % 10〉;
 }

 The advantages:

 *) Programmers can still use the normal ASCII template instantiation 
 syntax.
 *) The new syntax doesn't create any grammar ambiguities.
 *) More potential converts from the C++ world.

 The disadvantages:

 *) Using the angle brackets would require some effort, although smart 
 editors could alleviate this problem if it detects that an identifier 
 is a template or if you specify a macro that turns <- into 〈 and -> 
 into 〉.
 *) Practically any font I tried in kwrite/kate didn't render the angle 
 brackets at all and instead showed a rectangular box. Interestingly 
 enough a few other special Unicode mathematical characters are 
 rendered correctly.

 Here is a nice page of all mathematical Unicode characters: 
 http://tlt.its.psu.edu/suggestions/international/bylanguage/mathchart.html 


 
 There are also ‹ and ›, that are much cutier than yours!
 They also have a benefit that most of the fonts I've checked do support 
 them *and* you can type them using Alt+0139 and Alt+0155 hotkeys (i.e. 
 no copy-paste or special keyboard layouts needed) :)
 
 template reduce(F...)
 {
     NxNHelper!(F).For!(Args).Result reduce(Args...)(Args args)
     {
         alias NxNHelper!(F).For!(Args) Aux;
         ...
     }
 }
 
 now becomes:
 
 template reduce(F...)
 {
     NxNHelper‹F›.For‹Args›.Result reduce(Args...)(Args args)
     {
         alias NxNHelper‹F›.For‹Args› Aux;
         ...
     }
 }
 
 P.S. Hotkeys may be different on your system, check the Character Map 
 utility that comes with Windows for right hotkeys. Their codes are 
 U+2039 and U+203A.


Unicode characters would be great and quite innovative. My personal 
choice is the chevrons Foo«Bar» which are easily distinguished visually 
from ASCII symbols and also easy on the eyes. But I never thought of it 
as an either-or choice, only as an alternate. I mean, requiring special 
editor support or typing Alt+171 whenever it comes about templates will 
do nothing in their favor. So an ASCII-only syntax that's also palatable 
is a must.

It's fairly easy to add editor support such that whenever you type e.g. 
"Foo!(", that morphs into "Foo«»" and places the cursor inside the quotes.

I only have a source of worry. This is to some extent a bet - how sure 
can we be that today's and tomorrow's editors will display Unicode 
characters properly? In fact I was expecting things to be a lot worse. 
All editors I tried in both Unix and Windows displayed the chevrons 
properly (beautifully in fact). Even command-line programs such as less 
and cat had no problem. Could people try the chevrons with various 
editors and report their experience here?

Anyhow, this segment of the discussion is somewhat orthogonal to the 
rest of it as I think we all agree a Unicode notation will be an 
alternative, not an exclusive choice for template instantiations.


Andrei
Oct 08 2008
next sibling parent reply "Dave" <Dave_member pathlink.com> writes:
 Anyhow, this segment of the discussion is somewhat orthogonal to the rest 
 of it as I think we all agree a Unicode notation will be an alternative, 
 not an exclusive choice for template instantiations.


Alternative? That's really what we need; a different group of symbols that 
denote exactly the same thing, in Unicode no less <g>

This whole discussion is getting goofy.

Imagine a code maintainer who has a hard enough time grasping what the 
template code is doing, much less having to slog through code where the 
original developer(s) decided to use the Unicode "alternative" depending on 
what day of the week it was.

Beautiful!

Let's all step back for a second here, and then just grant that Walter's 
original idea is good enough and move on to more important issues.

It took me all of, oh, 5 seconds to look at some D template examples to 
figure out what was going on and start emulating it with a "Hello D Template 
World" of my own for a little practice. So I think the notion that new users 
are going to eschew D or D templates based on the !() syntax is just plain 
wrong, especially since somehow the discussion has now changed to a Unicode 
Alternative (which, BTW, would only make it harder on new users).

Even the original notion of deprecating the !() syntax in favor of something 
else is, to me at least, ludicrous. That said if it still needs to be done, 
we definately need to stick to ASCII.

Geesh!

- Dave
Oct 08 2008
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Dave wrote:

 Anyhow, this segment of the discussion is somewhat orthogonal to the 
 rest of it as I think we all agree a Unicode notation will be an 
 alternative, not an exclusive choice for template instantiations.


 
 Alternative? That's really what we need; a different group of symbols 
 that denote exactly the same thing, in Unicode no less <g>
 
 This whole discussion is getting goofy.
 
 Imagine a code maintainer who has a hard enough time grasping what the 
 template code is doing, much less having to slog through code where the 
 original developer(s) decided to use the Unicode "alternative" depending 
 on what day of the week it was.
 
 Beautiful!
 
 Let's all step back for a second here, and then just grant that Walter's 
 original idea is good enough and move on to more important issues.
 
 It took me all of, oh, 5 seconds to look at some D template examples to 
 figure out what was going on and start emulating it with a "Hello D 
 Template World" of my own for a little practice. So I think the notion 
 that new users are going to eschew D or D templates based on the !() 
 syntax is just plain wrong, especially since somehow the discussion has 
 now changed to a Unicode Alternative (which, BTW, would only make it 
 harder on new users).


You'd be amazed. I personally know two guys - awesome hackers - who 
wouldn't touch Eiffel in part because it introduces comments with "--". 
Not only that, but for one of them that was all the example he had to 
get to never even look at Eiffel. In fact I think this anecdote will 
start the introduction of TDPL. I think it's very instructive with 
regard to how much people care about syntax, and in what arbitrary ways.

Andrei
Oct 08 2008
next sibling parent reply KennyTM~ <kennytm gmail.com> writes:
Andrei Alexandrescu wrote:

 Dave wrote:

 Anyhow, this segment of the discussion is somewhat orthogonal to the 
 rest of it as I think we all agree a Unicode notation will be an 
 alternative, not an exclusive choice for template instantiations.


 Alternative? That's really what we need; a different group of symbols 
 that denote exactly the same thing, in Unicode no less <g>

 This whole discussion is getting goofy.

 Imagine a code maintainer who has a hard enough time grasping what the 
 template code is doing, much less having to slog through code where 
 the original developer(s) decided to use the Unicode "alternative" 
 depending on what day of the week it was.

 Beautiful!

 Let's all step back for a second here, and then just grant that 
 Walter's original idea is good enough and move on to more important 
 issues.

 It took me all of, oh, 5 seconds to look at some D template examples 
 to figure out what was going on and start emulating it with a "Hello D 
 Template World" of my own for a little practice. So I think the notion 
 that new users are going to eschew D or D templates based on the !() 
 syntax is just plain wrong, especially since somehow the discussion 
 has now changed to a Unicode Alternative (which, BTW, would only make 
 it harder on new users).


 
 You'd be amazed. I personally know two guys - awesome hackers - who 
 wouldn't touch Eiffel in part because it introduces comments with "--". 
 Not only that, but for one of them that was all the example he had to 
 get to never even look at Eiffel. In fact I think this anecdote will 
 start the introduction of TDPL. I think it's very instructive with 
 regard to how much people care about syntax, and in what arbitrary ways.
 
 Andrei


Why no one says this when “enum foo = 1;” was introduced. -__-"
Oct 08 2008
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
KennyTM~ wrote:

 Andrei Alexandrescu wrote:

 Dave wrote:

 Anyhow, this segment of the discussion is somewhat orthogonal to the 
 rest of it as I think we all agree a Unicode notation will be an 
 alternative, not an exclusive choice for template instantiations.


 Alternative? That's really what we need; a different group of symbols 
 that denote exactly the same thing, in Unicode no less <g>

 This whole discussion is getting goofy.

 Imagine a code maintainer who has a hard enough time grasping what 
 the template code is doing, much less having to slog through code 
 where the original developer(s) decided to use the Unicode 
 "alternative" depending on what day of the week it was.

 Beautiful!

 Let's all step back for a second here, and then just grant that 
 Walter's original idea is good enough and move on to more important 
 issues.

 It took me all of, oh, 5 seconds to look at some D template examples 
 to figure out what was going on and start emulating it with a "Hello 
 D Template World" of my own for a little practice. So I think the 
 notion that new users are going to eschew D or D templates based on 
 the !() syntax is just plain wrong, especially since somehow the 
 discussion has now changed to a Unicode Alternative (which, BTW, 
 would only make it harder on new users).


 You'd be amazed. I personally know two guys - awesome hackers - who 
 wouldn't touch Eiffel in part because it introduces comments with 
 "--". Not only that, but for one of them that was all the example he 
 had to get to never even look at Eiffel. In fact I think this anecdote 
 will start the introduction of TDPL. I think it's very instructive 
 with regard to how much people care about syntax, and in what 
 arbitrary ways.

 Andrei


 
 Why no one says this when enum foo = 1; was introduced. -__-"


Use of fancy quotes noted :o).

Andrei
Oct 08 2008
parent =?UTF-8?B?QWxleGFuZGVyIFDDoW5law==?= writes:
Andrei Alexandrescu wrote:

 KennyTM~ wrote:

 Andrei Alexandrescu wrote:

 Dave wrote:

 Anyhow, this segment of the discussion is somewhat orthogonal to 
 the rest of it as I think we all agree a Unicode notation will be 
 an alternative, not an exclusive choice for template instantiations.


 Alternative? That's really what we need; a different group of 
 symbols that denote exactly the same thing, in Unicode no less <g>

 This whole discussion is getting goofy.

 Imagine a code maintainer who has a hard enough time grasping what 
 the template code is doing, much less having to slog through code 
 where the original developer(s) decided to use the Unicode 
 "alternative" depending on what day of the week it was.

 Beautiful!

 Let's all step back for a second here, and then just grant that 
 Walter's original idea is good enough and move on to more important 
 issues.

 It took me all of, oh, 5 seconds to look at some D template examples 
 to figure out what was going on and start emulating it with a "Hello 
 D Template World" of my own for a little practice. So I think the 
 notion that new users are going to eschew D or D templates based on 
 the !() syntax is just plain wrong, especially since somehow the 
 discussion has now changed to a Unicode Alternative (which, BTW, 
 would only make it harder on new users).


 You'd be amazed. I personally know two guys - awesome hackers - who 
 wouldn't touch Eiffel in part because it introduces comments with 
 "--". Not only that, but for one of them that was all the example he 
 had to get to never even look at Eiffel. In fact I think this 
 anecdote will start the introduction of TDPL. I think it's very 
 instructive with regard to how much people care about syntax, and in 
 what arbitrary ways.

 Andrei


 Why no one says this when “enum foo = 1;” was introduced. -__-"


 
 Use of fancy quotes noted :o).


Yay! “Welcome aboard!”
Oct 08 2008
prev sibling next sibling parent reply "Jarrett Billingsley" <jarrett.billingsley gmail.com> writes:
On Wed, Oct 8, 2008 at 11:55 AM, Andrei Alexandrescu
<SeeWebsiteForEmail erdani.org> wrote:

 You'd be amazed. I personally know two guys - awesome hackers - who wouldn't
 touch Eiffel in part because it introduces comments with "--". Not only
 that, but for one of them that was all the example he had to get to never
 even look at Eiffel.


Are those the kinds of people we want using D?  ;)
Oct 08 2008
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Jarrett Billingsley wrote:

 On Wed, Oct 8, 2008 at 11:55 AM, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org> wrote:

 You'd be amazed. I personally know two guys - awesome hackers - who wouldn't
 touch Eiffel in part because it introduces comments with "--". Not only
 that, but for one of them that was all the example he had to get to never
 even look at Eiffel.


 
 Are those the kinds of people we want using D?  ;)


I sure think so. You'd be amazed if you found out who the guys are. 
Think up, up, up the food chain.

Andrei
Oct 08 2008
prev sibling next sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
Andrei Alexandrescu wrote:

 You'd be amazed. I personally know two guys - awesome hackers - who 
 wouldn't touch Eiffel in part because it introduces comments with "--". 
 Not only that, but for one of them that was all the example he had to 
 get to never even look at Eiffel. In fact I think this anecdote will 
 start the introduction of TDPL. I think it's very instructive with 
 regard to how much people care about syntax, and in what arbitrary ways.


There's another possibility at work. They may just not like Eiffel, or 
are too lazy to look at it. But they don't say that, because "I'm too 
lazy" doesn't make them look good. So they latch onto some minor issue 
and declare it a deal breaker for them.

How do I know this? I see it all the time. I won't use your product 
because of XYZ. So, I fix XYZ. Still no sale. Obviously, that was not 
the real reason.

You can make yourself crazy trying to cater to people who say "I won't 
use your product because of XYZ" because the odds are very good that 
isn't the real reason at all, it's the excuse.

This is why I place a LOT more weight on what the actual users say they 
need.
Oct 08 2008
parent reply Walter Bright <newshound1 digitalmars.com> writes:
Walter Bright wrote:

 How do I know this? I see it all the time. I won't use your product 
 because of XYZ. So, I fix XYZ. Still no sale. Obviously, that was not 
 the real reason.


I have an amusing anecdote on this. Many years ago back when DOS was 
king and buffalo roamed the plains, I heard a rant from a C++ developer 
that compile speed was the most important issue. He went on and on about 
it. So what C++ compiler did he use? Glockenspiel's translator and MS's 
C compiler. That combination was 4 times slower than other compilers.

Clearly, compile speed was not at all the issue that made him open his 
checkbook, not even close.

-------

10 years ago, a colleague made an impassioned pitch to me that what the 
world needed was a native code Java compiler. I listened politely while 
he told me what a killer compiler that would be, and that if I was smart 
I'd listen to him and build it.

I told him I'd already built one a couple years previously (for 
Symantec) and it did poorly. Nobody cared about it.

-------

Before I started on D, I was convinced by others that the world needed a 
fast Javascript interpreter. I wrote one that was 20 times (yes, twenty 
times) faster than Mozilla's. Nobody cared.

-------

The products I've done which were successful all, 100%, started out with 
people laughing at me for doing them.
Oct 08 2008
next sibling parent bearophile <bearophileHUGS lycos.com> writes:
Walter Bright:

 Before I started on D, I was convinced by others that the world needed a 
 fast Javascript interpreter. I wrote one that was 20 times (yes, twenty 
 times) faster than Mozilla's. Nobody cared.


I don't know why such thing is happened, it sounds weird to me now.
Maybe your timing was wrong, that is maybe you where too much ahead of the
time. In fact today fast javascript VMs seem the "most cool thing" of the
moment. See V8, squirrel fish extreme, WebKit, etc. Maybe your "error" was to
not insert that Javascript interpreter into a version of Mozilla (or Netscape
or something else).

Bye,
bearophile
Oct 08 2008
prev sibling next sibling parent reply Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
Walter Bright wrote:

 Walter Bright wrote:

 How do I know this? I see it all the time. I won't use your product 
 because of XYZ. So, I fix XYZ. Still no sale. Obviously, that was not 
 the real reason.


 
 I have an amusing anecdote on this. Many years ago back when DOS was 
 king and buffalo roamed the plains, I heard a rant from a C++ developer 
 that compile speed was the most important issue. He went on and on about 
 it. So what C++ compiler did he use? Glockenspiel's translator and MS's 
 C compiler. That combination was 4 times slower than other compilers.
 
 Clearly, compile speed was not at all the issue that made him open his 
 checkbook, not even close.
 
 -------
 
 10 years ago, a colleague made an impassioned pitch to me that what the 
 world needed was a native code Java compiler. I listened politely while 
 he told me what a killer compiler that would be, and that if I was smart 
 I'd listen to him and build it.
 
 I told him I'd already built one a couple years previously (for 
 Symantec) and it did poorly. Nobody cared about it.
 
 -------
 
 Before I started on D, I was convinced by others that the world needed a 
 fast Javascript interpreter. I wrote one that was 20 times (yes, twenty 
 times) faster than Mozilla's. Nobody cared.
 
 -------
 
 The products I've done which were successful all, 100%, started out with 
 people laughing at me for doing them.


I don't know the details in all those stories, but it might be, in some 
of those cases, that although you fixed the rant issue people were 
complaining about, you introduced other flaws or shortcomings in your 
production/solution that the other product did not have, and that the 
ranting user might not even have noticed it as important issue unless it 
as missing.

That won't be the case for comments such as "I won't use your product 
because of XYZ.", as those are clear, but it could be for comments 
phrased as "XYZ is the most important issue.", in which the person is 
actually thinking more of "assuming ABC, XYZ is the most important issue."

This is not a perfect analogy, but when I initially met some of my 
programmer friends, I often ranted about Windows instability, lack of 
speed, and general crapness, where often the response was "use Linux" 
(or "use MacOS"). And yes they are all faster, more stable, and robust. 
But, behold, they're simply not Windows, lol! What I mean with this, 
concretely, is that they don't have things or behaviors that Windows 
has, that are not immediately noticeable but are important to me, and 
that due to their nature, hardly ever will have. I'm not even talking 
about the availability of applications or games, but, in the case of 
Linux, stuff like a simple, organized and terse, filesystem model. (and 
in the case of MacOS it's rather "An OS without the gay, please". :-P )


-- 
Bruno Medeiros - Software Developer, MSc. in CS/E graduate
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
Oct 14 2008
parent reply "Bruce Adams" <tortoise_74 yeah.who.co.uk> writes:
On Tue, 14 Oct 2008 22:52:58 +0100, Bruno Medeiros  
<brunodomedeiros+spam com.gmail> wrote:


 This is not a perfect analogy, but when I initially met some of my  
 programmer friends, I often ranted about Windows instability, lack of  
 speed, and general crapness, where often the response was "use Linux"  
 (or "use MacOS"). And yes they are all faster, more stable, and robust.  
 But, behold, they're simply not Windows, lol! What I mean with this,  
 concretely, is that they don't have things or behaviors that Windows  
 has, that are not immediately noticeable but are important to me, and  
 that due to their nature, hardly ever will have. I'm not even talking  
 about the availability of applications or games, but, in the case of  
 Linux, stuff like a simple, organized and terse, filesystem model. (and  
 in the case of MacOS it's rather "An OS without the gay, please". :-P )


OT but what do you mean by a terse filesystem model? I can't think of one
advantage of windows file systems over linuxy ones, unless you actually
like 8.3 file names (okay that's old hat) and semantics that belong in the
file (as in I am type X) being in the filename instead.
The only difference I can think of is the case sensitivity. That counts as
simpler, but certainly not more organised or terse.
Oct 14 2008
parent reply Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
Bruce Adams wrote:

 On Tue, 14 Oct 2008 22:52:58 +0100, Bruno Medeiros 
 <brunodomedeiros+spam com.gmail> wrote:
 

 This is not a perfect analogy, but when I initially met some of my 
 programmer friends, I often ranted about Windows instability, lack of 
 speed, and general crapness, where often the response was "use Linux" 
 (or "use MacOS"). And yes they are all faster, more stable, and 
 robust. But, behold, they're simply not Windows, lol! What I mean with 
 this, concretely, is that they don't have things or behaviors that 
 Windows has, that are not immediately noticeable but are important to 
 me, and that due to their nature, hardly ever will have. I'm not even 
 talking about the availability of applications or games, but, in the 
 case of Linux, stuff like a simple, organized and terse, filesystem 
 model. (and in the case of MacOS it's rather "An OS without the gay, 
 please". :-P )


 OT but what do you mean by a terse filesystem model? I can't think of one
 advantage of windows file systems over linuxy ones, unless you actually
 like 8.3 file names (okay that's old hat) and semantics that belong in the
 file (as in I am type X) being in the filename instead.
 The only difference I can think of is the case sensitivity. That counts as
 simpler, but certainly not more organised or terse.


No, I don't mean the capabilities of the file system itself (ie, NTFS vs 
ext3), in fact, that stuff you mentioned (8.3 filenames or case 
sensitivity are things I consider as disadvantages)

I meant rather the way the Linux filesystem is organized (ie, 
/usr,/dev,/etc, /mnt,/opt,/bin ... etc.) the way mounts have to be made, 
etc.. Without going into detail, I don't like that the OS is spread 
across several directories. I would rather all the OS data were under 
one directory only. So the default directories after installation would 
only be 3: one for the OS, one for user data, one for programs. The same 
thing can be said of programs, I really dislike the traditional unix way 
of installing programs on several different directories, one for 
binaries, one for libraries, one for documentation, one for other 
data... ugh. I also don't like the way mounting works. Even when done 
automatically, I like it like Windows, when a new unit name is assigned 
automatically (hence being able to access my data tersely, ie, in terms 
of pathnames).

-- 
Bruno Medeiros - Software Developer, MSc. in CS/E graduate
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
Oct 15 2008
next sibling parent "Bruce Adams" <tortoise_74 yeah.who.co.uk> writes:
On Wed, 15 Oct 2008 11:40:51 +0100, Bruno Medeiros  
<brunodomedeiros+spam com.gmail> wrote:


 No, I don't mean the capabilities of the file system itself (ie, NTFS vs  
 ext3), in fact, that stuff you mentioned (8.3 filenames or case  
 sensitivity are things I consider as disadvantages)

 I meant rather the way the Linux filesystem is organized (ie,  
 /usr,/dev,/etc, /mnt,/opt,/bin ... etc.) the way mounts have to be made,  
 etc.. Without going into detail, I don't like that the OS is spread  
 across several directories. I would rather all the OS data were under  
 one directory only. So the default directories after installation would  
 only be 3: one for the OS, one for user data, one for programs. The same  
 thing can be said of programs, I really dislike the traditional unix way  
 of installing programs on several different directories, one for  
 binaries, one for libraries, one for documentation, one for other  
 data... ugh. I also don't like the way mounting works. Even when done  
 automatically, I like it like Windows, when a new unit name is assigned  
 automatically (hence being able to access my data tersely, ie, in terms  
 of pathnames).


I find that mildy amusing. I see the things you are decrying as advantages
rather than disadvantages. The way to organise files is into directories.  
If you lump
everything in together you end up with billions of files at the top level.  
In
the bad old days (fortunately before I got into this business), mainframes  
had files
but not directories. Ouch!
The OS data is all under one directory / :).
User data normally resides under /home
Conceptually I don't see much difference between /mnt/C and c:
The 'proper' (google Linux Standards Base) way to install applications on  
linux is
in /opt as in
   /opt/myapp/bin
   /opt/myapp/lib
   /opt/myapp/lib64
   /opt/myapp/etc

The distinctions made between bin, lib & etc are clear and useful.
The only one that isn't intuitive is why does "etc" mean configuration but  
once you know
that it does it is not a problem.
Now I know under windows I can find the OS in /windows
and programs in program files but its very hard to tell what libraries are
associated with what programs or what is configuration versus what is data.
There's no clear distinction between 64bit and 32bit stuff either (as far  
as I know).
lib64 resolves that satisfactorily (though it is a tad ugly).
I get the impression that what standards there are for naming and placing  
'things' in windows
are less standard than we might hope.
There are similar directories under /windows but they are more diverse.
What's the difference between system & system32. Why do we need a  
/windows/twain_32.
In /windows I have .log .exe .dll  and .ini files. I'm sure these would be  
better off placed somewhere
more specific. With the exception of /windows/Sun (for java) It isn't  
obvious whether to blame windows
or some crud I install myself for what's there.
Okay there's a similar problem with /usr and /usr/local but I don't think  
its nearly as bad.

One of the biggest advantages in the Unix way of doing things is the  
virtual file system approach.
Its so useful several dynamic languages have adopted it, including Python  
and TCL.

The /proc file-system is heaven to use. All the details about a running  
process are there:
The command line,  /proc/<pid>/cmdline
the memory usage,  /proc/<pid>/meminfo
a summary status. /proc/<pid>/status
Even if you've overwritten the original exe you can still use
gdb /proc/<pid>/exe <pid> to debug the one that was actually loaded and  
run.

To output audio you can just "cat foobar.wav /dev/audio". No need to mess  
around treating a device
as anything special except when you need to do something special with it.

This sort of stuff alone is worth installing cygwin for.
Oh and hello, symbolic links. Invented centuries ago by men in caves.

Much of Unix is dated and can easily be improved upon. BeOS was very  
promising. Unfortunately it was killed by the monopoly.
I can't see Windows doing it well any time soon.
Embrace and extend seems to mean crush under jackboot and put to work in  
slave camps.
The good ideas don't die (mostly :( ) but they take a lot longer to filter  
up.
Oct 15 2008
prev sibling parent downs <default_357-line yahoo.de> writes:
Bruno Medeiros wrote:

 No, I don't mean the capabilities of the file system itself (ie, NTFS vs
 ext3), in fact, that stuff you mentioned (8.3 filenames or case
 sensitivity are things I consider as disadvantages)
 
 I meant rather the way the Linux filesystem is organized (ie,
 /usr,/dev,/etc, /mnt,/opt,/bin ... etc.) the way mounts have to be made,
 etc.. Without going into detail, I don't like that the OS is spread
 across several directories. I would rather all the OS data were under
 one directory only. So the default directories after installation would
 only be 3: one for the OS, one for user data, one for programs. The same
 thing can be said of programs, I really dislike the traditional unix way
 of installing programs on several different directories, one for
 binaries, one for libraries, one for documentation, one for other
 data... ugh.


There are two ways to organize files - by program, and by type.

Both cannot be pushed into the same tree hierarchy.

Linux prioritizes one, Windows the other.

Obviously, what we need is a tag-based filesystem :)
Oct 16 2008
prev sibling parent Christopher Wright <dhasenan gmail.com> writes:
Walter Bright wrote:

 Walter Bright wrote:

 How do I know this? I see it all the time. I won't use your product 
 because of XYZ. So, I fix XYZ. Still no sale. Obviously, that was not 
 the real reason.


 
 I have an amusing anecdote on this. Many years ago back when DOS was 
 king and buffalo roamed the plains, I heard a rant from a C++ developer 
 that compile speed was the most important issue. He went on and on about 
 it. So what C++ compiler did he use? Glockenspiel's translator and MS's 
 C compiler. That combination was 4 times slower than other compilers.
 
 Clearly, compile speed was not at all the issue that made him open his 
 checkbook, not even close.
 
 -------
 
 10 years ago, a colleague made an impassioned pitch to me that what the 
 world needed was a native code Java compiler. I listened politely while 
 he told me what a killer compiler that would be, and that if I was smart 
 I'd listen to him and build it.
 
 I told him I'd already built one a couple years previously (for 
 Symantec) and it did poorly. Nobody cared about it.
 
 -------
 
 Before I started on D, I was convinced by others that the world needed a 
 fast Javascript interpreter. I wrote one that was 20 times (yes, twenty 
 times) faster than Mozilla's. Nobody cared.
 
 -------
 
 The products I've done which were successful all, 100%, started out with 
 people laughing at me for doing them.


Perhaps you need to hire a marketing agency for your less audacious 
projects?
Oct 14 2008
prev sibling parent "Nick Sabalausky" <a a.a> writes:
"Andrei Alexandrescu" <SeeWebsiteForEmail erdani.org> wrote in message 
news:gcil6r$de3$1 digitalmars.com...

 Dave wrote:

 Anyhow, this segment of the discussion is somewhat orthogonal to the 
 rest of it as I think we all agree a Unicode notation will be an 
 alternative, not an exclusive choice for template instantiations.


 Alternative? That's really what we need; a different group of symbols 
 that denote exactly the same thing, in Unicode no less <g>

 This whole discussion is getting goofy.

 Imagine a code maintainer who has a hard enough time grasping what the 
 template code is doing, much less having to slog through code where the 
 original developer(s) decided to use the Unicode "alternative" depending 
 on what day of the week it was.

 Beautiful!

 Let's all step back for a second here, and then just grant that Walter's 
 original idea is good enough and move on to more important issues.

 It took me all of, oh, 5 seconds to look at some D template examples to 
 figure out what was going on and start emulating it with a "Hello D 
 Template World" of my own for a little practice. So I think the notion 
 that new users are going to eschew D or D templates based on the !() 
 syntax is just plain wrong, especially since somehow the discussion has 
 now changed to a Unicode Alternative (which, BTW, would only make it 
 harder on new users).


 You'd be amazed. I personally know two guys - awesome hackers - who 
 wouldn't touch Eiffel in part because it introduces comments with "--". 
 Not only that, but for one of them that was all the example he had to get 
 to never even look at Eiffel. In fact I think this anecdote will start the 
 introduction of TDPL. I think it's very instructive with regard to how 
 much people care about syntax, and in what arbitrary ways.


I don't think it's worth it to cater to people who are that particular, 
because you'll probably just end up turning away other people who are every 
bit as particular, but on the opposite side of the fence.

That's not to say that small things don't matter and should never be given 
any thought. But making a language design choice of "--" vs. "//" or 
"!(...)" vs "<...>" shouldn't involve worrying about people that are 
dead-set on one or the other.
Oct 08 2008
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Dave wrote:

 Anyhow, this segment of the discussion is somewhat orthogonal to the 
 rest of it as I think we all agree a Unicode notation will be an 
 alternative, not an exclusive choice for template instantiations.


 
 Alternative? That's really what we need; a different group of symbols 
 that denote exactly the same thing, in Unicode no less <g>
 
 This whole discussion is getting goofy.
 
 Imagine a code maintainer who has a hard enough time grasping what the 
 template code is doing, much less having to slog through code where the 
 original developer(s) decided to use the Unicode "alternative" depending 
 on what day of the week it was.
 
 Beautiful!


Oh, one more thought about that. I think the ASCII/Unicode distinction 
changes the space a bit. For example, currently using:

int[] a;

or

int a[];

is decided by nothing in particular. But choosing the chevrons vs. the 
ASCII notation will be largely decided by the toolchain used. That's why 
I doubt any given codebase will be as heterogeneous as it could be with 
regard to other choices.

I wonder what choice the online D documentation should make. Using 
chevrons would be pretty neat, but then random people look at it and are 
like, "how do I ever type this?" etc.


Andrei
Oct 08 2008
parent reply "Dave" <Dave_member pathlink.com> writes:
"Andrei Alexandrescu" <SeeWebsiteForEmail erdani.org> wrote in message 
news:gcim2j$fhu$1 digitalmars.com...

 Dave wrote:

 Anyhow, this segment of the discussion is somewhat orthogonal to the 
 rest of it as I think we all agree a Unicode notation will be an 
 alternative, not an exclusive choice for template instantiations.


 Alternative? That's really what we need; a different group of symbols 
 that denote exactly the same thing, in Unicode no less <g>

 This whole discussion is getting goofy.

 Imagine a code maintainer who has a hard enough time grasping what the 
 template code is doing, much less having to slog through code where the 
 original developer(s) decided to use the Unicode "alternative" depending 
 on what day of the week it was.

 Beautiful!


 Oh, one more thought about that. I think the ASCII/Unicode distinction 
 changes the space a bit. For example, currently using:

 int[] a;

 or

 int a[];

 is decided by nothing in particular. But choosing the chevrons vs. the 
 ASCII notation will be largely decided by the toolchain used. That's why I 
 doubt any given codebase will be as heterogeneous as it could be with 
 regard to other choices.

 I wonder what choice the online D documentation should make. Using 
 chevrons would be pretty neat, but then random people look at it and are 
 like, "how do I ever type this?" etc.


 Andrei


That and the toolchain thing is what really bothers me. Plus the fact that 
I've never been a fan of multiple keystrokes for a single character other 
than CAPS, or of having to setup "smartkeys" for anything, especially 
day-today coding <g>

Back to your earlier Eiffel illustration (which I think speaks to a general 
dislike for any "un-C-like" feel more than anything else), what could be 
more "un-C-like" than something that cannot be displayed properly or even 
entered in a plain old editor that just knows ASCII?

- Dave
Oct 08 2008
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Dave wrote:

 "Andrei Alexandrescu" <SeeWebsiteForEmail erdani.org> wrote in message 
 news:gcim2j$fhu$1 digitalmars.com...

 Dave wrote:

 Anyhow, this segment of the discussion is somewhat orthogonal to the 
 rest of it as I think we all agree a Unicode notation will be an 
 alternative, not an exclusive choice for template instantiations.


 Alternative? That's really what we need; a different group of symbols 
 that denote exactly the same thing, in Unicode no less <g>

 This whole discussion is getting goofy.

 Imagine a code maintainer who has a hard enough time grasping what 
 the template code is doing, much less having to slog through code 
 where the original developer(s) decided to use the Unicode 
 "alternative" depending on what day of the week it was.

 Beautiful!


 Oh, one more thought about that. I think the ASCII/Unicode distinction 
 changes the space a bit. For example, currently using:

 int[] a;

 or

 int a[];

 is decided by nothing in particular. But choosing the chevrons vs. the 
 ASCII notation will be largely decided by the toolchain used. That's 
 why I doubt any given codebase will be as heterogeneous as it could be 
 with regard to other choices.

 I wonder what choice the online D documentation should make. Using 
 chevrons would be pretty neat, but then random people look at it and 
 are like, "how do I ever type this?" etc.


 Andrei


 
 That and the toolchain thing is what really bothers me. Plus the fact 
 that I've never been a fan of multiple keystrokes for a single character 
 other than CAPS, or of having to setup "smartkeys" for anything, 
 especially day-today coding <g>


Agreed. That's why I think an ASCII syntax is necessary.


 Back to your earlier Eiffel illustration (which I think speaks to a 
 general dislike for any "un-C-like" feel more than anything else), what 
 could be more "un-C-like" than something that cannot be displayed 
 properly or even entered in a plain old editor that just knows ASCII?


Well that's the very point. The usage of Unicode is novel enough, out of 
the box enough, and easy on the eyes enough to possibly cause a 
different kind of reaction than the "!(" which is but a permutation of 
old hats. But I agree it's somewhat of a gamble. But then again, you got 
to break eggs to make omelet. In the words of Jerome K. Jerome: "If 
everybody was as conservative as you, Irish sausages would have never 
been invented."

You can tell I'm getting hungry around here :o).


Andrei
Oct 08 2008
prev sibling next sibling parent reply Benji Smith <dlanguage benjismith.net> writes:
Andrei Alexandrescu wrote:

 Unicode characters would be great and quite innovative. My personal 
 choice is the chevrons Foo«Bar» which are easily distinguished visually 
 from ASCII symbols and also easy on the eyes. But I never thought of it 
 as an either-or choice, only as an alternate. I mean, requiring special 
 editor support or typing Alt+171 whenever it comes about templates will 
 do nothing in their favor. So an ASCII-only syntax that's also palatable 
 is a must.


The chevrons would be very cool. Visually, they're my favorite option.


 All editors I tried in both Unix and Windows displayed the chevrons 
 properly (beautifully in fact). Even command-line programs such as less 
 and cat had no problem. Could people try the chevrons with various 
 editors and report their experience here?


I use TextPad on Windows to edit all my D files. It doesn't handle UTF-8 
at all, unfortunately. It'll display the chevrons just fine, but it 
saves them as extended ASCII (byte values: 174 & 175) rather than as 
UTF-8 digraphs. Consequently, DMD rejects the source file.

Hmmmmm. I really ought to switch to a different text editor. Lacking 
good unicode support is really just inexcusable these days.

--benji
Oct 08 2008
parent Benji Smith <dlanguage benjismith.net> writes:
Benji Smith wrote:

 Andrei Alexandrescu wrote:

 Unicode characters would be great and quite innovative. My personal 
 choice is the chevrons Foo«Bar» which are easily distinguished 
 visually from ASCII symbols and also easy on the eyes. But I never 
 thought of it as an either-or choice, only as an alternate. I mean, 
 requiring special editor support or typing Alt+171 whenever it comes 
 about templates will do nothing in their favor. So an ASCII-only 
 syntax that's also palatable is a must.


 
 The chevrons would be very cool. Visually, they're my favorite option.
 

 All editors I tried in both Unix and Windows displayed the chevrons 
 properly (beautifully in fact). Even command-line programs such as 
 less and cat had no problem. Could people try the chevrons with 
 various editors and report their experience here?


 
 I use TextPad on Windows to edit all my D files. It doesn't handle UTF-8 
 at all, unfortunately. It'll display the chevrons just fine, but it 
 saves them as extended ASCII (byte values: 174 & 175) rather than as 
 UTF-8 digraphs. Consequently, DMD rejects the source file.
 
 Hmmmmm. I really ought to switch to a different text editor. Lacking 
 good unicode support is really just inexcusable these days.
 
 --benji


Oh, also, I do about 50% of my work on a laptop keyboard, with no 
separate number pad. The number lock button is a second-class citizen 
(invoked with the function key and scroll-lock), and the ALT-171 trick 
won't work with the top-of-keyboard numbers; only the numpad numbers.

So, on this device, it takes a minimum of twelve keystrokes for me to 
type a pair of chevron characters and then switch back to normal 
keyboard mode:

    FUNCTION
    SCROLL LOCK
    ALT
       j   (keypad: 1)
       7   (keypad: 7)
       u   (keypad: 4)
    ALT
       j   (keypad: 1)
       7   (keypad: 7)
       i   (keypad: 5)
    FUNCTION
    SCROLL LOCK

I think the chevrons are very cool, but there's just no way I'm willing 
to use them on a regular basis. They're too inconvenient to type.

--benji
Oct 08 2008
prev sibling parent "Bill Baxter" <wbaxter gmail.com> writes:
On Wed, Oct 8, 2008 at 11:49 PM, Andrei Alexandrescu
<SeeWebsiteForEmail erdani.org> wrote:

 I only have a source of worry. This is to some extent a bet - how sure ca=


n

 we be that today's and tomorrow's editors will display Unicode characters
 properly? In fact I was expecting things to be a lot worse. All editors I
 tried in both Unix and Windows displayed the chevrons properly (beautiful=


ly

 in fact). Even command-line programs such as less and cat had no problem.
 Could people try the chevrons with various editors and report their
 experience here?


Never underestimate the power of Microsoft to mess up perfectly good standa=
rds!
The Windows console doesn't seem to work properly on utf-8.
Even after chcp 65001, which is supposed to do the trick, I get
question marks appearing before the =AB and =BB symbols.

Also the msys implementation of less claims it's a binary file, and
displays hex codes in place of text.

--bb
Oct 08 2008
prev sibling parent reply J Duncan <jtd514_ ameritech.net> writes:
Andrei Alexandrescu wrote:

 Walter discovered a showstopper for the curls.
 
 class A : B
 {
 }
 
 
 Andrei


Good! ;)
Oct 08 2008
parent Walter Bright <newshound1 digitalmars.com> writes:
J Duncan wrote:

 Good! ;)


LOL!
Oct 08 2008
prev sibling next sibling parent ore-sama <spam here.lot> writes:
KennyTM~ Wrote:


 Isn't it too much asking a user to build a custom keyboard layout just 
 for using the template feature?


it is :)
however user can download and install it. The difficulty can't be compared to
installation of other programming tools.
Oct 08 2008
prev sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
Walter Bright wrote:

 The foo.(bar) syntax seems to be sinking. The foo{bar} seems to be the 
 most practical alternative. So, how about putting it in the next D2 
 release on a trial basis, so people can try it out and see how it looks?


I just discovered this won't work:

    class C : D { }

Oops!
Oct 08 2008
parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
"Walter Bright" wrote

 Walter Bright wrote:

 The foo.(bar) syntax seems to be sinking. The foo{bar} seems to be the 
 most practical alternative. So, how about putting it in the next D2 
 release on a trial basis, so people can try it out and see how it looks?


 I just discovered this won't work:

    class C : D { }

 Oops!


Andrei beat you to it ;)

Read all the respones to this later in this thread "An inconvenient truth"

-Steve
Oct 08 2008