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?

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

There are much bigger fish to fry.


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

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++, Java, C#, they all use <>, what gives? Then I read 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: 1. The user comes from a Java/C++/C#/etc. background and has the same 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): 1. User comes from Java/C++/C#/etc., has the same initial reaction 'Why 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
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?

There are much bigger fish to fry.


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++, Java, C#, they all use <>, what gives? Then I read 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.

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:
 
 1. The user comes from a Java/C++/C#/etc. background and has the same 
 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?

There are much bigger fish to fry.


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?

There are much bigger fish to fry.


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++, Java, C#, they all use <>, what gives? Then I read 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: 1. The user comes from a Java/C++/C#/etc. background and has the same 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.

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):
 
 1. User comes from Java/C++/C#/etc., has the same initial reaction 'Why 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 
 
 

Oct 07 2008
parent reply Tomas Lindquist Olsen <tomas famolsen.dk> writes:
Vincent Richomme wrote:
 Steven Schveighoffer a écrit :
 1. The user comes from a Java/C++/C#/etc. background and has the same 
 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.

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 :
 1. The user comes from a Java/C++/C#/etc. background and has the same 
 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.

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?

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++, Java, C#, they all use <>, what gives? Then I read 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: 1. The user comes from a Java/C++/C#/etc. background and has the same 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): 1. User comes from Java/C++/C#/etc., has the same initial reaction 'Why 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

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?

There are much bigger fish to fry.


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++, Java, C#, they all use <>, what gives? Then I read 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: 1. The user comes from a Java/C++/C#/etc. background and has the same 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): 1. User comes from Java/C++/C#/etc., has the same initial reaction 'Why 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 just too clumsy to mention (namely () #(), although 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?

There are much bigger fish to fry.


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++, Java, C#, they all use <>, what gives? Then I read 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: 1. The user comes from a Java/C++/C#/etc. background and has the same 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): 1. User comes from Java/C++/C#/etc., has the same initial reaction 'Why 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 just too clumsy to mention (namely () #(), although 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 =?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 "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?

There are much bigger fish to fry.


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
next sibling 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} crap. language design rule #0: never design a syntactic element that starts 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.


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 Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Ary Borenszweig wrote:
 superdan escribió:
 bearophile Wrote:

 Walter Bright:
 The foo.(bar) syntax seems to be sinking.

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




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

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



 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=


 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=

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

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 next 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 parent "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  

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
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 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
next sibling 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 like you just bought the wrong keyboard. Java, C#, C/C++, D, etc. all 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
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 
 like you just bought the wrong keyboard.  Java, C#, C/C++, D, etc. all 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 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
 like you just bought the wrong keyboard.  Java, C#, C/C++, D, etc. all 
 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
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
 like you just bought the wrong keyboard.  Java, C#, C/C++, D, etc. all 
 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

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

US-English, because it is easier in C-like programming.

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 like you just bought the wrong keyboard. Java, C#, C/C++, D, etc. all 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

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 DenseMatrix«num» PulType; alias SparseRowsMatrix«num,HashSparseVector» PuuType; alias BiMap«uint, Tuple«uint,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 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
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 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 ;) -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.


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


*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 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:
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 =?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.


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


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


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


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


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


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


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


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 "Steven Schveighoffer" <schveiguy yahoo.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.


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




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

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 !()

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

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

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

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 !()

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

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

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

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


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


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 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 !()

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

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

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

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 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 !()

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

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

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

because unlike brackets, this is easily done without affecting other expressions. It does look ok. Gide


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 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 Pánek" <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 "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=






 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=






 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=





 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=




 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=




 See it doesn't look too bad.

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



 :(

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



 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
prev sibling 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
 like you just bought the wrong keyboard.  Java, C#, C/C++, D, etc. all
 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
 like you just bought the wrong keyboard.  Java, C#, C/C++, D, etc. all
 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 next sibling parent "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.


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


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
prev sibling 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 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 "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?

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


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: ~ ! # $ % ^ & * - + = | \ / , < . > ? :


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


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: ~ ! # $ % ^ & * - + = | \ / , < . > ? :


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


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: ~ ! # $ % ^ & * - + = | \ / , < . > ? :


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


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: ~ ! # $ % ^ & * - + = | \ / , < . > ? :


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. ! #$\.

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?

SomeClass[3] a; // template or array?

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.

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


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: ~ ! # $ % ^ & * - + = | \ / , < . > ? :


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. ! #$\.

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?

SomeClass[3] a; // template or array?

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.

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


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: ~ ! # $ % ^ & * - + = | \ / , < . > ? :


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. ! #$\.

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?

SomeClass[3] a; // template or array?

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.

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


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: ~ ! # $ % ^ & * - + = | \ / , < . > ? :


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. ! #$\.

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?

SomeClass[3] a; // template or array?

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.

I prefer the !() syntax, it makes it incredibly easy to find creations of a template.

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

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

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.

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

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

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

Did you try any of the Eclipse ones, Descent or Mmrnmhrm?

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.

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

encounter? Did you try any of the Eclipse ones, Descent or Mmrnmhrm?

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.

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

encounter? Did you try any of the Eclipse ones, Descent or Mmrnmhrm?

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.

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 

 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 

 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


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: ~ ! # $ % ^ & * - + = | \ / , < . > ? :


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


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: ~ ! # $ % ^ & * - + = | \ / , < . > ? :


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.

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


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: ~ ! # $ % ^ & * - + = | \ / , < . > ? :


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.

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


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: ~ ! # $ % ^ & * - + = | \ / , < . > ? :


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. ! #$\.

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.

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.

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


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: ~ ! # $ % ^ & * - + = | \ / , < . > ? :


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.

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


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: ~ ! # $ % ^ & * - + = | \ / , < . > ? :


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.

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


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: ~ ! # $ % ^ & * - + = | \ / , < . > ? :


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.

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

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
prev sibling next sibling parent 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
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


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: ~ ! # $ % ^ & * - + = | \ / , < . > ? :


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.

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


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: ~ ! # $ % ^ & * - + = | \ / , < . > ? :


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.

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


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: ~ ! # $ % ^ & * - + = | \ / , < . > ? :


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.

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

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

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


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


sometimes uses my laptop and forgets to change the autocompleted field.

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


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


sometimes uses my laptop and forgets to change the autocompleted field.

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


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


sometimes uses my laptop and forgets to change the autocompleted field.

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


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


sometimes uses my laptop and forgets to change the autocompleted field.

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


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


sometimes uses my laptop and forgets to change the autocompleted field.

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


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


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


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


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: ~ ! # $ % ^ & * - + = | \ / , < . > ? :


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.

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
prev sibling parent "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


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: ~ ! # $ % ^ & * - + = | \ / , < . > ? :


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.

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
prev sibling next sibling parent "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=





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





 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=




 eyes for some people.

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



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



 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=



 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=

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

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

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

"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

So, what are we left with now? Does everything stay as is or are we still looking alternatives?

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

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
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 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 next sibling parent "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
prev sibling next 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=

 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=

 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 next sibling parent "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
prev sibling next 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 "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 )

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