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: OT: on IDEs and code writing on steroids
Rainer Deyke wrote: Yigal Chripun wrote: oh, I forgot my last point: for C link-time compatibility you need to be able to _read_ C object files and link them to your executable. you gain little from the ability to _write_ object files. You can transitivity. Two compilers for different languages that both produce C object files can link to each other; two compiler that can only read C object files cannot. good point. if you want to do a reverse integration (use D code in your C project) you can and IMO should have created a library anyway instead of using object files and the compiler should allow this as a separate option via a flag, e.g. --make-so or whatever If you can read and write compatible library files, you don't need to read or write compatible object files, since library files can take the place of object files. that's even better. just allow 2-way usage of C libs and that's it. no need to support the C object file formats directly.
Re: OT: on IDEs and code writing on steroids
BCS wrote: one other thing, this thread discusses also the VS project files. This is completely irrelevant. those XML files are VS specific and their complexity is MS' problem. Nothing prevents a developer from using different build tools like make, rake or scons with their C# sources since VS comes with a command line compiler. the issue is not the build tool but rather the compilation model itself. I think you are in error here as the c# files don't contain enough information for the compiler to know where to resolve symbols. You might be able to get away with throwing every single .cs/.dll/whatever file in the project at the compiler all at once. (Now if you want to talk about archaic!) Aside from that, how can it find meta-data for your types? you're mistaken since there are build tools that support C#. I think I saw this in Scons last time I looked.
Re: OT: on IDEs and code writing on steroids
Yigal Chripun wrote: > oh, I forgot my last point: > for C link-time compatibility you need to be able to _read_ C object > files and link them to your executable. you gain little from the ability > to _write_ object files. You can transitivity. Two compilers for different languages that both produce C object files can link to each other; two compiler that can only read C object files cannot. > if you want to do a reverse integration (use D code in your C project) > you can and IMO should have created a library anyway instead of using > object files and the compiler should allow this as a separate option via > a flag, e.g. --make-so or whatever If you can read and write compatible library files, you don't need to read or write compatible object files, since library files can take the place of object files. -- Rainer Deyke - rain...@eldwood.com
Re: OT: on IDEs and code writing on steroids
Yigal Chripun wrote: grauzone wrote: Just because it doesn't work on your shitty (SCNR) platform, it doesn't mean it's wrong. On Unix, there's a single ABI for C, and linking Just Works (TM). do YOU want D to succeed? that shitty platform is 90% of the market. But I kind of agree. The most useful thing about compiling each module to an object file is to enable separate compilation. But this is useless: it doesn't work because of bugs, it doesn't "scale" (because a single module is likely to have way too many transitive dependencies). I'm not suggesting coping Java's model letter for letter or using a VM either, but rather using a better representation. Ew, that's even worse. Java's model is right out retarded. I'd just compile a D project to a single (classic) object file. That would preserve C compatibility. Because the compiler knows _all_ D modules at compilation, we could enable some spiffy stuff, like virtual template functions or inter-procedural optimization. Instead of compiling per module, it should be more course grained like on the package/project level. in C# you can compile a single file and get a "module" file (IIRC), but that's a rare thing. usually you work with assemblies. oh, I forgot my last point: for C link-time compatibility you need to be able to _read_ C object files and link them to your executable. you gain little from the ability to _write_ object files. if you want to do a reverse integration (use D code in your C project) you can and IMO should have created a library anyway instead of using object files and the compiler should allow this as a separate option via a flag, e.g. --make-so or whatever
Re: OT: on IDEs and code writing on steroids
grauzone wrote: Just because it doesn't work on your shitty (SCNR) platform, it doesn't mean it's wrong. On Unix, there's a single ABI for C, and linking Just Works (TM). do YOU want D to succeed? that shitty platform is 90% of the market. But I kind of agree. The most useful thing about compiling each module to an object file is to enable separate compilation. But this is useless: it doesn't work because of bugs, it doesn't "scale" (because a single module is likely to have way too many transitive dependencies). I'm not suggesting coping Java's model letter for letter or using a VM either, but rather using a better representation. Ew, that's even worse. Java's model is right out retarded. I'd just compile a D project to a single (classic) object file. That would preserve C compatibility. Because the compiler knows _all_ D modules at compilation, we could enable some spiffy stuff, like virtual template functions or inter-procedural optimization. Instead of compiling per module, it should be more course grained like on the package/project level. in C# you can compile a single file and get a "module" file (IIRC), but that's a rare thing. usually you work with assemblies.
Re: OT: on IDEs and code writing on steroids
grauzone wrote: Oh, and how it indents multiline function calls is completely retarded. And every time I try to autocomplete a templated function call, it insists on inserting ALL of the template arguments, even when they're supposed to be derived. This is why I don't like IDEs. Plus, every time you type something, stuff BLINKS around, grabbing your attention, saying I'M SO ANNOYING PLEASE DISABLE ME AS A FEATURE. Like documentation tooltips, auto completion hints, or "intelligent" indentation. It's ridiculous. When I hit a key, I want the text editor insert that key. Not do random stuff. How do Eclipse user deal with it? Not look at the screen when typing? that sounds like an old man complaining that modern television has sound and colors. you can disable all features or just use a primitive text editor since that's what your used too, but those thing are *not* problems. It is extremely useful to have the documentation tooltips instead of spending time on searching manually in some book or whatever. the smart indentation is a godsend, if I paste a snippet it is adjusted to my code so I can see how many braces I need to have at the end. I certainly do *NOT* want to go back to writing shell scripts or emacs LISP functions just to copy some snippet from one file to another!
Re: OT: on IDEs and code writing on steroids
在 Tue, 19 May 2009 00:14:50 +0800，BCS 写道: Reply to Andrei, I've repeatedly failed to figure out the coolness of C#, and would appreciate a few pointers. Or references. Or delegates :o). The coolness of c# is that (in order, IMHO) 1) the tools are world class, 2) the support is back by MS, 3) the docs are great, and 4) the language is highly consistent and conservative, e.i. nothing is added until they've got it right. Aside from #4, the *language* isn't anything to write home about. Andrei The fact is MS has paven the way for getting people who uses C# open their source by default(lot of code can be disassembled). Reusing them itself is a very strong selling point. The market has a will to both reusing C# code while keeping the commercial secret. They don't want the others disassemble the app and tweak a little bit and rebuild the app(this is always possible if you don't strip the IL by only obfuscating it. For native cases, you would have a much higher barrier to rebuild others' app). The first 3 points can be shared with MS if we keep at a reasonable consistency with MS stuff. If we have the C# frontend and major .Net framework API, the tools can be built immediately by compiling SharpDevelop, which is also considered to be high quality to use. -- 使用 Opera 革命性的电子邮件客户程序: http://www.opera.com/mail/
Re: "with" still sucks + removing features + adding features
Derek Parnell wrote: I'm a bit confused. Are you saying that one must expect that the meaning of punctuation in a programming language depends on the context the punctuation is found in? If so, then ".." in "[a .. b]" can mean exclusive range and ".." in "case a .. b:" can mean inclusive range, no? No, you don't understand. But I sworn that I'll explain it for the last time in another post, so I'm out of times I can explain it. Let me make a separate point. With "...", people just defined the space operator. What's the space operator? Changes the meaning of 0...10 in two distinct ways: 0...10 is an all-inclusive integer range from 0 to 10 0. ..10 is a right-open floating-point range from 0 to 10 0.. .10 is a right-open floating-point range from 0 to 0.1 Not to mention: 0.10 is an all-inclusive floating-point range from 0 to .1 (if I counted my dots right). I have no doubt somebody will find this all intuitive and pleasing on the eye, and will suggest a couple of additional constructs and keywords to improve things. Andrei
Re: Switch
Andrei Alexandrescu wrote:
> Rainer Deyke wrote:
>> You're making two assumptions here:
>> 1. That inclusive ranges are preferable inside 'case' statements.
>
> Yes. The point of case a: .. case b: is to save you from writing case a:
> case a+1: and so on up to case b:. There is no exclusion. You write now
> the cases you want to handle.
>
>> 2. That non-inclusive ranges are preferable outside 'case' statements.
>
> Of course. One word: STL.
I can think of two concrete advantages of half-open/non-inclusive ranges:
1. When using zero-based indexing, '0 .. length' expresses all
elements in a sequence.
2. A range can be 'split' on any point 'x' into subranges '0 .. x' and
'x .. length'.
Both of these advantages also apply to 'case' statements:
const int
first_nullary_instruction = 5,
first_unary_instruction = 5,
first_binary_instruction = 10,
num_instructions = 15;
switch (c) {
case first_nullary_instruction .. first_unary_instruction:
executeNullaryInstruction();
break;
case first_unary_instruction .. first_binary_instruction:
executeUnaryInstruction();
break;
case first_binary_instruction .. num_instructions:
executeUnaryInstruction();
break;
default:
illegalInstruction();
break;
}
I can think of two concrete advantages of inclusive ranges:
1. The past-the-end element may not be known.
2. The past-the-end element may not be representable.
Both of these advantages also outside 'case' statements:
foreach (i; 0 ... int.max) doSomethingWith(i);
--
Rainer Deyke - rain...@eldwood.com
Re: "with" still sucks + removing features + adding features
On Mon, May 18, 2009 at 9:17 PM, Derek Parnell wrote: > On Mon, 18 May 2009 23:02:37 -0500, Andrei Alexandrescu wrote: > >> Derek Parnell wrote: >>> On Mon, 18 May 2009 21:47:01 -0500, Andrei Alexandrescu wrote: >>> Derek Parnell wrote: > On Mon, 18 May 2009 19:31:23 -0500, Andrei Alexandrescu wrote: > >> I completely disagree that that's a special case. ".." is punctuation. >> You can't pretend punctuation has the same meaning everywhere in a >> programming language. > I'm a bit confused. Are you saying that one must expect that the meaning > of > punctuation in a programming language depends on the context the > punctuation is found in? How many meanings does '[' have in your favorite programming language? >>> >>> One. >> >> No. > > But you never asked for the name of my favourite language? Does it have string or character literals? Then there's probably at least two meanings. ;-P --bb
Re: While we're lynching features, how bout' them omittable parens?
Jesse Phillips escribió: On Mon, 18 May 2009 21:53:06 -0400, Nick Sabalausky wrote: "Chad J" wrote in message news:gut1od$l5...@digitalmars.com... Lionello Lunesu wrote: "Chad J" wrote in message news:gut0f2$jc...@digitalmars.com... Nevermind properties. Any chance we can forbid the omittable parentheses, at least in the lhs of an assignment expression? This is not because of the omittable parens. Even with added parens that code should not compile! Agreed! I still want to get rid of omittable parens (and function-call-as-a-lhs) anyway. They're a horrible substitute for a real property syntax. I don't like C# properties, IMO it is pointless overhead. I agree you can misuse the omittable parentheses, but what is a "real" property syntax? Seems to me both D and C# provide the same syntax they are just set up differently. What I like in C# about properties is that they are like "pure" functions, so they don't have side-effects (this is just a contract on the semantic of properties). What that means is that you can invoke them while debugging code and be sure they don't alter the flow of execution. So when watching a variable you automatically can see it's properties, not just it's variables. I find that very useful, since properties basically tell you what's the representation of an object, what's it's meaning (hiding how it is implemented, ultimately). Currently you can't do that in a D debugger because a method like "int foo();" could have side effects. So for me, properties are way more than just syntax sugar.
Re: "with" still sucks + removing features + adding features
On Mon, 18 May 2009 23:20:11 -0500, Andrei Alexandrescu wrote: > Derek Parnell wrote: >> But you never asked for the name of my favourite language? > Yah, I realized my flawed supposition after sending :o). So, what is it? Actually I have two - Forth and Euphoria, but D comes a close second. Anyways ... back to the actually question that I asked and you haven't got around to answering yet -- (you're not doing politian training are you :-)) On Mon, 18 May 2009 19:31:23 -0500, Andrei Alexandrescu wrote: > I completely disagree that that's a special case. ".." is punctuation. > You can't pretend punctuation has the same meaning everywhere in a > programming language. I'm a bit confused. Are you saying that one must expect that the meaning of punctuation in a programming language depends on the context the punctuation is found in? If so, then ".." in "[a .. b]" can mean exclusive range and ".." in "case a .. b:" can mean inclusive range, no? -- Derek Parnell Melbourne, Australia skype: derek.j.parnell
Re: "with" still sucks + removing features + adding features
Andrei Alexandrescu wrote: Georg Wrede wrote: Rainer Deyke wrote: Andrei Alexandrescu wrote: Even Perl would turn its nose at a significant semantic difference brought by the third period. Not true: Perl has a '..' operator and a '...' operator with distinct but similar meanings. And as much as I loathe Perl in general, I don't see anything wrong with that. I am open to a reasonable alternate syntax. Having both .. and ... wouldn't be too bad. They're insistinguishable only as long as one is not expecting a distinction. But with a programming language, they look dissimilar enough. A side benefit would be to be able to specify inclusive and exclusive ranges both within switch statements and range contexts. '0' ... '9' 'a' ... 'z' a .. b a ... b 0 .. middle middle .. $ Of course, this idea will be drowned in a 2-month bicycle shed color discussion about which should be the inclusive range and which the exclusive one. And after that somebody suggests tokens for the remaining two inclusion permutations, and then we really can forget all this for good. I'm now sorry I even mentioned the blessed thing. This must have been the worst discussion on language design, ever. I was only half serious. :-)
Re: "with" still sucks + removing features + adding features
I dislike the fall through as much as you do.
What about fixing it?
My proposal was always to introduce a new, second syntax, which switches
to sane semantics:
switch (x) {
case(value) {
//no fall through
}
case value2:
//C compatibility, fall through
}
At least the colon should make the two syntaxes [proper plural?]
unambiguous.
Re: "with" still sucks + removing features + adding features
On Mon, 18 May 2009 23:09:21 -0500, Andrei Alexandrescu wrote: > I'm now sorry I even mentioned the blessed thing. This must have been > the worst discussion on language design, ever. LOL ... especially when these discussions have no influence on whatever the outcome will eventually be. -- Derek Parnell Melbourne, Australia skype: derek.j.parnell
Re: "with" still sucks + removing features + adding features
Derek Parnell wrote: On Mon, 18 May 2009 23:02:37 -0500, Andrei Alexandrescu wrote: Derek Parnell wrote: On Mon, 18 May 2009 21:47:01 -0500, Andrei Alexandrescu wrote: Derek Parnell wrote: On Mon, 18 May 2009 19:31:23 -0500, Andrei Alexandrescu wrote: I completely disagree that that's a special case. ".." is punctuation. You can't pretend punctuation has the same meaning everywhere in a programming language. I'm a bit confused. Are you saying that one must expect that the meaning of punctuation in a programming language depends on the context the punctuation is found in? How many meanings does '[' have in your favorite programming language? One. No. But you never asked for the name of my favourite language? Yah, I realized my flawed supposition after sending :o). So, what is it? Andrei
Re: "with" still sucks + removing features + adding features
On Mon, 18 May 2009 23:02:37 -0500, Andrei Alexandrescu wrote: > Derek Parnell wrote: >> On Mon, 18 May 2009 21:47:01 -0500, Andrei Alexandrescu wrote: >> >>> Derek Parnell wrote: On Mon, 18 May 2009 19:31:23 -0500, Andrei Alexandrescu wrote: > I completely disagree that that's a special case. ".." is punctuation. > You can't pretend punctuation has the same meaning everywhere in a > programming language. I'm a bit confused. Are you saying that one must expect that the meaning of punctuation in a programming language depends on the context the punctuation is found in? >>> How many meanings does '[' have in your favorite programming language? >> >> One. > > No. But you never asked for the name of my favourite language? -- Derek Parnell Melbourne, Australia skype: derek.j.parnell
Re: "with" still sucks + removing features + adding features
On Mon, 18 May 2009 23:05:03 -0500, Andrei Alexandrescu wrote:
> Derek Parnell wrote:
>> But back to your question ... here is 'static' used with three different
>> meanings within three lines of code.
>>
>> ---
>> module xyzzy;
>> import std.stdio;
>>
>> version(X) const int y = 1;
>> else const int y = -1;
>>
>> static this() {
>>static if (y == 1)
>> static int x = 0;
>>else
>> static int x = 42;
>>
>>writefln("X=%d Y=%d", x,y);
>> }
>>
>> void main()
>> {
>>
>> }
>>
>> --
>>
>> But maybe that's just me?
>
> Doesn't confuse me one bit.
That's nice.
--
Derek Parnell
Melbourne, Australia
skype: derek.j.parnell
Re: "with" still sucks + removing features + adding features
On Mon, 18 May 2009 19:24:13 -0400, bearophile wrote: > Christopher Wright: >> The more common suggestion is: >> alias bar = foo; > > This is acceptable, thank you :-) > Now I'd like to know what others think about that. But does that mean 'when I write "bar" I really mean "foo"' or visa versa? Just pointing out that the '=' sign doesn't really automatically make it fully intuitive. -- Derek Parnell Melbourne, Australia skype: derek.j.parnell
Re: While we're lynching features, how bout' them omittable parens?
On Mon, 18 May 2009 21:53:06 -0400, Nick Sabalausky wrote: > "Chad J" wrote in message > news:gut1od$l5...@digitalmars.com... >> Lionello Lunesu wrote: >>> >>> "Chad J" wrote in message >>> news:gut0f2$jc...@digitalmars.com... Nevermind properties. Any chance we can forbid the omittable parentheses, at least in the lhs of an assignment expression? >>> This is not because of the omittable parens. Even with added parens >>> that code should not compile! >>> >>> >> Agreed! > > I still want to get rid of omittable parens (and function-call-as-a-lhs) > anyway. They're a horrible substitute for a real property syntax. I don't like C# properties, IMO it is pointless overhead. I agree you can misuse the omittable parentheses, but what is a "real" property syntax? Seems to me both D and C# provide the same syntax they are just set up differently.
Re: "with" still sucks + removing features + adding features
On Mon, May 18, 2009 at 8:00 PM, Rainer Deyke wrote: > Andrei Alexandrescu wrote: >> Even Perl would turn its nose at a significant semantic difference >> brought by the third period. > > Not true: Perl has a '..' operator and a '...' operator with distinct > but similar meanings. And as much as I loathe Perl in general, I don't > see anything wrong with that. I am open to a reasonable alternate syntax. Heh, right you are. http://www.perl.com/doc/manual/html/pod/perlop.html#Range_Operators If Ruby won't turn it's nose up at a two dot / three dot distinction, then it would be hard to believe Perl would. But leave it to Perl to give it a completely obscure meaning. --bb
Re: "with" still sucks + removing features + adding features
Georg Wrede wrote: Rainer Deyke wrote: Andrei Alexandrescu wrote: Even Perl would turn its nose at a significant semantic difference brought by the third period. Not true: Perl has a '..' operator and a '...' operator with distinct but similar meanings. And as much as I loathe Perl in general, I don't see anything wrong with that. I am open to a reasonable alternate syntax. Having both .. and ... wouldn't be too bad. They're insistinguishable only as long as one is not expecting a distinction. But with a programming language, they look dissimilar enough. A side benefit would be to be able to specify inclusive and exclusive ranges both within switch statements and range contexts. '0' ... '9' 'a' ... 'z' a .. b a ... b 0 .. middle middle .. $ Of course, this idea will be drowned in a 2-month bicycle shed color discussion about which should be the inclusive range and which the exclusive one. And after that somebody suggests tokens for the remaining two inclusion permutations, and then we really can forget all this for good. I'm now sorry I even mentioned the blessed thing. This must have been the worst discussion on language design, ever. Andrei
Re: "with" still sucks + removing features + adding features
Derek Parnell Wrote: > On Mon, 18 May 2009 23:15:17 -0400, Jeremie Pelletier wrote: > > > Derek Parnell Wrote: > >> case [FIRST ; LAST] : > > > > Personally I feel that your syntax breaks the condition > > (6) Must not be keystroke-heavy > > Huh?? By keystroke-heavy I meant the number of keyboard presses the finger > would have to do to write it. > > > Ignoring FIRST/LAST, I have 3 (three) keystrokes and Andrei has 8 > keystrokes? > > Me = [ ; ] > > Andrei = SHIFT : .. case > > > I like Andei's syntax best but as previously stated, its ambiguous with > > exclusive ranges. > > > > Maybe the solution is a second range operator that is inclusive, such as: > > case FIRST ... LAST: > > Which is 3 keystrokes too. > > Sorry, I don't understand what you mean by saying my suggestion breaks (6). > > -- > Derek Parnell > Melbourne, Australia > skype: derek.j.parnell Ah yes if you go by the count of characters, then yes you are right. I assumed it meant the ease of typing it, as ... is way faster to get on the screen than [;]. Also your characters are only easily accessible on a keyboard using the US layout (I began programming on a french canadian layout, and you need to use the right alt key for both [ and ], real annoying).
Re: "with" still sucks + removing features + adding features
Rainer Deyke wrote: Andrei Alexandrescu wrote: Even Perl would turn its nose at a significant semantic difference brought by the third period. Not true: Perl has a '..' operator and a '...' operator with distinct but similar meanings. And as much as I loathe Perl in general, I don't see anything wrong with that. I am open to a reasonable alternate syntax. Having both .. and ... wouldn't be too bad. They're insistinguishable only as long as one is not expecting a distinction. But with a programming language, they look dissimilar enough. A side benefit would be to be able to specify inclusive and exclusive ranges both within switch statements and range contexts. '0' ... '9' 'a' ... 'z' a .. b a ... b 0 .. middle middle .. $ Of course, this idea will be drowned in a 2-month bicycle shed color discussion about which should be the inclusive range and which the exclusive one. And after that somebody suggests tokens for the remaining two inclusion permutations, and then we really can forget all this for good.
Re: "with" still sucks + removing features + adding features
Derek Parnell wrote:
But back to your question ... here is 'static' used with three different
meanings within three lines of code.
---
module xyzzy;
import std.stdio;
version(X) const int y = 1;
else const int y = -1;
static this() {
static if (y == 1)
static int x = 0;
else
static int x = 42;
writefln("X=%d Y=%d", x,y);
}
void main()
{
}
--
But maybe that's just me?
Doesn't confuse me one bit.
Andrei
Re: Switch
Rainer Deyke wrote: Georg Wrede wrote: This is usable, easy to read -- and the programmer has no problem to remember that .. works differently in case statements than in ranges. You're making two assumptions here: 1. That inclusive ranges are preferable inside 'case' statements. Yes. The point of case a: .. case b: is to save you from writing case a: case a+1: and so on up to case b:. There is no exclusion. You write now the cases you want to handle. 2. That non-inclusive ranges are preferable outside 'case' statements. Of course. One word: STL. I don't buy it. The issue of inclusive versus non-inclusive ranges is *exactly the same* in and outside 'case' statements. No. Andrei
Re: "with" still sucks + removing features + adding features
Derek Parnell Wrote: > On Mon, 18 May 2009 20:05:14 -0600, Rainer Deyke wrote: > > > Bill Baxter wrote: > > Although non-inclusive ranges are common enough that they deserve their > > own syntax, I think inclusive ranges are *also* important enough to > > deserve their own syntax. Writing '+1' is often error-prone or even > > just plain wrong (such as when it leads to integer overflow). > > Agreed. > > > I favor the syntax 'a ... b' for inclusive ranges. It's easy to read > > and similar to 'a .. b' without being too similar. It does require the > > programmer to pay attention, but that's unavoidable. From there, it > > naturally follows that 'case's in a 'switch' statement should follow the > > same convention. > > Sorry, but I don't share your sense of "easy to read" here. The eye can > glaze over the third dot very easily and just not notice it. > > -- > Derek Parnell > Melbourne, Australia > skype: derek.j.parnell I disagree, the ... syntax was also my suggestion for the reason that it is a very obvious syntax that isn't limited to only the switch ranges. I don't think its that easy to miss a third dot, especially if there are spaces around the operator, and the editor uses a fixed-width font (like any good editor should). If you want to be paranoid about confusion, comment it, just like closing }'s are often seen with a comment of the opening statement, just like you would do: } // version(Windows) you can do: case 1 ... 10: // inclusive You could also configure your editor to color code them differently, I already do that with a lot of other things, it gives the brain one more cue to detect what is going on. And since the operator also leaves .. available for inclusive ranges you can do: case FIRST .. LAST + 1: or even better: enum CASE_LAST = LAST + 1: case FIRST .. CASE_LAST: This goes along with the best feature of D: let the programmers do things the way they want to.
Re: "with" still sucks + removing features + adding features
Derek Parnell wrote: On Mon, 18 May 2009 21:47:01 -0500, Andrei Alexandrescu wrote: Derek Parnell wrote: On Mon, 18 May 2009 19:31:23 -0500, Andrei Alexandrescu wrote: I completely disagree that that's a special case. ".." is punctuation. You can't pretend punctuation has the same meaning everywhere in a programming language. I'm a bit confused. Are you saying that one must expect that the meaning of punctuation in a programming language depends on the context the punctuation is found in? How many meanings does '[' have in your favorite programming language? One. No. Andrei
Re: "with" still sucks + removing features + adding features
On Mon, May 18, 2009 at 8:48 PM, Derek Parnell wrote: > On Mon, 18 May 2009 20:05:14 -0600, Rainer Deyke wrote: > >> Bill Baxter wrote: >> Although non-inclusive ranges are common enough that they deserve their >> own syntax, I think inclusive ranges are *also* important enough to >> deserve their own syntax. Writing '+1' is often error-prone or even >> just plain wrong (such as when it leads to integer overflow). > > Agreed. > >> I favor the syntax 'a ... b' for inclusive ranges. It's easy to read >> and similar to 'a .. b' without being too similar. It does require the >> programmer to pay attention, but that's unavoidable. From there, it >> naturally follows that 'case's in a 'switch' statement should follow the >> same convention. > > Sorry, but I don't share your sense of "easy to read" here. The eye can > glaze over the third dot very easily and just not notice it. That's often said, but if you're looking at it in a fixed-width font, then I don't agree that it's so easy to glaze over the third dot. --bb
Re: "with" still sucks + removing features + adding features
On Mon, 18 May 2009 23:15:17 -0400, Jeremie Pelletier wrote: > Derek Parnell Wrote: >> case [FIRST ; LAST] : > > Personally I feel that your syntax breaks the condition > (6) Must not be keystroke-heavy Huh?? By keystroke-heavy I meant the number of keyboard presses the finger would have to do to write it. Ignoring FIRST/LAST, I have 3 (three) keystrokes and Andrei has 8 keystrokes? Me = [ ; ] Andrei = SHIFT : .. case > I like Andei's syntax best but as previously stated, its ambiguous with > exclusive ranges. > > Maybe the solution is a second range operator that is inclusive, such as: > case FIRST ... LAST: Which is 3 keystrokes too. Sorry, I don't understand what you mean by saying my suggestion breaks (6). -- Derek Parnell Melbourne, Australia skype: derek.j.parnell
Re: "with" still sucks + removing features + adding features
On Mon, 18 May 2009 20:05:14 -0600, Rainer Deyke wrote: > Bill Baxter wrote: > Although non-inclusive ranges are common enough that they deserve their > own syntax, I think inclusive ranges are *also* important enough to > deserve their own syntax. Writing '+1' is often error-prone or even > just plain wrong (such as when it leads to integer overflow). Agreed. > I favor the syntax 'a ... b' for inclusive ranges. It's easy to read > and similar to 'a .. b' without being too similar. It does require the > programmer to pay attention, but that's unavoidable. From there, it > naturally follows that 'case's in a 'switch' statement should follow the > same convention. Sorry, but I don't share your sense of "easy to read" here. The eye can glaze over the third dot very easily and just not notice it. -- Derek Parnell Melbourne, Australia skype: derek.j.parnell
Re: Switch
Andrei Alexandrescu wrote:
Georg Wrede wrote:
bearophile wrote:
void classify(char c) {
write("You passed ");
switch (c) {
case '#':
writeln("a hash sign.");
break;
case '0' ..> '9':
writeln("a digit.");
break;
case 'A' ..> 'Z', 'a' ..> 'z':
writeln("an ASCII character.");
break;
case '.', ',', ':', ';', '!', '?':
writeln("a punctuation mark.");
break;
default:
writeln("quite a character!");
break;
}
}
(A bunch of other versions omitted.)...
void classify(char c) {
write("You passed ");
switch (c) {
case '#':
writeln("a hash sign.");
break;
case '0' .. case '9':
writeln("a digit.");
break;
case 'A' .. case 'Z':
case 'a' .. case 'z':
writeln("an ASCII character.");
break;
case '.', ',', ':', ';', '!', '?':
writeln("a punctuation mark.");
break;
default:
writeln("quite a character!");
break;
}
}
This is usable, easy to read -- and the programmer has no problem to
remember that .. works differently in case statements than in ranges.
I'd like to keep the (non-required) colon after the first expression in
a ".." pair of case labels, that is:
case '0': .. case '9':
as opposed to
case '0' .. case '9':
That way it is abundantly clear that the notation has nothing in common
with expression1 .. expression2. The error message if someone forgot the
':' can easily be made clear.
So concatenating ranges would be
case '0': .. case '9': case 'a': .. case 'z':
do something
which then could be written, depending on programmer preferences
case '0':
.. case '9':
case 'a':
.. case 'z':
do something
or
case '0': .. case '9':
case 'a': .. case 'z':
do something
While I'd prefer to omit the colon, I can live with it.
Re: "with" still sucks + removing features + adding features
On Mon, 18 May 2009 21:58:19 -0500, Andrei Alexandrescu wrote:
> Derek Parnell wrote:
>> On Mon, 18 May 2009 19:53:51 -0400, bearophile wrote:
>>
>>> Bill Baxter:
Thinking about it more, I guess you must actually be seeing it as a
rule of " '..' always does the most useful thing",
>>> Such attitude/purposes have created the monkey mess named Perl :-]
>>
>> I submit the D words 'static', 'auto' and 'scope' as examples of this too.
>
> When was the last time you had trouble with "static"? Can you show a
> snippet of code that's confusing because of it?
"not having a trouble" and "not being consistant" are two different things.
For example, I have no trouble with ".." meaning exclusive range inside a
'[' ']' pair, and an inclusive range in a 'case' statement. That does not
trouble me at all and yet it is an inconsistancy.
But back to your question ... here is 'static' used with three different
meanings within three lines of code.
---
module xyzzy;
import std.stdio;
version(X) const int y = 1;
else const int y = -1;
static this() {
static if (y == 1)
static int x = 0;
else
static int x = 42;
writefln("X=%d Y=%d", x,y);
}
void main()
{
}
--
But maybe that's just me?
--
Derek Parnell
Melbourne, Australia
skype: derek.j.parnell
Re: Switch
On 2009-05-18 22:39:23 -0400, Andrei Alexandrescu said: I'd like to keep the (non-required) colon after the first expression in a ".." pair of case labels, that is: case '0': .. case '9': as opposed to case '0' .. case '9': That way it is abundantly clear that the notation has nothing in common with expression1 .. expression2. The error message if someone forgot the ':' can easily be made clear. You could have '::' denote an inclusive range. :-) case '0'..'9': // '9' excluded case '0'::'9': // '9' included Seriously, I don't care much what the syntax is as long as it's different from the one used for exclusive range. Both: case '0': .. case '9': looks acceptable to me. Although I agree with others about the inconsistency of using ".." for an inclusive range, having it finish with "case '9':" seems to indicate clearly the intent to include the last element. -- Michel Fortin michel.for...@michelf.com http://michelf.com/
Re: "with" still sucks + removing features + adding features
On Mon, 18 May 2009 21:47:01 -0500, Andrei Alexandrescu wrote: > Derek Parnell wrote: >> On Mon, 18 May 2009 19:31:23 -0500, Andrei Alexandrescu wrote: >> >>> I completely disagree that that's a special case. ".." is punctuation. >>> You can't pretend punctuation has the same meaning everywhere in a >>> programming language. >> >> I'm a bit confused. Are you saying that one must expect that the meaning of >> punctuation in a programming language depends on the context the >> punctuation is found in? > > How many meanings does '[' have in your favorite programming language? One. But how is your question an answer to my question? -- Derek Parnell Melbourne, Australia skype: derek.j.parnell
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
Re: Switch
Georg Wrede wrote:
> This is usable, easy to read -- and the programmer has no problem to
> remember that .. works differently in case statements than in ranges.
You're making two assumptions here:
1. That inclusive ranges are preferable inside 'case' statements.
2. That non-inclusive ranges are preferable outside 'case' statements.
I don't buy it. The issue of inclusive versus non-inclusive ranges is
*exactly the same* in and outside 'case' statements.
// Non-inclusive:
foreach (c; start .. middle) doA(c);
foreach (c; middle .. end) doB(c);
foreach (c; start .. end) {
switch (c) {
case start .. middle:
doA(c);
break;
case middle .. end:
doA(c);
break;
}
}
// Inclusive:
foreach (c; 'a' ... 'z') doSomething(c);
switch (c) {
case 'a' ... 'z':
doSomething(c);
break;
}
foreach (c; 0 ... int.max) doSomething(c);
switch (c) {
case 0 ... int.max:
doSomething(c);
break;
}
Since I don't accept your assumptions, I see no point in arguing whether
or not those assumptions would justify overloading the '..' operator to
have one meaning in 'case' statements and another meaning elsewhere.
--
Rainer Deyke - rain...@eldwood.com
Re: Differences between invariant and immutable?
On Mon, May 18, 2009 at 11:02 PM, Jeremie Pelletier wrote: > I upgraded to 2.0.30 today and noticed the new immutable keyword on the > migration to shared page. I knew of the keyword before but older versions of > DMD didn't seem to recognize it, so I assumed it meant invariant. > > But now I'd like to know what are the specific differences between the two, > as I couldn't find any detailed page on the subject. There are no pages on it. It's currently an alias for invariant. The idea is that invariant will eventually lose its meaning as a type constructor and just go back to a contract, with immutable taking its place.
Re: "with" still sucks + removing features + adding features
On Mon, May 18, 2009 at 1:57 PM, Andrei Alexandrescu 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:
(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
Differences between invariant and immutable?
I upgraded to 2.0.30 today and noticed the new immutable keyword on the migration to shared page. I knew of the keyword before but older versions of DMD didn't seem to recognize it, so I assumed it meant invariant. But now I'd like to know what are the specific differences between the two, as I couldn't find any detailed page on the subject. Jeremie
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: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
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
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: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
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: While we're lynching features, how bout' them omittable parens?
Chad J wrote: dsimcha wrote: Yeah, file a Bugzilla. Shouldn't ++, +=, etc. only work on lvalues? *shrug* http://d.puremagic.com/issues/show_bug.cgi?id=3008 Voted up! Andrei
Re: "with" still sucks + removing features + adding features
On Mon, 18 May 2009 19:31:23 -0500, Andrei Alexandrescu wrote: > I completely disagree that that's a special case. ".." is punctuation. > You can't pretend punctuation has the same meaning everywhere in a > programming language. I'm a bit confused. Are you saying that one must expect that the meaning of punctuation in a programming language depends on the context the punctuation is found in? If so, then ".." in "[a .. b]" can mean exclusive range and ".." in "case a .. b:" can mean inclusive range, no? -- Derek Parnell Melbourne, Australia skype: derek.j.parnell
Re: "with" still sucks + removing features + adding features
Andrei Alexandrescu wrote: Bill Baxter wrote: On Mon, May 18, 2009 at 4:15 PM, Bill Baxter wrote: But it's not "blarf". It's "case". I am floored that nobody sees the elegance of that syntax. So your argument is that "case" inherently deserves a special case? Thinking about it more, I guess you must actually be seeing it as a rule of " '..' always does the most useful thing", and the most useful thing for switches is inclusive. No! If I thought that, I would have said this is fine: case 'a' .. 'z': It is NOT fine because 'a' .. 'z' means one thing here and a different thing in another place. So I went for: case 'a': .. case 'z': specifically because case 'a': .. case 'z': does NOT have any meaning anywhere else. The colon is not needed there for understanding, and definitely not needed for remembering that .. in a case is inclusive. It's the overall context (being in a switch statement) that puts the programmer in the inclusive mindset. case 'a' .. case 'z': is adequate. Besides, then we can have discontinuous ranges without changing the current behavior, since case 'a' .. case 'z': case 'A' .. case 'Z': do something is the same as case 'a' .. case 'z': case 'A' .. case 'Z': do something already now.
Re: While we're lynching features, how bout' them omittable parens?
dsimcha wrote: > > Yeah, file a Bugzilla. Shouldn't ++, +=, etc. only work on lvalues? *shrug* http://d.puremagic.com/issues/show_bug.cgi?id=3008
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: Switch
Georg Wrede wrote:
bearophile wrote:
void classify(char c) {
write("You passed ");
switch (c) {
case '#':
writeln("a hash sign.");
break;
case '0' ..> '9':
writeln("a digit.");
break;
case 'A' ..> 'Z', 'a' ..> 'z':
writeln("an ASCII character.");
break;
case '.', ',', ':', ';', '!', '?':
writeln("a punctuation mark.");
break;
default:
writeln("quite a character!");
break;
}
}
(A bunch of other versions omitted.)...
void classify(char c) {
write("You passed ");
switch (c) {
case '#':
writeln("a hash sign.");
break;
case '0' .. case '9':
writeln("a digit.");
break;
case 'A' .. case 'Z':
case 'a' .. case 'z':
writeln("an ASCII character.");
break;
case '.', ',', ':', ';', '!', '?':
writeln("a punctuation mark.");
break;
default:
writeln("quite a character!");
break;
}
}
This is usable, easy to read -- and the programmer has no problem to
remember that .. works differently in case statements than in ranges.
I'd like to keep the (non-required) colon after the first expression in
a ".." pair of case labels, that is:
case '0': .. case '9':
as opposed to
case '0' .. case '9':
That way it is abundantly clear that the notation has nothing in common
with expression1 .. expression2. The error message if someone forgot the
':' can easily be made clear.
Andrei
Re: "with" still sucks + removing features + adding features
Nick Sabalausky wrote: "Andrei Alexandrescu" 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. Yes. I got a rush of endorphine out of that one. But others have brought up some very valid objections that I really have to agree with, and I'll add one more: A lot of people don't like the whole "fall-through" thing anyway and want to see D move farther from it rather than embracing it as this syntax seems to do. I dislike the fall through as much as you do. Andrei
Switch
bearophile wrote:
void classify(char c) {
write("You passed ");
switch (c) {
case '#':
writeln("a hash sign.");
break;
case '0' ..> '9':
writeln("a digit.");
break;
case 'A' ..> 'Z', 'a' ..> 'z':
writeln("an ASCII character.");
break;
case '.', ',', ':', ';', '!', '?':
writeln("a punctuation mark.");
break;
default:
writeln("quite a character!");
break;
}
}
(A bunch of other versions omitted.)...
void classify(char c) {
write("You passed ");
switch (c) {
case '#':
writeln("a hash sign.");
break;
case '0' .. case '9':
writeln("a digit.");
break;
case 'A' .. case 'Z':
case 'a' .. case 'z':
writeln("an ASCII character.");
break;
case '.', ',', ':', ';', '!', '?':
writeln("a punctuation mark.");
break;
default:
writeln("quite a character!");
break;
}
}
This is usable, easy to read -- and the programmer has no problem to
remember that .. works differently in case statements than in ranges.
There are other places in D that place an undue burden on the
programmer, but this is not IMHO one of them.
My pet peeve with case is that, since we don't seem to be getting rid of
break (and use some word for fall-through instead, "which would save a
good deal of ink"), we should at least try to make break more
conspicuous. I can name a hundred times I've forgotten a break from
somewhere. So the canonical indentation should be like this:
void classify(char c) {
write("You passed ");
switch (c) {
case '#':
writeln("a hash sign.");
break;
case '0' .. case '9':
writeln("a digit.");
break;
case 'A' .. case 'Z':
case 'a' .. case 'z':
writeln("an ASCII character.");
break;
case '.', ',', ':', ';', '!', '?':
writeln("a punctuation mark.");
break;
default:
writeln("quite a character!");
break;
}
}
(It'd look better when the cases have more lines, but still.) Currently
in D, break is at least as important as case, therefore it deserves a
conspicuous place, hence my suggestion.
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
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
"Andrei Alexandrescu" 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: While we're lynching features, how bout' them omittable parens?
Hello dsimcha,
== Quote from Chad J (chadj...@__spam.is.bad__gmail.com)'s article
Lionello Lunesu wrote:
"Chad J" wrote in message
news:gut0f2$jc...@digitalmars.com...
Nevermind properties. Any chance we can forbid the omittable
parentheses, at least in the lhs of an assignment expression?
In the more general case, any value type that gets modified but
never read or copied elsewhere is probably either dead code, a bug,
or a benchmark. The latter is easy to fix by adding the necessary
read/copy (return the value, pass it to a global or function, etc).
It'd be great if this kind of thing were a compile time error.
Code like this shouldn't compile:
struct S { int a = 0; }
S foo() { S s; return s; }
void main()
{
foo.a++;
}
This is not because of the omittable parens. Even with added parens
that code should not compile!
L.
Agreed!
Yeah, file a Bugzilla. Shouldn't ++, +=, etc. only work on lvalues?
Strictly speaking foo.a is an lvalue. Maybe value return types shouldn't
be? I think that might be the best keyhole fix.
Re: "with" still sucks + removing features + adding features
"Jason House" 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
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. It does require the programmer to pay attention, but that's unavoidable. From there, it naturally follows that 'case's in a 'switch' statement should follow the same convention. I don't believe it makes any sense to have inclusive ranges in 'switch' statements and non-inclusive ranges everywhere else. Inclusive ranges are fairly common outside 'switch' statements, and non-inclusive ranges are fairly common in 'switch' statements. -- Rainer Deyke - rain...@eldwood.com
Re: While we're lynching features, how bout' them omittable parens?
"Chad J" wrote in message news:gut1od$l5...@digitalmars.com... > Lionello Lunesu wrote: >> >> "Chad J" wrote in message >> news:gut0f2$jc...@digitalmars.com... >>> Nevermind properties. Any chance we can forbid the omittable >>> parentheses, at least in the lhs of an assignment expression? >>> >> >> This is not because of the omittable parens. Even with added parens that >> code should not compile! >> > > Agreed! I still want to get rid of omittable parens (and function-call-as-a-lhs) anyway. They're a horrible substitute for a real property syntax.
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
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: While we're lynching features, how bout' them omittable parens?
== Quote from Chad J (chadj...@__spam.is.bad__gmail.com)'s article
> Lionello Lunesu wrote:
> >
> > "Chad J" wrote in message
> > news:gut0f2$jc...@digitalmars.com...
> >> Nevermind properties. Any chance we can forbid the omittable
> >> parentheses, at least in the lhs of an assignment expression?
> >>
> >> In the more general case, any value type that gets modified but never
> >> read or copied elsewhere is probably either dead code, a bug, or a
> >> benchmark. The latter is easy to fix by adding the necessary read/copy
> >> (return the value, pass it to a global or function, etc). It'd be great
> >> if this kind of thing were a compile time error.
> >>
> >> Code like this shouldn't compile:
> >>
> >> struct S { int a = 0; }
> >> S foo() { S s; return s; }
> >>
> >> void main()
> >> {
> >>foo.a++;
> >> }
> >
> > This is not because of the omittable parens. Even with added parens that
> > code should not compile!
> >
> > L.
> Agreed!
Yeah, file a Bugzilla. Shouldn't ++, +=, etc. only work on lvalues?
Re: While we're lynching features, how bout' them omittable parens?
Lionello Lunesu wrote:
>
> "Chad J" wrote in message
> news:gut0f2$jc...@digitalmars.com...
>> Nevermind properties. Any chance we can forbid the omittable
>> parentheses, at least in the lhs of an assignment expression?
>>
>> In the more general case, any value type that gets modified but never
>> read or copied elsewhere is probably either dead code, a bug, or a
>> benchmark. The latter is easy to fix by adding the necessary read/copy
>> (return the value, pass it to a global or function, etc). It'd be great
>> if this kind of thing were a compile time error.
>>
>> Code like this shouldn't compile:
>>
>> struct S { int a = 0; }
>> S foo() { S s; return s; }
>>
>> void main()
>> {
>>foo.a++;
>> }
>
> This is not because of the omittable parens. Even with added parens that
> code should not compile!
>
> L.
Agreed!
Re: While we're lynching features, how bout' them omittable parens?
"Chad J" wrote in message
news:gut0f2$jc...@digitalmars.com...
Nevermind properties. Any chance we can forbid the omittable
parentheses, at least in the lhs of an assignment expression?
In the more general case, any value type that gets modified but never
read or copied elsewhere is probably either dead code, a bug, or a
benchmark. The latter is easy to fix by adding the necessary read/copy
(return the value, pass it to a global or function, etc). It'd be great
if this kind of thing were a compile time error.
Code like this shouldn't compile:
struct S { int a = 0; }
S foo() { S s; return s; }
void main()
{
foo.a++;
}
This is not because of the omittable parens. Even with added parens that
code should not compile!
L.
While we're lynching features, how bout' them omittable parens?
Nevermind properties. Any chance we can forbid the omittable
parentheses, at least in the lhs of an assignment expression?
In the more general case, any value type that gets modified but never
read or copied elsewhere is probably either dead code, a bug, or a
benchmark. The latter is easy to fix by adding the necessary read/copy
(return the value, pass it to a global or function, etc). It'd be great
if this kind of thing were a compile time error.
Code like this shouldn't compile:
struct S { int a = 0; }
S foo() { S s; return s; }
void main()
{
foo.a++;
}
Re: "with" still sucks + removing features + adding features
On Mon, May 18, 2009 at 5:33 PM, Andrei Alexandrescu wrote: > Bill Baxter wrote: >> >> On Mon, May 18, 2009 at 4:15 PM, Bill Baxter 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 3:29 PM, Jason House > > 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: The Final(ize) Challenge
Andrei Alexandrescu wrote:
Christopher Wright wrote:
Andrei Alexandrescu wrote:
I think you need to operate exclusively with string mixins in
Finalize, so __ident would be of marginal help there. Also, static
foreach is much more necessary.
That is a huge problem.
Let's say that the class you want to finalize, Target, has a method
like this:
void foo(SomeClass){}
Let's say that SomeClass is private and in the same module as Target.
You *may* be able to do this with templates. Probably.
You *can never* do this with a string mixin.
Of course you can. All you have to do is first check whether the call is
accessible from your instantiation point, BEFORE generating the string.
Andrei
And a lot of interesting usages will have the Finalize template
instantiated far from user code, but then passed back to user code. This
means you can't do much at all with string mixins.
I faced that problem with dmocks and didn't find a good solution for it
while still working on dmocks.
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
Bill Baxter wrote: On Mon, May 18, 2009 at 4:02 PM, Andrei Alexandrescu wrote: Bill Baxter wrote: On Mon, May 18, 2009 at 3:29 PM, Jason House 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
Bill Baxter wrote: On Mon, May 18, 2009 at 4:15 PM, Bill Baxter 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
Andrei Alexandrescu:
Thank you for bringing a "real" example that gives something to work on.
>Awful!<
Well, one of your cases was wrong. Using the +1 at the end one of those cases
become:
case 'A' .. 'Z'+1, 'a' .. 'z'+1:
Instead of what you have written:
case 'A' .. 'Z'+1: case 'a' .. 'z'+1:
I agree that that syntax with +1 isn't very nice looking. But the advantage of
+1 is that it introduces (almost) no new syntax, it's not easy to miss, its
meaning is easy to understand. AND you don't have to remember that in a case
the .. is inclusive while in foreach is exclusive on the right, keeping the
standard way in D to denote ranges.
-
We can introduce in D a syntax that maps on the semantics of iota(start, stop)
or even iota(start, stop, step) (I don't remember if iota() supports opIn_r,
and has length, if not then it's better to add them).
So you can do:
foreach (i; somerangesyntax) {...}
(So this replaces the current ranged foreach syntax).
case somerangesyntax: ...
if (x in somerangesyntax) {...}
map(fun, somerangesyntax);
And more, using only one (or two) general syntaxes.
-
The simple exclusive range syntax, with +1:
void classify(char c) {
write("You passed ");
switch (c) {
case '#':
writeln("a hash sign.");
break;
case '0' .. '9'+1:
writeln("a digit.");
break;
case 'A' .. 'Z'+1, 'a' .. 'z'+1:
writeln("an ASCII character.");
break;
case '.', ',', ':', ';', '!', '?':
writeln("a punctuation mark.");
break;
default:
writeln("quite a character!");
break;
}
}
Using Chapel closed range syntax:
void classify(char c) {
write("You passed ");
switch (c) {
case '#':
writeln("a hash sign.");
break;
case '0' ..# '9':
writeln("a digit.");
break;
case 'A' ..# 'Z', 'a' ..# 'z':
writeln("an ASCII character.");
break;
case '.', ',', ':', ';', '!', '?':
writeln("a punctuation mark.");
break;
default:
writeln("quite a character!");
break;
}
}
An alternative to that Chapel syntax:
void classify(char c) {
write("You passed ");
switch (c) {
case '#':
writeln("a hash sign.");
break;
case '0' ..> '9':
writeln("a digit.");
break;
case 'A' ..> 'Z', 'a' ..> 'z':
writeln("an ASCII character.");
break;
case '.', ',', ':', ';', '!', '?':
writeln("a punctuation mark.");
break;
default:
writeln("quite a character!");
break;
}
}
It may be easy to miss the third point (but it's not a noisy syntax)
void classify(char c) {
write("You passed ");
switch (c) {
case '#':
writeln("a hash sign.");
break;
case '0' ... '9':
writeln("a digit.");
break;
case 'A' ... 'Z', 'a' ... 'z':
writeln("an ASCII character.");
break;
case '.', ',', ':', ';', '!', '?':
writeln("a punctuation mark.");
break;
default:
writeln("quite a character!");
break;
}
}
Using something more explicit (interval() is lazy and inclusive on the right.
The D compiler optimizes away at compile time the following calls):
void classify(char c) {
write("You passed ");
switch (c) {
case '#':
writeln("a hash sign.");
break;
case interval('0', '9'):
writeln("a digit.");
break;
case interval('A', 'Z'), interval('a', 'z'):
writeln("an ASCII character.");
break;
case '.', ',', ':', ';', '!', '?':
writeln("a punctuation mark.");
break;
default:
writeln("quite a character!");
break;
}
}
void classify(char c) {
write("You passed ");
switch (c) {
case '#':
writeln("a hash sign.");
break;
case ['0' .. '9']:
writeln("a digit.");
break;
case ['A' .. 'Z'], ['a' .. 'z']:
writeln("an ASCII character.");
break;
case '.', ',', ':', ';', '!', '?':
writeln("a punctuation mark.");
break;
default:
writeln("quite a character!");
break;
}
}
Such syntaxes are meant to be used in every other situation too (and I'd like
to have another syntax that is non-inclusive, possibly like the current one):
foreach (i; 'A' .. 'Z'+1) {...}
case 'A' .. 'Z'+1: ...
if (x in 'A' .. 'Z'+1) {...}
map(fun, 'A' .. 'Z'+1);
foreach (i; 'A' ..# 'Z') {...}
case 'A' ..# 'Z': ...
if (x in 'A' ..# 'Z') {...}
map(fun, 'A' ..# 'Z');
foreach (i; 'A' ..> 'Z') {...}
case 'A' ..> 'Z': ...
if (x in 'A' ..> 'Z') {...}
map(fun, 'A' ..> 'Z');
foreach (i; 'A' ... 'Z') {...}
case 'A' ... 'Z':
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
On Mon, May 18, 2009 at 4:15 PM, Bill Baxter 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
-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
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
On Mon, May 18, 2009 at 4:02 PM, Andrei Alexandrescu wrote: > Bill Baxter wrote: >> >> On Mon, May 18, 2009 at 3:29 PM, Jason House >> 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" should be deprecated with extreme prejudice
grauzone wrote:
Nick Sabalausky wrote:
"grauzone" wrote in message
news:guqrj2$2l7...@digitalmars.com...
Here's another simple fix for with();
int x, y;
with (whatever)
{
.y += x; //.y references this is whatever.y
++x; //x references local scope
}
That already means global scope.
Yes, but who uses that anyway?
There's that perennial annoyance that class methods with a given name
hide free functions of the same name, even if they are not covariant.
This crops up a lot with toString, and the fix is to prepend a dot to
the invocation.
Re: std.string.sformat broken in DMD 2.030 ?
I filed a bugzilla report on this one back in November with 2.022 (bug #
2479) Its still is open.
Sivo Schilling wrote:
Hi all,
consider the following simple code snippet
---
// check sformat with DMD 2.030/1.045
import std.stdio;
import std.string;
void test_sformat(int value)
{
char[128] buf_;
char[] buf;
buf = sformat(buf_, "Test sformat with value %d", value);
writefln("%s", buf);
}
void main()
{
for (int i = 130465; i < 130480; i++) test_sformat(i);
}
---
With dmd 1.045 compile and run is as expected. The output is:
---
C:\user\sisch\devel\dsource\tests\bin>check_sformat_v1
Test sformat with value 130465
Test sformat with value 130466
Test sformat with value 130467
Test sformat with value 130468
Test sformat with value 130469
Test sformat with value 130470
Test sformat with value 130471
Test sformat with value 130472
Test sformat with value 130473
Test sformat with value 130474
Test sformat with value 130475
Test sformat with value 130476
Test sformat with value 130477
Test sformat with value 130478
Test sformat with value 130479
With dmd 2.030 building an executable is successfull too, but
running the program yields:
C:\user\sisch\devel\dsource\tests\bin>check_sformat_v2
object.Error: Access Violation
Is this a bug ? Could someone explain this unexpected behaviour ?
OS: Windows XP, SP3
DMD: see above
Thanks,
Sivo.
Re: the cast mess
grauzone wrote: The worst thing about the current cast(T) operator is that it easily allows reinterpret cast. This is SO NOT SAFE! Especially with arrays, it doesn't do something what the user expects. It's a hidden reinterpret cast. This really should be changed. I use this functionality in a few places. However, there are several other ways of doing it.
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: OT: on IDEs and code writing on steroids
Andrei Alexandrescu escribió: Christopher Wright wrote: BCS wrote: Reply to Andrei, I've repeatedly failed to figure out the coolness of C#, and would appreciate a few pointers. Or references. Or delegates :o). The coolness of c# is that (in order, IMHO) 1) the tools are world class, 2) the support is back by MS, 3) the docs are great, and 4) the language is highly consistent and conservative, e.i. nothing is added until they've got it right. Aside from #4, the *language* isn't anything to write home about. I'd say C#2 is Java with the top 10 or so feature requests implemented, I can confirm straight from the source (important person, name undisclosed to protect the innocent) that it is true that C# was without any buts and ands Microsoft's direct response to Java. and another 5 or so major feature requests implemented each major version. That isn't a bad state to be in, really. It's good enough, with a billion dollars in corporate backing, to make you the Current Big Language. I have the feeling that C#, for all its features, lacks some pretty essential capabilities. Like...?
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: The Final(ize) Challenge
Christopher Wright wrote:
Andrei Alexandrescu wrote:
I think you need to operate exclusively with string mixins in
Finalize, so __ident would be of marginal help there. Also, static
foreach is much more necessary.
That is a huge problem.
Let's say that the class you want to finalize, Target, has a method like
this:
void foo(SomeClass){}
Let's say that SomeClass is private and in the same module as Target.
You *may* be able to do this with templates. Probably.
You *can never* do this with a string mixin.
Of course you can. All you have to do is first check whether the call is
accessible from your instantiation point, BEFORE generating the string.
Andrei
Re: "with" still sucks + removing features + adding features
Bill Baxter wrote: On Mon, May 18, 2009 at 3:29 PM, Jason House 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
Re: The Final(ize) Challenge
On Mon, May 18, 2009 at 6:54 PM, Christopher Wright wrote:
> Andrei Alexandrescu wrote:
>>
>> I think you need to operate exclusively with string mixins in Finalize, so
>> __ident would be of marginal help there. Also, static foreach is much more
>> necessary.
>
> That is a huge problem.
>
> Let's say that the class you want to finalize, Target, has a method like
> this:
> void foo(SomeClass){}
>
> Let's say that SomeClass is private and in the same module as Target.
>
> You *may* be able to do this with templates. Probably.
>
> You *can never* do this with a string mixin.
Exactly. This is one of the problems I mentioned earlier, and I know
Andrei's got experience with this as well - std.algorithm doesn't
import std.math by default, so you can't use math functions in the
string expressions. Oh sure, you could kludge that in there, but it's
far from scalable.
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: The Final(ize) Challenge
Andrei Alexandrescu wrote:
I think you need to operate exclusively with string mixins in Finalize,
so __ident would be of marginal help there. Also, static foreach is much
more necessary.
That is a huge problem.
Let's say that the class you want to finalize, Target, has a method like
this:
void foo(SomeClass){}
Let's say that SomeClass is private and in the same module as Target.
You *may* be able to do this with templates. Probably.
You *can never* do this with a string mixin.
Let's say you have another method:
void bar(SomeOtherClass!(int)){}
SomeOtherClass!(int).stringof == "SomeOtherClass". That is also
guaranteed fail.
What you can do is:
void foo(ParameterTupleOf!(__traits(getVirtualFunctions, Target,
"foo")[0] u) { super.foo(u); }
Here, the only string you need to mix in is for the identifier.
Re: "with" still sucks + removing features + adding features
On Mon, May 18, 2009 at 3:29 PM, Jason House 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: The Final(ize) Challenge
Frits van Bommel wrote:
Andrei Alexandrescu wrote:
Good point! Now define Unfinalize that opens the final methods of a
class for method overriding.
class A
{
final int foo(string) { ... }
}
class UnfinalizeA : A
{
int foo(string a) { return super.foo(a); }
}
DMD rightly doesn't allow this:
---
test.d(8): Error: function test.UnfinalizeA.foo cannot override final
function test.A.foo
---
There's a workaround though:
---
class UnfinalizeA : A
{
int foo_(string a) { return super.foo(a); }
alias foo_ foo;
}
Damn. I meant to NOT inherit from A.
Andrei
Re: OT: on IDEs and code writing on steroids
Christopher Wright wrote: BCS wrote: Reply to Andrei, I've repeatedly failed to figure out the coolness of C#, and would appreciate a few pointers. Or references. Or delegates :o). The coolness of c# is that (in order, IMHO) 1) the tools are world class, 2) the support is back by MS, 3) the docs are great, and 4) the language is highly consistent and conservative, e.i. nothing is added until they've got it right. Aside from #4, the *language* isn't anything to write home about. I'd say C#2 is Java with the top 10 or so feature requests implemented, I can confirm straight from the source (important person, name undisclosed to protect the innocent) that it is true that C# was without any buts and ands Microsoft's direct response to Java. and another 5 or so major feature requests implemented each major version. That isn't a bad state to be in, really. It's good enough, with a billion dollars in corporate backing, to make you the Current Big Language. I have the feeling that C#, for all its features, lacks some pretty essential capabilities. Andrei
Re: The Final(ize) Challenge
Jarrett Billingsley wrote: The second is worse. __ctor (if it exists) is not virtual, so it's not possible to get a list of overloads of it with __traits. One of two things has to change: either __traits needs a way to get overloads of nonvirtual functions (that seems like an incredible oversight!), or as Sean and others have proposed numerous times, derived classes should inherit ctors. This would eliminate the need to write forwarding constructors in the Finalize class altogether. http://d.puremagic.com/issues/show_bug.cgi?id=2855
Re: The Final(ize) Challenge
Jarrett Billingsley wrote: On Mon, May 18, 2009 at 12:12 PM, Andrei Alexandrescu wrote: Have at it! Well? Where's my cookie? ;) As soon as I'm coming off my prostration and awe engendered by your solution, I'll reply to that. I have to admit, though, that Denis' insight sort of took the wind out of my sails. Thanks! Andrei
Re: OT: on IDEs and code writing on steroids
BCS wrote: Reply to Andrei, I've repeatedly failed to figure out the coolness of C#, and would appreciate a few pointers. Or references. Or delegates :o). The coolness of c# is that (in order, IMHO) 1) the tools are world class, 2) the support is back by MS, 3) the docs are great, and 4) the language is highly consistent and conservative, e.i. nothing is added until they've got it right. Aside from #4, the *language* isn't anything to write home about. I'd say C#2 is Java with the top 10 or so feature requests implemented, and another 5 or so major feature requests implemented each major version. That isn't a bad state to be in, really. It's good enough, with a billion dollars in corporate backing, to make you the Current Big Language.
Re: "with" should be deprecated with extreme prejudice
On Mon, May 18, 2009 at 2:56 PM, Andrei Alexandrescu
wrote:
> Bill Baxter wrote:
>>
>> On Mon, May 18, 2009 at 1:36 PM, Andrei Alexandrescu
>> wrote:
>>>
>>> That's not an "equiv of". It's "completely missing the point of". Each
>>> "using" costs one new scope and one level of indentation which makes it
>>> non-scalable. Indentation is *expensive*. I think the C# folks missed the
>>> class when try/catch/finally showed with extensive examples just how
>>> expensive extra indentation is.
>>
>> Oh. Is that the only thing that bothers you about it?
>> That doesn't bother me much since it's basically for things you only
>> want to hold on to for a short span. You should either do your
>> business in a few lines of code and get out of there, or if you can't
>> then make it a function. Anyway, if the indentation bugs you, you
>> can always set emacs up not to indent on "using" blocks.
>
> It's huge! In TDPL, as soon as I show the expansion of two scope(exit)
> statements, code became unreadable. No wonder today's software has so
> crappy error handling and state leaks: languages seem to make it as hard
> as possible to write correct transactional code.
I agree that scope(exit) is a more general solution that allows for
more interesting tricks.
I think I'm only disagreeing with you on the magnitude of the lameness.
You can always create a new scope if you want one, but you can't
remove a scope if it is defined to be a part of the construct. So to
me it seems clear that not building the scope into the construct is
the way to go. This is also a strike against D's current with(),
which also forces a new scope whether you want it or not.
---
In related news, scope(exit) is not without it's own issues. Mainly,
this doesn't seem nice to me:
void foo() {
auto x = new Thing;
scope(exit) x.doADance();
// bunch of code
x = otherThing;
// more code
}
This will happily doADance on otherThing instead of the original x
when it exits. I'm guessing the C# using / Python with are safer wrt
re-assignment, but I have not investigated this. Anyone know?
--bb
Re: OT: on IDEs and code writing on steroids
davidl wrote: From a commercial basis for Walter, it may be easier to glue a C# frontend against the DMD backend to create a native C# compiler. Mono has AOT compilation. On the other hand, I've experienced more ICE per minute with Mono than with dmd. This is partially due to dmd's near monoculture and .NET's huge majority market share -- people code around dmdfe bugs, but not around Mono bugs.
Re: "with" still sucks + removing features + adding features
Andrei Alexandrescu Wrote: > Jason House wrote: > > Andrei Alexandrescu Wrote: > > > >> Jarrett Billingsley wrote: > >>> On Mon, May 18, 2009 at 1:46 PM, Andrei Alexandrescu > >>> wrote: > >>> > Final switch works with enums and forces you to handle each and every > value > of the enum. Regular switch gets ranged cases by the syntax case a: .. > case > b: (I've always thought switch would be greatly helped by that). > >>> Kind of an odd syntax. Why not "case a .. b:"? Parsing issues? > >> It's consistency. Everywhere in the language a .. b implies b is > >> excluded. In a switch you want to include b. So I reflected that in the > >> syntax. In fact, I confess I'm more proud than I should be about that > >> little detail. > > > > Consistency??? > > > > While I can see where you're coming from, I still see plenty of > > inconsistencies. It's still a range (defined with .. too). Having slices > > and foreach use syntax a and meaning 1 but switch using syntax a' and > > meaning 2 kind of sucks. > > You'd have to squint real hard to see a range. A range is > > expr1 .. expr2 > > That code is > > case expr1: .. case expr2: > > I mean you can't tell me that as soon as ".." is within a mile it's a range. > > > Andrei It's all a matter of perspective. I see both as begin .. end. That may be the same reason why I think addition when I see foo(bar()) + baz(37). The extra cruft is more or less ignored when figuring out the basics of what is going on.
