Re: with still sucks + removing features + adding features
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
Re: with still sucks + removing features + adding features
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 ab 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. :)
Re: with still sucks + removing features + adding features
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;
Re: with still sucks + removing features + adding features
On Wed, 20 May 2009 00:43:56 +0400, Andrei Alexandrescu
seewebsiteforem...@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
Re: with still sucks + removing features + adding features
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.
Re: with still sucks + removing features + adding features
Denis Koroskin wrote: On Wed, 20 May 2009 00:43:56 +0400, Andrei Alexandrescu seewebsiteforem...@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(0int.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
Re: with still sucks + removing features + adding features
Andrei Alexandrescu wrote: Denis Koroskin wrote: On Wed, 20 May 2009 00:43:56 +0400, Andrei Alexandrescu seewebsiteforem...@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(0int.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.
Re: with still sucks + removing features + adding features
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
Re: with still sucks + removing features + adding features
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
Re: with still sucks + removing features + adding features
On Wed, May 20, 2009 at 7:28 AM, Andrei Alexandrescu seewebsiteforem...@erdani.org wrote: Denis Koroskin wrote: On Wed, 20 May 2009 00:43:56 +0400, Andrei Alexandrescu seewebsiteforem...@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(0int.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
Re: with still sucks + removing features + adding features
Andrei Alexandrescu wrote: Denis Koroskin wrote: On Wed, 20 May 2009 00:43:56 +0400, Andrei Alexandrescu seewebsiteforem...@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(0int.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
Re: with still sucks + removing features + adding features
Bill Baxter wrote: On Wed, May 20, 2009 at 7:28 AM, Andrei Alexandrescu seewebsiteforem...@erdani.org wrote: Denis Koroskin wrote: On Wed, 20 May 2009 00:43:56 +0400, Andrei Alexandrescu seewebsiteforem...@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(0int.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
Re: with still sucks + removing features + adding features
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
Re: with still sucks + removing features + adding features
KennyTM~ wrote: Andrei Alexandrescu wrote: Denis Koroskin wrote: On Wed, 20 May 2009 00:43:56 +0400, Andrei Alexandrescu seewebsiteforem...@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
Re: with still sucks + removing features + adding features
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 ;)
Re: with still sucks + removing features + adding features
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
Re: with still sucks + removing features + adding features
Andrei Alexandrescu seewebsiteforem...@erdani.org wrote in message news:gut7lb$ue...@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.
Re: with still sucks + removing features + adding features
Nick Sabalausky wrote: Andrei Alexandrescu seewebsiteforem...@erdani.org wrote in message news:gut7lb$ue...@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
Re: with still sucks + removing features + adding features
Andrei Alexandrescu seewebsiteforem...@erdani.org wrote in message news:gutd12$16h...@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.
Re: with still sucks + removing features + adding features
On Mon, 18 May 2009 21:30:41 -0700, Bill Baxter wrote: On Mon, May 18, 2009 at 9:17 PM, Derek Parnell de...@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
Re: with still sucks + removing features + adding features
On Tue, 19 May 2009 18:23:25 +1000, Derek Parnell de...@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 de...@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)
Re: with still sucks + removing features + adding features
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.
Re: with still sucks + removing features + adding features
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
Re: with still sucks + removing features + adding features
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
Re: with still sucks + removing features + adding features
Nick Sabalausky wrote: Andrei Alexandrescu seewebsiteforem...@erdani.org wrote in message news:gutd12$16h...@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: 12 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.
Re: with still sucks + removing features + adding features
Nick Sabalausky schrieb: Derek Parnell de...@psych.ward wrote in message news:2m4gnylh4ggc.1hhjynllwweim@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
Re: with still sucks + removing features + adding features
On Tue, May 19, 2009 at 8:37 AM, Georg Wrede georg.wr...@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.
Re: with still sucks + removing features + adding features
Jarrett Billingsley wrote: On Tue, May 19, 2009 at 8:37 AM, Georg Wrede georg.wr...@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.
Re: with still sucks + removing features + adding features
Georg Wrede wrote: Jarrett Billingsley wrote: On Tue, May 19, 2009 at 8:37 AM, Georg Wrede georg.wr...@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.
Re: with still sucks + removing features + adding features
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
Re: with still sucks + removing features + adding features
-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-
Re: with still sucks + removing features + adding features
On Tue, May 19, 2009 at 10:51 AM, div0 d...@users.sourceforge.net wrote: -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. I use it too. Looks fine to me. I also use the 3.f form on occasion to get an integral float. --bb
Re: with still sucks + removing features + adding features
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 '...'.
Re: with still sucks + removing features + adding features
Georg Wrede georg.wr...@iki.fi wrote in message news:guu95i$2p6...@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.
Re: with still sucks + removing features + adding features
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...
Re: with still sucks + removing features + adding features
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 ab I don't plan to discuss minor features on this group anymore. Andrei
Re: with still sucks + removing features + adding features
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 ab 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.
Re: with still sucks + removing features + adding features
On Tue, May 19, 2009 at 4:47 PM, Jarrett Billingsley jarrett.billings...@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 ab 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?
Re: with still sucks + removing features + adding features
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jarrett Billingsley wrote: On Tue, May 19, 2009 at 4:47 PM, Jarrett Billingsley jarrett.billings...@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 ab 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-
Re: with still sucks + removing features + adding features
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
Re: with still sucks + removing features + adding features
On Tue, May 19, 2009 at 5:38 PM, div0 d...@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.billings...@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 ab 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- 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.
Re: with still sucks + removing features + adding features
On Tue, 19 May 2009 16:48:41 -0400, Jarrett Billingsley jarrett.billings...@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
Re: with still sucks + removing features + adding features
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.
Re: with still sucks + removing features + adding features
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
Re: with still sucks + removing features + adding features
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 ab 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.
Re: with still sucks + removing features + adding features
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.
Re: with still sucks + removing features + adding features
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
Re: with still sucks + removing features + adding features
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 ab 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. ;-)
Re: with still sucks + removing features + adding features
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.
Re: with still sucks + removing features + adding features
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...
Re: with still sucks + removing features + adding features
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
Re: with still sucks + removing features + adding features
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.
Re: with still sucks + removing features + adding features
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! :-)
Re: with still sucks + removing features + adding features
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... Aaah... I thought they were talking about .1, .2, etc. I forgot about .foo
with still sucks + removing features + adding features
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
Re: with still sucks + removing features + adding features
On Mon, May 18, 2009 at 1:46 PM, Andrei Alexandrescu seewebsiteforem...@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.
Re: with still sucks + removing features + adding features
Jarrett Billingsley wrote: On Mon, May 18, 2009 at 1:46 PM, Andrei Alexandrescu seewebsiteforem...@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
Re: with still sucks + removing features + adding features
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
Re: with still sucks + removing features + adding features
On Mon, May 18, 2009 at 10:46 AM, Andrei Alexandrescu
seewebsiteforem...@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?
--bb
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
Re: with still sucks + removing features + adding features
Bill Baxter wrote:
On Mon, May 18, 2009 at 10:46 AM, Andrei Alexandrescu
seewebsiteforem...@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
Re: with still sucks + removing features + adding features
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
Re: with still sucks + removing features + adding features
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
Re: with still sucks + removing features + adding features
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.
Re: with still sucks + removing features + adding features
bearophile wrote: I am not good at all. *shares some prozac*
Re: with still sucks + removing features + adding features
On Mon, May 18, 2009 at 3:29 PM, Robert Fraser fraseroftheni...@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.
Re: with still sucks + removing features + adding features
bearophile bearophileh...@lycos.com wrote in message news:guscb3$2iq...@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.
Re: with still sucks + removing features + adding features
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
Re: with still sucks + removing features + adding features
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.
Re: with still sucks + removing features + adding features
Andrei Alexandrescu Wrote: Jarrett Billingsley wrote: On Mon, May 18, 2009 at 1:46 PM, Andrei Alexandrescu seewebsiteforem...@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!
Re: with still sucks + removing features + adding features
Jason House wrote: Andrei Alexandrescu Wrote: Jarrett Billingsley wrote: On Mon, May 18, 2009 at 1:46 PM, Andrei Alexandrescu seewebsiteforem...@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
Re: with still sucks + removing features + adding features
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.
Re: with still sucks + removing features + adding features
On Mon, May 18, 2009 at 3:29 PM, Jason House jason.james.ho...@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 whatblarf 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
Re: with still sucks + removing features + adding features
Bill Baxter: Agreed. If you tell someone a .. b means a non-inclusive range from a to b, then ask them to guess whatblarf 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
Re: with still sucks + removing features + adding features
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 whatblarf 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
Re: with still sucks + removing features + adding features
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;
Re: with still sucks + removing features + adding features
On Mon, May 18, 2009 at 4:02 PM, Andrei Alexandrescu seewebsiteforem...@erdani.org wrote: Bill Baxter wrote: On Mon, May 18, 2009 at 3:29 PM, Jason House jason.james.ho...@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? 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
Re: with still sucks + removing features + adding features
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
Re: with still sucks + removing features + adding features
-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-
Re: with still sucks + removing features + adding features
On Mon, May 18, 2009 at 4:15 PM, Bill Baxter wbax...@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
Re: with still sucks + removing features + adding features
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
Re: with still sucks + removing features + adding features
Bill Baxter wrote: On Mon, May 18, 2009 at 4:15 PM, Bill Baxter wbax...@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
Re: with still sucks + removing features + adding features
Bill Baxter wrote: On Mon, May 18, 2009 at 4:02 PM, Andrei Alexandrescu seewebsiteforem...@erdani.org wrote: Bill Baxter wrote: On Mon, May 18, 2009 at 3:29 PM, Jason House jason.james.ho...@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 whatblarf 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
Re: with still sucks + removing features + adding features
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
Re: with still sucks + removing features + adding features
Andrei Alexandrescu Wrote: Bill Baxter wrote: On Mon, May 18, 2009 at 3:29 PM, Jason House jason.james.ho...@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 whatblarf 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.
Re: with still sucks + removing features + adding features
On Mon, May 18, 2009 at 5:33 PM, Andrei Alexandrescu seewebsiteforem...@erdani.org wrote: Bill Baxter wrote: On Mon, May 18, 2009 at 4:15 PM, Bill Baxter wbax...@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. 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
Re: with still sucks + removing features + adding features
Andrei Alexandrescu wrote:
Bill Baxter wrote:
On Mon, May 18, 2009 at 10:46 AM, Andrei Alexandrescu
seewebsiteforem...@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! Ye. 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.
Re: with still sucks + removing features + adding features
Jason House jason.james.ho...@gmail.com wrote in message news:gusvsq$i8...@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.
Re: with still sucks + removing features + adding features
Andrei Alexandrescu seewebsiteforem...@erdani.org wrote in message news:gusuoi$ft...@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.
Re: with still sucks + removing features + adding features
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
Re: with still sucks + removing features + adding features
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 whatblarf 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
Re: with still sucks + removing features + adding features
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
Re: with still sucks + removing features + adding features
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
Re: with still sucks + removing features + adding features
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
Re: with still sucks + removing features + adding features
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.
Re: with still sucks + removing features + adding features
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
Re: with still sucks + removing features + adding features
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
Re: with still sucks + removing features + adding features
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 - rain...@eldwood.com
Re: with still sucks + removing features + adding features
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
Re: with still sucks + removing features + adding features
On Mon, May 18, 2009 at 1:57 PM, Andrei Alexandrescu seewebsiteforem...@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. 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. 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.
Re: with still sucks + removing features + adding features
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
