www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - "with" should be deprecated with extreme prejudice

reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
I think "with" is a very dangerous feature due to the way it hides 
symbols. It essentially makes the feeblest attempt at modular reasoning 
utterly impossible:

int x, y;
with (whatever)
{
     y += x;
     ++x;
}

What can be said about such code? Nothing. If whatever has or will ever 
have fields x or y or both, the names will bind to them; otherwise, 
they'll bind to the locals. Non-local code dependency at its finest.

Maintenance of any type that is being used with "with" becomes a very 
dangerous proposition because it can silently change meaning of code.

I therefore submit that "with" is an extremely dangerous feature and 
should be removed from the language. What say you?


Andrei
May 17 2009
next sibling parent reply dsimcha <dsimcha yahoo.com> writes:
== Quote from Andrei Alexandrescu (SeeWebsiteForEmail erdani.org)'s article
 I think "with" is a very dangerous feature due to the way it hides
 symbols. It essentially makes the feeblest attempt at modular reasoning
 utterly impossible:
 int x, y;
 with (whatever)
 {
      y += x;
      ++x;
 }
 What can be said about such code? Nothing. If whatever has or will ever
 have fields x or y or both, the names will bind to them; otherwise,
 they'll bind to the locals. Non-local code dependency at its finest.
 Maintenance of any type that is being used with "with" becomes a very
 dangerous proposition because it can silently change meaning of code.
 I therefore submit that "with" is an extremely dangerous feature and
 should be removed from the language. What say you?
 Andrei
Absolutely not. It's far too useful as syntactic sugar when working heavily with plain old data structs, and saves a lot of tedious repetition of the struct instance name. There are lots of similar bonehead things one could do. For one, think of the opposite: accidentally declaring a local variable in a member function that hides the struct- or class-level variable. I see your point, but I simply think the benefits drastically outweigh the downsides. You can pry with() out of my cold, dead hands.
May 17 2009
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
dsimcha wrote:
 == Quote from Andrei Alexandrescu (SeeWebsiteForEmail erdani.org)'s article
 I think "with" is a very dangerous feature due to the way it hides
 symbols. It essentially makes the feeblest attempt at modular reasoning
 utterly impossible:
 int x, y;
 with (whatever)
 {
      y += x;
      ++x;
 }
 What can be said about such code? Nothing. If whatever has or will ever
 have fields x or y or both, the names will bind to them; otherwise,
 they'll bind to the locals. Non-local code dependency at its finest.
 Maintenance of any type that is being used with "with" becomes a very
 dangerous proposition because it can silently change meaning of code.
 I therefore submit that "with" is an extremely dangerous feature and
 should be removed from the language. What say you?
 Andrei
Absolutely not. It's far too useful as syntactic sugar when working heavily with plain old data structs, and saves a lot of tedious repetition of the struct instance name.
Make it a member function! If you don't have access to the struct, use "s." as the prefix! I can't believe that's stopping you from getting work done!
 There are lots of similar bonehead things one could do.  For one,
 think of the opposite:  accidentally declaring a local variable in a member
 function that hides the struct- or class-level variable.  I see your point,
but I
 simply think the benefits drastically outweigh the downsides.  You can pry
with()
 out of my cold, dead hands.
That there are other bad things in D doesn't make "with" any more virtuous! I think you don't entirely get my point. The "with" statement is almost a textbook example of bad language design, creating a mess of long-distance dependencies. It is terrible. I can't believe it snuck under our nose for so long. It's a radioactive-leaking sarcophagus that must be buried. Andrei
May 17 2009
next sibling parent reply BCS <none anon.com> writes:
Hello Andrei,

 dsimcha wrote:
 
 Absolutely not.  It's far too useful as syntactic sugar when working
 heavily with plain old data structs, and saves a lot of tedious
 repetition of the struct instance name.
 
Make it a member function! If you don't have access to the struct, use "s." as the prefix! I can't believe that's stopping you from getting work done!
I don't follow.
May 17 2009
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
BCS wrote:
 Hello Andrei,
 
 dsimcha wrote:

 Absolutely not.  It's far too useful as syntactic sugar when working
 heavily with plain old data structs, and saves a lot of tedious
 repetition of the struct instance name.
Make it a member function! If you don't have access to the struct, use "s." as the prefix! I can't believe that's stopping you from getting work done!
I don't follow.
"s." is hardly any typing. Andrei
May 17 2009
parent reply BCS <none anon.com> writes:
Hello Andrei,

 BCS wrote:
 
 Hello Andrei,
 
 dsimcha wrote:
 
 Absolutely not.  It's far too useful as syntactic sugar when
 working heavily with plain old data structs, and saves a lot of
 tedious repetition of the struct instance name.
 
Make it a member function! If you don't have access to the struct, use "s." as the prefix! I can't believe that's stopping you from getting work done!
I don't follow.
"s." is hardly any typing.
wrong bit, I should have cut more:
 Make it a member function!
?
May 17 2009
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
BCS wrote:
 Hello Andrei,
 
 BCS wrote:

 Hello Andrei,

 dsimcha wrote:

 Absolutely not.  It's far too useful as syntactic sugar when
 working heavily with plain old data structs, and saves a lot of
 tedious repetition of the struct instance name.
Make it a member function! If you don't have access to the struct, use "s." as the prefix! I can't believe that's stopping you from getting work done!
I don't follow.
"s." is hardly any typing.
wrong bit, I should have cut more:
 Make it a member function!
?
In a member function there's no need to prefix each member. Andrei
May 17 2009
next sibling parent reply Rainer Deyke <rainerd eldwood.com> writes:
Andrei Alexandrescu wrote:
 In a member function there's no need to prefix each member.
There isn't, but there should be. IMO. 'with' should be banned. Implicit access to members of 'this' should also be banned. I always use explicit 'this->' in C++ and explicit 'this.' in D. It makes the code much easier to read. -- Rainer Deyke - rainerd eldwood.com
May 17 2009
next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Rainer Deyke wrote:
 Andrei Alexandrescu wrote:
 In a member function there's no need to prefix each member.
There isn't, but there should be. IMO. 'with' should be banned. Implicit access to members of 'this' should also be banned. I always use explicit 'this->' in C++ and explicit 'this.' in D. It makes the code much easier to read.
You see, this is an interesting point. Not using "this." may lead to local bugs. The masking effected by "with" may lead to nonlocal bugs. The difference in risk is enormous. Andrei
May 17 2009
prev sibling next sibling parent "Nick Sabalausky" <a a.a> writes:
"Rainer Deyke" <rainerd eldwood.com> wrote in message 
news:guqno8$2fci$1 digitalmars.com...
 Andrei Alexandrescu wrote:
 In a member function there's no need to prefix each member.
There isn't, but there should be. IMO. 'with' should be banned. Implicit access to members of 'this' should also be banned. I always use explicit 'this->' in C++ and explicit 'this.' in D. It makes the code much easier to read.
This is what I love about Ruby's member access. It's just like you suggest, but with " " prepended instead of "this." which IMO is much too clunky to require for something as common as accessing a member of the current instance. But other than that little quibble I love the idea.
May 17 2009
prev sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Andrei, I agree that "with" is dangerous when it shadows outer names (Python
designers have not added a "with" because of this).

------------------

Rainer Deyke:

 Implicit access to members of 'this' should also be banned.  I always
 use explicit 'this->' in C++ and explicit 'this.' in D.  It makes the
 code much easier to read.
I too usually add "this." in my D code to increase readability. But it's quite long (as "self." in Python), so the solution used by Ruby may be better: before instance attributes (Ruby also uses before class attributes, that are absent in D. D has static variables that are something different and more primitive). ------------------- Derek Parnell:
 int x, y;
 with (p as "somevery.long.struct.or.class[17].name") {
       y += p.x;
       ++p.x;
 }
I also use alias to create a shorter name, so it may be used an extension of the alias syntax (to allow to use {} to define where such alias exists. Also notice the "as" keyword, used in renamed imports too): int x, y; alias somevery.long.struct.or.class[17].name as s { y += p.x; ++p.x; } Bye, bearophile
May 18 2009
parent reply Leandro Lucarella <llucax gmail.com> writes:
bearophile, el 18 de mayo a las 04:33 me escribiste:
 Andrei, I agree that "with" is dangerous when it shadows outer names
 (Python designers have not added a "with" because of this).
They did, but with different semantics =) It's used for RAII (I guess you already know that, but maybe other people don't). -- Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/ ---------------------------------------------------------------------------- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) ----------------------------------------------------------------------------
May 18 2009
parent reply "Nick Sabalausky" <a a.a> writes:
"Leandro Lucarella" <llucax gmail.com> wrote in message 
news:20090518141908.GB9277 burns.springfield.home...
 bearophile, el 18 de mayo a las 04:33 me escribiste:
 Andrei, I agree that "with" is dangerous when it shadows outer names
 (Python designers have not added a "with" because of this).
They did, but with different semantics =) It's used for RAII (I guess you already know that, but maybe other people don't).
You mean like C#'s "using"?
May 18 2009
next sibling parent Leandro Lucarella <llucax gmail.com> writes:
Nick Sabalausky, el 18 de mayo a las 15:23 me escribiste:
 "Leandro Lucarella" <llucax gmail.com> wrote in message 
 news:20090518141908.GB9277 burns.springfield.home...
 bearophile, el 18 de mayo a las 04:33 me escribiste:
 Andrei, I agree that "with" is dangerous when it shadows outer names
 (Python designers have not added a "with" because of this).
They did, but with different semantics =) It's used for RAII (I guess you already know that, but maybe other people don't).
You mean like C#'s "using"?
I don't know C#'s "using" =) In Python, with calls a special method at the begining and some other special method at the end of the block: with lock: do_something() is like: lock.__enter__() try: do_something finally: lock.__exit__() Or something like that. I think you can use a special method to be called if an exception was raised (similar to scope(exit|failure|success)). You can also do something like: with file("some file") as f: x = f.read() to define an alias to a "temporary" object, so you can work with it. f.__enter__() does nothing and f.__exit__() closes the file. This is what I remember, for a full, authoritative, description: http://www.python.org/doc/2.5/whatsnew/pep-343.html -- Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/ ---------------------------------------------------------------------------- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) ----------------------------------------------------------------------------
May 18 2009
prev sibling next sibling parent bearophile <bearophileHUGS lycos.com> writes:
Nick Sabalausky:
 You mean like C#'s "using"? 
http://effbot.org/pyref/context-managers.htm http://www.python.org/dev/peps/pep-0343/ Bye, bearophile
May 18 2009
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Nick Sabalausky wrote:
 "Leandro Lucarella" <llucax gmail.com> wrote in message 
 news:20090518141908.GB9277 burns.springfield.home...
 bearophile, el 18 de mayo a las 04:33 me escribiste:
 Andrei, I agree that "with" is dangerous when it shadows outer names
 (Python designers have not added a "with" because of this).
They did, but with different semantics =) It's used for RAII (I guess you already know that, but maybe other people don't).
You mean like C#'s "using"?
What a God awful feature. Honestly, "what were they sinking about?" People who explained that C# is cool - please explain this one. Andrei
May 18 2009
next sibling parent reply Ary Borenszweig <ary esperanto.org.ar> writes:
Andrei Alexandrescu wrote:
 Nick Sabalausky wrote:
 "Leandro Lucarella" <llucax gmail.com> wrote in message 
 news:20090518141908.GB9277 burns.springfield.home...
 bearophile, el 18 de mayo a las 04:33 me escribiste:
 Andrei, I agree that "with" is dangerous when it shadows outer names
 (Python designers have not added a "with" because of this).
They did, but with different semantics =) It's used for RAII (I guess you already know that, but maybe other people don't).
You mean like C#'s "using"?
What a God awful feature. Honestly, "what were they sinking about?" People who explained that C# is cool - please explain this one. Andrei
http://msdn.microsoft.com/en-us/library/aa664736.aspx
May 18 2009
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Ary Borenszweig wrote:
 Andrei Alexandrescu wrote:
 Nick Sabalausky wrote:
 "Leandro Lucarella" <llucax gmail.com> wrote in message 
 news:20090518141908.GB9277 burns.springfield.home...
 bearophile, el 18 de mayo a las 04:33 me escribiste:
 Andrei, I agree that "with" is dangerous when it shadows outer names
 (Python designers have not added a "with" because of this).
They did, but with different semantics =) It's used for RAII (I guess you already know that, but maybe other people don't).
You mean like C#'s "using"?
What a God awful feature. Honestly, "what were they sinking about?" People who explained that C# is cool - please explain this one. Andrei
http://msdn.microsoft.com/en-us/library/aa664736.aspx
I meant: "explain what were they sinking about when they designed this awful feature", not "explain this awful feature in detail". I know the feature, and that doesn't help its case. Andrei
May 18 2009
prev sibling next sibling parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Mon, 18 May 2009 16:14:29 -0400, Andrei Alexandrescu  
<SeeWebsiteForEmail erdani.org> wrote:

 Nick Sabalausky wrote:
 "Leandro Lucarella" <llucax gmail.com> wrote in message  
 news:20090518141908.GB9277 burns.springfield.home...
 bearophile, el 18 de mayo a las 04:33 me escribiste:
 Andrei, I agree that "with" is dangerous when it shadows outer names
 (Python designers have not added a "with" because of this).
They did, but with different semantics =) It's used for RAII (I guess you already know that, but maybe other people don't).
You mean like C#'s "using"?
What a God awful feature. Honestly, "what were they sinking about?" People who explained that C# is cool - please explain this one.
Had to look it up, never used it. Not sure it's that terrible, it looks to be the equivalent in D of: { scope C = new C(); ... } I suppose it's good in cases where you want to have somewhat manual memory management. Does seem poorly named though. -Steve
May 18 2009
parent Christopher Wright <dhasenan gmail.com> writes:
Steven Schveighoffer wrote:
 On Mon, 18 May 2009 16:14:29 -0400, Andrei Alexandrescu 
 <SeeWebsiteForEmail erdani.org> wrote:
 
 Nick Sabalausky wrote:
 "Leandro Lucarella" <llucax gmail.com> wrote in message 
 news:20090518141908.GB9277 burns.springfield.home...
 bearophile, el 18 de mayo a las 04:33 me escribiste:
 Andrei, I agree that "with" is dangerous when it shadows outer names
 (Python designers have not added a "with" because of this).
They did, but with different semantics =) It's used for RAII (I guess you already know that, but maybe other people don't).
You mean like C#'s "using"?
What a God awful feature. Honestly, "what were they sinking about?" People who explained that C# is cool - please explain this one.
Had to look it up, never used it. Not sure it's that terrible, it looks to be the equivalent in D of: { scope C = new C(); ... } I suppose it's good in cases where you want to have somewhat manual memory management. Does seem poorly named though.
Or transactions, or locking, or similar things. One of the interesting uses of it that I've seen is in Rhino Mocks: using (Mocks.Ordered()) { everything in this block records expected calls where the order matters } but over here, order doesn't matter.
May 18 2009
prev sibling parent reply Bill Baxter <wbaxter gmail.com> writes:
On Mon, May 18, 2009 at 1:14 PM, Andrei Alexandrescu
<SeeWebsiteForEmail erdani.org> wrote:
 Nick Sabalausky wrote:
 "Leandro Lucarella" <llucax gmail.com> wrote in message
 news:20090518141908.GB9277 burns.springfield.home...
 bearophile, el 18 de mayo a las 04:33 me escribiste:
 Andrei, I agree that "with" is dangerous when it shadows outer names
 (Python designers have not added a "with" because of this).
They did, but with different semantics =) It's used for RAII (I guess you already know that, but maybe other people don't).
You mean like C#'s "using"?
What a God awful feature. Honestly, "what were they sinking about?" People who explained that C# is cool - please explain this one.
Looks like using(Foo x = new Foo()) { // do stuff } It's basically equiv of { auto x = new Foo(); scope(exit) foo.Dispose; // do stuff } So it saves a little typing but is capable of less. scope(exit) is way cooler. Python has a similar feature to C#'s using. In Python it's called "with". http://effbot.org/zone/python-with-statement.htm --bb
May 18 2009
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Bill Baxter wrote:
 On Mon, May 18, 2009 at 1:14 PM, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org> wrote:
 Nick Sabalausky wrote:
 "Leandro Lucarella" <llucax gmail.com> wrote in message
 news:20090518141908.GB9277 burns.springfield.home...
 bearophile, el 18 de mayo a las 04:33 me escribiste:
 Andrei, I agree that "with" is dangerous when it shadows outer names
 (Python designers have not added a "with" because of this).
They did, but with different semantics =) It's used for RAII (I guess you already know that, but maybe other people don't).
You mean like C#'s "using"?
What a God awful feature. Honestly, "what were they sinking about?" People who explained that C# is cool - please explain this one.
Looks like using(Foo x = new Foo()) { // do stuff } It's basically equiv of { auto x = new Foo(); scope(exit) foo.Dispose; // do stuff } So it saves a little typing but is capable of less. scope(exit) is way cooler. Python has a similar feature to C#'s using. In Python it's called "with". http://effbot.org/zone/python-with-statement.htm
That's not an "equiv of". It's "completely missing the point of". Each "using" costs one new scope and one level of indentation which makes it non-scalable. Indentation is *expensive*. I think the C# folks missed the class when try/catch/finally showed with extensive examples just how expensive extra indentation is. Andrei
May 18 2009
next sibling parent reply Bill Baxter <wbaxter gmail.com> writes:
On Mon, May 18, 2009 at 1:36 PM, Andrei Alexandrescu
<SeeWebsiteForEmail erdani.org> wrote:
 That's not an "equiv of". It's "completely missing the point of". Each
 "using" costs one new scope and one level of indentation which makes it
 non-scalable. Indentation is *expensive*. I think the C# folks missed the
 class when try/catch/finally showed with extensive examples just how
 expensive extra indentation is.
Oh. Is that the only thing that bothers you about it? That doesn't bother me much since it's basically for things you only want to hold on to for a short span. You should either do your business in a few lines of code and get out of there, or if you can't then make it a function. Anyway, if the indentation bugs you, you can always set emacs up not to indent on "using" blocks. --bb
May 18 2009
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Bill Baxter wrote:
 On Mon, May 18, 2009 at 1:36 PM, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org> wrote:
 That's not an "equiv of". It's "completely missing the point of". Each
 "using" costs one new scope and one level of indentation which makes it
 non-scalable. Indentation is *expensive*. I think the C# folks missed the
 class when try/catch/finally showed with extensive examples just how
 expensive extra indentation is.
Oh. Is that the only thing that bothers you about it? That doesn't bother me much since it's basically for things you only want to hold on to for a short span. You should either do your business in a few lines of code and get out of there, or if you can't then make it a function. Anyway, if the indentation bugs you, you can always set emacs up not to indent on "using" blocks.
It's huge! In TDPL, as soon as I show the expansion of two scope(exit) statements, code became unreadable. No wonder today's software has so crappy error handling and state leaks: languages seem to make it as hard as possible to write correct transactional code. Andrei
May 18 2009
next sibling parent Christopher Wright <dhasenan gmail.com> writes:
Andrei Alexandrescu wrote:
 Bill Baxter wrote:
 On Mon, May 18, 2009 at 1:36 PM, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org> wrote:
 That's not an "equiv of". It's "completely missing the point of". Each
 "using" costs one new scope and one level of indentation which makes it
 non-scalable. Indentation is *expensive*. I think the C# folks missed 
 the
 class when try/catch/finally showed with extensive examples just how
 expensive extra indentation is.
Oh. Is that the only thing that bothers you about it? That doesn't bother me much since it's basically for things you only want to hold on to for a short span. You should either do your business in a few lines of code and get out of there, or if you can't then make it a function. Anyway, if the indentation bugs you, you can always set emacs up not to indent on "using" blocks.
It's huge! In TDPL, as soon as I show the expansion of two scope(exit) statements, code became unreadable. No wonder today's software has so crappy error handling and state leaks: languages seem to make it as hard as possible to write correct transactional code. Andrei
Not to mention, C#'s implementation requires an object that implements IDisposable. This means the code that actually executes is highly non-local, and requires a fair bit of boilerplate. That makes 'using' even less maintainable. (This is also my complaint about using RAII for scope guards in C++.)
May 18 2009
prev sibling parent Bill Baxter <wbaxter gmail.com> writes:
On Mon, May 18, 2009 at 2:56 PM, Andrei Alexandrescu
<SeeWebsiteForEmail erdani.org> wrote:
 Bill Baxter wrote:
 On Mon, May 18, 2009 at 1:36 PM, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org> wrote:
 That's not an "equiv of". It's "completely missing the point of". Each
 "using" costs one new scope and one level of indentation which makes it
 non-scalable. Indentation is *expensive*. I think the C# folks missed t=
he
 class when try/catch/finally showed with extensive examples just how
 expensive extra indentation is.
Oh. =A0Is that the only thing that bothers you about it? That doesn't bother me much since it's basically for things you only want to hold on to for a short span. =A0You should either do your business in a few lines of code and get out of there, or if you can't then make it a function. =A0 Anyway, if the indentation bugs you, you can always set emacs up not to indent on "using" blocks.
It's huge! In TDPL, as soon as I show the expansion of two scope(exit) statements, code became unreadable. No wonder today's software has so crappy error handling and state leaks: languages seem to make it as hard as possible to write correct transactional code.
I agree that scope(exit) is a more general solution that allows for more interesting tricks. I think I'm only disagreeing with you on the magnitude of the lameness. You can always create a new scope if you want one, but you can't remove a scope if it is defined to be a part of the construct. So to me it seems clear that not building the scope into the construct is the way to go. This is also a strike against D's current with(), which also forces a new scope whether you want it or not. --- In related news, scope(exit) is not without it's own issues. Mainly, this doesn't seem nice to me: void foo() { auto x =3D new Thing; scope(exit) x.doADance(); // bunch of code x =3D otherThing; // more code } This will happily doADance on otherThing instead of the original x when it exits. I'm guessing the C# using / Python with are safer wrt re-assignment, but I have not investigated this. Anyone know? --bb
May 18 2009
prev sibling parent reply Joel Lucsy <jjlucsy gmail.com> writes:
Andrei Alexandrescu wrote:
 <SeeWebsiteForEmail erdani.org> wrote:
 using(Foo x = new Foo()) {
      // do stuff
 }

 It's basically equiv of

 {
     auto x = new Foo();
     scope(exit) foo.Dispose;
     // do stuff
 }
That's not an "equiv of". It's "completely missing the point of". Each "using" costs one new scope and one level of indentation which makes it non-scalable. Indentation is *expensive*. I think the C# folks missed the class when try/catch/finally showed with extensive examples just how expensive extra indentation is.
You can mitigate this somewhat by realizing that multiple usings can be wrapped into only one indentation level. Like: using (Bar bar = new Bar()) using (Foo foo = new Foo()) using (Jim jim = new Jim()) { //do something } -- Joel Lucsy "The dinosaurs became extinct because they didn't have a space program." -- Larry Niven
May 19 2009
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Joel Lucsy wrote:
 Andrei Alexandrescu wrote:
 <SeeWebsiteForEmail erdani.org> wrote:
 using(Foo x = new Foo()) {
      // do stuff
 }

 It's basically equiv of

 {
     auto x = new Foo();
     scope(exit) foo.Dispose;
     // do stuff
 }
That's not an "equiv of". It's "completely missing the point of". Each "using" costs one new scope and one level of indentation which makes it non-scalable. Indentation is *expensive*. I think the C# folks missed the class when try/catch/finally showed with extensive examples just how expensive extra indentation is.
You can mitigate this somewhat by realizing that multiple usings can be wrapped into only one indentation level. Like: using (Bar bar = new Bar()) using (Foo foo = new Foo()) using (Jim jim = new Jim()) { //do something }
Thanks, that's a good point. (It's a limited option, though. My code uses scope() statements to do things transactionally (e.g. search Phobos for scope) and the pattern sometimes is to do some work, plant a scope(), then do some work, plan another, etc. This would be difficult with using().) Andrei
May 19 2009
prev sibling parent reply BCS <none anon.com> writes:
Hello Andrei,

 BCS wrote:
 
 Hello Andrei,
 
 BCS wrote:
 
 Hello Andrei,
 
 dsimcha wrote:
 
 Absolutely not.  It's far too useful as syntactic sugar when
 working heavily with plain old data structs, and saves a lot of
 tedious repetition of the struct instance name.
 
Make it a member function! If you don't have access to the struct, use "s." as the prefix! I can't believe that's stopping you from getting work done!
I don't follow.
"s." is hardly any typing.
wrong bit, I should have cut more:
 Make it a member function!
 
?
In a member function there's no need to prefix each member. Andrei
how does that heplp you when you either don't have access to the type or don't want to add the code using the type to it module somelib; struct S { int x, y, z; } module someapp; import somelib; void fn(char[] str, S s) { with(s) { sscanf(str.ptr, "<%i, %i, %i>", &x, &z, &y); // I'm not adding this to S } }
May 17 2009
parent reply "Nick Sabalausky" <a a.a> writes:
"BCS" <none anon.com> wrote in message 
news:a6268ff5f598cba54ecba238c8 news.digitalmars.com...
 void fn(char[] str, S s)
 {
    with(s)
    {
         sscanf(str.ptr, "<%i, %i, %i>", &x, &z, &y); // I'm not adding 
 this to S
    }
 }
You don't really see that as an improvement over this do you?: void fn(char[] str, S s) { sscanf(str.ptr, "<%i, %i, %i>", &s.x, &s.z, &s.y); } If anything, the "with" version looks worse to me, and those three "s." are trivial.
May 17 2009
parent BCS <none anon.com> writes:
Hello Nick,

 "BCS" <none anon.com> wrote in message
 news:a6268ff5f598cba54ecba238c8 news.digitalmars.com...
 
 void fn(char[] str, S s)
 {
 with(s)
 {
 sscanf(str.ptr, "<%i, %i, %i>", &x, &z, &y); // I'm not adding
 this to S
 }
 }
You don't really see that as an improvement over this do you?: void fn(char[] str, S s) { sscanf(str.ptr, "<%i, %i, %i>", &s.x, &s.z, &s.y); } If anything, the "with" version looks worse to me, and those three "s." are trivial.
I do like it over the full form: void someFn() { static void fn(char[] str, S s) { sscanf(str.ptr, "<%i, %i, %i>", &s.x, &s.z, &s.y); } fn(str); }
May 17 2009
prev sibling parent reply Manfred Nowak <svv1999 hotmail.com> writes:
Andrei Alexandrescu wrote:

 It is terrible. I can't believe it snuck under our nose for so long.
I wrote about that more than four years ago: http://www.digitalmars.com/d/archives/digitalmars/D/15653.html -manfred
May 18 2009
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Manfred Nowak wrote:
 Andrei Alexandrescu wrote:
 
 It is terrible. I can't believe it snuck under our nose for so long.
I wrote about that more than four years ago: http://www.digitalmars.com/d/archives/digitalmars/D/15653.html
Very well put. I'm very sorry that costly mistake wasn't fixed at that time. Andrei
May 18 2009
prev sibling next sibling parent reply Jason House <jason.james.house gmail.com> writes:
Andrei Alexandrescu Wrote:

 I think "with" is a very dangerous feature due to the way it hides 
 symbols. It essentially makes the feeblest attempt at modular reasoning 
 utterly impossible:
 
 int x, y;
 with (whatever)
 {
      y += x;
      ++x;
 }
 
 What can be said about such code? Nothing. If whatever has or will ever 
 have fields x or y or both, the names will bind to them; otherwise, 
 they'll bind to the locals. Non-local code dependency at its finest.
 
 Maintenance of any type that is being used with "with" becomes a very 
 dangerous proposition because it can silently change meaning of code.
 
 I therefore submit that "with" is an extremely dangerous feature and 
 should be removed from the language. What say you?
 
 
 Andrei
How about we keep in D's tradition and outlaw shadowing instead? I use "with" rarely, but appreciate it when I do.
May 17 2009
next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Jason House wrote:
 Andrei Alexandrescu Wrote:
 
 I think "with" is a very dangerous feature due to the way it hides
  symbols. It essentially makes the feeblest attempt at modular
 reasoning utterly impossible:
 
 int x, y; with (whatever) { y += x; ++x; }
 
 What can be said about such code? Nothing. If whatever has or will
 ever have fields x or y or both, the names will bind to them;
 otherwise, they'll bind to the locals. Non-local code dependency at
 its finest.
 
 Maintenance of any type that is being used with "with" becomes a
 very dangerous proposition because it can silently change meaning
 of code.
 
 I therefore submit that "with" is an extremely dangerous feature
 and should be removed from the language. What say you?
 
 
 Andrei
How about we keep in D's tradition and outlaw shadowing instead? I use "with" rarely, but appreciate it when I do.
That's a good alternative. At least if someone introduces a field name in the struct and that clashes with something you see, you'll have an error. Andrei
May 17 2009
prev sibling parent reply Robert Fraser <fraserofthenight gmail.com> writes:
Jason House wrote:
 Andrei Alexandrescu Wrote:
 
 I think "with" is a very dangerous feature due to the way it hides 
 symbols. It essentially makes the feeblest attempt at modular reasoning 
 utterly impossible:

 int x, y;
 with (whatever)
 {
      y += x;
      ++x;
 }

 What can be said about such code? Nothing. If whatever has or will ever 
 have fields x or y or both, the names will bind to them; otherwise, 
 they'll bind to the locals. Non-local code dependency at its finest.

 Maintenance of any type that is being used with "with" becomes a very 
 dangerous proposition because it can silently change meaning of code.

 I therefore submit that "with" is an extremely dangerous feature and 
 should be removed from the language. What say you?


 Andrei
How about we keep in D's tradition and outlaw shadowing instead? I use "with" rarely, but appreciate it when I do.
This. Just issue an error/warning if something in the with shadows something outside. That way, if the struct/class/template/whatever changes, affected code will be notified.
May 17 2009
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Robert Fraser wrote:
 Jason House wrote:
 Andrei Alexandrescu Wrote:

 I think "with" is a very dangerous feature due to the way it hides 
 symbols. It essentially makes the feeblest attempt at modular 
 reasoning utterly impossible:

 int x, y;
 with (whatever)
 {
      y += x;
      ++x;
 }

 What can be said about such code? Nothing. If whatever has or will 
 ever have fields x or y or both, the names will bind to them; 
 otherwise, they'll bind to the locals. Non-local code dependency at 
 its finest.

 Maintenance of any type that is being used with "with" becomes a very 
 dangerous proposition because it can silently change meaning of code.

 I therefore submit that "with" is an extremely dangerous feature and 
 should be removed from the language. What say you?


 Andrei
How about we keep in D's tradition and outlaw shadowing instead? I use "with" rarely, but appreciate it when I do.
This. Just issue an error/warning if something in the with shadows something outside. That way, if the struct/class/template/whatever changes, affected code will be notified.
No warning, error! This is a great idea Jason. Andrei
May 17 2009
next sibling parent reply BCS <none anon.com> writes:
Hello Andrei,

 Robert Fraser wrote:
 
 This. Just issue an error/warning if something in the with shadows
 something outside. That way, if the struct/class/template/whatever
 changes, affected code will be notified.
 
No warning, error!
warning if it exist, error if used?
May 17 2009
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
BCS wrote:
 Hello Andrei,
 
 Robert Fraser wrote:

 This. Just issue an error/warning if something in the with shadows
 something outside. That way, if the struct/class/template/whatever
 changes, affected code will be notified.
No warning, error!
warning if it exist, error if used?
I go with Walter's stance: either compiles or not. Warnings suck. Andrei
May 17 2009
parent reply BCS <none anon.com> writes:
Hello Andrei,

 BCS wrote:
 
 Hello Andrei,
 
 Robert Fraser wrote:
 
 This. Just issue an error/warning if something in the with shadows
 something outside. That way, if the struct/class/template/whatever
 changes, affected code will be notified.
 
No warning, error!
warning if it exist, error if used?
I go with Walter's stance: either compiles or not. Warnings suck. Andrei
warningd are optional and off by default.
May 17 2009
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
BCS wrote:
 Hello Andrei,
 
 BCS wrote:

 Hello Andrei,

 Robert Fraser wrote:

 This. Just issue an error/warning if something in the with shadows
 something outside. That way, if the struct/class/template/whatever
 changes, affected code will be notified.
No warning, error!
warning if it exist, error if used?
I go with Walter's stance: either compiles or not. Warnings suck. Andrei
warningd are optional and off by default.
And that doesn't help either! Andrei
May 17 2009
parent reply Don <nospam nospam.com> writes:
Andrei Alexandrescu wrote:
 BCS wrote:
 Hello Andrei,

 BCS wrote:

 Hello Andrei,

 Robert Fraser wrote:

 This. Just issue an error/warning if something in the with shadows
 something outside. That way, if the struct/class/template/whatever
 changes, affected code will be notified.
No warning, error!
warning if it exist, error if used?
I go with Walter's stance: either compiles or not. Warnings suck. Andrei
warningd are optional and off by default.
And that doesn't help either! Andrei
If warnings exist, libraries must not do anything that creates a warning. They are NOT optional. Warnings suck.
May 18 2009
parent reply "Nick Sabalausky" <a a.a> writes:
"Don" <nospam nospam.com> wrote in message 
news:gur1ec$18a$1 digitalmars.com...
 If warnings exist, libraries must not do anything that creates a warning. 
 They are NOT optional.
That's only true if a compiler (such as DMD) is only capable of treating warnings as errors.
May 18 2009
parent reply Don <nospam nospam.com> writes:
Nick Sabalausky wrote:
 "Don" <nospam nospam.com> wrote in message 
 news:gur1ec$18a$1 digitalmars.com...
 If warnings exist, libraries must not do anything that creates a warning. 
 They are NOT optional.
That's only true if a compiler (such as DMD) is only capable of treating warnings as errors.
No. Users complain if library code generates warnings. Because a user cannot make their code warning-free if the libraries they use are generating warnings.
May 18 2009
parent reply "Nick Sabalausky" <a a.a> writes:
"Don" <nospam nospam.com> wrote in message 
news:gurkuo$17nv$1 digitalmars.com...
 Nick Sabalausky wrote:
 "Don" <nospam nospam.com> wrote in message 
 news:gur1ec$18a$1 digitalmars.com...
 If warnings exist, libraries must not do anything that creates a 
 warning. They are NOT optional.
That's only true if a compiler (such as DMD) is only capable of treating warnings as errors.
No. Users complain if library code generates warnings. Because a user cannot make their code warning-free if the libraries they use are generating warnings.
They can if they use a prebuilt version of the library, a lib/a/dll.
May 18 2009
parent reply "Nick Sabalausky" <a a.a> writes:
"Nick Sabalausky" <a a.a> wrote in message 
news:guscm2$2jff$1 digitalmars.com...
 "Don" <nospam nospam.com> wrote in message 
 news:gurkuo$17nv$1 digitalmars.com...
 Nick Sabalausky wrote:
 "Don" <nospam nospam.com> wrote in message 
 news:gur1ec$18a$1 digitalmars.com...
 If warnings exist, libraries must not do anything that creates a 
 warning. They are NOT optional.
That's only true if a compiler (such as DMD) is only capable of treating warnings as errors.
No. Users complain if library code generates warnings. Because a user cannot make their code warning-free if the libraries they use are generating warnings.
They can if they use a prebuilt version of the library, a lib/a/dll.
Warnings are optional built-in lint tools (kinda like how we already have a built-in doc tool, built-in code generation tool (ie, mixins), built-in profiling/code-coverage, etc). And it's pretty difficult to claim that lint tools are bad. So deciding that (optional) warnings are bad just because some people might get warnings from a non-pre-compiled lib and then bitch about it is a rather large case of "throwing away the baby with the bathwater". And even aside from pre-compiled lib's (which admittedly probably wouldn't work for template-using libs, although I consider that more a problem with the existing obj/lib formats than anything else), there are still other solutions that don't "throw away the baby with the bathwater". Like maybe a switch that only enables warnings for anything in the same package as "main". Or "-warn=this.package.only", or "-nowarn=tango", etc. And before anyone notices that I've filed a bug report in tango for a warning despite my "complaining about warnings in libs is silly" stance, I'll point out that I've filed bug reports for warnings in libs *only* because DMD refuses to allow warnings to actually be treated as warnings (or at least until bugzilla #2567 (with patch) gets taken care of). Yes, under current versions of DMD, fixing warnings are manditory for libs. But that's only because DMD's current handling of "warnings" is one hell of a bizarre anomoly (ie, In DMD, "warnings" are really "optional errors" at this point, *not* true warnings. And yes, *that* kind of so-called "warning" *is* a bad thing).
May 18 2009
parent Don <nospam nospam.com> writes:
Nick Sabalausky wrote:
 "Nick Sabalausky" <a a.a> wrote in message 
 news:guscm2$2jff$1 digitalmars.com...
 "Don" <nospam nospam.com> wrote in message 
 news:gurkuo$17nv$1 digitalmars.com...
 Nick Sabalausky wrote:
 "Don" <nospam nospam.com> wrote in message 
 news:gur1ec$18a$1 digitalmars.com...
 If warnings exist, libraries must not do anything that creates a 
 warning. They are NOT optional.
That's only true if a compiler (such as DMD) is only capable of treating warnings as errors.
No. Users complain if library code generates warnings. Because a user cannot make their code warning-free if the libraries they use are generating warnings.
They can if they use a prebuilt version of the library, a lib/a/dll.
Warnings are optional built-in lint tools (kinda like how we already have a built-in doc tool, built-in code generation tool (ie, mixins), built-in profiling/code-coverage, etc). And it's pretty difficult to claim that lint tools are bad.
If they are standardised, they _are_ bad, because they become mandatory for libraries. If they're not standardised, no problem, it's just a third-party tool which you particular users find helpful in eliminating bugs; and demanding that a library support your third-party tool is unreasonable. Warnings can be categorised based on "probability that they indicate a bug", with a range from: (1) it almost always indicates a bug --> in this case, it should be an error. (2) it hardly ever indicates a bug --> in this case, it's useless at best, but in practice it's harmful. If there's anything in between, it indicates a weakness in that part of the language design. DMD's warnings are now extremely close to (1), I hope they can become errors soon. (Eg, leaving off a return statement in a function which doesn't contain asm statements is almost guaranteed to be a bug).
May 20 2009
prev sibling parent Spacen Jasset <spacenjasset yahoo.co.uk> writes:
BCS wrote:
 Hello Andrei,
 
 Robert Fraser wrote:

 This. Just issue an error/warning if something in the with shadows
 something outside. That way, if the struct/class/template/whatever
 changes, affected code will be notified.
No warning, error!
warning if it exist, error if used?
It probably should be an error. Then though, you have the unfortunate thing whereby adding something to say struct X will shadow and generate a compile error, which you can only fix by: a) Not using with b) rename identifier in your sturct c) rename local variable I seem to remember some language (I think it's VB) supporting with that required a "." prefix in front of with enclosures. Like so: auto a = 0; with (foo) { a = 0; .a = 1; } This is a bit dangerous too though, in terms of typos.
May 18 2009
prev sibling parent Derek Parnell <derek psych.ward> writes:
On Sun, 17 May 2009 20:56:14 -0500, Andrei Alexandrescu wrote:

 Andrei Alexandrescu Wrote:

 I think "with" is a very dangerous feature due to the way it hides 
 symbols.
 Jason House wrote:
 This. Just issue an error/warning if something in the with shadows 
 something outside. That way, if the struct/class/template/whatever 
 changes, affected code will be notified.
On Sun, 17 May 2009 20:56:14 -0500, Andrei Alexandrescu wrote:
 No warning, error!
 
 This is a great idea Jason.
Wow, that's they way I thought it already worked. I never use 'with' because of the reasons that Andrei has already cited, but if it doesn't trip such syntax-mines already then I'm even more glad that I haven't used it. So yes Jason, that idea has my support too ... though I still can't see me using the construct anytime soon. -- Derek Parnell Melbourne, Australia skype: derek.j.parnell
May 17 2009
prev sibling next sibling parent reply Georg Wrede <georg.wrede iki.fi> writes:
Andrei Alexandrescu wrote:
 I think "with" is a very dangerous feature due to the way it hides 
 symbols. It essentially makes the feeblest attempt at modular reasoning 
 utterly impossible:
 
 int x, y;
 with (whatever)
 {
     y += x;
     ++x;
 }
 
 What can be said about such code? Nothing. If whatever has or will ever 
 have fields x or y or both, the names will bind to them; otherwise, 
 they'll bind to the locals. Non-local code dependency at its finest.
 
 Maintenance of any type that is being used with "with" becomes a very 
 dangerous proposition because it can silently change meaning of code.
 
 I therefore submit that "with" is an extremely dangerous feature and 
 should be removed from the language. What say you?
Non-touch typers will riot.
May 17 2009
next sibling parent BCS <none anon.com> writes:
Hello Georg,

 Non-touch typers will riot.
 
Not a good reason as nobody cares about us (first person, plural, non inclusive of the second person (why can't English have a better set of pronouns?)).
May 17 2009
prev sibling parent reply "Nick Sabalausky" <a a.a> writes:
"Georg Wrede" <georg.wrede iki.fi> wrote in message 
news:guqdmn$1tks$2 digitalmars.com...
 Andrei Alexandrescu wrote:
 I therefore submit that "with" is an extremely dangerous feature and 
 should be removed from the language. What say you?
Non-touch typers will riot.
I'm not a touch-typer, but I've never seen much of a point to "with". If I have to access a bunch of members of "foo.member.x.bar[17].fizzle", I'll just do "auto fizz = foo.member.x.bar[17].fizzle;" and use that, or put it into a function that takes a "typeof(fizze)", or do something else along those lines. I've yet to come across a case where something like that isn't perfectly sufficient.
May 17 2009
parent reply BCS <none anon.com> writes:
Hello Nick,

 "Georg Wrede" <georg.wrede iki.fi> wrote in message
 news:guqdmn$1tks$2 digitalmars.com...
 
 Andrei Alexandrescu wrote:
 
 I therefore submit that "with" is an extremely dangerous feature and
 should be removed from the language. What say you?
 
Non-touch typers will riot.
I'm not a touch-typer, but I've never seen much of a point to "with". If I have to access a bunch of members of "foo.member.x.bar[17].fizzle", I'll just do "auto fizz = foo.member.x.bar[17].fizzle;" and use that, or put it into
that dosn't work if it's by value and is used as an Lvalue.
 a function that takes a "typeof(fizze)", or do something else along
like this? that looks... odd. void outer() { void inner(ref T t) { t.somthing; ... } inner(foo.member.x.bar[17].fizzle); }
 those lines. I've yet to come across a case where something like
 that isn't perfectly sufficient.
 
May 17 2009
parent reply "Nick Sabalausky" <a a.a> writes:
"BCS" <none anon.com> wrote in message 
news:a6268ff5f5d8cba54f824da454 news.digitalmars.com...
 Hello Nick,

 I'm not a touch-typer, but I've never seen much of a point to "with".
 If I have to access a bunch of members of
 "foo.member.x.bar[17].fizzle", I'll just do "auto fizz = 
 foo.member.x.bar[17].fizzle;" and use that, or put it into
that dosn't work if it's by value and is used as an Lvalue.
 a function that takes a "typeof(fizze)", or do something else along
like this? that looks... odd. void outer() { void inner(ref T t) { t.somthing; ... } inner(foo.member.x.bar[17].fizzle); }
 those lines. I've yet to come across a case where something like
 that isn't perfectly sufficient.
Like I said, "or something along those lines". It all depends on the specific code. I just haven't ever had any specific case where I felt like I needed "with".
May 17 2009
parent reply Robert Fraser <fraserofthenight gmail.com> writes:
Nick Sabalausky wrote:
 "BCS" <none anon.com> wrote in message 
 news:a6268ff5f5d8cba54f824da454 news.digitalmars.com...
 Hello Nick,

 I'm not a touch-typer, but I've never seen much of a point to "with".
 If I have to access a bunch of members of
 "foo.member.x.bar[17].fizzle", I'll just do "auto fizz = 
 foo.member.x.bar[17].fizzle;" and use that, or put it into
that dosn't work if it's by value and is used as an Lvalue.
 a function that takes a "typeof(fizze)", or do something else along
like this? that looks... odd. void outer() { void inner(ref T t) { t.somthing; ... } inner(foo.member.x.bar[17].fizzle); }
 those lines. I've yet to come across a case where something like
 that isn't perfectly sufficient.
Like I said, "or something along those lines". It all depends on the specific code. I just haven't ever had any specific case where I felt like I needed "with".
I mainly use it for initialization of things: static S opCall(_x, _y) { S s; with(s) { x = _x; y = _y; happiness = null; } return s; }
May 17 2009
next sibling parent "Nick Sabalausky" <a a.a> writes:
"Robert Fraser" <fraserofthenight gmail.com> wrote in message 
news:guqpkf$2h49$2 digitalmars.com...
 I mainly use it for initialization of things:

 static S opCall(_x, _y)
 {
 S s;
 with(s)
 {
 x = _x;
 y = _y;
 happiness = null;
 }
 return s;
 }
For things like that I have a series of util mixins, for example: class Foo { int x; int y; char[] name; this(int x, int y, char[] name) { mixin(initMember!(x, y, name)); } } And even if I didn't, I've never considered the repeated "this." or "s.", etc, to be non-trivial enough to really be worth an extra language construct - and I'm normally a complete DRY-maniac.
May 17 2009
prev sibling next sibling parent Bill Baxter <wbaxter gmail.com> writes:
On Sun, May 17, 2009 at 9:53 PM, Robert Fraser
<fraserofthenight gmail.com> wrote:
 Nick Sabalausky wrote:
 "BCS" <none anon.com> wrote in message
 news:a6268ff5f5d8cba54f824da454 news.digitalmars.com...
 Hello Nick,

 I'm not a touch-typer, but I've never seen much of a point to "with".
 If I have to access a bunch of members of
 "foo.member.x.bar[17].fizzle", I'll just do "auto fizz =3D
 foo.member.x.bar[17].fizzle;" and use that, or put it into
that dosn't work if it's by value and is used as an Lvalue.
 a function that takes a "typeof(fizze)", or do something else along
like this? that looks... odd. void outer() { =A0 =A0void inner(ref T t) =A0 =A0{ =A0 =A0 =A0 =A0 t.somthing; =A0 =A0 =A0 =A0 ... =A0 =A0} =A0 =A0inner(foo.member.x.bar[17].fizzle); }
 those lines. I've yet to come across a case where something like
 that isn't perfectly sufficient.
Like I said, "or something along those lines". It all depends on the specific code. I just haven't ever had any specific case where I felt li=
ke I
 needed "with".
I mainly use it for initialization of things: static S opCall(_x, _y) { =A0 =A0 =A0 =A0S s; =A0 =A0 =A0 =A0with(s) =A0 =A0 =A0 =A0{ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0x =3D _x; =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0y =3D _y; =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0happiness =3D null; =A0 =A0 =A0 =A0} =A0 =A0 =A0 =A0return s; }
I find this to be the most convenient way to transform C++ constructors into struct static opCalls, so I've used it a lot in code I translated from C++. But the need there should be eliminated by giving structs real constructors instead of this static opCall kludge (I thought D2 had this already, actually...) One place 'with' is kinda cute is for configuring new objects in a fire & forget manner: with (new WindowWidget) { parent =3D mainWin; width =3D 100; height =3D 100; } That gives you something that works almost like named arguments. --- On a related note I do think some mechanism similar to C++'s "using" would be good to have that would let you bring particular namespaces into the direct lookup scope. However the same caveats apply -- it should never be possible to silently change the meaning of code that has "using foo.bar" by adding or removing something from module foo.bar. I think someone proposed allowing aliasing of dot like "alias foo.bar ." to achieve that -- kind of like alias this for structs. Anyway, I think if you're going to allow co-mingling of module scopes with top-level imports, then it should also be possible to limit the mingling to just inner scopes. --bb
May 18 2009
prev sibling parent reply Ary Borenszweig <ary esperanto.org.ar> writes:
Robert Fraser wrote:
 Nick Sabalausky wrote:
 "BCS" <none anon.com> wrote in message 
 news:a6268ff5f5d8cba54f824da454 news.digitalmars.com...
 Hello Nick,

 I'm not a touch-typer, but I've never seen much of a point to "with".
 If I have to access a bunch of members of
 "foo.member.x.bar[17].fizzle", I'll just do "auto fizz = 
 foo.member.x.bar[17].fizzle;" and use that, or put it into
that dosn't work if it's by value and is used as an Lvalue.
 a function that takes a "typeof(fizze)", or do something else along
like this? that looks... odd. void outer() { void inner(ref T t) { t.somthing; ... } inner(foo.member.x.bar[17].fizzle); }
 those lines. I've yet to come across a case where something like
 that isn't perfectly sufficient.
Like I said, "or something along those lines". It all depends on the specific code. I just haven't ever had any specific case where I felt like I needed "with".
I mainly use it for initialization of things: static S opCall(_x, _y) { S s; with(s) { x = _x; y = _y; happiness = null; } return s; }
Because of that, C# added the following syntax: new S { x = _x, y = _y, }; And I think that could replace "with" with no problem, because most of the time (or all of the time) you use it when initializing an object.
May 18 2009
parent bearophile <bearophileHUGS lycos.com> writes:
Ary Borenszweig:

 Because of that, C# added the following syntax:
 
 new S {
    x = _x,
    y = _y,
 };
Better to add named arguments to methods/functions and templates, it's a more general solution. Bye, bearophile
May 18 2009
prev sibling next sibling parent reply Lester L. Martin II <lestermartin92 gmail.com> writes:
Andrei Alexandrescu Wrote:

 I think "with" is a very dangerous feature due to the way it hides 
 symbols. It essentially makes the feeblest attempt at modular reasoning 
 utterly impossible:
 
 int x, y;
 with (whatever)
 {
      y += x;
      ++x;
 }
 
 What can be said about such code? Nothing. If whatever has or will ever 
 have fields x or y or both, the names will bind to them; otherwise, 
 they'll bind to the locals. Non-local code dependency at its finest.
 
 Maintenance of any type that is being used with "with" becomes a very 
 dangerous proposition because it can silently change meaning of code.
 
 I therefore submit that "with" is an extremely dangerous feature and 
 should be removed from the language. What say you?
 
 
 Andrei
I agree with dsimcha. When you do this, do you consider how much code written in D actually uses this. I find it very, very useful. It's deprecation and further removal would take a huge hit on my code. What I would propose instead is that you can't modify variables outside of the scope, but only those that reside in the type whatever. In this case, you can't possibly change the variables outside of the with(whatever) scope, but you can modify anything that is in the type whatever, because this is how I believe it is mainly used. Deprecation of this feature should never happen. I doubt I and dsimcha will be the only unhappy coders. Lester L. Martin II
May 17 2009
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Lester L. Martin II wrote:
 Andrei Alexandrescu Wrote:
 
 I think "with" is a very dangerous feature due to the way it hides
  symbols. It essentially makes the feeblest attempt at modular
 reasoning utterly impossible:
 
 int x, y; with (whatever) { y += x; ++x; }
 
 What can be said about such code? Nothing. If whatever has or will
 ever have fields x or y or both, the names will bind to them;
 otherwise, they'll bind to the locals. Non-local code dependency at
 its finest.
 
 Maintenance of any type that is being used with "with" becomes a
 very dangerous proposition because it can silently change meaning
 of code.
 
 I therefore submit that "with" is an extremely dangerous feature
 and should be removed from the language. What say you?
 
 
 Andrei
I agree with dsimcha. When you do this, do you consider how much code written in D actually uses this.
That code is a bomb waiting to explode.
 I find it very, very useful.
I believe you don't understand its extreme dangers.
 It's deprecation and further
 removal would take a huge hit on my code.
I understand.
 What I would propose
 instead is that you can't modify variables outside of the scope, but
 only those that reside in the type whatever. In this case, you can't
 possibly change the variables outside of the with(whatever) scope,
 but you can modify anything that is in the type whatever, because
 this is how I believe it is mainly used. Deprecation of this feature
 should never happen. I doubt I and dsimcha will be the only unhappy
 coders.
I think that restriction would be too harsh, as it would make with essentially an isolated bubble. Would you be ok with Jason's suggestion that shadowing will be flagged? Consider: struct Widget { //int wyda; } void main() { int wyda; Widget w; with (w) { wyda = 4; } } Would you agree to issue a compile-time error upon uncommenting the member of Widget. Andrei
May 17 2009
parent Lester L. Martin II <lestermartin92 gmail.com> writes:
Andrei Alexandrescu Wrote:

 Lester L. Martin II wrote:
 Andrei Alexandrescu Wrote:
 
 I think "with" is a very dangerous feature due to the way it hides
  symbols. It essentially makes the feeblest attempt at modular
 reasoning utterly impossible:
 
 int x, y; with (whatever) { y += x; ++x; }
 
 What can be said about such code? Nothing. If whatever has or will
 ever have fields x or y or both, the names will bind to them;
 otherwise, they'll bind to the locals. Non-local code dependency at
 its finest.
 
 Maintenance of any type that is being used with "with" becomes a
 very dangerous proposition because it can silently change meaning
 of code.
 
 I therefore submit that "with" is an extremely dangerous feature
 and should be removed from the language. What say you?
 
 
 Andrei
I agree with dsimcha. When you do this, do you consider how much code written in D actually uses this.
That code is a bomb waiting to explode.
 I find it very, very useful.
I believe you don't understand its extreme dangers.
 It's deprecation and further
 removal would take a huge hit on my code.
I understand.
 What I would propose
 instead is that you can't modify variables outside of the scope, but
 only those that reside in the type whatever. In this case, you can't
 possibly change the variables outside of the with(whatever) scope,
 but you can modify anything that is in the type whatever, because
 this is how I believe it is mainly used. Deprecation of this feature
 should never happen. I doubt I and dsimcha will be the only unhappy
 coders.
I think that restriction would be too harsh, as it would make with essentially an isolated bubble. Would you be ok with Jason's suggestion that shadowing will be flagged? Consider: struct Widget { //int wyda; } void main() { int wyda; Widget w; with (w) { wyda = 4; } } Would you agree to issue a compile-time error upon uncommenting the member of Widget. Andrei
I understand that my suggestion makes with a bubble, but I always use and have always considered its use to mainly be for accessing the members of a variable and being able to act upon (set) them. That's why I believe that my idea was good. The shadowing idea will be fine. If I'm right, you can easily just escape the scope by placing the with statement in a new function if worst comes to worst and names match in almost every scope. Or it could automagically be made a member function.
May 17 2009
prev sibling next sibling parent reply BCS <none anon.com> writes:
Hello Andrei,

 I think "with" is a very dangerous feature due to the way it hides
 symbols. It essentially makes the feeblest attempt at modular
 reasoning utterly impossible:
 
 int x, y;
 with (whatever)
 {
 y += x;
 ++x;
 }

 Maintenance of any type that is being used with "with" becomes a very
 dangerous proposition because it can silently change meaning of code.
I'd be willing to go the half way solution of making accessing a shadowing symbol an error, resulting in (loudly) not being able to access either.
May 17 2009
parent reply Johan Granberg <lijat.meREM OVEgmail.com> writes:
BCS wrote:

 Hello Andrei,
 
 I think "with" is a very dangerous feature due to the way it hides
 symbols. It essentially makes the feeblest attempt at modular
 reasoning utterly impossible:
 
 int x, y;
 with (whatever)
 {
 y += x;
 ++x;
 }

 Maintenance of any type that is being used with "with" becomes a very
 dangerous proposition because it can silently change meaning of code.
I'd be willing to go the half way solution of making accessing a shadowing symbol an error, resulting in (loudly) not being able to access either.
I think this solution is a good idea but that removing or restricting anything more regarding with is a bad idea as others have pointed out. I'm using with quit a lot and it was one of thous things that attracted me to D (I get the feeling that D has a quite pragmatic way of looking at language features, if it's usefull lets have it unless it's harmfull to other parts of D, sort of.). On a similar note, Andrei, what is this spree of removing features? Ok some are obviously bad, imaginary types for example, but why remove other stuff such as commplex and with?
May 18 2009
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Johan Granberg wrote:
 BCS wrote:
 
 Hello Andrei,

 I think "with" is a very dangerous feature due to the way it hides
 symbols. It essentially makes the feeblest attempt at modular
 reasoning utterly impossible:

 int x, y;
 with (whatever)
 {
 y += x;
 ++x;
 }

 Maintenance of any type that is being used with "with" becomes a very
 dangerous proposition because it can silently change meaning of code.
I'd be willing to go the half way solution of making accessing a shadowing symbol an error, resulting in (loudly) not being able to access either.
I think this solution is a good idea but that removing or restricting anything more regarding with is a bad idea as others have pointed out. I'm using with quit a lot and it was one of thous things that attracted me to D (I get the feeling that D has a quite pragmatic way of looking at language features, if it's usefull lets have it unless it's harmfull to other parts of D, sort of.).
I personally still think it's a bad feature because it introduces long-distance coupling between symbols defined in two different places, both distinct from the place where the statement is used! Consider: import wyda; // defines symbol write import geeba; // defines struct S { ... } void main() { S s; with (s) { write(5); } } Machiavelly would jump in joy at such code. What did I achieve? I saved a few "s.". What did I lose? The ability so say anything, but absolutely anything on what the code does. If S changes, the code may compile and run, yet doing something completely different. The dependency is not between the code as seen and wyda or geeba. It's between wyda and geeba, intermediated by "with"! I mean, if one _planned_ to design a maximally damaging language feature one couldn't come up with something better. And for what? Because you find it convenient to not type "s." a few times or just go in the blessed object and define a member? Is _this_ what makes or breaks your productivity? And are you willing to pay the ability to do the feeblest reasoning about your code for that doubtful benefit? This is so against every single good notion of language design, I kid you not I feel my blood pressure rising only as I think of it. No amount of "but I find it useful" can protect this awful non-feature. It should be taken in the back and shot in the head, no trial. Shoot the lawyer too if it has one.
 On a similar note, Andrei, what is this spree of removing features? Ok some
 are obviously bad, imaginary types for example, but why remove other stuff
 such as commplex and with?
TDPL is coming out. This is quite literally the last chance to shed some old skin. Complex as a built-in does nothing of interest to anyone except a cute syntax for literals that nobody uses (how many remarkable complex literals could you imagine?) About "with"... see above before I die of a heart attack. The baroque "!<>=" operators became much more attractive since Walter said he's considering making them overloadable. On the other hand new features are coming, which I believe are "good skin". Narrowing integral conversions will go. Walter is working on a very cool scheme for inferring the range of expressions that makes casts unnecessary in many cases. Casts are a plague not only for safe code, but also for generic code that wants to be scalable and change-robust. The ease with which C and C++ allow losing state and the drowning necessity of integral casts in Java or C# are both extremes that I'm happy to see D avoid. Final switch works with enums and forces you to handle each and every value of the enum. Regular switch gets ranged cases by the syntax case a: .. case b: (I've always thought switch would be greatly helped by that). Static foreach might be making it too. Andrei
May 18 2009
next sibling parent reply Jarrett Billingsley <jarrett.billingsley gmail.com> writes:
On Mon, May 18, 2009 at 1:46 PM, Andrei Alexandrescu
<SeeWebsiteForEmail erdani.org> wrote:

 Final switch works with enums and forces you to handle each and every value
 of the enum. Regular switch gets ranged cases by the syntax case a: .. case
 b: (I've always thought switch would be greatly helped by that).
Kind of an odd syntax. Why not "case a .. b:"? Parsing issues?
 Static foreach might be making it too.
That'd be a nice addition. Especially with __traits returning arrays/tuples, it'd be an alternative to CTFE (shudder) or template recursion.
May 18 2009
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Jarrett Billingsley wrote:
 On Mon, May 18, 2009 at 1:46 PM, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org> wrote:
 
 Final switch works with enums and forces you to handle each and every value
 of the enum. Regular switch gets ranged cases by the syntax case a: .. case
 b: (I've always thought switch would be greatly helped by that).
Kind of an odd syntax. Why not "case a .. b:"? Parsing issues?
It's consistency. Everywhere in the language a .. b implies b is excluded. In a switch you want to include b. So I reflected that in the syntax. In fact, I confess I'm more proud than I should be about that little detail.
 Static foreach might be making it too.
That'd be a nice addition. Especially with __traits returning arrays/tuples, it'd be an alternative to CTFE (shudder) or template recursion.
Yah, can't wait. Andrei
May 18 2009
parent Jarrett Billingsley <jarrett.billingsley gmail.com> writes:
On Mon, May 18, 2009 at 1:57 PM, Andrei Alexandrescu
<SeeWebsiteForEmail erdani.org> wrote:

 of the enum. Regular switch gets ranged cases by the syntax case a: ..
 case
 b: (I've always thought switch would be greatly helped by that).
Kind of an odd syntax. =A0Why not "case a .. b:"? =A0Parsing issues?
It's consistency. Everywhere in the language a .. b implies b is excluded=
.
 In a switch you want to include b. So I reflected that in the syntax. In
 fact, I confess I'm more proud than I should be about that little detail.
Well after all this discussion, I think I like your syntax after all :P In fact, I might be inclined to use it in MiniD. It already has ranged cases of the form "case a .. b:" but the inconsistency between it being inclusive and slices being inclusive has never sat well with me.
May 18 2009
prev sibling parent reply Robert Fraser <fraserofthenight gmail.com> writes:
Jarrett Billingsley wrote:
 it'd be an alternative to CTFE (shudder)
Why shudder? CTFE has familiar syntax (the syntax of the runtime language) and, I've found, less bugs in general.
May 18 2009
parent reply Jarrett Billingsley <jarrett.billingsley gmail.com> writes:
On Mon, May 18, 2009 at 3:29 PM, Robert Fraser
<fraserofthenight gmail.com> wrote:
 Jarrett Billingsley wrote:
 it'd be an alternative to CTFE (shudder)
Why shudder? CTFE has familiar syntax (the syntax of the runtime language) and, I've found, less bugs in general.
It's extremely difficult to make CTFE functions that work. The compiler often coughs on seemingly-legal code, sometimes due to bugs. The biggest issue with developing CTFE functions is that if something does go wrong during CTFE, all you get is a message along the lines of "function X can't be evaluated at compile time", with no indication as to _why_ it couldn't, no stack trace etc. There's also no means of outputting debugging statements during CTFE. At least with templates I have pragma(msg). CTFE is also mainly useful for building up string mixins, but since everything inside a CTFE function has to be code that can be executed at runtime as well, you forgo some really useful metaprogramming features that are native to templates, like pattern matching. So it ends up being convenient in simple cases (i.e. given a list of names, generate a bunch of almost-identical declarations for them), but not in more complex ones. Not to mention it's much slower than template instantiation and eats memory for lunch.
May 18 2009
parent BCS <ao pathlink.com> writes:
Reply to Jarrett,

 Not to mention it's much slower than template instantiation and eats
 memory for lunch
 
Template instantiation eats memory for breakfast lunch and dinner, plus a few snack in between (it adds a symbol table entry of anything you do) and is not much, if any, faster.
May 18 2009
prev sibling next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Andrei Alexandrescu:

TDPL is coming out. This is quite literally the last chance to shed some old
skin.<
I think D2 will not fully stop evolving when TDPL is printed. I don't think D2 will be fully finished in few months.
 About "with"... see above before I die of a heart attack.<
Qualified imports are safer. And it's better for: import foo; to import in the current namespace only the "foo" module name.
 The baroque "!<>=" operators became much more attractive since Walter 
 said he's considering making them overloadable.
That makes them more flexible, but this doesn't make them more readable or nice looking :-)
 Walter is working on a very cool scheme for inferring the range of expressions
that makes casts unnecessary in many cases.<
I guess all we can do is Wait and Hope then? :-)
 Final switch works with enums and forces you to handle each and every value of
the enum.<
Do you mean like this? final switch (...) {...}
 Regular switch gets ranged cases by the syntax case a: .. case b: (I've always
thought switch would be greatly helped by that).<
Isn't a syntax like the following better? case a .. b: Or (much) better still, isn't it better to give a built-in syntax to something like your iota(), removing the special syntax of ranged foreach and such ranged switch case? Bye, bearophile
May 18 2009
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
bearophile wrote:
 Andrei Alexandrescu:
 About "with"... see above before I die of a heart attack.<
Qualified imports are safer. And it's better for: import foo; to import in the current namespace only the "foo" module name.
Yeah, so for the sake of a feature intended to save some minor typing, I'm thrilled to introduce a feature requiring me a ton of typing.
 Do you mean like this? final switch (...) {...}
Yah. enum DeviceStatus { ready, busy, fail } ... void process(DeviceStatus status) { final switch (status) { case DeviceStatus.ready: ... case DeviceStatus.busy: ... case DeviceStatus.fail: ... } } If you then add a new value for DeviceStatus, the final switch won't compile.
 Regular switch gets ranged cases by the syntax case a: .. case b:
 (I've always thought switch would be greatly helped by that).<
Isn't a syntax like the following better? case a .. b: Or (much) better still, isn't it better to give a built-in syntax to something like your iota(), removing the special syntax of ranged foreach and such ranged switch case?
I think it's important to give switch a crack on properly optimizing its code. And case a .. b I just explained to Jarrett. Andrei
May 18 2009
parent reply bearophile <bearophileHUGS lycos.com> writes:
Andrei Alexandrescu:

Yeah, so for the sake of a feature intended to save some minor typing, I'm
thrilled to introduce a feature requiring me a ton of typing.<
Please, be serious. You can have the same old behavour with just 2 added chars: import foo.*; I have discussed about something like this four times in the past.
 enum DeviceStatus { ready, busy, fail }
 ...
 void process(DeviceStatus status) {
     final switch (status) {
     case DeviceStatus.ready:
        ...
     case DeviceStatus.busy:
        ...
     case DeviceStatus.fail:
        ...
     }
 }
 If you then add a new value for DeviceStatus, the final switch
 won't compile.
1) I don't like this idea. I think that normal switches can behave like such final switches. 2) I'd like Walter to ask people before implement features. People here discuss about feature X for a week, that they think it is cool (or maybe even useful!), and then weeks later Walter implements feature Y that no one was asking for. This is not just wrong, it's silly. 3) If you want to add a second kind of switch, then let's add a truly safer one, with no fall-through, etc. We have discussed about this more than one time. See the switch of C#, for example.
I think it's important to give switch a crack on properly optimizing its code.<
Of course. That's why I was talking about a "built-in syntax". I am sure the compiler doesn't need rocket science to optimize a new syntax to say the same thing. I have done this in the ShedSkin compiler, and it's doable.
And case a .. b I just explained to Jarrett.<
1) The syntax you talk about isn't intuitive. This is bad. 2) Before introducing new syntax it's MUCH better to discuss it first, because what's intuitive for me can be not intuitive for you. So the best you can do is to ask for several ideas to people, and then use the one that is both logically sound, and intuitive for most people. This is how Python syntax is designed. And Python3 has less warts than most languages around. 3) In the past I have discussed how Ruby, Chapel and other languages solve this problem. A solution is to use a .. #b to denote that b is inclusive. You may not like this idea (and I am not sure I like it much), but it doesn't look so much worse than case a: .. case b: Thank you uncovering part of the future work of Walter, giving people 1 chance to cach design mistakes before they happen. Bye, bearophile
May 18 2009
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
bearophile wrote:
 2) I'd like Walter to ask people before implement features. People
 here discuss about feature X for a week, that they think it is cool
 (or maybe even useful!), and then weeks later Walter implements
 feature Y that no one was asking for. This is not just wrong, it's
 silly.
To be brutally honest, I think many features discussed here are completely missing the point. Only a couple of posts ago, there were suggestions for alternate syntaxes for "with" that were not only useless, they added new keywords like they were up for grabs. If somebody wants to make "as" into a keyword, I'm liable to go postal. More to the point, I forgot the exact context, but recently a poster wrote a long message describing how he wants simultaneously two completely antagonistic features, to finally (and to his credit) courageously face the inevitable truth: that he had no idea what he really wanted. This is happening a lot in this group, just that most of the time it goes undetected. My perception is that the recently-added features are of good quality.
 3) In the past I have discussed how Ruby, Chapel
 and other languages solve this problem. A solution is to use a .. #b
 to denote that b is inclusive. You may not like this idea (and I am
 not sure I like it much), but it doesn't look so much worse than case
 a: .. case b:
It looks and is a million times worse. If you know D1 and see case 'a': .. case 'z': you pretty sure know exactly what's going on. If you know D1 but haven't been illuminated by the likes of Ruby and Chapel and see: case 'a' .. #'z': you're like, what the heck were they thinking about when they designed this ass-backward syntax? Andrei
May 18 2009
next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Andrei Alexandrescu:

Thank you for your answers.

To be brutally honest, I think many features discussed here are completely
missing the point.<
I know, most of the things I say are wrong or useless. I am not good at all. Yet, no one is perfect, and in the past I/we have discussed about several things that are badly designed in D.
Only a couple of posts ago, there were suggestions for alternate syntaxes for
"with" that were not only useless, they added new keywords like they were up
for grabs. If somebody wants to make "as" into a keyword, I'm liable to go
postal.<
That was me, and it was not a much serious proposal (I was not sure in the first place). But sometimes I don't like how much D relies on punctuation (like the semicolon in the middle of foreach). When I see a syntax like: alias foo bar; I often have troubles understanding if the new name is bar or foo. A syntax like: alias foo as bar; Is less ambigous. Now feel free to go postal :-) I have even troubles to remember if in the following syntax n is the number of rows or the number of columns: auto mat = new[][](n, m); Maybe I'm just dumb :-)
My perception is that the recently-added features are of good quality.<
This is probably thank to you too, because now there are two people designing things instead of just one.
 It looks and is a million times worse. If you know D1 and see
 case 'a': .. case 'z':
 you pretty sure know exactly what's going on. If you know D1 but haven't
been illuminated by the likes of Ruby and Chapel and see:
 case 'a' .. #'z':
 you're like, what the heck were they thinking about when they designed this
ass-backward syntax?
The problem with a syntax like: case 'a': .. case 'z': Is that it's not general enough. The language clearly needs a syntax to specify ranges, both closed and open, that can iterated on, that support opIn_r, that can lazily iterated, that have a length, etc. Using a .. syntax inside the foreach, and another .. syntax inside the switch, and defining iota() into the std lib, doesn't like a good idea to me. It howls for a general language-wide solution. Bye, bearophile
May 18 2009
next sibling parent reply Robert Fraser <fraserofthenight gmail.com> writes:
bearophile wrote:
 I am not good at all.
*shares some prozac*
May 18 2009
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Robert Fraser wrote:
 bearophile wrote:
 I am not good at all.
*shares some prozac*
I'll have some too. I didn't mean to put bearophile or anyone down more than myself. The crude reality is that D does not have any real programming language expert on board. We are trying to do the best with what we have. Andrei
May 18 2009
prev sibling next sibling parent "Nick Sabalausky" <a a.a> writes:
"bearophile" <bearophileHUGS lycos.com> wrote in message 
news:guscb3$2iqj$1 digitalmars.com...
 I have even troubles to remember if in the following syntax n is the 
 number of rows or the number of columns:
 auto mat = new[][](n, m);
That's just a matter of convention. Neither is inherently a row or a column.
May 18 2009
prev sibling parent reply Christopher Wright <dhasenan gmail.com> writes:
bearophile wrote:
 When I see a syntax like:
 alias foo bar;
 I often have troubles understanding if the new name is bar or foo.
 A syntax like:
 alias foo as bar;
 Is less ambigous.
 Now feel free to go postal :-)
The more common suggestion is: alias bar = foo; This has the advantage of looking like renamed imports and not adding keywords. Additionally, C# uses similar syntax: using Name=My.Really.Long.Namespace.CollidingName;
May 18 2009
next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Christopher Wright:
 The more common suggestion is:
 alias bar = foo;
This is acceptable, thank you :-) Now I'd like to know what others think about that. Bye, bearophile
May 18 2009
next sibling parent div0 <div0 users.sourceforge.net> writes:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

bearophile wrote:
 Christopher Wright:
 The more common suggestion is:
 alias bar = foo;
This is acceptable, thank you :-) Now I'd like to know what others think about that. Bye, bearophile
That's rather nice. Would make coding after a few beers easier. - -- My enormous talent is exceeded only by my outrageous laziness. http://www.ssTk.co.uk -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFKEe/FT9LetA9XoXwRAoCuAJ9ns6O5kEMXVftt6GZP26wNTpCJxACgiSaN Q4ClZbiH5vGmlFHpBPnsSuc= =hJnG -----END PGP SIGNATURE-----
May 18 2009
prev sibling next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
bearophile wrote:
 Christopher Wright:
 The more common suggestion is:
 alias bar = foo;
This is acceptable, thank you :-) Now I'd like to know what others think about that. Bye, bearophile
I'd love that. Andrei
May 18 2009
prev sibling next sibling parent Christopher Wright <dhasenan gmail.com> writes:
bearophile wrote:
 Christopher Wright:
 The more common suggestion is:
 alias bar = foo;
This is acceptable, thank you :-) Now I'd like to know what others think about that. Bye, bearophile
Why thank me? It's been batted around a few times, and it was not my suggestion originally.
May 18 2009
prev sibling parent reply Derek Parnell <derek psych.ward> writes:
On Mon, 18 May 2009 19:24:13 -0400, bearophile wrote:

 Christopher Wright:
 The more common suggestion is:
 alias bar = foo;
This is acceptable, thank you :-) Now I'd like to know what others think about that.
But does that mean 'when I write "bar" I really mean "foo"' or visa versa? Just pointing out that the '=' sign doesn't really automatically make it fully intuitive. -- Derek Parnell Melbourne, Australia skype: derek.j.parnell
May 18 2009
next sibling parent reply "Nick Sabalausky" <a a.a> writes:
"Derek Parnell" <derek psych.ward> wrote in message 
news:2m4gnylh4ggc.1hhjynllwweim.dlg 40tude.net...
 On Mon, 18 May 2009 19:24:13 -0400, bearophile wrote:

 Christopher Wright:
 The more common suggestion is:
 alias bar = foo;
This is acceptable, thank you :-) Now I'd like to know what others think about that.
But does that mean 'when I write "bar" I really mean "foo"' or visa versa? Just pointing out that the '=' sign doesn't really automatically make it fully intuitive.
It makes it consistent with "auto foo = bar;" which is a big improvement in intuitiveness.
May 19 2009
parent Chris Mueller <ruun.net googlemail.com> writes:
Nick Sabalausky schrieb:
 "Derek Parnell" <derek psych.ward> wrote in message 
 news:2m4gnylh4ggc.1hhjynllwweim.dlg 40tude.net...
 On Mon, 18 May 2009 19:24:13 -0400, bearophile wrote:

 Christopher Wright:
 The more common suggestion is:
 alias bar = foo;
This is acceptable, thank you :-) Now I'd like to know what others think about that.
But does that mean 'when I write "bar" I really mean "foo"' or visa versa? Just pointing out that the '=' sign doesn't really automatically make it fully intuitive.
It makes it consistent with "auto foo = bar;" which is a big improvement in intuitiveness.
I would also welcome this change. Like someone here already mentioned it's also consistent with renaming imports, which has the same syntax. import io = std.stdio; Chris
May 18 2009
prev sibling parent Christopher Wright <dhasenan gmail.com> writes:
Derek Parnell wrote:
 On Mon, 18 May 2009 19:24:13 -0400, bearophile wrote:
 
 Christopher Wright:
 The more common suggestion is:
 alias bar = foo;
This is acceptable, thank you :-) Now I'd like to know what others think about that.
But does that mean 'when I write "bar" I really mean "foo"' or visa versa? Just pointing out that the '=' sign doesn't really automatically make it fully intuitive.
It would work like assignments and renamed imports. Since when did you make an assignment in D where the right hand side was modified according to the value of the left hand side? It's not immediately obvious to someone who hasn't programmed yet, necessarily, but to someone even vaguely familiar with any modern programming language, there is one obvious meaning.
May 19 2009
prev sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Christopher Wright:
 The more common suggestion is:
 alias bar = foo;
I can add this too: typedef Bar = Foo; This changes in typedef and alias can solve two of the small problems I have with D. Let's see if Walter accepts such ideas. (In the last days two more ideas have floated in this newsgroup: disallowing floating point literals with nothing before the point like ".57", and making "with" safer). Such small improvements pile up. Bye, bearophile
May 20 2009
parent KennyTM~ <kennytm gmail.com> writes:
bearophile wrote:
 Christopher Wright:
 The more common suggestion is:
 alias bar = foo;
I can add this too: typedef Bar = Foo; This changes in typedef and alias can solve two of the small problems I have with D. Let's see if Walter accepts such ideas. (In the last days two more ideas have floated in this newsgroup: disallowing floating point literals with nothing before the point like ".57", and making "with" safer). Such small improvements pile up. Bye, bearophile
typedef int MyInt = 1;
May 20 2009
prev sibling parent Yigal Chripun <yigal100 gmail.com> writes:
Andrei Alexandrescu wrote:
 To be brutally honest, I think many features discussed here are 
 completely missing the point. Only a couple of posts ago, there were 
 suggestions for alternate syntaxes for "with" that were not only 
 useless, they added new keywords like they were up for grabs. If 
 somebody wants to make "as" into a keyword, I'm liable to go postal. 
 More to the point, I forgot the exact context, but recently a poster 
 wrote a long message describing how he wants simultaneously two 
 completely antagonistic features, to finally (and to his credit) 
 courageously face the inevitable truth: that he had no idea what he 
 really wanted. This is happening a lot in this group, just that most of 
 the time it goes undetected.
 
 Andrei
we don't need any new syntax to get rid of with. most of the time you use it like (for example): for (int i = 0; i < 10; ++i) { with (myLongVar[i].myLongMember.MylongOtherMember) { myLongMethod(); } } so why not allow: for (int i = 0; i < 10; ++i) { alias myLongVar[i].myLongMember.MylongOtherMember tempSymbol; tempSymbol.myLongMethod(); } this doesn't add any new syntax
May 18 2009
prev sibling parent Derek Parnell <derek psych.ward> writes:
On Mon, 18 May 2009 14:33:29 -0400, bearophile wrote:

 3) If you want to add a second kind of switch, then let's
    add a truly safer one, with no fall-through, etc.
**WARNING** an off-topic aside follows ... The next version of the Euphoria programming language has implemented 'switch'. The language only had 'if-elsif-' constructs before. The new 'switch' has this syntax ... 'switch' ['with fallthru'] 'do' 'case' EXPRESSION 'then' STATEMENTS [( 'break' | 'fallthru')] . . . 'end' 'switch' Yeah, I know is not a punctuation-heavy language like D, but get over that for now. The point is that by default the cases do not fallthru. If you want cases to fallthru by default you need to add the 'with fallthru' qualifier. Furthermore, each case can have 'break' to explicitly prevent it falling thru to the next case, or 'fallthru' to explicitly cause it to fall thru to the next case. If you have neither, then it does the default action indicated on the 'switch' line. procedure classify(char c) write("You passed ") switch c do case '#' then writeln("a hash sign.") case in "012345679" then writeln("a digit.") case 'A' to 'Z', 'a' to 'z' then writeln("an ASCII character.") case '.', ',', ':', ';', '!', '?' then writeln("a punctuation mark.") case else writeln("quite a character!") end switch end procedure -- Derek Parnell Melbourne, Australia skype: derek.j.parnell
May 18 2009
prev sibling next sibling parent reply Bill Baxter <wbaxter gmail.com> writes:
On Mon, May 18, 2009 at 10:46 AM, Andrei Alexandrescu
<SeeWebsiteForEmail erdani.org> wrote:
 Johan Granberg wrote:
 BCS wrote:

 Hello Andrei,

 I think "with" is a very dangerous feature due to the way it hides
 symbols. It essentially makes the feeblest attempt at modular
 reasoning utterly impossible:

 int x, y;
 with (whatever)
 {
 y +=3D x;
 ++x;
 }

 Maintenance of any type that is being used with "with" becomes a very
 dangerous proposition because it can silently change meaning of code.
I'd be willing to go the half way solution of making accessing a shadowing symbol an error, resulting in (loudly) not being able to access either.
I think this solution is a good idea but that removing or restricting anything more regarding with is a bad idea as others have pointed out. I'm using with quit a lot and it was one of thous things that attracted =
me
 to D (I get the feeling that D has a quite pragmatic way of looking at
 language features, if it's usefull lets have it unless it's harmfull to
 other parts of D, sort of.).
I personally still think it's a bad feature because it introduces long-distance coupling between symbols defined in two different places, b=
oth
 distinct from the place where the statement is used! Consider:

 import wyda; =A0// defines symbol write
 import geeba; // defines struct S { ... }

 void main()
 {
 =A0 S s;
 =A0 with (s) {
 =A0 =A0 =A0write(5);
 =A0 }
 }

 Machiavelly would jump in joy at such code. What did I achieve? I saved a
 few "s.". What did I lose? The ability so say anything, but absolutely
 anything on what the code does.
Shouldn't the feature just follow the same rules as module imports do? If I say import foo; import bar; void main() { write(5); } It's fine as long as foo and bar don't both define bar. Why shouldn't the same scope resolution mechanism not apply to with? So in your example write(5) is fine as long as S and some module don't both define a write(). I think that's what others were saying in the other thread, too. Makes things more consistent too. Given that do you still object to with() so vehemently? --bb If S changes, the code may compile and run,
 yet doing something completely different. The dependency is not between t=
he
 code as seen and wyda or geeba. It's between wyda and geeba, intermediate=
d
 by "with"! I mean, if one _planned_ to design a maximally damaging langua=
ge
 feature one couldn't come up with something better. And for what? Because
 you find it convenient to not type "s." a few times or just go in the
 blessed object and define a member? Is _this_ what makes or breaks your
 productivity? And are you willing to pay the ability to do the feeblest
 reasoning about your code for that doubtful benefit?

 This is so against every single good notion of language design, I kid you
 not I feel my blood pressure rising only as I think of it. No amount of "=
but
 I find it useful" can protect this awful non-feature. It should be taken =
in
 the back and shot in the head, no trial. Shoot the lawyer too if it has o=
ne.
 On a similar note, Andrei, what is this spree of removing features? Ok
 some
 are obviously bad, imaginary types for example, but why remove other stu=
ff
 such as commplex and with?
TDPL is coming out. This is quite literally the last chance to shed some =
old
 skin. Complex as a built-in does nothing of interest to anyone except a c=
ute
 syntax for literals that nobody uses (how many remarkable complex literal=
s
 could you imagine?) About "with"... see above before I die of a heart
 attack.

 The baroque "!<>=3D" operators became much more attractive since Walter s=
aid
 he's considering making them overloadable.

 On the other hand new features are coming, which I believe are "good skin=
".
 Narrowing integral conversions will go. Walter is working on a very cool
 scheme for inferring the range of expressions that makes casts unnecessar=
y
 in many cases. Casts are a plague not only for safe code, but also for
 generic code that wants to be scalable and change-robust. The ease with
 which C and C++ allow losing state and the drowning necessity of integral
 casts in Java or C# are both extremes that I'm happy to see D avoid.

 Final switch works with enums and forces you to handle each and every val=
ue
 of the enum. Regular switch gets ranged cases by the syntax case a: .. ca=
se
 b: (I've always thought switch would be greatly helped by that).

 Static foreach might be making it too.


 Andrei
May 18 2009
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Bill Baxter wrote:
 On Mon, May 18, 2009 at 10:46 AM, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org> wrote:
 Johan Granberg wrote:
 BCS wrote:

 Hello Andrei,

 I think "with" is a very dangerous feature due to the way it hides
 symbols. It essentially makes the feeblest attempt at modular
 reasoning utterly impossible:

 int x, y;
 with (whatever)
 {
 y += x;
 ++x;
 }

 Maintenance of any type that is being used with "with" becomes a very
 dangerous proposition because it can silently change meaning of code.
I'd be willing to go the half way solution of making accessing a shadowing symbol an error, resulting in (loudly) not being able to access either.
I think this solution is a good idea but that removing or restricting anything more regarding with is a bad idea as others have pointed out. I'm using with quit a lot and it was one of thous things that attracted me to D (I get the feeling that D has a quite pragmatic way of looking at language features, if it's usefull lets have it unless it's harmfull to other parts of D, sort of.).
I personally still think it's a bad feature because it introduces long-distance coupling between symbols defined in two different places, both distinct from the place where the statement is used! Consider: import wyda; // defines symbol write import geeba; // defines struct S { ... } void main() { S s; with (s) { write(5); } } Machiavelly would jump in joy at such code. What did I achieve? I saved a few "s.". What did I lose? The ability so say anything, but absolutely anything on what the code does.
Shouldn't the feature just follow the same rules as module imports do? If I say import foo; import bar; void main() { write(5); } It's fine as long as foo and bar don't both define bar. Why shouldn't the same scope resolution mechanism not apply to with? So in your example write(5) is fine as long as S and some module don't both define a write(). I think that's what others were saying in the other thread, too. Makes things more consistent too. Given that do you still object to with() so vehemently?
I'd be happy if "with" were consistent in the way you describe. Nice idea! Andrei
May 18 2009
parent Georg Wrede <georg.wrede iki.fi> writes:
Andrei Alexandrescu wrote:
 Bill Baxter wrote:
 On Mon, May 18, 2009 at 10:46 AM, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org> wrote:
 Johan Granberg wrote:
 BCS wrote:

 Hello Andrei,

 I think "with" is a very dangerous feature due to the way it hides
 symbols. It essentially makes the feeblest attempt at modular
 reasoning utterly impossible:

 int x, y;
 with (whatever)
 {
 y += x;
 ++x;
 }

 Maintenance of any type that is being used with "with" becomes a very
 dangerous proposition because it can silently change meaning of code.
I'd be willing to go the half way solution of making accessing a shadowing symbol an error, resulting in (loudly) not being able to access either.
I think this solution is a good idea but that removing or restricting anything more regarding with is a bad idea as others have pointed out. I'm using with quit a lot and it was one of thous things that attracted me to D (I get the feeling that D has a quite pragmatic way of looking at language features, if it's usefull lets have it unless it's harmfull to other parts of D, sort of.).
I personally still think it's a bad feature because it introduces long-distance coupling between symbols defined in two different places, both distinct from the place where the statement is used! Consider: import wyda; // defines symbol write import geeba; // defines struct S { ... } void main() { S s; with (s) { write(5); } } Machiavelly would jump in joy at such code. What did I achieve? I saved a few "s.". What did I lose? The ability so say anything, but absolutely anything on what the code does.
Shouldn't the feature just follow the same rules as module imports do? If I say import foo; import bar; void main() { write(5); } It's fine as long as foo and bar don't both define bar. Why shouldn't the same scope resolution mechanism not apply to with? So in your example write(5) is fine as long as S and some module don't both define a write(). I think that's what others were saying in the other thread, too. Makes things more consistent too. Given that do you still object to with() so vehemently?
I'd be happy if "with" were consistent in the way you describe. Nice idea!
Then we could have "an implicit with" in effect all the time! I.e., every time i use 'write', and there's no ambiguity, I wouldn't have to write foo.write or bar.write. Saves a lot of ink! Yessss. And this should not be hard to implement at all. Except that code would then become hard to analyze. End result: using 's.' really isn't such a bad alternative.
May 18 2009
prev sibling next sibling parent reply Jason House <jason.james.house gmail.com> writes:
Andrei Alexandrescu Wrote:

 Jarrett Billingsley wrote:
 On Mon, May 18, 2009 at 1:46 PM, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org> wrote:
 
 Final switch works with enums and forces you to handle each and every value
 of the enum. Regular switch gets ranged cases by the syntax case a: .. case
 b: (I've always thought switch would be greatly helped by that).
Kind of an odd syntax. Why not "case a .. b:"? Parsing issues?
It's consistency. Everywhere in the language a .. b implies b is excluded. In a switch you want to include b. So I reflected that in the syntax. In fact, I confess I'm more proud than I should be about that little detail.
Consistency??? While I can see where you're coming from, I still see plenty of inconsistencies. It's still a range (defined with .. too). Having slices and foreach use syntax a and meaning 1 but switch using syntax a' and meaning 2 kind of sucks.
 Static foreach might be making it too.
That'd be a nice addition. Especially with __traits returning arrays/tuples, it'd be an alternative to CTFE (shudder) or template recursion.
Yah, can't wait.
I'm still hoping for static switch too!
May 18 2009
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Jason House wrote:
 Andrei Alexandrescu Wrote:
 
 Jarrett Billingsley wrote:
 On Mon, May 18, 2009 at 1:46 PM, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org> wrote:

 Final switch works with enums and forces you to handle each and every value
 of the enum. Regular switch gets ranged cases by the syntax case a: .. case
 b: (I've always thought switch would be greatly helped by that).
Kind of an odd syntax. Why not "case a .. b:"? Parsing issues?
It's consistency. Everywhere in the language a .. b implies b is excluded. In a switch you want to include b. So I reflected that in the syntax. In fact, I confess I'm more proud than I should be about that little detail.
Consistency??? While I can see where you're coming from, I still see plenty of inconsistencies. It's still a range (defined with .. too). Having slices and foreach use syntax a and meaning 1 but switch using syntax a' and meaning 2 kind of sucks.
You'd have to squint real hard to see a range. A range is expr1 .. expr2 That code is case expr1: .. case expr2: I mean you can't tell me that as soon as ".." is within a mile it's a range. Andrei
May 18 2009
parent reply Jason House <jason.james.house gmail.com> writes:
Andrei Alexandrescu Wrote:

 Jason House wrote:
 Andrei Alexandrescu Wrote:
 
 Jarrett Billingsley wrote:
 On Mon, May 18, 2009 at 1:46 PM, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org> wrote:

 Final switch works with enums and forces you to handle each and every value
 of the enum. Regular switch gets ranged cases by the syntax case a: .. case
 b: (I've always thought switch would be greatly helped by that).
Kind of an odd syntax. Why not "case a .. b:"? Parsing issues?
It's consistency. Everywhere in the language a .. b implies b is excluded. In a switch you want to include b. So I reflected that in the syntax. In fact, I confess I'm more proud than I should be about that little detail.
Consistency??? While I can see where you're coming from, I still see plenty of inconsistencies. It's still a range (defined with .. too). Having slices and foreach use syntax a and meaning 1 but switch using syntax a' and meaning 2 kind of sucks.
You'd have to squint real hard to see a range. A range is expr1 .. expr2 That code is case expr1: .. case expr2: I mean you can't tell me that as soon as ".." is within a mile it's a range. Andrei
It's all a matter of perspective. I see both as begin .. end. That may be the same reason why I think addition when I see foo(bar()) + baz(37). The extra cruft is more or less ignored when figuring out the basics of what is going on.
May 18 2009
parent reply Bill Baxter <wbaxter gmail.com> writes:
On Mon, May 18, 2009 at 3:29 PM, Jason House
<jason.james.house gmail.com> wrote:

 It's all a matter of perspective. I see both as begin .. end. That may be the
same reason why I think addition when I see foo(bar()) + baz(37). The extra
cruft is more or less ignored when figuring out the basics of what is going on.
Agreed. If you tell someone a .. b means a non-inclusive range from a to b, then ask them to guess what blarf a .. blarf b means, I would be very surprised if many guessed "inclusive range from blarf a to blarf b". ... Unless they guess that the fact you were asking something which should be so obvious meant that it was probably a trick question, in which case they'd answer inclusive, that being the non-obvious answer. --bb
May 18 2009
next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Bill Baxter:
 Agreed.  If you tell someone   a .. b  means a non-inclusive range
 from a to b, then ask them to guess what    blarf a .. blarf b  means,
 I would be very surprised if many guessed "inclusive range from blarf
 a  to blarf b".
Thank you for nicely expressing one of the critics I was trying to express. (My other problem is that I'd like a more general syntax). ------------------------ A different simple solution can be: case a .. b+1: That requires no new syntax. Bye, bearophile
May 18 2009
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
bearophile wrote:
 Bill Baxter:
 Agreed.  If you tell someone   a .. b  means a non-inclusive range
 from a to b, then ask them to guess what    blarf a .. blarf b  means,
 I would be very surprised if many guessed "inclusive range from blarf
 a  to blarf b".
Thank you for nicely expressing one of the critics I was trying to express. (My other problem is that I'd like a more general syntax). ------------------------ A different simple solution can be: case a .. b+1: That requires no new syntax. Bye, bearophile
void classify(char c) { write("You passed "); switch (c) { case '#': writeln("a hash sign."); break; case '0' .. case '9': writeln("a digit."); break; case 'A' .. case 'Z': case 'a' .. case 'z': writeln("an ASCII character."); break; case '.', ',', ':', ';', '!', '?': writeln("a punctuation mark."); break; default: writeln("quite a character!"); break; } } Cool! void classify(char c) { write("You passed "); switch (c) { case '#': writeln("a hash sign."); break; case '0' .. '9'+1: writeln("a digit."); break; case 'A' .. 'Z'+1: case 'a' .. 'z'+1: writeln("an ASCII character."); break; case '.', ',', ':', ';', '!', '?': writeln("a punctuation mark."); break; default: writeln("quite a character!"); break; } } Awful! Andrei
May 18 2009
parent reply bearophile <bearophileHUGS lycos.com> writes:
Andrei Alexandrescu:

Thank you for bringing a "real" example that gives something to work on.

Awful!<
Well, one of your cases was wrong. Using the +1 at the end one of those cases become: case 'A' .. 'Z'+1, 'a' .. 'z'+1: Instead of what you have written: case 'A' .. 'Z'+1: case 'a' .. 'z'+1: I agree that that syntax with +1 isn't very nice looking. But the advantage of +1 is that it introduces (almost) no new syntax, it's not easy to miss, its meaning is easy to understand. AND you don't have to remember that in a case the .. is inclusive while in foreach is exclusive on the right, keeping the standard way in D to denote ranges. ------------------------- We can introduce in D a syntax that maps on the semantics of iota(start, stop) or even iota(start, stop, step) (I don't remember if iota() supports opIn_r, and has length, if not then it's better to add them). So you can do: foreach (i; somerangesyntax) {...} (So this replaces the current ranged foreach syntax). case somerangesyntax: ... if (x in somerangesyntax) {...} map(fun, somerangesyntax); And more, using only one (or two) general syntaxes. ------------------------- The simple exclusive range syntax, with +1: void classify(char c) { write("You passed "); switch (c) { case '#': writeln("a hash sign."); break; case '0' .. '9'+1: writeln("a digit."); break; case 'A' .. 'Z'+1, 'a' .. 'z'+1: writeln("an ASCII character."); break; case '.', ',', ':', ';', '!', '?': writeln("a punctuation mark."); break; default: writeln("quite a character!"); break; } } Using Chapel closed range syntax: void classify(char c) { write("You passed "); switch (c) { case '#': writeln("a hash sign."); break; case '0' ..# '9': writeln("a digit."); break; case 'A' ..# 'Z', 'a' ..# 'z': writeln("an ASCII character."); break; case '.', ',', ':', ';', '!', '?': writeln("a punctuation mark."); break; default: writeln("quite a character!"); break; } } An alternative to that Chapel syntax: void classify(char c) { write("You passed "); switch (c) { case '#': writeln("a hash sign."); break; case '0' ..> '9': writeln("a digit."); break; case 'A' ..> 'Z', 'a' ..> 'z': writeln("an ASCII character."); break; case '.', ',', ':', ';', '!', '?': writeln("a punctuation mark."); break; default: writeln("quite a character!"); break; } } It may be easy to miss the third point (but it's not a noisy syntax) void classify(char c) { write("You passed "); switch (c) { case '#': writeln("a hash sign."); break; case '0' ... '9': writeln("a digit."); break; case 'A' ... 'Z', 'a' ... 'z': writeln("an ASCII character."); break; case '.', ',', ':', ';', '!', '?': writeln("a punctuation mark."); break; default: writeln("quite a character!"); break; } } Using something more explicit (interval() is lazy and inclusive on the right. The D compiler optimizes away at compile time the following calls): void classify(char c) { write("You passed "); switch (c) { case '#': writeln("a hash sign."); break; case interval('0', '9'): writeln("a digit."); break; case interval('A', 'Z'), interval('a', 'z'): writeln("an ASCII character."); break; case '.', ',', ':', ';', '!', '?': writeln("a punctuation mark."); break; default: writeln("quite a character!"); break; } } void classify(char c) { write("You passed "); switch (c) { case '#': writeln("a hash sign."); break; case ['0' .. '9']: writeln("a digit."); break; case ['A' .. 'Z'], ['a' .. 'z']: writeln("an ASCII character."); break; case '.', ',', ':', ';', '!', '?': writeln("a punctuation mark."); break; default: writeln("quite a character!"); break; } } Such syntaxes are meant to be used in every other situation too (and I'd like to have another syntax that is non-inclusive, possibly like the current one): foreach (i; 'A' .. 'Z'+1) {...} case 'A' .. 'Z'+1: ... if (x in 'A' .. 'Z'+1) {...} map(fun, 'A' .. 'Z'+1); foreach (i; 'A' ..# 'Z') {...} case 'A' ..# 'Z': ... if (x in 'A' ..# 'Z') {...} map(fun, 'A' ..# 'Z'); foreach (i; 'A' ..> 'Z') {...} case 'A' ..> 'Z': ... if (x in 'A' ..> 'Z') {...} map(fun, 'A' ..> 'Z'); foreach (i; 'A' ... 'Z') {...} case 'A' ... 'Z': ... if (x in 'A' ... 'Z') {...} map(fun, 'A' ... 'Z'); foreach (i; interval('A', 'Z')) {...} case interval('A', 'Z'): ... if (x in interval('A', 'Z')) {...} map(fun, interval('A', 'Z')); foreach (i; ['A' .. 'Z']) {...} case ['A' .. 'Z']: ... if (x in ['A' .. 'Z']) {...} map(fun, ['A' .. 'Z']); The a..b+1 syntax can't be used inside map() in a simple way. The [a .. b] syntax is acceptable, but then it doesn't offer a good way to define those if() and map() for the noninclusive situation: // inclusive cases? foreach (i; ['A' .. 'Z']) {...} case ['A' .. 'Z']: ... if (x in ['A' .. 'Z']) {...} map(fun, ['A' .. 'Z']); // noninclusive cases? foreach (i; 'A' .. 'Z') {...} case 'A' .. 'Z': ... if (x in 'A' .. 'Z') {...} map(fun, 'A' .. 'Z'); Well... That's not perfect, but it looks better than the syntax suggested by Andrei. Do you have better ideas? Bye, bearophile
May 18 2009
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
bearophile wrote:
 Andrei Alexandrescu:
 
 Thank you for bringing a "real" example that gives something to work on.
 
 Awful!<
Well, one of your cases was wrong. Using the +1 at the end one of those cases become: case 'A' .. 'Z'+1, 'a' .. 'z'+1: Instead of what you have written: case 'A' .. 'Z'+1: case 'a' .. 'z'+1: I agree that that syntax with +1 isn't very nice looking. But the advantage of +1 is that it introduces (almost) no new syntax, it's not easy to miss, its meaning is easy to understand. AND you don't have to remember that in a case the .. is inclusive while in foreach is exclusive on the right, keeping the standard way in D to denote ranges.
You don't understand. My point is not that people will dislike 'Z'+1. They will FORGET TO WRITE THE BLESSED +1. They'll write: case 'A' .. 'Z': and they'll wonder why the hell Z is not handled. Now do you see why it's sometimes ungainly to discuss language design here? It can only go forever, and in the end anyone can say "but I just don't like it". In fact I'll use that prerogative right now: [snip]
 Well... That's not perfect, but it looks better than the syntax suggested by
Andrei. Do you have better ideas?
I like my syntax better than all you mentioned, by a mile. Andrei
May 18 2009
next sibling parent reply Derek Parnell <derek psych.ward> writes:
On Mon, 18 May 2009 19:38:05 -0500, Andrei Alexandrescu wrote:

 I like my syntax better than all you mentioned, by a mile.
Problem: Define a syntax that indicates a specific range of values for a single case statement. Constraints: (1) No new keywords permitted. (2) No new operators permitted. (3) Must indicate an *inclusive* range (4) A range has an explicit starting value and ending value (5) A range has an implicit step value of 1. (6) Must not be keystroke-heavy (7) Must be easy to read (8) Must be easy to remember while writing (9) Must not be ambiguous with existing syntax (10) Must be consistent with existing syntax (11) Must take the general form ... 'case' RANGE ':' Andrei ... case FIRST .. case LAST : [[ -(8)- The second 'case' is easy to forget to write ]] [[ -(10)- The ".." means exclusive range elsewhere but not here ]] bearophile ... case FIRST .. LAST+1 : [[ -(8)- The +1 is easy to forget to write ]] JB (first pass) case FIRST .. LAST : [[ -(10)- inconsistent with exclusive range syntax]] So just as a thought without a lot of adademic introspection derek ... case [FIRST ; LAST] : sample code ... void classify(char c) { write("You passed "); switch (c) { case '#': writeln("a hash sign."); break; case ['0' ; '9']: writeln("a digit."); break; case ['A' ; 'Z'], ['a' ; 'z']: writeln("an ASCII character."); break; case '.', ',', ':', ';', '!', '?': writeln("a punctuation mark."); break; default: writeln("quite a character!"); break; } } -- Derek Parnell Melbourne, Australia skype: derek.j.parnell
May 18 2009
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Derek Parnell wrote:
 On Mon, 18 May 2009 19:38:05 -0500, Andrei Alexandrescu wrote:
 
 I like my syntax better than all you mentioned, by a mile.
Problem: Define a syntax that indicates a specific range of values for a single case statement. Constraints:
(0) Must be recognizable and understood at first sight without the user running to the manual and looking it up.
 (1) No new keywords permitted.
 (2) No new operators permitted.
 (3) Must indicate an *inclusive* range
 (4) A range has an explicit starting value and ending value
 (5) A range has an implicit step value of 1.
 (6) Must not be keystroke-heavy
 (7) Must be easy to read
 (8) Must be easy to remember while writing
 (9) Must not be ambiguous with existing syntax
 (10) Must be consistent with existing syntax
 (11) Must take the general form ...
 
     'case' RANGE ':'
 
 
 Andrei ...
   case FIRST .. case LAST :
    [[ -(8)- The second 'case' is easy to forget to write ]]
Compile-time error.
    [[ -(10)- The ".." means exclusive range elsewhere but not here ]]
NO. NO. NO. BY GOLLY NO. Please understand the very basics of a grammar. I swear this is the last time I explain that. ".." is a TOKEN. TOKEN. TOKEN. Punctuation. It is NOT any grammatical construct in particular. expression1 .. expression2 is a notation for ranges. All elements must be present. ".." by itself does not have a meaning. case expression1: .. case expression2: is an entirely different construct. It does not have expression1 .. expression2 anywhere in sight. It is ridiculous to attribute meaning to ".." alone as much as saying that "(" must only used to initiate a function call or "[" must be only used to initiate an array indexing operation.
 bearophile ...
   case FIRST .. LAST+1 :
    [[ -(8)- The +1 is easy to forget to write ]]
 
 JB (first pass)
   case FIRST .. LAST :
    [[ -(10)- inconsistent with exclusive range syntax]]
 So just as a thought without a lot of adademic introspection 
 
 derek ...
   case [FIRST ; LAST] :
Fails (0) with flying colors. Andrei
May 18 2009
parent reply "Nick Sabalausky" <a a.a> writes:
"Andrei Alexandrescu" <SeeWebsiteForEmail erdani.org> wrote in message 
news:gut7lb$ue8$1 digitalmars.com...
 (0) Must be recognizable and understood at first sight without the user 
 running to the manual and looking it up.
I've never considered that a particularly good criterea in most cases. Most language features/syntax are non-obvious at a glance for anyone who isn't already familiar with it. And typically, you only need to look it up once and then next time you see it you'll remember. People had the same complaint when '$' was proposed for blah.length, but seriously, one it was included who here has ever had a non-trivial time learning and internalizing that? Does '!()' scream "template" to someone who hasn't used D or looked at the D docs? Of course not. But it works fine. And I sure someone could have easily said the same about the '#' at the beginning of preprocessor directives back whenever those were first created. But who ever has any real trouble with that? I didn't even the very first time I was introduced to it. This '(0)' is barely an issue at all.
May 19 2009
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Nick Sabalausky wrote:
 "Andrei Alexandrescu" <SeeWebsiteForEmail erdani.org> wrote in message 
 news:gut7lb$ue8$1 digitalmars.com...
 (0) Must be recognizable and understood at first sight without the user 
 running to the manual and looking it up.
I've never considered that a particularly good criterea in most cases. Most language features/syntax are non-obvious at a glance for anyone who isn't already familiar with it.
Not slight departures from existing syntax. Andrei
May 19 2009
prev sibling parent reply Jeremie Pelletier <jeremiep gmail.com> writes:
Derek Parnell Wrote:

 On Mon, 18 May 2009 19:38:05 -0500, Andrei Alexandrescu wrote:
 
 I like my syntax better than all you mentioned, by a mile.
Problem: Define a syntax that indicates a specific range of values for a single case statement. Constraints: (1) No new keywords permitted. (2) No new operators permitted. (3) Must indicate an *inclusive* range (4) A range has an explicit starting value and ending value (5) A range has an implicit step value of 1. (6) Must not be keystroke-heavy (7) Must be easy to read (8) Must be easy to remember while writing (9) Must not be ambiguous with existing syntax (10) Must be consistent with existing syntax (11) Must take the general form ... 'case' RANGE ':' Andrei ... case FIRST .. case LAST : [[ -(8)- The second 'case' is easy to forget to write ]] [[ -(10)- The ".." means exclusive range elsewhere but not here ]] bearophile ... case FIRST .. LAST+1 : [[ -(8)- The +1 is easy to forget to write ]] JB (first pass) case FIRST .. LAST : [[ -(10)- inconsistent with exclusive range syntax]] So just as a thought without a lot of adademic introspection derek ... case [FIRST ; LAST] :
Personally I feel that your syntax breaks the condition (6) Must not be keystroke-heavy I like Andei's syntax best but as previously stated, its ambiguous with exclusive ranges. Maybe the solution is a second range operator that is inclusive, such as: case FIRST ... LAST: I don't feel it breaks the no new operator rule as ... is already handled by the lexer, and it is obvious to the parser what the intended usage is. Also the operator can be generalized to all range statements. Jeremie
May 18 2009
parent reply Derek Parnell <derek psych.ward> writes:
On Mon, 18 May 2009 23:15:17 -0400, Jeremie Pelletier wrote:

 Derek Parnell Wrote:
   case [FIRST ; LAST] :
Personally I feel that your syntax breaks the condition (6) Must not be keystroke-heavy
Huh?? By keystroke-heavy I meant the number of keyboard presses the finger would have to do to write it. Ignoring FIRST/LAST, I have 3 (three) keystrokes and Andrei has 8 keystrokes? Me = [ ; ] Andrei = SHIFT : .. case
 I like Andei's syntax best but as previously stated, its ambiguous with
exclusive ranges.
 
 Maybe the solution is a second range operator that is inclusive, such as:
     case FIRST ... LAST:
Which is 3 keystrokes too. Sorry, I don't understand what you mean by saying my suggestion breaks (6). -- Derek Parnell Melbourne, Australia skype: derek.j.parnell
May 18 2009
parent Jeremie Pelletier <jeremiep gmail.com> writes:
Derek Parnell Wrote:

 On Mon, 18 May 2009 23:15:17 -0400, Jeremie Pelletier wrote:
 
 Derek Parnell Wrote:
   case [FIRST ; LAST] :
Personally I feel that your syntax breaks the condition (6) Must not be keystroke-heavy
Huh?? By keystroke-heavy I meant the number of keyboard presses the finger would have to do to write it. Ignoring FIRST/LAST, I have 3 (three) keystrokes and Andrei has 8 keystrokes? Me = [ ; ] Andrei = SHIFT : .. case
 I like Andei's syntax best but as previously stated, its ambiguous with
exclusive ranges.
 
 Maybe the solution is a second range operator that is inclusive, such as:
     case FIRST ... LAST:
Which is 3 keystrokes too. Sorry, I don't understand what you mean by saying my suggestion breaks (6). -- Derek Parnell Melbourne, Australia skype: derek.j.parnell
Ah yes if you go by the count of characters, then yes you are right. I assumed it meant the ease of typing it, as ... is way faster to get on the screen than [;]. Also your characters are only easily accessible on a keyboard using the US layout (I began programming on a french canadian layout, and you need to use the right alt key for both [ and ], real annoying).
May 18 2009
prev sibling parent reply =?UTF-8?B?QWxleGFuZGVyIFDDoW5law==?= writes:
Andrei Alexandrescu wrote:
 bearophile wrote:
 Andrei Alexandrescu:

 Thank you for bringing a "real" example that gives something to work on.

 Awful!<
Well, one of your cases was wrong. Using the +1 at the end one of those cases become: case 'A' .. 'Z'+1, 'a' .. 'z'+1: Instead of what you have written: case 'A' .. 'Z'+1: case 'a' .. 'z'+1: I agree that that syntax with +1 isn't very nice looking. But the advantage of +1 is that it introduces (almost) no new syntax, it's not easy to miss, its meaning is easy to understand. AND you don't have to remember that in a case the .. is inclusive while in foreach is exclusive on the right, keeping the standard way in D to denote ranges.
You don't understand. My point is not that people will dislike 'Z'+1. They will FORGET TO WRITE THE BLESSED +1. They'll write: case 'A' .. 'Z':
You know, Ruby solves this by introducing a “seperate” range syntax for exclusive ranges: “...”. An inclusive range is written the same as an exclusive range in D: “..”. a[1 .. 2].length #=> 1 ([a[1]]) a[1 ... 2].length #=> 2 ([a[1], a[2]]) I see no reason not to include such a seperate syntax in D. “..” being exclusive and “...” being inclusive, not the other way round as in Ruby — see “Programmer’s Paradox” http://www.programmersparadox.com/2009/01/11/ruby-range-mnemonic/ . Kind regards, Alex
May 19 2009
next sibling parent "Denis Koroskin" <2korden gmail.com> writes:
On Tue, 19 May 2009 16:19:32 +0400, Alexander Pánek
<alexander.panek brainsware.org> wrote:

 Andrei Alexandrescu wrote:
 bearophile wrote:
 Andrei Alexandrescu:

 Thank you for bringing a "real" example that gives something to work  
 on.

 Awful!<
Well, one of your cases was wrong. Using the +1 at the end one of those cases become: case 'A' .. 'Z'+1, 'a' .. 'z'+1: Instead of what you have written: case 'A' .. 'Z'+1: case 'a' .. 'z'+1: I agree that that syntax with +1 isn't very nice looking. But the advantage of +1 is that it introduces (almost) no new syntax, it's not easy to miss, its meaning is easy to understand. AND you don't have to remember that in a case the .. is inclusive while in foreach is exclusive on the right, keeping the standard way in D to denote ranges.
You don't understand. My point is not that people will dislike 'Z'+1. They will FORGET TO WRITE THE BLESSED +1. They'll write: case 'A' .. 'Z':
You know, Ruby solves this by introducing a “seperate” range syntax for exclusive ranges: “...”. An inclusive range is written the same as an exclusive range in D: “..”. a[1 .. 2].length #=> 1 ([a[1]]) a[1 ... 2].length #=> 2 ([a[1], a[2]]) I see no reason not to include such a seperate syntax in D. “..” being exclusive and “...” being inclusive, not the other way round as in Ruby — see “Programmer’s Paradox” http://www.programmersparadox.com/2009/01/11/ruby-range-mnemonic/ . Kind regards, Alex
I think this is reasonable. ++vote;
May 19 2009
prev sibling parent reply Frank Benoit <keinfarbton googlemail.com> writes:
Alexander Pánek schrieb:
 Andrei Alexandrescu wrote:
 bearophile wrote:
 Andrei Alexandrescu:

 Thank you for bringing a "real" example that gives something to work on.

 Awful!<
Well, one of your cases was wrong. Using the +1 at the end one of those cases become: case 'A' .. 'Z'+1, 'a' .. 'z'+1: Instead of what you have written: case 'A' .. 'Z'+1: case 'a' .. 'z'+1: I agree that that syntax with +1 isn't very nice looking. But the advantage of +1 is that it introduces (almost) no new syntax, it's not easy to miss, its meaning is easy to understand. AND you don't have to remember that in a case the .. is inclusive while in foreach is exclusive on the right, keeping the standard way in D to denote ranges.
You don't understand. My point is not that people will dislike 'Z'+1. They will FORGET TO WRITE THE BLESSED +1. They'll write: case 'A' .. 'Z':
You know, Ruby solves this by introducing a “seperate” range syntax for exclusive ranges: “...”. An inclusive range is written the same as an exclusive range in D: “..”. a[1 .. 2].length #=> 1 ([a[1]]) a[1 ... 2].length #=> 2 ([a[1], a[2]]) I see no reason not to include such a seperate syntax in D. “..” being exclusive and “...” being inclusive, not the other way round as in Ruby — see “Programmer’s Paradox” http://www.programmersparadox.com/2009/01/11/ruby-range-mnemonic/ . Kind regards, Alex
Yes, this is useful for all use cases of ranges. I like '...'.
May 19 2009
parent reply Robert Fraser <fraserofthenight gmail.com> writes:
Frank Benoit wrote:
 Alexander Pánek schrieb:
 Andrei Alexandrescu wrote:
 bearophile wrote:
 Andrei Alexandrescu:

 Thank you for bringing a "real" example that gives something to work on.

 Awful!<
Well, one of your cases was wrong. Using the +1 at the end one of those cases become: case 'A' .. 'Z'+1, 'a' .. 'z'+1: Instead of what you have written: case 'A' .. 'Z'+1: case 'a' .. 'z'+1: I agree that that syntax with +1 isn't very nice looking. But the advantage of +1 is that it introduces (almost) no new syntax, it's not easy to miss, its meaning is easy to understand. AND you don't have to remember that in a case the .. is inclusive while in foreach is exclusive on the right, keeping the standard way in D to denote ranges.
You don't understand. My point is not that people will dislike 'Z'+1. They will FORGET TO WRITE THE BLESSED +1. They'll write: case 'A' .. 'Z':
You know, Ruby solves this by introducing a “seperate” range syntax for exclusive ranges: “...”. An inclusive range is written the same as an exclusive range in D: “..”. a[1 .. 2].length #=> 1 ([a[1]]) a[1 ... 2].length #=> 2 ([a[1], a[2]]) I see no reason not to include such a seperate syntax in D. “..” being exclusive and “...” being inclusive, not the other way round as in Ruby — see “Programmer’s Paradox” http://www.programmersparadox.com/2009/01/11/ruby-range-mnemonic/ . Kind regards, Alex
Yes, this is useful for all use cases of ranges. I like '...'.
Indeed it's not a bad idea... But it might be easily mistyped, lead to strange off-by-one errors and be very difficult to find while debugging them. Hmmm...
May 19 2009
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Robert Fraser wrote:
 Frank Benoit wrote:
 Alexander Pánek schrieb:
 Andrei Alexandrescu wrote:
 bearophile wrote:
 Andrei Alexandrescu:

 Thank you for bringing a "real" example that gives something to 
 work on.

 Awful!<
Well, one of your cases was wrong. Using the +1 at the end one of those cases become: case 'A' .. 'Z'+1, 'a' .. 'z'+1: Instead of what you have written: case 'A' .. 'Z'+1: case 'a' .. 'z'+1: I agree that that syntax with +1 isn't very nice looking. But the advantage of +1 is that it introduces (almost) no new syntax, it's not easy to miss, its meaning is easy to understand. AND you don't have to remember that in a case the .. is inclusive while in foreach is exclusive on the right, keeping the standard way in D to denote ranges.
You don't understand. My point is not that people will dislike 'Z'+1. They will FORGET TO WRITE THE BLESSED +1. They'll write: case 'A' .. 'Z':
You know, Ruby solves this by introducing a “seperate” range syntax for exclusive ranges: “...”. An inclusive range is written the same as an exclusive range in D: “..”. a[1 .. 2].length #=> 1 ([a[1]]) a[1 ... 2].length #=> 2 ([a[1], a[2]]) I see no reason not to include such a seperate syntax in D. “..” being exclusive and “...” being inclusive, not the other way round as in Ruby — see “Programmer’s Paradox” http://www.programmersparadox.com/2009/01/11/ruby-range-mnemonic/ . Kind regards, Alex
Yes, this is useful for all use cases of ranges. I like '...'.
Indeed it's not a bad idea... But it might be easily mistyped, lead to strange off-by-one errors and be very difficult to find while debugging them. Hmmm...
It's an awful idea. It's a non-idea. If "idea" had an antonym, that would be it. I can't fathom what's on the mind of a person (not you, at least you foresee some potential problems) who, even after patiently explained the issues with this mental misfire, several times, still can bring themselves to think it's not that bad. Let me add one more, although more than sure someone will find a remedy for it, too. a...b vs. a.. .b and of course the beauty a....b I don't plan to discuss minor features on this group anymore. Andrei
May 19 2009
next sibling parent Jarrett Billingsley <jarrett.billingsley gmail.com> writes:
On Tue, May 19, 2009 at 4:43 PM, Andrei Alexandrescu
 It's an awful idea. It's a non-idea. If "idea" had an antonym, that would be
 it.

 I can't fathom what's on the mind of a person (not you, at least you
 foresee some potential problems) who, even after patiently explained the
 issues with this mental misfire, several times, still can bring
 themselves to think it's not that bad.

 Let me add one more, although more than sure someone will find a remedy
 for it, too.

 a...b

 vs.

 a.. .b

 and of course the beauty

 a....b

 I don't plan to discuss minor features on this group anymore.
Maybe if you weren't prone to such humorous bouts of hyperbole, you wouldn't get your blood boiling so easily. This is the internet, and we're talking about programming languages. It's not like we're defusing a tense international arms conflict or something.
May 19 2009
prev sibling next sibling parent reply Jarrett Billingsley <jarrett.billingsley gmail.com> writes:
On Tue, May 19, 2009 at 4:47 PM, Jarrett Billingsley
<jarrett.billingsley gmail.com> wrote:
 On Tue, May 19, 2009 at 4:43 PM, Andrei Alexandrescu
 It's an awful idea. It's a non-idea. If "idea" had an antonym, that woul=
d be
 it.

 I can't fathom what's on the mind of a person (not you, at least you
 foresee some potential problems) who, even after patiently explained the
 issues with this mental misfire, several times, still can bring
 themselves to think it's not that bad.

 Let me add one more, although more than sure someone will find a remedy
 for it, too.

 a...b

 vs.

 a.. .b

 and of course the beauty

 a....b

 I don't plan to discuss minor features on this group anymore.
Maybe if you weren't prone to such humorous bouts of hyperbole, you wouldn't get your blood boiling so easily. =A0This is the internet, and we're talking about programming languages. =A0It's not like we're defusing a tense international arms conflict or something.
Also, why does the puremagic mailing list software hate me so much when it comes to threading my replies?
May 19 2009
next sibling parent reply div0 <div0 users.sourceforge.net> writes:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Jarrett Billingsley wrote:
 On Tue, May 19, 2009 at 4:47 PM, Jarrett Billingsley
 <jarrett.billingsley gmail.com> wrote:
 On Tue, May 19, 2009 at 4:43 PM, Andrei Alexandrescu
 It's an awful idea. It's a non-idea. If "idea" had an antonym, that would be
 it.

 I can't fathom what's on the mind of a person (not you, at least you
 foresee some potential problems) who, even after patiently explained the
 issues with this mental misfire, several times, still can bring
 themselves to think it's not that bad.

 Let me add one more, although more than sure someone will find a remedy
 for it, too.

 a...b

 vs.

 a.. .b

 and of course the beauty

 a....b

 I don't plan to discuss minor features on this group anymore.
Maybe if you weren't prone to such humorous bouts of hyperbole, you wouldn't get your blood boiling so easily. This is the internet, and we're talking about programming languages. It's not like we're defusing a tense international arms conflict or something.
Also, why does the puremagic mailing list software hate me so much when it comes to threading my replies?
You're probably breaching some volume of posts limit. ;) Thunderbird works nice. - -- My enormous talent is exceeded only by my outrageous laziness. http://www.ssTk.co.uk -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFKEybQT9LetA9XoXwRAkDXAKCo9PS0+GRCCyZibMe3WcbiZo5HlgCeMp92 fUcS3bLFqSaQ/Pk8KKVNzJM= =k/lq -----END PGP SIGNATURE-----
May 19 2009
parent Jarrett Billingsley <jarrett.billingsley gmail.com> writes:
On Tue, May 19, 2009 at 5:38 PM, div0 <div0 users.sourceforge.net> wrote:
 -----BEGIN PGP SIGNED MESSAGE-----
 Hash: SHA1

 Jarrett Billingsley wrote:
 On Tue, May 19, 2009 at 4:47 PM, Jarrett Billingsley
 <jarrett.billingsley gmail.com> wrote:
 On Tue, May 19, 2009 at 4:43 PM, Andrei Alexandrescu
 It's an awful idea. It's a non-idea. If "idea" had an antonym, that wo=
uld be
 it.

 I can't fathom what's on the mind of a person (not you, at least you
 foresee some potential problems) who, even after patiently explained t=
he
 issues with this mental misfire, several times, still can bring
 themselves to think it's not that bad.

 Let me add one more, although more than sure someone will find a remed=
y
 for it, too.

 a...b

 vs.

 a.. .b

 and of course the beauty

 a....b

 I don't plan to discuss minor features on this group anymore.
Maybe if you weren't prone to such humorous bouts of hyperbole, you wouldn't get your blood boiling so easily. =A0This is the internet, and we're talking about programming languages. =A0It's not like we're defusing a tense international arms conflict or something.
Also, why does the puremagic mailing list software hate me so much when it comes to threading my replies?
You're probably breaching some volume of posts limit. ;) Thunderbird works nice. - -- My enormous talent is exceeded only by my outrageous laziness. http://www.ssTk.co.uk -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFKEybQT9LetA9XoXwRAkDXAKCo9PS0+GRCCyZibMe3WcbiZo5HlgCeMp92 fUcS3bLFqSaQ/Pk8KKVNzJM=3D =3Dk/lq -----END PGP SIGNATURE-----
I'd vastly prefer a newsreader. Sadly I've yet to encounter a newsreader that can store its state in a shared location, which is important for me as I need to be able to access the newsgroups from multiple computers. Cough, googlegroups, cough, but whatever. It might be the way I snip out parts of quoted posts. Maybe it doesn't like that.
May 19 2009
prev sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Tue, 19 May 2009 16:48:41 -0400, Jarrett Billingsley  
<jarrett.billingsley gmail.com> wrote:

 Also, why does the puremagic mailing list software hate me so much
 when it comes to threading my replies?
FWIW, your replies also sometimes thread your replies in a new thread in opera (and I recall this happening with Outlook Express before I switched). There must be something your client isn't transmitting properly to signal it's the continuation of a thread. Probably you should examine your headers closely on replies that do get threaded properly vs. replies that for some reason start a new thread. -Steve
May 19 2009
prev sibling next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Andrei Alexandrescu:
 I don't plan to discuss minor features on this group anymore.
In about two years I've never heard Walter say something like that (even if may think similar things every day), he doesn't need a pedestal. Thank you, bearophile
May 19 2009
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
bearophile wrote:
 Andrei Alexandrescu:
 I don't plan to discuss minor features on this group anymore.
In about two years I've never heard Walter say something like that (even if may think similar things every day), he doesn't need a pedestal.
This has nothing to do with a pedestal. It's simple pragmatics. We are fulfilling Wadler's law (http://www.haskell.org/haskellwiki/Wadlers_Law) around here, and that's counterproductive. Some of language design and most of syntax design are subjective. We all have a tendency to subjectively prefer features that we created and to be more critical of features that others have created. It's natural. They call it the better-than-average bias (http://en.wikipedia.org/wiki/Lake_Wobegon_effect). I have that tendency as much as the next guy, but I also like to believe I do not let that mask my reasoning too bad. That is, I wouldn't go at any length to defend a no-win case and argue against others while at the same time consistently ignoring any explanation given several times and in several forms. Case in point: omitting the trailing parens in function calls... I got destroyed on that one :o). Andrei
May 19 2009
next sibling parent reply Robert Fraser <fraserofthenight gmail.com> writes:
Andrei Alexandrescu wrote:
 bearophile wrote:
 Andrei Alexandrescu:
 I don't plan to discuss minor features on this group anymore.
In about two years I've never heard Walter say something like that (even if may think similar things every day), he doesn't need a pedestal.
This has nothing to do with a pedestal. It's simple pragmatics. We are fulfilling Wadler's law (http://www.haskell.org/haskellwiki/Wadlers_Law) around here, and that's counterproductive. Some of language design and most of syntax design are subjective. We all have a tendency to subjectively prefer features that we created and to be more critical of features that others have created. It's natural. They call it the better-than-average bias (http://en.wikipedia.org/wiki/Lake_Wobegon_effect). I have that tendency as much as the next guy, but I also like to believe I do not let that mask my reasoning too bad. That is, I wouldn't go at any length to defend a no-win case and argue against others while at the same time consistently ignoring any explanation given several times and in several forms. Case in point: omitting the trailing parens in function calls... I got destroyed on that one :o). Andrei
I think the other effect is we don't often have time to think about our suggestions for very long... Design is a process and something often "sounds good at the time". Consider the A{} syntax for templates... a whole newsgroup, a month of discussion, and it took until Walter started implementing it to realize the syntactic ambiguity. Having more heads to think about a syntactic change can't be a bad thing.
May 19 2009
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Robert Fraser wrote:
 Andrei Alexandrescu wrote:
 bearophile wrote:
 Andrei Alexandrescu:
 I don't plan to discuss minor features on this group anymore.
In about two years I've never heard Walter say something like that (even if may think similar things every day), he doesn't need a pedestal.
This has nothing to do with a pedestal. It's simple pragmatics. We are fulfilling Wadler's law (http://www.haskell.org/haskellwiki/Wadlers_Law) around here, and that's counterproductive. Some of language design and most of syntax design are subjective. We all have a tendency to subjectively prefer features that we created and to be more critical of features that others have created. It's natural. They call it the better-than-average bias (http://en.wikipedia.org/wiki/Lake_Wobegon_effect). I have that tendency as much as the next guy, but I also like to believe I do not let that mask my reasoning too bad. That is, I wouldn't go at any length to defend a no-win case and argue against others while at the same time consistently ignoring any explanation given several times and in several forms. Case in point: omitting the trailing parens in function calls... I got destroyed on that one :o). Andrei
I think the other effect is we don't often have time to think about our suggestions for very long... Design is a process and something often "sounds good at the time". Consider the A{} syntax for templates... a whole newsgroup, a month of discussion, and it took until Walter started implementing it to realize the syntactic ambiguity. Having more heads to think about a syntactic change can't be a bad thing.
Good point. "Think" is key :o). I'm sure it's often happened to many of us to share with a friend something we spent nights poring over, for them to come with what they're convinced is a much better idea after dignifying the matter with five seconds worth of thinking. Andrei
May 19 2009
parent Georg Wrede <georg.wrede iki.fi> writes:
Andrei Alexandrescu wrote:
 Robert Fraser wrote:
 Andrei Alexandrescu wrote:
 bearophile wrote:
 Andrei Alexandrescu:
 I don't plan to discuss minor features on this group anymore.
In about two years I've never heard Walter say something like that (even if may think similar things every day), he doesn't need a pedestal.
This has nothing to do with a pedestal. It's simple pragmatics. We are fulfilling Wadler's law (http://www.haskell.org/haskellwiki/Wadlers_Law) around here, and that's counterproductive. Some of language design and most of syntax design are subjective. We all have a tendency to subjectively prefer features that we created and to be more critical of features that others have created. It's natural. They call it the better-than-average bias (http://en.wikipedia.org/wiki/Lake_Wobegon_effect). I have that tendency as much as the next guy, but I also like to believe I do not let that mask my reasoning too bad. That is, I wouldn't go at any length to defend a no-win case and argue against others while at the same time consistently ignoring any explanation given several times and in several forms. Case in point: omitting the trailing parens in function calls... I got destroyed on that one :o). Andrei
I think the other effect is we don't often have time to think about our suggestions for very long... Design is a process and something often "sounds good at the time". Consider the A{} syntax for templates... a whole newsgroup, a month of discussion, and it took until Walter started implementing it to realize the syntactic ambiguity. Having more heads to think about a syntactic change can't be a bad thing.
Good point. "Think" is key :o).
And another thing is, of course, that even a simple language can become too hard for a normal programmer, if it becomes too elegant or assumes too much generalizing, memorizing, and abstract thinking from the programmer when he is coding. Some of the vociferous things (well, like the trailing parens thing) may be related to that. So, this NG serves a purpose in helping the language stay near most regular programmers' reach. Wich is a must, if we intend to take over the world.
May 19 2009
prev sibling parent Georg Wrede <georg.wrede iki.fi> writes:
Andrei Alexandrescu wrote:
 bearophile wrote:
 Andrei Alexandrescu:
 I don't plan to discuss minor features on this group anymore.
In about two years I've never heard Walter say something like that (even if may think similar things every day), he doesn't need a pedestal.
This has nothing to do with a pedestal. It's simple pragmatics. We are fulfilling Wadler's law (http://www.haskell.org/haskellwiki/Wadlers_Law) around here, and that's counterproductive.
Yeah. But more important is, of course, that you are important to the development of D, even on your own. That means, that unless you are careful with the time spent on this newsgroup, it will unduely eat away from your time with actual development. (And even thinking, in some cases.) For example, spending copious amounts of ink on trying to explain some of the most esoteric features to some who have no chance of getting it with any amount of explanation, is a waste of time. Let the ideas trickle down. At the end of the day (er, actually, the month), the guys sitting next to him will explain it in more suitable terms anyway. Also, sometimes being too terse, only causes a flurry of (either misunderstandings, or) a barrage of questions, that you then have to answer, instead of answering properly the first time around. BUT, THIS IS not important, and please, don't take the above personally. It was just thoughts in response to "not planning to discuss minor features". They're important too. AND I'm not perfect either. Definitely not.
May 19 2009
prev sibling parent reply Georg Wrede <georg.wrede iki.fi> writes:
bearophile wrote:
 Andrei Alexandrescu:
 I don't plan to discuss minor features on this group anymore.
In about two years I've never heard Walter say something like that (even if may think similar things every day), he doesn't need a pedestal.
Walter hasn't done it in 10 years in this NG.
May 19 2009
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Georg Wrede wrote:
 bearophile wrote:
 Andrei Alexandrescu:
 I don't plan to discuss minor features on this group anymore.
In about two years I've never heard Walter say something like that (even if may think similar things every day), he doesn't need a pedestal.
Walter hasn't done it in 10 years in this NG.
There's only one Walter! Andrei
May 19 2009
parent Georg Wrede <georg.wrede iki.fi> writes:
Andrei Alexandrescu wrote:
 Georg Wrede wrote:
 bearophile wrote:
 Andrei Alexandrescu:
 I don't plan to discuss minor features on this group anymore.
In about two years I've never heard Walter say something like that (even if may think similar things every day), he doesn't need a pedestal.
Walter hasn't done it in 10 years in this NG.
There's only one Walter!
:-)
May 19 2009
prev sibling next sibling parent reply Robert Fraser <fraserofthenight gmail.com> writes:
Andrei Alexandrescu wrote:
 Let me add one more, although more than sure someone will find a remedy
 for it, too.
 
 a...b
 
 vs.
 
 a.. .b
 
 and of course the beauty
 
 a....b
Oh, and this speaks more about the .b syntax than anything else. Does anyone actually use this...? If it was removed, b could still be accessed by its fully-qualified name, so its' removal not a huge loss.
May 19 2009
parent reply Ary Borenszweig <ary esperanto.org.ar> writes:
Robert Fraser escribió:
 Andrei Alexandrescu wrote:
 Let me add one more, although more than sure someone will find a remedy
 for it, too.

 a...b

 vs.

 a.. .b

 and of course the beauty

 a....b
Oh, and this speaks more about the .b syntax than anything else. Does anyone actually use this...? If it was removed, b could still be accessed by its fully-qualified name, so its' removal not a huge loss.
"But that will make porting C code harder" Guess who'll say that. ;-)
May 19 2009
parent reply Robert Fraser <fraserofthenight gmail.com> writes:
Ary Borenszweig wrote:
 Oh, and this speaks more about the .b syntax than anything else. Does 
 anyone actually use this...? If it was removed, b could still be 
 accessed by its fully-qualified name, so its' removal not a huge loss.
"But that will make porting C code harder" Guess who'll say that. ;-)
??? C allows .x to access a global member? You learn something useless every day...
May 19 2009
parent Ary Borenszweig <ary esperanto.org.ar> writes:
Robert Fraser escribió:
 Ary Borenszweig wrote:
 Oh, and this speaks more about the .b syntax than anything else. Does 
 anyone actually use this...? If it was removed, b could still be 
 accessed by its fully-qualified name, so its' removal not a huge loss.
"But that will make porting C code harder" Guess who'll say that. ;-)
??? C allows .x to access a global member? You learn something useless every day...
Aaaaaaaaaaah... I thought they were talking about .1, .2, etc. I forgot about .foo
May 19 2009
prev sibling next sibling parent =?UTF-8?B?QWxleGFuZGVyIFDDoW5law==?= writes:
Andrei Alexandrescu wrote:
 Robert Fraser wrote:
 Frank Benoit wrote:
 Alexander Pánek schrieb:
 Andrei Alexandrescu wrote:
 bearophile wrote:
 Andrei Alexandrescu:

 Thank you for bringing a "real" example that gives something to 
 work on.

 Awful!<
Well, one of your cases was wrong. Using the +1 at the end one of those cases become: case 'A' .. 'Z'+1, 'a' .. 'z'+1: Instead of what you have written: case 'A' .. 'Z'+1: case 'a' .. 'z'+1: I agree that that syntax with +1 isn't very nice looking. But the advantage of +1 is that it introduces (almost) no new syntax, it's not easy to miss, its meaning is easy to understand. AND you don't have to remember that in a case the .. is inclusive while in foreach is exclusive on the right, keeping the standard way in D to denote ranges.
You don't understand. My point is not that people will dislike 'Z'+1. They will FORGET TO WRITE THE BLESSED +1. They'll write: case 'A' .. 'Z':
You know, Ruby solves this by introducing a “seperate” range syntax for exclusive ranges: “...”. An inclusive range is written the same as an exclusive range in D: “..”. a[1 .. 2].length #=> 1 ([a[1]]) a[1 ... 2].length #=> 2 ([a[1], a[2]]) I see no reason not to include such a seperate syntax in D. “..” being exclusive and “...” being inclusive, not the other way round as in Ruby — see “Programmer’s Paradox” http://www.programmersparadox.com/2009/01/11/ruby-range-mnemonic/ . Kind regards, Alex
Yes, this is useful for all use cases of ranges. I like '...'.
Indeed it's not a bad idea... But it might be easily mistyped, lead to strange off-by-one errors and be very difficult to find while debugging them. Hmmm...
It's an awful idea. It's a non-idea. If "idea" had an antonym, that would be it. I can't fathom what's on the mind of a person (not you, at least you foresee some potential problems) who, even after patiently explained the issues with this mental misfire, several times, still can bring themselves to think it's not that bad.
I don’t see a reason not to restrict other features to introduce a new one. I never used .foo to access the global scope or .1 for floating point literals. But what I do use very often is array[n..m + 1], which would ease things for quite a lot of things going on when working with arrays. Of course it’s just syntactic sugar, but so is the whole slicing feature. It could easily be done in the standard library. So I’m not demanding anything, I’m just providing my very own thoughts on this topic. If there are too many obstacles then it’s probably not worth it. The thing is, I don’t know half as much as most of the guys here do, so I don’t see those obstacles at first glance. Please bear with me. :)
 Let me add one more, although more than sure someone will find a remedy
 for it, too.
 
 a...b
inclusive range from a to b
 vs.
 
 a.. .b
exclusive range from a to .b Personally, I see “...” as an atomic operator, like “!=” or “==”. I wouldn’t ever recognize “.. .” as “...” or “! =” as “!=”. Additionally, I add a space before and after every operator, so there’s no ambiguity in any way, plus it’s nicely recognizable what the hell is going on. If it was for me, I’d even go as far as to make this a requirement in the specification. But that would upset downs. Actually, what about “…” as inclusive range operator? :P I’d love that.
 and of course the beauty
 
 a....b
Inclusive range from “a” to “.b”? Pretty clear in this *particular* case. ;)
 I don't plan to discuss minor features on this group anymore.
But.. bike shed discussions are fun! Seriously, though — I learn a lot thanks to people “nitpicking” other people’s ideas, showing corner cases, obstacles and so on. So please, don’t stop discussing minor features. :)
May 20 2009
prev sibling parent reply "Denis Koroskin" <2korden gmail.com> writes:
On Wed, 20 May 2009 00:43:56 +0400, Andrei Alexandrescu
<SeeWebsiteForEmail erdani.org> wrote:

 It's an awful idea. It's a non-idea. If "idea" had an antonym, that  
 would be it.

 I can't fathom what's on the mind of a person (not you, at least you
 foresee some potential problems) who, even after patiently explained the
 issues with this mental misfire, several times, still can bring
 themselves to think it's not that bad.
Your post is emotional rather than rational.
 Let me add one more, although more than sure someone will find a remedy
 for it, too.

 a...b

 vs.

 a.. .b
a..b vs a.b - no one complains It also gracefully solves an issue with uniform distribution uniform(0..int.max) - exclusive uniform(0...int.max) - inclusive (can't be replaced with 0..int.max+1) also in switch: switch(a) { case 0..10: // exclusive case 10...100: // inclusive }
 I don't plan to discuss minor features on this group anymore.
It is as minor as "case a: .. case b:", i.e. not minor at all. I'd say that there is no such thing as minor feature, every feature is important.
 Andrei
May 20 2009
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Denis Koroskin wrote:
 On Wed, 20 May 2009 00:43:56 +0400, Andrei Alexandrescu
<SeeWebsiteForEmail erdani.org> wrote:
 
 It's an awful idea. It's a non-idea. If "idea" had an antonym, that  
 would be it.

 I can't fathom what's on the mind of a person (not you, at least you
 foresee some potential problems) who, even after patiently explained the
 issues with this mental misfire, several times, still can bring
 themselves to think it's not that bad.
Your post is emotional rather than rational.
Agreed. In my defense, let me mention that I've been rational in my previous 50 posts on the topic :o).
 Let me add one more, although more than sure someone will find a remedy
 for it, too.

 a...b

 vs.

 a.. .b
a..b vs a.b - no one complains
You see, you didn't understand my point. My point was that the introduction of a space changes semantics. We should avoid that.
 It also gracefully solves an issue with uniform distribution
 
 uniform(0..int.max)  - exclusive
 uniform(0...int.max) - inclusive (can't be replaced with 0..int.max+1)
Yeah, and this does something else: uniform(0....int.max) and if you use an alias we also have: uniform(0.....A.max) It's interesting how there is a continuum of number of "." that still lead to compilable code that does different things every time. Perfect material for "Why D is a horrible language" articles. Andrei
May 20 2009
next sibling parent reply Ary Borenszweig <ary esperanto.org.ar> writes:
Andrei Alexandrescu wrote:
 Denis Koroskin wrote:
 On Wed, 20 May 2009 00:43:56 +0400, Andrei Alexandrescu 
 <SeeWebsiteForEmail erdani.org> wrote:

 It's an awful idea. It's a non-idea. If "idea" had an antonym, that  
 would be it.

 I can't fathom what's on the mind of a person (not you, at least you
 foresee some potential problems) who, even after patiently explained the
 issues with this mental misfire, several times, still can bring
 themselves to think it's not that bad.
Your post is emotional rather than rational.
Agreed. In my defense, let me mention that I've been rational in my previous 50 posts on the topic :o).
 Let me add one more, although more than sure someone will find a remedy
 for it, too.

 a...b

 vs.

 a.. .b
a..b vs a.b - no one complains
You see, you didn't understand my point. My point was that the introduction of a space changes semantics. We should avoid that.
 It also gracefully solves an issue with uniform distribution

 uniform(0..int.max)  - exclusive
 uniform(0...int.max) - inclusive (can't be replaced with 0..int.max+1)
Yeah, and this does something else: uniform(0....int.max) and if you use an alias we also have: uniform(0.....A.max) It's interesting how there is a continuum of number of "." that still lead to compilable code that does different things every time. Perfect material for "Why D is a horrible language" articles.
This is easily solved by making the lexer not allow the "...." token, or "....." token, etc. (maximum 3 dots.) This way you are forced to insert a space there to make your intention clear, and you can never have bugs like that. Perfect material for "Why D is a beautiful language" articles.
May 20 2009
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Ary Borenszweig wrote:
 This is easily solved by making the lexer not allow the "...." token, or 
   "....." token, etc. (maximum 3 dots.) This way you are forced to 
 insert a space there to make your intention clear, and you can never 
 have bugs like that.
I agree that things could be fixed. This is, however, a hack because a lexer is not supposed to operate that way. Lexers are "maximum munch". So we're looking at a number of problems here. One is that we'd need to change the language in several places to accommodate an ill-conceived feature. Another is that I can't seem to get some very simple points across such as the difference between a token and a non-terminal, in spite of having tried repeatedly and in various forms. Another is that I am becoming suffocated with self-righteousness and therefore am losing goodwill in this thread at an exponentially-increasing rate. Finally, it looks like such discussions necessitate more than a full-time job. Andrei
May 20 2009
parent Lutger <lutger.blijdestijn gmail.com> writes:
Andrei Alexandrescu wrote:

...
 
 So we're looking at a number of problems here. One is that we'd need to 
 change the language in several places to accommodate an ill-conceived 
 feature. Another is that I can't seem to get some very simple points 
 across such as the difference between a token and a non-terminal, in 
 spite of having tried repeatedly and in various forms. Another is that I 
 am becoming suffocated with self-righteousness and therefore am losing 
 goodwill in this thread at an exponentially-increasing rate. Finally, it 
 looks like such discussions necessitate more than a full-time job.
 
 
 Andrei
You could ask Walter for advice on most of these matters ;)
May 20 2009
prev sibling next sibling parent reply Bill Baxter <wbaxter gmail.com> writes:
On Wed, May 20, 2009 at 7:28 AM, Andrei Alexandrescu
<SeeWebsiteForEmail erdani.org> wrote:
 Denis Koroskin wrote:
 On Wed, 20 May 2009 00:43:56 +0400, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org> wrote:

 It's an awful idea. It's a non-idea. If "idea" had an antonym, that
 =A0would be it.

 I can't fathom what's on the mind of a person (not you, at least you
 foresee some potential problems) who, even after patiently explained th=
e
 issues with this mental misfire, several times, still can bring
 themselves to think it's not that bad.
Your post is emotional rather than rational.
Agreed. In my defense, let me mention that I've been rational in my previ=
ous
 50 posts on the topic :o).

 Let me add one more, although more than sure someone will find a remedy
 for it, too.

 a...b

 vs.

 a.. .b
a..b vs a.b - no one complains
You see, you didn't understand my point. My point was that the introducti=
on
 of a space changes semantics. We should avoid that.

 It also gracefully solves an issue with uniform distribution

 uniform(0..int.max) =A0- exclusive
 uniform(0...int.max) - inclusive (can't be replaced with 0..int.max+1)
Yeah, and this does something else: uniform(0....int.max) and if you use an alias we also have: uniform(0.....A.max) It's interesting how there is a continuum of number of "." that still lea=
d
 to compilable code that does different things every time. Perfect materia=
l
 for "Why D is a horrible language" articles.
Isn't 0...a already a horrendously awful non-idea and mental misfire by these arguments? --bb
May 20 2009
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Bill Baxter wrote:
 On Wed, May 20, 2009 at 7:28 AM, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org> wrote:
 Denis Koroskin wrote:
 On Wed, 20 May 2009 00:43:56 +0400, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org> wrote:

 It's an awful idea. It's a non-idea. If "idea" had an antonym, that
  would be it.

 I can't fathom what's on the mind of a person (not you, at least you
 foresee some potential problems) who, even after patiently explained the
 issues with this mental misfire, several times, still can bring
 themselves to think it's not that bad.
Your post is emotional rather than rational.
Agreed. In my defense, let me mention that I've been rational in my previous 50 posts on the topic :o).
 Let me add one more, although more than sure someone will find a remedy
 for it, too.

 a...b

 vs.

 a.. .b
a..b vs a.b - no one complains
You see, you didn't understand my point. My point was that the introduction of a space changes semantics. We should avoid that.
 It also gracefully solves an issue with uniform distribution

 uniform(0..int.max)  - exclusive
 uniform(0...int.max) - inclusive (can't be replaced with 0..int.max+1)
Yeah, and this does something else: uniform(0....int.max) and if you use an alias we also have: uniform(0.....A.max) It's interesting how there is a continuum of number of "." that still lead to compilable code that does different things every time. Perfect material for "Why D is a horrible language" articles.
Isn't 0...a already a horrendously awful non-idea and mental misfire by these arguments? --bb
The problems increase exponentially with the number of dots. Andrei
May 20 2009
prev sibling parent reply KennyTM~ <kennytm gmail.com> writes:
Andrei Alexandrescu wrote:
 Denis Koroskin wrote:
 On Wed, 20 May 2009 00:43:56 +0400, Andrei Alexandrescu 
 <SeeWebsiteForEmail erdani.org> wrote:

 It's an awful idea. It's a non-idea. If "idea" had an antonym, that  
 would be it.

 I can't fathom what's on the mind of a person (not you, at least you
 foresee some potential problems) who, even after patiently explained the
 issues with this mental misfire, several times, still can bring
 themselves to think it's not that bad.
Your post is emotional rather than rational.
Agreed. In my defense, let me mention that I've been rational in my previous 50 posts on the topic :o).
 Let me add one more, although more than sure someone will find a remedy
 for it, too.

 a...b

 vs.

 a.. .b
a..b vs a.b - no one complains
You see, you didn't understand my point. My point was that the introduction of a space changes semantics. We should avoid that.
Like, a- --b vs. a-- -b ?
 It also gracefully solves an issue with uniform distribution

 uniform(0..int.max)  - exclusive
 uniform(0...int.max) - inclusive (can't be replaced with 0..int.max+1)
Yeah, and this does something else: uniform(0....int.max) and if you use an alias we also have: uniform(0.....A.max) It's interesting how there is a continuum of number of "." that still lead to compilable code that does different things every time. Perfect material for "Why D is a horrible language" articles. Andrei
May 20 2009
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
KennyTM~ wrote:
 Andrei Alexandrescu wrote:
 Denis Koroskin wrote:
 On Wed, 20 May 2009 00:43:56 +0400, Andrei Alexandrescu 
 <SeeWebsiteForEmail erdani.org> wrote:

 It's an awful idea. It's a non-idea. If "idea" had an antonym, that  
 would be it.

 I can't fathom what's on the mind of a person (not you, at least you
 foresee some potential problems) who, even after patiently explained 
 the
 issues with this mental misfire, several times, still can bring
 themselves to think it's not that bad.
Your post is emotional rather than rational.
Agreed. In my defense, let me mention that I've been rational in my previous 50 posts on the topic :o).
 Let me add one more, although more than sure someone will find a remedy
 for it, too.

 a...b

 vs.

 a.. .b
a..b vs a.b - no one complains
You see, you didn't understand my point. My point was that the introduction of a space changes semantics. We should avoid that.
Like, a- --b vs. a-- -b ?
Yes, like that. I didn't say there aren't any right now. I said we should avoid that. Andrei
May 20 2009
prev sibling parent bearophile <bearophileHUGS lycos.com> writes:
Denis Koroskin:
 It also gracefully solves an issue with uniform distribution
 uniform(0..int.max)  - exclusive
 uniform(0...int.max) - inclusive (can't be replaced with 0..int.max+1)
To avoid the possible confusion caused by ... Chapel uses ..# uniform(0 .. int.max) - exclusive uniform(0 ..# int.max) - inclusive Bye, bearophile
May 20 2009
prev sibling parent reply Georg Wrede <georg.wrede iki.fi> writes:
bearophile wrote:
 
 void classify(char c) {
     write("You passed ");
     switch (c) {
        case '#':
           writeln("a hash sign.");
           break;
        case '0' ..> '9':
           writeln("a digit.");
           break;
        case 'A' ..> 'Z', 'a' ..> 'z':
           writeln("an ASCII character.");
           break;
        case '.', ',', ':', ';', '!', '?':
           writeln("a punctuation mark.");
           break;
        default:
           writeln("quite a character!");
           break;
     }
 }
(A bunch of other versions omitted.)... void classify(char c) { write("You passed "); switch (c) { case '#': writeln("a hash sign."); break; case '0' .. case '9': writeln("a digit."); break; case 'A' .. case 'Z': case 'a' .. case 'z': writeln("an ASCII character."); break; case '.', ',', ':', ';', '!', '?': writeln("a punctuation mark."); break; default: writeln("quite a character!"); break; } } This is usable, easy to read -- and the programmer has no problem to remember that .. works differently in case statements than in ranges. There are other places in D that place an undue burden on the programmer, but this is not IMHO one of them. -------------------- My pet peeve with case is that, since we don't seem to be getting rid of break (and use some word for fall-through instead, "which would save a good deal of ink"), we should at least try to make break more conspicuous. I can name a hundred times I've forgotten a break from somewhere. So the canonical indentation should be like this: void classify(char c) { write("You passed "); switch (c) { case '#': writeln("a hash sign."); break; case '0' .. case '9': writeln("a digit."); break; case 'A' .. case 'Z': case 'a' .. case 'z': writeln("an ASCII character."); break; case '.', ',', ':', ';', '!', '?': writeln("a punctuation mark."); break; default: writeln("quite a character!"); break; } } (It'd look better when the cases have more lines, but still.) Currently in D, break is at least as important as case, therefore it deserves a conspicuous place, hence my suggestion.
May 18 2009
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Georg Wrede wrote:
 bearophile wrote:
 void classify(char c) {
     write("You passed ");
     switch (c) {
        case '#':
           writeln("a hash sign.");
           break;
        case '0' ..> '9':
           writeln("a digit.");
           break;
        case 'A' ..> 'Z', 'a' ..> 'z':
           writeln("an ASCII character.");
           break;
        case '.', ',', ':', ';', '!', '?':
           writeln("a punctuation mark.");
           break;
        default:
           writeln("quite a character!");
           break;
     }
 }
(A bunch of other versions omitted.)... void classify(char c) { write("You passed "); switch (c) { case '#': writeln("a hash sign."); break; case '0' .. case '9': writeln("a digit."); break; case 'A' .. case 'Z': case 'a' .. case 'z': writeln("an ASCII character."); break; case '.', ',', ':', ';', '!', '?': writeln("a punctuation mark."); break; default: writeln("quite a character!"); break; } } This is usable, easy to read -- and the programmer has no problem to remember that .. works differently in case statements than in ranges.
I'd like to keep the (non-required) colon after the first expression in a ".." pair of case labels, that is: case '0': .. case '9': as opposed to case '0' .. case '9': That way it is abundantly clear that the notation has nothing in common with expression1 .. expression2. The error message if someone forgot the ':' can easily be made clear. Andrei
May 18 2009
next sibling parent Michel Fortin <michel.fortin michelf.com> writes:
On 2009-05-18 22:39:23 -0400, Andrei Alexandrescu 
<SeeWebsiteForEmail erdani.org> said:

 I'd like to keep the (non-required) colon after the first expression in 
 a ".." pair of case labels, that is:
 
 case '0': .. case '9':
 
 as opposed to
 
 case '0' .. case '9':
 
 That way it is abundantly clear that the notation has nothing in common 
 with expression1 .. expression2. The error message if someone forgot 
 the ':' can easily be made clear.
You could have '::' denote an inclusive range. :-) case '0'..'9': // '9' excluded case '0'::'9': // '9' included Seriously, I don't care much what the syntax is as long as it's different from the one used for exclusive range. Both: case '0': .. case '9': looks acceptable to me. Although I agree with others about the inconsistency of using ".." for an inclusive range, having it finish with "case '9':" seems to indicate clearly the intent to include the last element. -- Michel Fortin michel.fortin michelf.com http://michelf.com/
May 18 2009
prev sibling next sibling parent Georg Wrede <georg.wrede iki.fi> writes:
Andrei Alexandrescu wrote:
 Georg Wrede wrote:
 bearophile wrote:
 void classify(char c) {
     write("You passed ");
     switch (c) {
        case '#':
           writeln("a hash sign.");
           break;
        case '0' ..> '9':
           writeln("a digit.");
           break;
        case 'A' ..> 'Z', 'a' ..> 'z':
           writeln("an ASCII character.");
           break;
        case '.', ',', ':', ';', '!', '?':
           writeln("a punctuation mark.");
           break;
        default:
           writeln("quite a character!");
           break;
     }
 }
(A bunch of other versions omitted.)... void classify(char c) { write("You passed "); switch (c) { case '#': writeln("a hash sign."); break; case '0' .. case '9': writeln("a digit."); break; case 'A' .. case 'Z': case 'a' .. case 'z': writeln("an ASCII character."); break; case '.', ',', ':', ';', '!', '?': writeln("a punctuation mark."); break; default: writeln("quite a character!"); break; } } This is usable, easy to read -- and the programmer has no problem to remember that .. works differently in case statements than in ranges.
I'd like to keep the (non-required) colon after the first expression in a ".." pair of case labels, that is: case '0': .. case '9': as opposed to case '0' .. case '9': That way it is abundantly clear that the notation has nothing in common with expression1 .. expression2. The error message if someone forgot the ':' can easily be made clear.
So concatenating ranges would be case '0': .. case '9': case 'a': .. case 'z': do something which then could be written, depending on programmer preferences case '0': .. case '9': case 'a': .. case 'z': do something or case '0': .. case '9': case 'a': .. case 'z': do something While I'd prefer to omit the colon, I can live with it.
May 18 2009
prev sibling parent "Denis Koroskin" <2korden gmail.com> writes:
On Tue, 19 May 2009 06:39:23 +0400, Andrei Alexandrescu
<SeeWebsiteForEmail erdani.org> wrote:

 Georg Wrede wrote:
 bearophile wrote:
 void classify(char c) {
     write("You passed ");
     switch (c) {
        case '#':
           writeln("a hash sign.");
           break;
        case '0' ..> '9':
           writeln("a digit.");
           break;
        case 'A' ..> 'Z', 'a' ..> 'z':
           writeln("an ASCII character.");
           break;
        case '.', ',', ':', ';', '!', '?':
           writeln("a punctuation mark.");
           break;
        default:
           writeln("quite a character!");
           break;
     }
 }
(A bunch of other versions omitted.)... void classify(char c) { write("You passed "); switch (c) { case '#': writeln("a hash sign."); break; case '0' .. case '9': writeln("a digit."); break; case 'A' .. case 'Z': case 'a' .. case 'z': writeln("an ASCII character."); break; case '.', ',', ':', ';', '!', '?': writeln("a punctuation mark."); break; default: writeln("quite a character!"); break; } } This is usable, easy to read -- and the programmer has no problem to remember that .. works differently in case statements than in ranges.
I'd like to keep the (non-required) colon after the first expression in a ".." pair of case labels, that is: case '0': .. case '9': as opposed to case '0' .. case '9': That way it is abundantly clear that the notation has nothing in common with expression1 .. expression2. The error message if someone forgot the ':' can easily be made clear. Andrei
Will it be possible to write like this? void classify(char c) { write("You passed "); switch (c) { case '0': .. case '9': writeln("a digit."); break; case 'A': .. case 'Z': writeln("upper case ASCII character."); break; case 'a': .. case 'z': writeln("lower case ASCII character."); break; case '.', ',', ':', ';', '!', '?': writeln("a punctuation mark."); break; default: writeln("quite a character!"); break; } } Looks cool!
May 19 2009
prev sibling next sibling parent reply Rainer Deyke <rainerd eldwood.com> writes:
Georg Wrede wrote:
 This is usable, easy to read -- and the programmer has no problem to
 remember that .. works differently in case statements than in ranges.
You're making two assumptions here: 1. That inclusive ranges are preferable inside 'case' statements. 2. That non-inclusive ranges are preferable outside 'case' statements. I don't buy it. The issue of inclusive versus non-inclusive ranges is *exactly the same* in and outside 'case' statements. // Non-inclusive: foreach (c; start .. middle) doA(c); foreach (c; middle .. end) doB(c); foreach (c; start .. end) { switch (c) { case start .. middle: doA(c); break; case middle .. end: doA(c); break; } } // Inclusive: foreach (c; 'a' ... 'z') doSomething(c); switch (c) { case 'a' ... 'z': doSomething(c); break; } foreach (c; 0 ... int.max) doSomething(c); switch (c) { case 0 ... int.max: doSomething(c); break; } Since I don't accept your assumptions, I see no point in arguing whether or not those assumptions would justify overloading the '..' operator to have one meaning in 'case' statements and another meaning elsewhere. -- Rainer Deyke - rainerd eldwood.com
May 18 2009
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Rainer Deyke wrote:
 Georg Wrede wrote:
 This is usable, easy to read -- and the programmer has no problem to
 remember that .. works differently in case statements than in ranges.
You're making two assumptions here: 1. That inclusive ranges are preferable inside 'case' statements.
Yes. The point of case a: .. case b: is to save you from writing case a: case a+1: and so on up to case b:. There is no exclusion. You write now the cases you want to handle.
 2. That non-inclusive ranges are preferable outside 'case' statements.
Of course. One word: STL.
 I don't buy it.  The issue of inclusive versus non-inclusive ranges is
 *exactly the same* in and outside 'case' statements.
No. Andrei
May 18 2009
parent Rainer Deyke <rainerd eldwood.com> writes:
Andrei Alexandrescu wrote:
 Rainer Deyke wrote:
 You're making two assumptions here:
 1. That inclusive ranges are preferable inside 'case' statements.
Yes. The point of case a: .. case b: is to save you from writing case a: case a+1: and so on up to case b:. There is no exclusion. You write now the cases you want to handle.
 2. That non-inclusive ranges are preferable outside 'case' statements.
Of course. One word: STL.
I can think of two concrete advantages of half-open/non-inclusive ranges: 1. When using zero-based indexing, '0 .. length' expresses all elements in a sequence. 2. A range can be 'split' on any point 'x' into subranges '0 .. x' and 'x .. length'. Both of these advantages also apply to 'case' statements: const int first_nullary_instruction = 5, first_unary_instruction = 5, first_binary_instruction = 10, num_instructions = 15; switch (c) { case first_nullary_instruction .. first_unary_instruction: executeNullaryInstruction(); break; case first_unary_instruction .. first_binary_instruction: executeUnaryInstruction(); break; case first_binary_instruction .. num_instructions: executeUnaryInstruction(); break; default: illegalInstruction(); break; } I can think of two concrete advantages of inclusive ranges: 1. The past-the-end element may not be known. 2. The past-the-end element may not be representable. Both of these advantages also outside 'case' statements: foreach (i; 0 ... int.max) doSomethingWith(i); -- Rainer Deyke - rainerd eldwood.com
May 18 2009
prev sibling parent reply Mike James <foo bar.com> writes:
Georg Wrede Wrote:

 bearophile wrote:
 
 void classify(char c) {
     write("You passed ");
     switch (c) {
        case '#':
           writeln("a hash sign.");
           break;
        case '0' ..> '9':
           writeln("a digit.");
           break;
        case 'A' ..> 'Z', 'a' ..> 'z':
           writeln("an ASCII character.");
           break;
        case '.', ',', ':', ';', '!', '?':
           writeln("a punctuation mark.");
           break;
        default:
           writeln("quite a character!");
           break;
     }
 }
(A bunch of other versions omitted.)... void classify(char c) { write("You passed "); switch (c) { case '#': writeln("a hash sign."); break; case '0' .. case '9': writeln("a digit."); break; case 'A' .. case 'Z': case 'a' .. case 'z': writeln("an ASCII character."); break; case '.', ',', ':', ';', '!', '?': writeln("a punctuation mark."); break; default: writeln("quite a character!"); break; } } This is usable, easy to read -- and the programmer has no problem to remember that .. works differently in case statements than in ranges. There are other places in D that place an undue burden on the programmer, but this is not IMHO one of them. -------------------- My pet peeve with case is that, since we don't seem to be getting rid of break (and use some word for fall-through instead, "which would save a good deal of ink"), we should at least try to make break more conspicuous. I can name a hundred times I've forgotten a break from somewhere. So the canonical indentation should be like this: void classify(char c) { write("You passed "); switch (c) { case '#': writeln("a hash sign."); break; case '0' .. case '9': writeln("a digit."); break; case 'A' .. case 'Z': case 'a' .. case 'z': writeln("an ASCII character."); break; case '.', ',', ':', ';', '!', '?': writeln("a punctuation mark."); break; default: writeln("quite a character!"); break; } } (It'd look better when the cases have more lines, but still.) Currently in D, break is at least as important as case, therefore it deserves a conspicuous place, hence my suggestion.
Full Circle... http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=81519
May 19 2009
parent Georg Wrede <georg.wrede iki.fi> writes:
Mike James wrote:
 Full Circle...
 
If you're trying to emphasize the significance of this proposal, then good. But if you're trying to say that one should post more original posts, then bad.
May 19 2009
prev sibling next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Bill Baxter wrote:
 On Mon, May 18, 2009 at 3:29 PM, Jason House
 <jason.james.house gmail.com> wrote:
 
 It's all a matter of perspective. I see both as begin .. end. That may be the
same reason why I think addition when I see foo(bar()) + baz(37). The extra
cruft is more or less ignored when figuring out the basics of what is going on.
Agreed. If you tell someone a .. b means a non-inclusive range from a to b, then ask them to guess what blarf a .. blarf b means, I would be very surprised if many guessed "inclusive range from blarf a to blarf b".
But it's not "blarf". It's "case". I am floored that nobody sees the elegance of that syntax. Andrei
May 18 2009
next sibling parent reply Bill Baxter <wbaxter gmail.com> writes:
On Mon, May 18, 2009 at 4:02 PM, Andrei Alexandrescu
<SeeWebsiteForEmail erdani.org> wrote:
 Bill Baxter wrote:
 On Mon, May 18, 2009 at 3:29 PM, Jason House
 <jason.james.house gmail.com> wrote:

 It's all a matter of perspective. I see both as begin .. end. That may =
be
 the same reason why I think addition when I see foo(bar()) + baz(37). T=
he
 extra cruft is more or less ignored when figuring out the basics of wha=
t is
 going on.
Agreed. =A0If you tell someone =A0 a .. b =A0means a non-inclusive range from a to b, then ask them to guess what =A0 =A0blarf a .. blarf b =A0me=
ans,
 I would be very surprised if many guessed "inclusive range from blarf
 a =A0to blarf b".
But it's not "blarf". It's "case". I am floored that nobody sees the elegance of that syntax.
So your argument is that "case" inherently deserves a special case? I don't think it's a terrible syntax, but I wouldn't go as far as to call it elegant. I'm with bear that it would be better if we could come up with some syntax that means "inclusive range" everywhere. Rather than introducing special cases. Special cases are generally a sign that something has gone wrong in a language design. --bb
May 18 2009
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Bill Baxter wrote:
 On Mon, May 18, 2009 at 4:02 PM, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org> wrote:
 Bill Baxter wrote:
 On Mon, May 18, 2009 at 3:29 PM, Jason House
 <jason.james.house gmail.com> wrote:

 It's all a matter of perspective. I see both as begin .. end. That may be
 the same reason why I think addition when I see foo(bar()) + baz(37). The
 extra cruft is more or less ignored when figuring out the basics of what is
 going on.
Agreed. If you tell someone a .. b means a non-inclusive range from a to b, then ask them to guess what blarf a .. blarf b means, I would be very surprised if many guessed "inclusive range from blarf a to blarf b".
But it's not "blarf". It's "case". I am floored that nobody sees the elegance of that syntax.
So your argument is that "case" inherently deserves a special case?
It has been a keyword with a specific meaning for many years. That's bound to mean something.
 I don't think it's a terrible syntax, but I wouldn't go as far as to
 call it elegant.  I'm with bear that it would be better if we could
 come up with some syntax that means "inclusive range" everywhere.
 Rather than introducing special cases.  Special cases are generally a
 sign that something has gone wrong in a language design.
I completely disagree that that's a special case. ".." is punctuation. You can't pretend punctuation has the same meaning everywhere in a programming language. Andrei
May 18 2009
parent reply Derek Parnell <derek psych.ward> writes:
On Mon, 18 May 2009 19:31:23 -0500, Andrei Alexandrescu wrote:

 I completely disagree that that's a special case. ".." is punctuation. 
 You can't pretend punctuation has the same meaning everywhere in a 
 programming language.
I'm a bit confused. Are you saying that one must expect that the meaning of punctuation in a programming language depends on the context the punctuation is found in? If so, then ".." in "[a .. b]" can mean exclusive range and ".." in "case a .. b:" can mean inclusive range, no? -- Derek Parnell Melbourne, Australia skype: derek.j.parnell
May 18 2009
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Derek Parnell wrote:
 On Mon, 18 May 2009 19:31:23 -0500, Andrei Alexandrescu wrote:
 
 I completely disagree that that's a special case. ".." is punctuation. 
 You can't pretend punctuation has the same meaning everywhere in a 
 programming language.
I'm a bit confused. Are you saying that one must expect that the meaning of punctuation in a programming language depends on the context the punctuation is found in?
How many meanings does '[' have in your favorite programming language? Andrei
May 18 2009
parent reply Derek Parnell <derek psych.ward> writes:
On Mon, 18 May 2009 21:47:01 -0500, Andrei Alexandrescu wrote:

 Derek Parnell wrote:
 On Mon, 18 May 2009 19:31:23 -0500, Andrei Alexandrescu wrote:
 
 I completely disagree that that's a special case. ".." is punctuation. 
 You can't pretend punctuation has the same meaning everywhere in a 
 programming language.
I'm a bit confused. Are you saying that one must expect that the meaning of punctuation in a programming language depends on the context the punctuation is found in?
How many meanings does '[' have in your favorite programming language?
One. But how is your question an answer to my question? -- Derek Parnell Melbourne, Australia skype: derek.j.parnell
May 18 2009
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Derek Parnell wrote:
 On Mon, 18 May 2009 21:47:01 -0500, Andrei Alexandrescu wrote:
 
 Derek Parnell wrote:
 On Mon, 18 May 2009 19:31:23 -0500, Andrei Alexandrescu wrote:

 I completely disagree that that's a special case. ".." is punctuation. 
 You can't pretend punctuation has the same meaning everywhere in a 
 programming language.
I'm a bit confused. Are you saying that one must expect that the meaning of punctuation in a programming language depends on the context the punctuation is found in?
How many meanings does '[' have in your favorite programming language?
One.
No. Andrei
May 18 2009
parent reply Derek Parnell <derek psych.ward> writes:
On Mon, 18 May 2009 23:02:37 -0500, Andrei Alexandrescu wrote:

 Derek Parnell wrote:
 On Mon, 18 May 2009 21:47:01 -0500, Andrei Alexandrescu wrote:
 
 Derek Parnell wrote:
 On Mon, 18 May 2009 19:31:23 -0500, Andrei Alexandrescu wrote:

 I completely disagree that that's a special case. ".." is punctuation. 
 You can't pretend punctuation has the same meaning everywhere in a 
 programming language.
I'm a bit confused. Are you saying that one must expect that the meaning of punctuation in a programming language depends on the context the punctuation is found in?
How many meanings does '[' have in your favorite programming language?
One.
No.
But you never asked for the name of my favourite language? -- Derek Parnell Melbourne, Australia skype: derek.j.parnell
May 18 2009
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Derek Parnell wrote:
 On Mon, 18 May 2009 23:02:37 -0500, Andrei Alexandrescu wrote:
 
 Derek Parnell wrote:
 On Mon, 18 May 2009 21:47:01 -0500, Andrei Alexandrescu wrote:

 Derek Parnell wrote:
 On Mon, 18 May 2009 19:31:23 -0500, Andrei Alexandrescu wrote:

 I completely disagree that that's a special case. ".." is punctuation. 
 You can't pretend punctuation has the same meaning everywhere in a 
 programming language.
I'm a bit confused. Are you saying that one must expect that the meaning of punctuation in a programming language depends on the context the punctuation is found in?
How many meanings does '[' have in your favorite programming language?
One.
No.
But you never asked for the name of my favourite language?
Yah, I realized my flawed supposition after sending :o). So, what is it? Andrei
May 18 2009
parent reply Derek Parnell <derek psych.ward> writes:
On Mon, 18 May 2009 23:20:11 -0500, Andrei Alexandrescu wrote:

 Derek Parnell wrote:
 But you never asked for the name of my favourite language?
 Yah, I realized my flawed supposition after sending :o). So, what is it?
Actually I have two - Forth and Euphoria, but D comes a close second. Anyways ... back to the actually question that I asked and you haven't got around to answering yet -- (you're not doing politian training are you :-)) On Mon, 18 May 2009 19:31:23 -0500, Andrei Alexandrescu wrote:
 I completely disagree that that's a special case. ".." is punctuation. 
 You can't pretend punctuation has the same meaning everywhere in a 
 programming language.
I'm a bit confused. Are you saying that one must expect that the meaning of punctuation in a programming language depends on the context the punctuation is found in? If so, then ".." in "[a .. b]" can mean exclusive range and ".." in "case a .. b:" can mean inclusive range, no? -- Derek Parnell Melbourne, Australia skype: derek.j.parnell
May 18 2009
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Derek Parnell wrote:
 I'm a bit confused. Are you saying that one must expect that the meaning of
 punctuation in a programming language depends on the context the
 punctuation is found in?
 
 If so, then ".." in "[a .. b]" can mean exclusive range and ".." in "case a
 .. b:" can mean inclusive range, no?
No, you don't understand. But I sworn that I'll explain it for the last time in another post, so I'm out of times I can explain it. Let me make a separate point. With "...", people just defined the space operator. What's the space operator? Changes the meaning of 0...10 in two distinct ways: 0...10 is an all-inclusive integer range from 0 to 10 0. ..10 is a right-open floating-point range from 0 to 10 0.. .10 is a right-open floating-point range from 0 to 0.1 Not to mention: 0.....10 is an all-inclusive floating-point range from 0 to .1 (if I counted my dots right). I have no doubt somebody will find this all intuitive and pleasing on the eye, and will suggest a couple of additional constructs and keywords to improve things. Andrei
May 18 2009
parent reply "Nick Sabalausky" <a a.a> writes:
"Andrei Alexandrescu" <SeeWebsiteForEmail erdani.org> wrote in message 
news:gutd12$16h9$1 digitalmars.com...
 Let me make a separate point. With "...", people just defined the space 
 operator. What's the space operator? Changes the meaning of 0...10 in two 
 distinct ways:

 0...10 is an all-inclusive integer range from 0 to 10
 0. ..10 is a right-open floating-point range from 0 to 10
 0.. .10 is a right-open floating-point range from 0 to 0.1
So '1.' and '.1' are legal numbers in D? I would have assumed that any numerical literal with a decimal point would require at least one digit on both sides of the decimal point. Not sure I see a good reason for this not to be required.
May 19 2009
parent reply Georg Wrede <georg.wrede iki.fi> writes:
Nick Sabalausky wrote:
 "Andrei Alexandrescu" <SeeWebsiteForEmail erdani.org> wrote in message 
 news:gutd12$16h9$1 digitalmars.com...
 Let me make a separate point. With "...", people just defined the space 
 operator. What's the space operator? Changes the meaning of 0...10 in two 
 distinct ways:

 0...10 is an all-inclusive integer range from 0 to 10
 0. ..10 is a right-open floating-point range from 0 to 10
 0.. .10 is a right-open floating-point range from 0 to 0.1
So '1.' and '.1' are legal numbers in D? I would have assumed that any numerical literal with a decimal point would require at least one digit on both sides of the decimal point. Not sure I see a good reason for this not to be required.
Agreed. Saving ink in 1. versus 1.0 and .1 versus 0.1 is stupid -- even if we don't consider "the new space operator" implications!!!!!! It really makes it hard to spot the odd decimal value when you're not expecting it there. That's mainly an American invention. In Europe, in most countries, you couldn't ever write .1 without everybody shouting typo! Had D been invented in Europe, .1 would never have crossed anybodys mind. After several decades, I'm still uncomfortable when anybody writes .1, be it in programming or on street billboards. Then we could go on (not that Andrei ever meant it, so I'm not serious here), and write 1.0..2.0 an all-inclusive floating range from 1.0 to 2.0 1.0 ..2.0 a right-inclusive floating range from 1.0 to 2.0 1.0.. 2.0 a left-inclusive floating range from 1.0 to 2.0 1.0 .. 2.0 a non-inclusive floating range from 1.0 to 2.0 1..2 an all-inclusive integer range from 1 to 2 1 ..2 a right-inclusive integer range from 1 to 2 1.. 2 a left-inclusive integer range from 1 to 2 1 .. 2 a non-iclusive integer range from 1 to 2 (And we didn't even need the triple-dot operator!) But this would break existing code, make white-space significant, choke Andrei, pop Walter's ulcer, and generally be reminiscent of interpreted languages (read: embarrassing). (Not that whitespace isn't already significant in a way, otherwise we could write 1 . 2 and it would be the same thing as 1.2.) Actually, I'm not sure there would be ambuguity with the American decimals, either: 1....2 an all-inclusive range from 1. to .2 1. ...2 a right-inclusive range from 1. to .2 1... .2 a left-inclusive range from 1. to .2 1. .. .2 a non-inclusive range from 1. to .2 1...2 Error: improperly mixing integers and floating point. Note, I'm personally against having decimals in ranges in the first place.
May 19 2009
next sibling parent reply Jarrett Billingsley <jarrett.billingsley gmail.com> writes:
On Tue, May 19, 2009 at 8:37 AM, Georg Wrede <georg.wrede iki.fi> wrote:

 So '1.' and '.1' =A0are legal numbers in D? I would have assumed that an=
y
 numerical literal with a decimal point would require at least one digit =
on
 both sides of the decimal point. Not sure I see a good reason for this n=
ot
 to be required.
Agreed. Saving ink in 1. versus 1.0 and .1 versus 0.1 is stupid -- even i=
f
 we don't consider "the new space operator" implications!!!!!! It really
 makes it hard to spot the odd decimal value when you're not expecting it
 there.

 That's mainly an American invention. In Europe, in most countries, you
 couldn't ever write .1 without everybody shouting typo!

 Had D been invented in Europe, .1 would never have crossed anybodys mind.
 After several decades, I'm still uncomfortable when anybody writes .1, be=
it
 in programming or on street billboards.
For what it's worth, I'm American and have neither seen the 'one-sided floating-point number' used in public nor am I comfortable with it being in a programming language. It just doesn't look right.
May 19 2009
parent reply Georg Wrede <georg.wrede iki.fi> writes:
Jarrett Billingsley wrote:
 On Tue, May 19, 2009 at 8:37 AM, Georg Wrede <georg.wrede iki.fi> wrote:
 
 So '1.' and '.1'  are legal numbers in D? I would have assumed that any
 numerical literal with a decimal point would require at least one digit on
 both sides of the decimal point. Not sure I see a good reason for this not
 to be required.
Agreed. Saving ink in 1. versus 1.0 and .1 versus 0.1 is stupid -- even if we don't consider "the new space operator" implications!!!!!! It really makes it hard to spot the odd decimal value when you're not expecting it there. That's mainly an American invention. In Europe, in most countries, you couldn't ever write .1 without everybody shouting typo! Had D been invented in Europe, .1 would never have crossed anybodys mind. After several decades, I'm still uncomfortable when anybody writes .1, be it in programming or on street billboards.
For what it's worth, I'm American and have neither seen the 'one-sided floating-point number' used in public nor am I comfortable with it being in a programming language. It just doesn't look right.
Yeah. If it was up to me, it'd be forbidden.
May 19 2009
parent reply =?UTF-8?B?QWxleGFuZGVyIFDDoW5law==?= writes:
Georg Wrede wrote:
 Jarrett Billingsley wrote:
 On Tue, May 19, 2009 at 8:37 AM, Georg Wrede <georg.wrede iki.fi> wrote:
 After several decades, I'm still uncomfortable when anybody writes 
 .1, be it
 in programming or on street billboards.
For what it's worth, I'm American and have neither seen the 'one-sided floating-point number' used in public nor am I comfortable with it being in a programming language. It just doesn't look right.
Yeah. If it was up to me, it'd be forbidden.
Same here.
May 19 2009
parent reply bearophile <bearophileHUGS lycos.com> writes:
Alexander Pánek:
 Same here.
I too don't like .56, I add a zero when I see a literal like that in the code. But what about Walter? :-) Bye, bearophile
May 19 2009
parent reply div0 <div0 users.sourceforge.net> writes:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

bearophile wrote:
 Alexander Pánek:
 Same here.
I too don't like .56, I add a zero when I see a literal like that in the code. But what about Walter? :-) Bye, bearophile
I always use it, but I won't be bothered if it was outlawed. - -- My enormous talent is exceeded only by my outrageous laziness. http://www.ssTk.co.uk -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFKEvG/T9LetA9XoXwRAkIaAKCdqOLBL9X+KwRm/vAmtoxVR4KXCQCeOaQt Tsgo4JIuNIfP9UgiTaMLLtM= =eo39 -----END PGP SIGNATURE-----
May 19 2009
parent Bill Baxter <wbaxter gmail.com> writes:
On Tue, May 19, 2009 at 10:51 AM, div0 <div0 users.sourceforge.net> wrote:
 -----BEGIN PGP SIGNED MESSAGE-----
 Hash: SHA1

 bearophile wrote:
 Alexander P=E1nek:
 Same here.
I too don't like .56, I add a zero when I see a literal like that in the=
code. But what about Walter? :-)
 Bye,
 bearophile
I always use it, but I won't be bothered if it was outlawed.
I use it too. Looks fine to me. I also use the 3.f form on occasion to get an integral float. --bb
May 19 2009
prev sibling parent "Nick Sabalausky" <a a.a> writes:
"Georg Wrede" <georg.wrede iki.fi> wrote in message 
news:guu95i$2p6c$1 digitalmars.com...
 That's mainly an American invention. In Europe, in most countries, you 
 couldn't ever write .1 without everybody shouting typo!
*shrug*, I've lived in the US all my life and it's never occurred to me to consider .1 anything but a typo (or at least laziness).
 Then we could go on (not that Andrei ever meant it, so I'm not serious 
 here), and write

 1.0..2.0   an all-inclusive floating range from 1.0 to 2.0
 1.0 ..2.0   a right-inclusive floating range from 1.0 to 2.0
 1.0.. 2.0   a left-inclusive floating range from 1.0 to 2.0
 1.0 .. 2.0   a non-inclusive floating range from 1.0 to 2.0

 1..2   an all-inclusive integer range from 1 to 2
 1 ..2   a right-inclusive integer range from 1 to 2
 1.. 2   a left-inclusive integer range from 1 to 2
 1 .. 2   a non-iclusive integer range from 1 to 2

 (And we didn't even need the triple-dot operator!)

 But this would break existing code, make white-space significant, choke 
 Andrei, pop Walter's ulcer, and generally be reminiscent of interpreted 
 languages (read: embarrassing).
Hee hee hee :)
 (Not that whitespace isn't already significant in a way, otherwise we 
 could write 1 . 2 and it would be the same thing as 1.2.)
Or "int foo" vs "intfoo".
May 19 2009
prev sibling parent reply Bill Baxter <wbaxter gmail.com> writes:
On Mon, May 18, 2009 at 9:17 PM, Derek Parnell <derek psych.ward> wrote:
 On Mon, 18 May 2009 23:02:37 -0500, Andrei Alexandrescu wrote:

 Derek Parnell wrote:
 On Mon, 18 May 2009 21:47:01 -0500, Andrei Alexandrescu wrote:

 Derek Parnell wrote:
 On Mon, 18 May 2009 19:31:23 -0500, Andrei Alexandrescu wrote:

 I completely disagree that that's a special case. ".." is punctuation.
 You can't pretend punctuation has the same meaning everywhere in a
 programming language.
I'm a bit confused. Are you saying that one must expect that the meaning of punctuation in a programming language depends on the context the punctuation is found in?
How many meanings does '[' have in your favorite programming language?
One.
No.
But you never asked for the name of my favourite language?
Does it have string or character literals? Then there's probably at least two meanings. ;-P --bb
May 18 2009
parent reply Derek Parnell <derek psych.ward> writes:
On Mon, 18 May 2009 21:30:41 -0700, Bill Baxter wrote:

 On Mon, May 18, 2009 at 9:17 PM, Derek Parnell <derek psych.ward> wrote:
 On Mon, 18 May 2009 23:02:37 -0500, Andrei Alexandrescu wrote:

 Derek Parnell wrote:
 On Mon, 18 May 2009 21:47:01 -0500, Andrei Alexandrescu wrote:

 Derek Parnell wrote:
 On Mon, 18 May 2009 19:31:23 -0500, Andrei Alexandrescu wrote:

 I completely disagree that that's a special case. ".." is punctuation.
 You can't pretend punctuation has the same meaning everywhere in a
 programming language.
I'm a bit confused. Are you saying that one must expect that the meaning of punctuation in a programming language depends on the context the punctuation is found in?
How many meanings does '[' have in your favorite programming language?
One.
No.
But you never asked for the name of my favourite language?
Does it have string or character literals? Then there's probably at least two meanings. ;-P
Huh? "two meanings" of '[' ... is that what you are saying? Ok, the language has both string literals and character literals, so how does that imply that '[' has two meanings? -- Derek Parnell Melbourne, Australia skype: derek.j.parnell
May 19 2009
parent reply Max Samukha <outer space.com> writes:
On Tue, 19 May 2009 18:23:25 +1000, Derek Parnell <derek psych.ward>
wrote:

On Mon, 18 May 2009 21:30:41 -0700, Bill Baxter wrote:

 On Mon, May 18, 2009 at 9:17 PM, Derek Parnell <derek psych.ward> wrote:
 On Mon, 18 May 2009 23:02:37 -0500, Andrei Alexandrescu wrote:

 Derek Parnell wrote:
 On Mon, 18 May 2009 21:47:01 -0500, Andrei Alexandrescu wrote:

 Derek Parnell wrote:
 On Mon, 18 May 2009 19:31:23 -0500, Andrei Alexandrescu wrote:

 I completely disagree that that's a special case. ".." is punctuation.
 You can't pretend punctuation has the same meaning everywhere in a
 programming language.
I'm a bit confused. Are you saying that one must expect that the meaning of punctuation in a programming language depends on the context the punctuation is found in?
How many meanings does '[' have in your favorite programming language?
One.
No.
But you never asked for the name of my favourite language?
Does it have string or character literals? Then there's probably at least two meanings. ;-P
Huh? "two meanings" of '[' ... is that what you are saying? Ok, the language has both string literals and character literals, so how does that imply that '[' has two meanings?
In D, [ has at least four meanings: auto a = [1, 2, 3]; - array initializer a[1] - indexing operator a[c..d] - slicing operator int[10] - static array declarator C++ has [] for lambdas (no! C++ should be banned by the international law, if there is any)
May 19 2009
parent Daniel Keep <daniel.keep.lists gmail.com> writes:
Max Samukha wrote:
 ...
 
 In D, [ has at least four meanings:
 
 auto a = [1, 2, 3]; - array initializer
 a[1] - indexing operator
 a[c..d] - slicing operator 
 int[10] - static array declarator
 
 C++ has [] for lambdas (no! C++ should be banned by the international
 law, if there is any)
Actually, it's more like two. a[1] int[] int[10] a[c..d] These are all subscript notation. [1, 2, 3] [a:b, c:d] These are array literal notation. From a strict, semantics nazi point of view, that's really six meanings. But that's like arguing there's a meaningful difference between a.b and A.b where a is a value and A is a type. It's worth noting that I still sometimes forget that [...] is for array literals, but I never ever forget its use for subscripting. -- Daniel
May 19 2009
prev sibling next sibling parent reply Bill Baxter <wbaxter gmail.com> writes:
On Mon, May 18, 2009 at 4:15 PM, Bill Baxter <wbaxter gmail.com> wrote:
 But it's not "blarf". It's "case". I am floored that nobody sees the
 elegance of that syntax.
So your argument is that "case" inherently deserves a special case?
Thinking about it more, I guess you must actually be seeing it as a rule of " '..' always does the most useful thing", and the most useful thing for switches is inclusive. I see that as a local minimum in the design space that would be exceeded by having a good syntax to express inclusive ranges when you want them. --bb
May 18 2009
next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Bill Baxter:
 Thinking about it more, I guess you must actually be seeing it as a
 rule of   " '..' always does the most useful thing",
Such attitude/purposes have created the monkey mess named Perl :-] Bye, bearophile
May 18 2009
parent reply Derek Parnell <derek psych.ward> writes:
On Mon, 18 May 2009 19:53:51 -0400, bearophile wrote:

 Bill Baxter:
 Thinking about it more, I guess you must actually be seeing it as a
 rule of   " '..' always does the most useful thing",
Such attitude/purposes have created the monkey mess named Perl :-]
I submit the D words 'static', 'auto' and 'scope' as examples of this too. -- Derek Parnell Melbourne, Australia skype: derek.j.parnell
May 18 2009
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Derek Parnell wrote:
 On Mon, 18 May 2009 19:53:51 -0400, bearophile wrote:
 
 Bill Baxter:
 Thinking about it more, I guess you must actually be seeing it as a
 rule of   " '..' always does the most useful thing",
Such attitude/purposes have created the monkey mess named Perl :-]
I submit the D words 'static', 'auto' and 'scope' as examples of this too.
When was the last time you had trouble with "static"? Can you show a snippet of code that's confusing because of it? Andrei
May 18 2009
parent reply Derek Parnell <derek psych.ward> writes:
On Mon, 18 May 2009 21:58:19 -0500, Andrei Alexandrescu wrote:

 Derek Parnell wrote:
 On Mon, 18 May 2009 19:53:51 -0400, bearophile wrote:
 
 Bill Baxter:
 Thinking about it more, I guess you must actually be seeing it as a
 rule of   " '..' always does the most useful thing",
Such attitude/purposes have created the monkey mess named Perl :-]
I submit the D words 'static', 'auto' and 'scope' as examples of this too.
When was the last time you had trouble with "static"? Can you show a snippet of code that's confusing because of it?
"not having a trouble" and "not being consistant" are two different things. For example, I have no trouble with ".." meaning exclusive range inside a '[' ']' pair, and an inclusive range in a 'case' statement. That does not trouble me at all and yet it is an inconsistancy. But back to your question ... here is 'static' used with three different meanings within three lines of code. ------- module xyzzy; import std.stdio; version(X) const int y = 1; else const int y = -1; static this() { static if (y == 1) static int x = 0; else static int x = 42; writefln("X=%d Y=%d", x,y); } void main() { } ---------- But maybe that's just me? -- Derek Parnell Melbourne, Australia skype: derek.j.parnell
May 18 2009
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Derek Parnell wrote:
 But back to your question ... here is 'static' used with three different
 meanings within three lines of code.
 
 -------
 module xyzzy;
 import std.stdio;
 
 version(X) const int y = 1;
 else       const int y = -1;
            
 static this() {
    static if (y == 1) 
       static int x = 0;
    else
       static int x = 42;
  
    writefln("X=%d Y=%d", x,y);
 }
 
 void main()
 {
    
 }
 
 ----------
 
 But maybe that's just me?
Doesn't confuse me one bit. Andrei
May 18 2009
parent Derek Parnell <derek psych.ward> writes:
On Mon, 18 May 2009 23:05:03 -0500, Andrei Alexandrescu wrote:

 Derek Parnell wrote:
 But back to your question ... here is 'static' used with three different
 meanings within three lines of code.
 
 -------
 module xyzzy;
 import std.stdio;
 
 version(X) const int y = 1;
 else       const int y = -1;
            
 static this() {
    static if (y == 1) 
       static int x = 0;
    else
       static int x = 42;
  
    writefln("X=%d Y=%d", x,y);
 }
 
 void main()
 {
    
 }
 
 ----------
 
 But maybe that's just me?
Doesn't confuse me one bit.
That's nice. -- Derek Parnell Melbourne, Australia skype: derek.j.parnell
May 18 2009
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Bill Baxter wrote:
 On Mon, May 18, 2009 at 4:15 PM, Bill Baxter <wbaxter gmail.com> wrote:
 But it's not "blarf". It's "case". I am floored that nobody sees the
 elegance of that syntax.
So your argument is that "case" inherently deserves a special case?
Thinking about it more, I guess you must actually be seeing it as a rule of " '..' always does the most useful thing", and the most useful thing for switches is inclusive.
No! If I thought that, I would have said this is fine: case 'a' .. 'z': It is NOT fine because 'a' .. 'z' means one thing here and a different thing in another place. So I went for: case 'a': .. case 'z': specifically because case 'a': .. case 'z': does NOT have any meaning anywhere else. Andrei
May 18 2009
next sibling parent Bill Baxter <wbaxter gmail.com> writes:
On Mon, May 18, 2009 at 5:33 PM, Andrei Alexandrescu
<SeeWebsiteForEmail erdani.org> wrote:
 Bill Baxter wrote:
 On Mon, May 18, 2009 at 4:15 PM, Bill Baxter <wbaxter gmail.com> wrote:
 But it's not "blarf". It's "case". I am floored that nobody sees the
 elegance of that syntax.
So your argument is that "case" inherently deserves a special case?
Thinking about it more, I guess you must actually be seeing it as a rule of =A0 " '..' always does the most useful thing", and the most useful thing for switches is inclusive.
No! If I thought that, I would have said this is fine: case 'a' .. 'z': It is NOT fine because 'a' .. 'z' means one thing here and a different th=
ing
 in another place. So I went for:

 case 'a': .. case 'z':

 specifically because case 'a': .. case 'z': does NOT have any meaning
 anywhere else.
Well, I'm floored that you find that at all elegant. It's "elegant" in much the same way using static to mean 12 different things, depending upon context, is "elegant". Although here it's worse I'd say because the meaning is so much closer to the other meaning, so the expectation of matching behavior is greater. But maybe you dig on that kind of thing. I see it as a necessary evil. Not something to go strutting around proudly about. Dat's all I'm gonna say about it though. I've had my fill on this one. --bb
May 18 2009
prev sibling next sibling parent reply "Nick Sabalausky" <a a.a> writes:
"Andrei Alexandrescu" <SeeWebsiteForEmail erdani.org> wrote in message 
news:gusuoi$ftk$2 digitalmars.com...
 No! If I thought that, I would have said this is fine:

 case 'a' .. 'z':

 It is NOT fine because 'a' .. 'z' means one thing here and a different 
 thing in another place. So I went for:

 case 'a': .. case 'z':

 specifically because case 'a': .. case 'z': does NOT have any meaning 
 anywhere else.
After reading that over and over many times, I think I finally see what you were trying to get at with that. People are supposed to see that as: case 'a': case 'b': case 'c': /*snipped, but you get the idea*/ case 'x': case 'y': case 'z': And everything except the first and last is just "shrunk down". I think I understand how that can be seen as elegance. But others have brought up some very valid objections that I really have to agree with, and I'll add one more: A lot of people don't like the whole "fall-through" thing anyway and want to see D move farther from it rather than embracing it as this syntax seems to do.
May 18 2009
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Nick Sabalausky wrote:
 "Andrei Alexandrescu" <SeeWebsiteForEmail erdani.org> wrote in message 
 news:gusuoi$ftk$2 digitalmars.com...
 No! If I thought that, I would have said this is fine:

 case 'a' .. 'z':

 It is NOT fine because 'a' .. 'z' means one thing here and a different 
 thing in another place. So I went for:

 case 'a': .. case 'z':

 specifically because case 'a': .. case 'z': does NOT have any meaning 
 anywhere else.
After reading that over and over many times, I think I finally see what you were trying to get at with that. People are supposed to see that as: case 'a': case 'b': case 'c': /*snipped, but you get the idea*/ case 'x': case 'y': case 'z': And everything except the first and last is just "shrunk down". I think I understand how that can be seen as elegance.
Yes. I got a rush of endorphine out of that one.
 But others have brought up some very valid objections that I really have to 
 agree with, and I'll add one more: A lot of people don't like the whole 
 "fall-through" thing anyway and want to see D move farther from it rather 
 than embracing it as this syntax seems to do.
I dislike the fall through as much as you do. Andrei
May 18 2009
parent grauzone <none example.net> writes:
 I dislike the fall through as much as you do.
What about fixing it? My proposal was always to introduce a new, second syntax, which switches to sane semantics: switch (x) { case(value) { //no fall through } case value2: //C compatibility, fall through } At least the colon should make the two syntaxes [proper plural?] unambiguous.
May 18 2009
prev sibling parent Georg Wrede <georg.wrede iki.fi> writes:
Andrei Alexandrescu wrote:
 Bill Baxter wrote:
 On Mon, May 18, 2009 at 4:15 PM, Bill Baxter <wbaxter gmail.com> wrote:
 But it's not "blarf". It's "case". I am floored that nobody sees the
 elegance of that syntax.
So your argument is that "case" inherently deserves a special case?
Thinking about it more, I guess you must actually be seeing it as a rule of " '..' always does the most useful thing", and the most useful thing for switches is inclusive.
No! If I thought that, I would have said this is fine: case 'a' .. 'z': It is NOT fine because 'a' .. 'z' means one thing here and a different thing in another place. So I went for: case 'a': .. case 'z': specifically because case 'a': .. case 'z': does NOT have any meaning anywhere else.
The colon is not needed there for understanding, and definitely not needed for remembering that .. in a case is inclusive. It's the overall context (being in a switch statement) that puts the programmer in the inclusive mindset. case 'a' .. case 'z': is adequate. Besides, then we can have discontinuous ranges without changing the current behavior, since case 'a' .. case 'z': case 'A' .. case 'Z': do something is the same as case 'a' .. case 'z': case 'A' .. case 'Z': do something already now.
May 18 2009
prev sibling parent reply Jason House <jason.james.house gmail.com> writes:
Andrei Alexandrescu Wrote:

 Bill Baxter wrote:
 On Mon, May 18, 2009 at 3:29 PM, Jason House
 <jason.james.house gmail.com> wrote:
 
 It's all a matter of perspective. I see both as begin .. end. That may be the
same reason why I think addition when I see foo(bar()) + baz(37). The extra
cruft is more or less ignored when figuring out the basics of what is going on.
Agreed. If you tell someone a .. b means a non-inclusive range from a to b, then ask them to guess what blarf a .. blarf b means, I would be very surprised if many guessed "inclusive range from blarf a to blarf b".
But it's not "blarf". It's "case". I am floored that nobody sees the elegance of that syntax. Andrei
I don't know if it's a consolation or throwing salt in your eyes, but I still don't see the elegance of using the keyword for an enumerated set to represent manifest constants.
May 18 2009
parent "Nick Sabalausky" <a a.a> writes:
"Jason House" <jason.james.house gmail.com> wrote in message 
news:gusvsq$i81$1 digitalmars.com...
 I don't know if it's a consolation or throwing salt in your eyes, but I 
 still don't see the elegance of using the keyword for an enumerated set to 
 represent manifest constants.
As a testament to the sucky-ness of "enum manifst constants", even though I've been seeing discussions about it for years, there hasn't been a single time where it's actually occurred to me to use it. Anytime I write in D, I still just keep using "const" instead of "enum" to creat my ...*constants*... without even thinking about it.
May 18 2009
prev sibling parent reply Rainer Deyke <rainerd eldwood.com> writes:
Bill Baxter wrote:
 Agreed.  If you tell someone   a .. b  means a non-inclusive range
 from a to b, then ask them to guess what    blarf a .. blarf b  means,
 I would be very surprised if many guessed "inclusive range from blarf
 a  to blarf b".
Agreed. Although non-inclusive ranges are common enough that they deserve their own syntax, I think inclusive ranges are *also* important enough to deserve their own syntax. Writing '+1' is often error-prone or even just plain wrong (such as when it leads to integer overflow). I favor the syntax 'a ... b' for inclusive ranges. It's easy to read and similar to 'a .. b' without being too similar. It does require the programmer to pay attention, but that's unavoidable. From there, it naturally follows that 'case's in a 'switch' statement should follow the same convention. I don't believe it makes any sense to have inclusive ranges in 'switch' statements and non-inclusive ranges everywhere else. Inclusive ranges are fairly common outside 'switch' statements, and non-inclusive ranges are fairly common in 'switch' statements. -- Rainer Deyke - rainerd eldwood.com
May 18 2009
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Rainer Deyke wrote:
 Bill Baxter wrote:
 Agreed.  If you tell someone   a .. b  means a non-inclusive range
 from a to b, then ask them to guess what    blarf a .. blarf b  means,
 I would be very surprised if many guessed "inclusive range from blarf
 a  to blarf b".
Agreed. Although non-inclusive ranges are common enough that they deserve their own syntax, I think inclusive ranges are *also* important enough to deserve their own syntax. Writing '+1' is often error-prone or even just plain wrong (such as when it leads to integer overflow). I favor the syntax 'a ... b' for inclusive ranges. It's easy to read and similar to 'a .. b' without being too similar.
I swear I didn't see the difference til the third read. I thought you were kidding. Even Perl would turn its nose at a significant semantic difference brought by the third period. Andrei
May 18 2009
parent reply Rainer Deyke <rainerd eldwood.com> writes:
Andrei Alexandrescu wrote:
 Even Perl would turn its nose at a significant semantic difference
 brought by the third period.
Not true: Perl has a '..' operator and a '...' operator with distinct but similar meanings. And as much as I loathe Perl in general, I don't see anything wrong with that. I am open to a reasonable alternate syntax. -- Rainer Deyke - rainerd eldwood.com
May 18 2009
next sibling parent reply Georg Wrede <georg.wrede iki.fi> writes:
Rainer Deyke wrote:
 Andrei Alexandrescu wrote:
 Even Perl would turn its nose at a significant semantic difference
 brought by the third period.
Not true: Perl has a '..' operator and a '...' operator with distinct but similar meanings. And as much as I loathe Perl in general, I don't see anything wrong with that. I am open to a reasonable alternate syntax.
Having both .. and ... wouldn't be too bad. They're insistinguishable only as long as one is not expecting a distinction. But with a programming language, they look dissimilar enough. A side benefit would be to be able to specify inclusive and exclusive ranges both within switch statements and range contexts. '0' ... '9' 'a' ... 'z' a .. b a ... b 0 .. middle middle .. $ Of course, this idea will be drowned in a 2-month bicycle shed color discussion about which should be the inclusive range and which the exclusive one. And after that somebody suggests tokens for the remaining two inclusion permutations, and then we really can forget all this for good.
May 18 2009
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Georg Wrede wrote:
 Rainer Deyke wrote:
 Andrei Alexandrescu wrote:
 Even Perl would turn its nose at a significant semantic difference
 brought by the third period.
Not true: Perl has a '..' operator and a '...' operator with distinct but similar meanings. And as much as I loathe Perl in general, I don't see anything wrong with that. I am open to a reasonable alternate syntax.
Having both .. and ... wouldn't be too bad. They're insistinguishable only as long as one is not expecting a distinction. But with a programming language, they look dissimilar enough. A side benefit would be to be able to specify inclusive and exclusive ranges both within switch statements and range contexts. '0' ... '9' 'a' ... 'z' a .. b a ... b 0 .. middle middle .. $ Of course, this idea will be drowned in a 2-month bicycle shed color discussion about which should be the inclusive range and which the exclusive one. And after that somebody suggests tokens for the remaining two inclusion permutations, and then we really can forget all this for good.
I'm now sorry I even mentioned the blessed thing. This must have been the worst discussion on language design, ever. Andrei
May 18 2009
next sibling parent Derek Parnell <derek psych.ward> writes:
On Mon, 18 May 2009 23:09:21 -0500, Andrei Alexandrescu wrote:

 I'm now sorry I even mentioned the blessed thing. This must have been 
 the worst discussion on language design, ever.
LOL ... especially when these discussions have no influence on whatever the outcome will eventually be. -- Derek Parnell Melbourne, Australia skype: derek.j.parnell
May 18 2009
prev sibling parent Georg Wrede <georg.wrede iki.fi> writes:
Andrei Alexandrescu wrote:
 Georg Wrede wrote:
 Rainer Deyke wrote:
 Andrei Alexandrescu wrote:
 Even Perl would turn its nose at a significant semantic difference
 brought by the third period.
Not true: Perl has a '..' operator and a '...' operator with distinct but similar meanings. And as much as I loathe Perl in general, I don't see anything wrong with that. I am open to a reasonable alternate syntax.
Having both .. and ... wouldn't be too bad. They're insistinguishable only as long as one is not expecting a distinction. But with a programming language, they look dissimilar enough. A side benefit would be to be able to specify inclusive and exclusive ranges both within switch statements and range contexts. '0' ... '9' 'a' ... 'z' a .. b a ... b 0 .. middle middle .. $ Of course, this idea will be drowned in a 2-month bicycle shed color discussion about which should be the inclusive range and which the exclusive one. And after that somebody suggests tokens for the remaining two inclusion permutations, and then we really can forget all this for good.
I'm now sorry I even mentioned the blessed thing. This must have been the worst discussion on language design, ever.
I was only half serious. :-)
May 18 2009
prev sibling parent Bill Baxter <wbaxter gmail.com> writes:
On Mon, May 18, 2009 at 8:00 PM, Rainer Deyke <rainerd eldwood.com> wrote:
 Andrei Alexandrescu wrote:
 Even Perl would turn its nose at a significant semantic difference
 brought by the third period.
Not true: Perl has a '..' operator and a '...' operator with distinct but similar meanings. =A0And as much as I loathe Perl in general, I don't see anything wrong with that. =A0I am open to a reasonable alternate synt=
ax. Heh, right you are. http://www.perl.com/doc/manual/html/pod/perlop.html#Range_Operators If Ruby won't turn it's nose up at a two dot / three dot distinction, then it would be hard to believe Perl would. But leave it to Perl to give it a completely obscure meaning. --bb
May 18 2009
prev sibling parent reply Derek Parnell <derek psych.ward> writes:
On Mon, 18 May 2009 20:05:14 -0600, Rainer Deyke wrote:

 Bill Baxter wrote:
 Although non-inclusive ranges are common enough that they deserve their
 own syntax, I think inclusive ranges are *also* important enough to
 deserve their own syntax.  Writing '+1' is often error-prone or even
 just plain wrong (such as when it leads to integer overflow).
Agreed.
 I favor the syntax 'a ... b' for inclusive ranges.  It's easy to read
 and similar to 'a .. b' without being too similar.  It does require the
 programmer to pay attention, but that's unavoidable.  From there, it
 naturally follows that 'case's in a 'switch' statement should follow the
 same convention.
Sorry, but I don't share your sense of "easy to read" here. The eye can glaze over the third dot very easily and just not notice it. -- Derek Parnell Melbourne, Australia skype: derek.j.parnell
May 18 2009
next sibling parent Bill Baxter <wbaxter gmail.com> writes:
On Mon, May 18, 2009 at 8:48 PM, Derek Parnell <derek psych.ward> wrote:
 On Mon, 18 May 2009 20:05:14 -0600, Rainer Deyke wrote:

 Bill Baxter wrote:
 Although non-inclusive ranges are common enough that they deserve their
 own syntax, I think inclusive ranges are *also* important enough to
 deserve their own syntax. =A0Writing '+1' is often error-prone or even
 just plain wrong (such as when it leads to integer overflow).
Agreed.
 I favor the syntax 'a ... b' for inclusive ranges. =A0It's easy to read
 and similar to 'a .. b' without being too similar. =A0It does require th=
e
 programmer to pay attention, but that's unavoidable. =A0From there, it
 naturally follows that 'case's in a 'switch' statement should follow the
 same convention.
Sorry, but I don't share your sense of "easy to read" here. The eye can glaze over the third dot very easily and just not notice it.
That's often said, but if you're looking at it in a fixed-width font, then I don't agree that it's so easy to glaze over the third dot. --bb
May 18 2009
prev sibling parent Jeremie Pelletier <jeremiep gmail.com> writes:
Derek Parnell Wrote:

 On Mon, 18 May 2009 20:05:14 -0600, Rainer Deyke wrote:
 
 Bill Baxter wrote:
 Although non-inclusive ranges are common enough that they deserve their
 own syntax, I think inclusive ranges are *also* important enough to
 deserve their own syntax.  Writing '+1' is often error-prone or even
 just plain wrong (such as when it leads to integer overflow).
Agreed.
 I favor the syntax 'a ... b' for inclusive ranges.  It's easy to read
 and similar to 'a .. b' without being too similar.  It does require the
 programmer to pay attention, but that's unavoidable.  From there, it
 naturally follows that 'case's in a 'switch' statement should follow the
 same convention.
Sorry, but I don't share your sense of "easy to read" here. The eye can glaze over the third dot very easily and just not notice it. -- Derek Parnell Melbourne, Australia skype: derek.j.parnell
I disagree, the ... syntax was also my suggestion for the reason that it is a very obvious syntax that isn't limited to only the switch ranges. I don't think its that easy to miss a third dot, especially if there are spaces around the operator, and the editor uses a fixed-width font (like any good editor should). If you want to be paranoid about confusion, comment it, just like closing }'s are often seen with a comment of the opening statement, just like you would do: } // version(Windows) you can do: case 1 ... 10: // inclusive You could also configure your editor to color code them differently, I already do that with a lot of other things, it gives the brain one more cue to detect what is going on. And since the operator also leaves .. available for inclusive ranges you can do: case FIRST .. LAST + 1: or even better: enum CASE_LAST = LAST + 1: case FIRST .. CASE_LAST: This goes along with the best feature of D: let the programmers do things the way they want to.
May 18 2009
prev sibling next sibling parent Jason House <jason.james.house gmail.com> writes:
 
 On a similar note, Andrei, what is this spree of removing features? Ok some
 are obviously bad, imaginary types for example, but why remove other stuff
 such as commplex and with?
TDPL is coming out. This is quite literally the last chance to shed some old skin. Complex as a built-in does nothing of interest to anyone except a cute syntax for literals that nobody uses (how many remarkable complex literals could you imagine?) About "with"... see above before I die of a heart attack. The baroque "!<>=" operators became much more attractive since Walter said he's considering making them overloadable. On the other hand new features are coming, which I believe are "good skin". Narrowing integral conversions will go. Walter is working on a very cool scheme for inferring the range of expressions that makes casts unnecessary in many cases.
Can you give us more detail?
 Casts are a plague not only for safe code, 
 but also for generic code that wants to be scalable and change-robust. 
I'm still hoping that one day D will be able to implicitly cast to scope invariant... such as when calling pure functions with non-shared data. On an almost unrelated note, D currently makes it far too easy to share non-shared data. Kicking off threads with non-unique unshared data is unsafe but works without casting. That really should get fixed.
 The ease with which C and C++ allow losing state and the drowning 
 necessity of integral casts in Java or C# are both extremes that I'm 
 happy to see D avoid.
May 18 2009
prev sibling next sibling parent Johan Granberg <lijat.meREM OVEgmail.com> writes:
Andrei Alexandrescu wrote:
 I personally still think it's a bad feature because it introduces
 long-distance coupling between symbols defined in two different places,
 both distinct from the place where the statement is used! Consider:
 
 import wyda;  // defines symbol write
 import geeba; // defines struct S { ... }
 
 void main()
 {
     S s;
     with (s) {
        write(5);
     }
 }
 
 Machiavelly would jump in joy at such code. What did I achieve? I saved
 a few "s.". What did I lose? The ability so say anything, but absolutely
 anything on what the code does. 
I understand the problem you are pointing out even if I don't belive it's a significant issue. The problem with your assumption that it saves a few "s." is that where I usualy use it is in cases like this. with(listofdecentlysizedstructs[i].vector3d){ return x*x+y*y+z*z; } Maybe not an ideal example, usualy I have several lines of math algorithms or physics formula in the with scope. The gain here is both that I dont have to type long variable names (could be solved with an alias maybe) but more importantly it allows me to keep pysics and math formula close to the form they have in math or pysics. For example writing x y and z for the parts of some point I'm currently working on instead of p[i].x p[i].y and p[i].z can in a formula with lots of them make the code easier to read. For a single use of symbols I see no important use of the with statement.
May 19 2009
prev sibling parent reply Jason House <jason.james.house gmail.com> writes:
bearophile Wrote:

Andrei Alexandrescu:
 I don't plan to discuss minor features on this group anymore.
That's a real pity. I had a lot of respect for you and your perpetual inclusion of the D community (both announcing features and getting design feedback). Very early on in this thread, it became obvious to me that too much of it was getting under your skin. I've lost count of the insults posted in this thread. We're all trying to make D the best language we can, even if we come from vastly different perspectives.
May 20 2009
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Jason House wrote:
 bearophile Wrote:
 
 Andrei Alexandrescu:
 I don't plan to discuss minor features on this group anymore.
That's a real pity. I had a lot of respect for you and your perpetual inclusion of the D community (both announcing features and getting design feedback). Very early on in this thread, it became obvious to me that too much of it was getting under your skin. I've lost count of the insults posted in this thread. We're all trying to make D the best language we can, even if we come from vastly different perspectives.
I am sorry I have gotten on the wrong side of civility in this thread. Andrei
May 20 2009
prev sibling next sibling parent reply Derek Parnell <derek psych.ward> writes:
On Sun, 17 May 2009 19:33:35 -0500, Andrei Alexandrescu wrote:

 I think "with" is a very dangerous feature due to the way it hides 
 symbols. It essentially makes the feeblest attempt at modular reasoning 
 utterly impossible:
 
 int x, y;
 with (whatever)
 {
      y += x;
      ++x;
 }
I guess the reason for using with() is to avoid typing repetitive stuff. Would this work instead ... int x, y; with (p as "somevery.long.struct.or.class[17].name") { y += p.x; ++p.x; } -- Derek Parnell Melbourne, Australia skype: derek.j.parnell
May 17 2009
next sibling parent reply grauzone <none example.net> writes:
Derek Parnell wrote:
 On Sun, 17 May 2009 19:33:35 -0500, Andrei Alexandrescu wrote:
 
 I think "with" is a very dangerous feature due to the way it hides 
 symbols. It essentially makes the feeblest attempt at modular reasoning 
 utterly impossible:

 int x, y;
 with (whatever)
 {
      y += x;
      ++x;
 }
I agree.
 I guess the reason for using with() is to avoid typing repetitive stuff.
 Would this work instead ...
 
 
  int x, y;
  with (p as "somevery.long.struct.or.class[17].name")
  {
       y += p.x;
       ++p.x;
  }
 
You could as well use auto and a block without statement before it to set the scope. But that'd look kind of ugly. A block without statement looks like you forgot an if. Here's another simple fix for with(); int x, y; with (whatever) { .y += x; //.y references this is whatever.y ++x; //x references local scope }
May 17 2009
parent reply "Nick Sabalausky" <a a.a> writes:
"grauzone" <none example.net> wrote in message 
news:guqrj2$2l7h$2 digitalmars.com...
 Here's another simple fix for with();

 int x, y;
 with (whatever)
 {
       .y += x; //.y references this is whatever.y
       ++x;     //x references local scope
 }
That already means global scope.
May 18 2009
parent reply grauzone <none example.net> writes:
Nick Sabalausky wrote:
 "grauzone" <none example.net> wrote in message 
 news:guqrj2$2l7h$2 digitalmars.com...
 Here's another simple fix for with();

 int x, y;
 with (whatever)
 {
       .y += x; //.y references this is whatever.y
       ++x;     //x references local scope
 }
That already means global scope.
Yes, but who uses that anyway?
May 18 2009
parent Christopher Wright <dhasenan gmail.com> writes:
grauzone wrote:
 Nick Sabalausky wrote:
 "grauzone" <none example.net> wrote in message 
 news:guqrj2$2l7h$2 digitalmars.com...
 Here's another simple fix for with();

 int x, y;
 with (whatever)
 {
       .y += x; //.y references this is whatever.y
       ++x;     //x references local scope
 }
That already means global scope.
Yes, but who uses that anyway?
There's that perennial annoyance that class methods with a given name hide free functions of the same name, even if they are not covariant. This crops up a lot with toString, and the fix is to prepend a dot to the invocation.
May 18 2009
prev sibling parent reply Sean Kelly <sean invisibleduck.org> writes:
Derek Parnell wrote:
 
 I guess the reason for using with() is to avoid typing repetitive stuff.
 Would this work instead ...
 
 
  int x, y;
  with (p as "somevery.long.struct.or.class[17].name")
  {
       y += p.x;
       ++p.x;
  }
{ ref p = somevery.long.struct.or.class[17].name; y += p.x; ++p.x; }
May 18 2009
next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Sean Kelly:

 {
      ref p = somevery.long.struct.or.class[17].name;
      y += p.x;
      ++p.x;
 }
{ alias somevery.long.struct.or.class[17].name p; y += p.x; ++p.x; } Or: { alias somevery.long.struct.or.class[17].name as p; y += p.x; ++p.x; } Or nicer: alias somevery.long.struct.or.class[17].name as p { y += p.x; ++p.x; } Bye, bearophile
May 18 2009
parent Derek Parnell <derek psych.ward> writes:
On Mon, 18 May 2009 12:59:08 -0400, bearophile wrote:

 Or nicer:
 
 alias somevery.long.struct.or.class[17].name as p {
      y += p.x;
      ++p.x;
 }
Yeah, that's nice too. -- Derek Parnell Melbourne, Australia skype: derek.j.parnell
May 18 2009
prev sibling parent Derek Parnell <derek psych.ward> writes:
On Mon, 18 May 2009 09:55:42 -0700, Sean Kelly wrote:

 Derek Parnell wrote:
 
 I guess the reason for using with() is to avoid typing repetitive stuff.
 Would this work instead ...
 
  int x, y;
  with (p as "somevery.long.struct.or.class[17].name")
  {
       y += p.x;
       ++p.x;
  }
{ ref p = somevery.long.struct.or.class[17].name; y += p.x; ++p.x; }
Yes that would work too, and probably better code generation too. The difference being that my suggestion is a compile-time behaviour and yours is a run time behaviour. -- Derek Parnell Melbourne, Australia skype: derek.j.parnell
May 18 2009
prev sibling next sibling parent reply "Lars T. Kyllingstad" <public kyllingen.NOSPAMnet> writes:
Andrei Alexandrescu wrote:
 I think "with" is a very dangerous feature due to the way it hides 
 symbols. It essentially makes the feeblest attempt at modular reasoning 
 utterly impossible:
 
 int x, y;
 with (whatever)
 {
     y += x;
     ++x;
 }
 
 What can be said about such code? Nothing. If whatever has or will ever 
 have fields x or y or both, the names will bind to them; otherwise, 
 they'll bind to the locals. Non-local code dependency at its finest.
 
 Maintenance of any type that is being used with "with" becomes a very 
 dangerous proposition because it can silently change meaning of code.
 
 I therefore submit that "with" is an extremely dangerous feature and 
 should be removed from the language. What say you?
I agree, "with" makes code difficult to read. If one really wants to avoid typing, just use alias: alias my.very.long.string.of.symbols x; a = x.foo; x.foo = b; This works with lvalues as well. -Lars
May 18 2009
parent reply bearophile <bearophileHUGS lycos.com> writes:
Lars T. Kyllingstad:

 f one really wants to avoid typing, just use alias:
     alias my.very.long.string.of.symbols x;
     a = x.foo;
     x.foo = b;
See my suggestion (where there's a p instead of s: http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=90439 Bye, bearophile
May 18 2009
parent "Lars T. Kyllingstad" <public kyllingen.NOSPAMnet> writes:
bearophile wrote:
 Lars T. Kyllingstad:
 
 f one really wants to avoid typing, just use alias:
     alias my.very.long.string.of.symbols x;
     a = x.foo;
     x.foo = b;
See my suggestion (where there's a p instead of s: http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=90439 Bye, bearophile
Sorry, I didn't see that you had already made the suggestion. I don't think there is any need to extend the alias syntax, though. If you only want the alias to work in a limited scope, just enclose it in one: int x, y; { alias another.very.long.name s; y += s.x; s.x = x; } s.x = 1; // Doesn't work, s is not in scope. -Lars
May 18 2009
prev sibling next sibling parent "Simen Kjaeraas" <simen.kjaras gmail.com> writes:
Andrei Alexandrescu wrote:

 I therefore submit that "with" is an extremely dangerous feature and  
 should be removed from the language. What say you?
I say 'with' is useful, but (as you say) dangerous. I believe this could be fixed by requiring an alias inside the parentheses. This way, code would look like this: with (alias foo.bar baz) { baz.x = y; } -- Simen
May 18 2009
prev sibling parent reply Sean Kelly <sean invisibleduck.org> writes:
Andrei Alexandrescu wrote:
 I think "with" is a very dangerous feature due to the way it hides 
 symbols. It essentially makes the feeblest attempt at modular reasoning 
 utterly impossible:
 
 int x, y;
 with (whatever)
 {
     y += x;
     ++x;
 }
"with" is a useless feature and a waste of a keyword. I'd love to get rid of it.
May 18 2009
parent "Denis Koroskin" <2korden gmail.com> writes:
On Mon, 18 May 2009 20:45:26 +0400, Sean Kelly <sean invisibleduck.org> wrote:

 Andrei Alexandrescu wrote:
 I think "with" is a very dangerous feature due to the way it hides  
 symbols. It essentially makes the feeblest attempt at modular reasoning  
 utterly impossible:
  int x, y;
 with (whatever)
 {
     y += x;
     ++x;
 }
"with" is a useless feature and a waste of a keyword. I'd love to get rid of it.
Same here. I don't remember myself using it ever.
May 18 2009