Re: Descent 0.5.5 released
Ary Borenszweig schrieb: For this release Robert Fraser made an excelent addition: when compiling programs using an external tool such as dsss, rebuild, dmd, gdc, ldc, gdmd or bud, there are now links to the files in the console output for warnings and errors. I think this one was pretty requested. So say thanks to him! :-) FINALLY! Yha. Many thanks to Robert!
D identi.ca microblogging group
Hi, It's some time now that a group about d programming language is active in identi.ca, it's: http://identi.ca/group/dlanguage Microblogging is going to be an effective way to ping/send small messages/send news in the FOSS community, so feel free to join the group and write anything related to D research, compilers, programs, libraries. To write to all the members of the group just add !dlanguage in your identi.ca message. Hope it helps in spreading the good word about the D programming language as Walter said many times :) See you.
Re: Please test: black holes and white holes
Shin Fujishiro wrote: I wrote: Now it came to my mind that the problem could be solved by inserting alias ReturnType!(C.foo) X; in generated code. I'll try this. OK, I did it! I checked in a new version. http://code.google.com/p/kabe/source/browse/branches/bhwh/test.d http://code.google.com/p/kabe/source/browse/branches/bhwh/nonstd/traits.d http://code.google.com/p/kabe/source/browse/branches/bhwh/nonstd/typecons.d Also, there's a trick to extracting parameter storage classes from a parameter type tuple (template parameterStorageClasses in traits.d). Perfect! Andrei
Serialization for D. Comments, please!
I'm planning on taking a crack at a Serialization template library and I'm looking for feed back. My thinking so far is up on my blog here: http://arrayboundserror.blogspot.com/2009/05/serialization-for-d-part-1-of-n.html Please comment! (here or there, doesn't matter, I think I'll see both)
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
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
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: 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
Yigal Chripun wrote: ... IMO, designing the language to support this better work-flow is a good decision made by MS, and D should follow it instead of trying to get away without an IDE. I'm not sure about this. D is designed to be easier to parse than C++ (but that's saying nothing) to allow better tools made for it. I think this should be enough. C# friends not only better supports working inside an IDE, but makes it a pain to do without. Autocomplete dictates that related functions should be named with the exact same prefix - even when this isn't logical. It also encourages names to be as descriptive as possible, in practice leading to a part of the api docs encoded in the function name. Extremely bloated names are the consequence of this. It doesn't always make code more readable imho. The documentation comments are in xml: pure insanity. I tried to generate documentation for my stuff at work once, expecting to be done in max 5 min. like ddoc. Turns out nobody at work uses documentation generation for a reason: it isn't really fleshed out and one-click from the IDE, in fact it is a pain in the arse compared to using ddoc. I should stop now before this turns into a rant.
Re: OT: on IDEs and code writing on steroids
BCS wrote: ... all LINQ is is a set of standard nameing conventions and sugar. I Add a Where function to some SQL tabel object and you get the above as well. ... Not really, LINQ is 'sugar' for the underlying libraries that implements querying. Instead of calling it just sugar, it is more proper to call it a language in it's own right. LINQ to SQL is just one thing, the power of LINQ is that you separate queries from source of data. You can write one query (ideally) that works with SQL, XML or plain Arrays. It's not only that you don't have to write SQL queries anymore, a lot of messy for/while/etc. loops can be totally replaced with LINQ queries too.
Re: with still sucks + removing features + adding features
Andrei Alexandrescu seewebsiteforem...@erdani.org wrote in message news:gut7lb$ue...@digitalmars.com... (0) Must be recognizable and understood at first sight without the user running to the manual and looking it up. I've never considered that a particularly good criterea in most cases. Most language features/syntax are non-obvious at a glance for anyone who isn't already familiar with it. And typically, you only need to look it up once and then next time you see it you'll remember. People had the same complaint when '$' was proposed for blah.length, but seriously, one it was included who here has ever had a non-trivial time learning and internalizing that? Does '!()' scream template to someone who hasn't used D or looked at the D docs? Of course not. But it works fine. And I sure someone could have easily said the same about the '#' at the beginning of preprocessor directives back whenever those were first created. But who ever has any real trouble with that? I didn't even the very first time I was introduced to it. This '(0)' is barely an issue at all.
Re: with still sucks + removing features + adding features
Nick Sabalausky wrote: Andrei Alexandrescu seewebsiteforem...@erdani.org wrote in message news:gut7lb$ue...@digitalmars.com... (0) Must be recognizable and understood at first sight without the user running to the manual and looking it up. I've never considered that a particularly good criterea in most cases. Most language features/syntax are non-obvious at a glance for anyone who isn't already familiar with it. Not slight departures from existing syntax. Andrei
Re: with still sucks + removing features + adding features
Andrei Alexandrescu seewebsiteforem...@erdani.org wrote in message news:gutd12$16h...@digitalmars.com... Let me make a separate point. With ..., people just defined the space operator. What's the space operator? Changes the meaning of 0...10 in two distinct ways: 0...10 is an all-inclusive integer range from 0 to 10 0. ..10 is a right-open floating-point range from 0 to 10 0.. .10 is a right-open floating-point range from 0 to 0.1 So '1.' and '.1' are legal numbers in D? I would have assumed that any numerical literal with a decimal point would require at least one digit on both sides of the decimal point. Not sure I see a good reason for this not to be required.
Re: While we're lynching features, how bout' them omittable parens?
Jesse Phillips jessekphill...@gmail.com wrote in message news:gutbro$14e...@digitalmars.com... On Mon, 18 May 2009 21:53:06 -0400, Nick Sabalausky wrote: 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. D leaves the function/property distinction up to the caller, which is rediculous because in most cases only one or the other actually makes sense. C# places the responsilibily for that function-syntax/property-syntax choice on the callee instead, where it belongs. D's approach is like saying You can index an array with 'myArray[5]' *or* 'myArray+5', and you can add two numbers with 'myInt+5' *or* 'myInt[5]'. Either way, it's your choice!!. It's a completely useless form of flexibility and comes at the cost of encouraging confusion.
Re: with still sucks + removing features + adding features
On Mon, 18 May 2009 21:30:41 -0700, Bill Baxter wrote: On Mon, May 18, 2009 at 9:17 PM, Derek Parnell de...@psych.ward wrote: On Mon, 18 May 2009 23:02:37 -0500, Andrei Alexandrescu wrote: Derek Parnell wrote: On Mon, 18 May 2009 21:47:01 -0500, Andrei Alexandrescu wrote: Derek Parnell wrote: On Mon, 18 May 2009 19:31:23 -0500, Andrei Alexandrescu wrote: I completely disagree that that's a special case. .. is punctuation. You can't pretend punctuation has the same meaning everywhere in a programming language. I'm a bit confused. Are you saying that one must expect that the meaning of punctuation in a programming language depends on the context the punctuation is found in? How many meanings does '[' have in your favorite programming language? One. No. But you never asked for the name of my favourite language? Does it have string or character literals? Then there's probably at least two meanings. ;-P Huh? two meanings of '[' ... is that what you are saying? Ok, the language has both string literals and character literals, so how does that imply that '[' has two meanings? -- Derek Parnell Melbourne, Australia skype: derek.j.parnell
Re: with still sucks + removing features + adding features
On Tue, 19 May 2009 18:23:25 +1000, Derek Parnell de...@psych.ward wrote: On Mon, 18 May 2009 21:30:41 -0700, Bill Baxter wrote: On Mon, May 18, 2009 at 9:17 PM, Derek Parnell de...@psych.ward wrote: On Mon, 18 May 2009 23:02:37 -0500, Andrei Alexandrescu wrote: Derek Parnell wrote: On Mon, 18 May 2009 21:47:01 -0500, Andrei Alexandrescu wrote: Derek Parnell wrote: On Mon, 18 May 2009 19:31:23 -0500, Andrei Alexandrescu wrote: I completely disagree that that's a special case. .. is punctuation. You can't pretend punctuation has the same meaning everywhere in a programming language. I'm a bit confused. Are you saying that one must expect that the meaning of punctuation in a programming language depends on the context the punctuation is found in? How many meanings does '[' have in your favorite programming language? One. No. But you never asked for the name of my favourite language? Does it have string or character literals? Then there's probably at least two meanings. ;-P Huh? two meanings of '[' ... is that what you are saying? Ok, the language has both string literals and character literals, so how does that imply that '[' has two meanings? In D, [ has at least four meanings: auto a = [1, 2, 3]; - array initializer a[1] - indexing operator a[c..d] - slicing operator int[10] - static array declarator C++ has [] for lambdas (no! C++ should be banned by the international law, if there is any)
Re: Switch
On Tue, 19 May 2009 06:39:23 +0400, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
Georg Wrede wrote:
bearophile wrote:
void classify(char c) {
write(You passed );
switch (c) {
case '#':
writeln(a hash sign.);
break;
case '0' .. '9':
writeln(a digit.);
break;
case 'A' .. 'Z', 'a' .. 'z':
writeln(an ASCII character.);
break;
case '.', ',', ':', ';', '!', '?':
writeln(a punctuation mark.);
break;
default:
writeln(quite a character!);
break;
}
}
(A bunch of other versions omitted.)...
void classify(char c) {
write(You passed );
switch (c) {
case '#':
writeln(a hash sign.);
break;
case '0' .. case '9':
writeln(a digit.);
break;
case 'A' .. case 'Z':
case 'a' .. case 'z':
writeln(an ASCII character.);
break;
case '.', ',', ':', ';', '!', '?':
writeln(a punctuation mark.);
break;
default:
writeln(quite a character!);
break;
}
}
This is usable, easy to read -- and the programmer has no problem to
remember that .. works differently in case statements than in ranges.
I'd like to keep the (non-required) colon after the first expression in
a .. pair of case labels, that is:
case '0': .. case '9':
as opposed to
case '0' .. case '9':
That way it is abundantly clear that the notation has nothing in common
with expression1 .. expression2. The error message if someone forgot the
':' can easily be made clear.
Andrei
Will it be possible to write like this?
void classify(char c) {
write(You passed );
switch (c) {
case '0':
..
case '9':
writeln(a digit.);
break;
case 'A':
..
case 'Z':
writeln(upper case ASCII character.);
break;
case 'a':
..
case 'z':
writeln(lower case ASCII character.);
break;
case '.', ',', ':', ';', '!', '?':
writeln(a punctuation mark.);
break;
default:
writeln(quite a character!);
break;
}
}
Looks cool!
Re: The Final(ize) Challenge
Jarrett Billingsley wrote: On Mon, May 18, 2009 at 1:57 PM, Jarrett Billingsley jarrett.billings...@gmail.com wrote: On Mon, May 18, 2009 at 1:56 PM, Bill Baxter wbax...@gmail.com wrote: When did templated constructors start being allowed?! I see nothing about it in the change log. I was about to say the same thing. It doesn't work. Let me guess: 2.031. :P It's hardly fair to issue a challenge which can only be completed [1] with an unreleased compiler only you have seen. Actually, that *still* isn't going to cut it: it won't handle ref or out arguments correctly. I'm not sure what it'd do with scope. We *really* need to come up with a sane solution to generalising on storage class. Every time I have to generate functions, they make my life a complete pain in the arse. The only solution I've found is this hideous hack that parses ParameterTuple!(T).stringof and builds an array of enums... yech. ... and yeah, when were you gonna tell us about templated ctors?! -- Daniel [1] Qualification because I know if I don't, I'll regret it: I'm assuming the next compiler does support templated ctors (as otherwise your it's easy statement is bogus) and that this is the only way of solving the problem (I can't think of any other way of doing it.)
Re: The Final(ize) Challenge
Ary Borenszweig wrote: Jarrett Billingsley wrote: ... For the love of all that is holy, can we PLEASE get something like __ident(blah)? This would be so much easier and would probably drastically reduce my use of string mixins in general. Better __traits(ident, blah)? That'd only make sense if it was interrogative; it's constructive. -- Daniel
Re: While we're lynching features, how bout' them omittable parens?
Nick Sabalausky wrote:
D leaves the function/property distinction up to the caller, which is
rediculous because in most cases only one or the other actually makes sense.
I totally agree with this.
C# places the responsilibily for that function-syntax/property-syntax choice
on the callee instead, where it belongs.
C#'s properties are a bit syntax-heavy for my taste. I'd be happy with
this:
class C {
void set_x(int);
int get_x();
int f();
int y;
}
C c;
int i = c.get_x(); // Obviously allowed.
i = c.x; // Short for 'c.get_x()'.
c.x = i; // Short for 'c.set_x(i)'.
i = c.get_y(); // Even this is allowed.
c.set_y(i); // And this.
//i = c.x(); // But not this.
//i = c.f; // And not this.
This would still leave choice of syntax on the caller side, but it would
remove the ambiguity between method calls and properties. 'c.get_x()'
is clearly trying to read a property and 'c.set_x(i)' is clearly trying
to set a property, even if they use method call syntax.
Unfortunately, this doesn't mesh well with the camelCase capitalization
style. I'm not fond of camelCase in the first place, but camelCase
seems to be so entrenched in the D culture that there is no hope of ever
removing it.
--
Rainer Deyke - rain...@eldwood.com
Re: While we're lynching features, how bout' them omittable parens?
On Tue, 19 May 2009 05:53:06 +0400, Nick Sabalausky a...@a.a wrote: Chad J chadj...@__spam.is.bad__gmail.com wrote in message news:gut1od$l5...@digitalmars.com... Lionello Lunesu wrote: Chad J chadj...@__spam.is.bad__gmail.com 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. Absolutely agree! Most importantly, if we won't be get rid of them right now (before TDPL is out and D2 stabilized), we will have to wait for it to happen until at least D3.
Re: with still sucks + removing features + adding features
Derek Parnell wrote: On Mon, 18 May 2009 19:24:13 -0400, bearophile wrote: Christopher Wright: The more common suggestion is: alias bar = foo; This is acceptable, thank you :-) Now I'd like to know what others think about that. But does that mean 'when I write bar I really mean foo' or visa versa? Just pointing out that the '=' sign doesn't really automatically make it fully intuitive. It would work like assignments and renamed imports. Since when did you make an assignment in D where the right hand side was modified according to the value of the left hand side? It's not immediately obvious to someone who hasn't programmed yet, necessarily, but to someone even vaguely familiar with any modern programming language, there is one obvious meaning.
Re: OT: on IDEs and code writing on steroids
Frits van Bommel escribió: Ary Borenszweig wrote: Frits van Bommel wrote: Jacob Carlborg wrote: Daniel Keep wrote: Actually, Descent isn't perfect, either. For example, it mandates that cases in a switch MUST be aligned with the braces. What's more fun is that you can't override it until AFTER it's corrected YOU. Just file a ticket. The relevant ticket[1] is a year old, according to dsource... [1]: At least I *think* he's talking about this: http://dsource.org/projects/descent/ticket/82 Well, I didn't know it was *that* important for using it. If you consider it really important, post something in the forums, reply to that ticket, or something like that. Why would I reply to it? I *wrote* it. LOL!
Re: with still sucks + removing features + adding features
Andrei Alexandrescu wrote: bearophile wrote: Andrei Alexandrescu: Thank you for bringing a real example that gives something to work on. Awful! Well, one of your cases was wrong. Using the +1 at the end one of those cases become: case 'A' .. 'Z'+1, 'a' .. 'z'+1: Instead of what you have written: case 'A' .. 'Z'+1: case 'a' .. 'z'+1: I agree that that syntax with +1 isn't very nice looking. But the advantage of +1 is that it introduces (almost) no new syntax, it's not easy to miss, its meaning is easy to understand. AND you don't have to remember that in a case the .. is inclusive while in foreach is exclusive on the right, keeping the standard way in D to denote ranges. You don't understand. My point is not that people will dislike 'Z'+1. They will FORGET TO WRITE THE BLESSED +1. They'll write: case 'A' .. 'Z': You know, Ruby solves this by introducing a “seperate” range syntax for exclusive ranges: “...”. An inclusive range is written the same as an exclusive range in D: “..”. a[1 .. 2].length #= 1 ([a[1]]) a[1 ... 2].length #= 2 ([a[1], a[2]]) I see no reason not to include such a seperate syntax in D. “..” being exclusive and “...” being inclusive, not the other way round as in Ruby — see “Programmer’s Paradox” @ http://www.programmersparadox.com/2009/01/11/ruby-range-mnemonic/ . Kind regards, Alex
Class.classinfo.name and Class.stringof
There are two ways to get class name as string; Class.classinfo.name and Class.stringof. I have tried to use class names as string for conditional codes, instead of dynamic casts, if- and switch-statements, associative arrays, or something. Then I bumped into a problem. Class.classinfo.name returns class name with full module names. On the contrary, Class.stringof returns without module name. They returns different string for the same class. This means there is no way to compare class names determined in compile-time and runtime. A) Make Class.classinfo to be invariant (leave object.classinfo as runtime at the same time). Then we are able to get same string for a class in both compile-time and runtime. I think this might be a better solution. B) Append full module names to Class.stringof. This will cause destructive change.
Re: with still sucks + removing features + adding features
Max Samukha wrote: ... In D, [ has at least four meanings: auto a = [1, 2, 3]; - array initializer a[1] - indexing operator a[c..d] - slicing operator int[10] - static array declarator C++ has [] for lambdas (no! C++ should be banned by the international law, if there is any) Actually, it's more like two. a[1] int[] int[10] a[c..d] These are all subscript notation. [1, 2, 3] [a:b, c:d] These are array literal notation. From a strict, semantics nazi point of view, that's really six meanings. But that's like arguing there's a meaningful difference between a.b and A.b where a is a value and A is a type. It's worth noting that I still sometimes forget that [...] is for array literals, but I never ever forget its use for subscripting. -- Daniel
Re: with still sucks + removing features + adding features
Nick Sabalausky wrote: Andrei Alexandrescu seewebsiteforem...@erdani.org wrote in message news:gutd12$16h...@digitalmars.com... Let me make a separate point. With ..., people just defined the space operator. What's the space operator? Changes the meaning of 0...10 in two distinct ways: 0...10 is an all-inclusive integer range from 0 to 10 0. ..10 is a right-open floating-point range from 0 to 10 0.. .10 is a right-open floating-point range from 0 to 0.1 So '1.' and '.1' are legal numbers in D? I would have assumed that any numerical literal with a decimal point would require at least one digit on both sides of the decimal point. Not sure I see a good reason for this not to be required. Agreed. Saving ink in 1. versus 1.0 and .1 versus 0.1 is stupid -- even if we don't consider the new space operator implications!! It really makes it hard to spot the odd decimal value when you're not expecting it there. That's mainly an American invention. In Europe, in most countries, you couldn't ever write .1 without everybody shouting typo! Had D been invented in Europe, .1 would never have crossed anybodys mind. After several decades, I'm still uncomfortable when anybody writes .1, be it in programming or on street billboards. Then we could go on (not that Andrei ever meant it, so I'm not serious here), and write 1.0..2.0 an all-inclusive floating range from 1.0 to 2.0 1.0 ..2.0 a right-inclusive floating range from 1.0 to 2.0 1.0.. 2.0 a left-inclusive floating range from 1.0 to 2.0 1.0 .. 2.0 a non-inclusive floating range from 1.0 to 2.0 1..2 an all-inclusive integer range from 1 to 2 1 ..2 a right-inclusive integer range from 1 to 2 1.. 2 a left-inclusive integer range from 1 to 2 1 .. 2 a non-iclusive integer range from 1 to 2 (And we didn't even need the triple-dot operator!) But this would break existing code, make white-space significant, choke Andrei, pop Walter's ulcer, and generally be reminiscent of interpreted languages (read: embarrassing). (Not that whitespace isn't already significant in a way, otherwise we could write 1 . 2 and it would be the same thing as 1.2.) Actually, I'm not sure there would be ambuguity with the American decimals, either: 12 an all-inclusive range from 1. to .2 1. ...2 a right-inclusive range from 1. to .2 1... .2 a left-inclusive range from 1. to .2 1. .. .2 a non-inclusive range from 1. to .2 1...2 Error: improperly mixing integers and floating point. Note, I'm personally against having decimals in ranges in the first place.
Introspection - how?
Hello, guys! I have a question related D's introspection. I try to solve serialization task (implementing JSON protocol) and stuck at very start: getting all class' fields with types, names and values. Just test code: Thread d; foreach(mi; d.classinfo.getMembers(null)) 13: writefln(mi.name); test.d(13): Error: function object.MemberInfo.name () does not match parameter types () test.d(13): Error: mi.name can only be called on a mutable object, not const(MemberInfo) I'm confused with such strange error: what is a problem with using MemberInfo? I just try to GET info, not WRITE! Anybody have idea how to get info about members? (see task above) Thanks.
Re: with still sucks + removing features + adding features
Nick Sabalausky schrieb: Derek Parnell de...@psych.ward wrote in message news:2m4gnylh4ggc.1hhjynllwweim@40tude.net... On Mon, 18 May 2009 19:24:13 -0400, bearophile wrote: Christopher Wright: The more common suggestion is: alias bar = foo; This is acceptable, thank you :-) Now I'd like to know what others think about that. But does that mean 'when I write bar I really mean foo' or visa versa? Just pointing out that the '=' sign doesn't really automatically make it fully intuitive. It makes it consistent with auto foo = bar; which is a big improvement in intuitiveness. I would also welcome this change. Like someone here already mentioned it's also consistent with renaming imports, which has the same syntax. import io = std.stdio; Chris
Re: While we're lynching features, how bout' them omittable parens?
On Tue, 19 May 2009 00:29:17 -0400, Ary Borenszweig a...@esperanto.org.ar wrote: Jesse Phillips escribió: On Mon, 18 May 2009 21:53:06 -0400, Nick Sabalausky wrote: Chad J chadj...@__spam.is.bad__gmail.com wrote in message news:gut1od$l5...@digitalmars.com... Lionello Lunesu wrote: Chad J chadj...@__spam.is.bad__gmail.com 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. AFAIK, this is not enforced by the compiler... I write C# properties that have side effects. -Steve
Re: While we're lynching features, how bout' them omittable parens?
On Tue, May 19, 2009 at 1:15 AM, Nick Sabalausky a...@a.a wrote: Jesse Phillips jessekphill...@gmail.com wrote in message news:gutbro$14e...@digitalmars.com... On Mon, 18 May 2009 21:53:06 -0400, Nick Sabalausky wrote: 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. D leaves the function/property distinction up to the caller, which is rediculous because in most cases only one or the other actually makes sense. C# places the responsilibily for that function-syntax/property-syntax choice on the callee instead, where it belongs. D's approach is like saying You can index an array with 'myArray[5]' *or* 'myArray+5', and you can add two numbers with 'myInt+5' *or* 'myInt[5]'. or 5[myArray] even! (In C/C++ anyway). --bb
Re: While we're lynching features, how bout' them omittable parens?
Steven Schveighoffer, el 19 de mayo a las 09:54 me escribiste:
So for me, properties are way more than just syntax sugar.
AFAIK, this is not enforced by the compiler...
I write C# properties that have side effects.
Well, in D2 it would make sense to make mandatory that properties are pure
=)
I think the actual syntax is really nice and simple, the only thing
missing is a way to declare that you expect some function to be
a property.
Something like this should be enough for me:
class C
{
int no_prop() { return 1; }
property int prop() { return 2; }
}
C c = new C;
int x = c.no_prop; // error
x = x.prop; // ok
property should imply pure.
--
Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05)
Re: with should be deprecated with extreme prejudice
Andrei Alexandrescu wrote:
seewebsiteforem...@erdani.org wrote:
using(Foo x = new Foo()) {
// do stuff
}
It's basically equiv of
{
auto x = new Foo();
scope(exit) foo.Dispose;
// do stuff
}
That's not an equiv of. It's completely missing the point of. Each
using costs one new scope and one level of indentation which makes it
non-scalable. Indentation is *expensive*. I think the C# folks missed
the class when try/catch/finally showed with extensive examples just how
expensive extra indentation is.
You can mitigate this somewhat by realizing that multiple usings can be
wrapped into only one indentation level. Like:
using (Bar bar = new Bar())
using (Foo foo = new Foo())
using (Jim jim = new Jim())
{
//do something
}
--
Joel Lucsy
The dinosaurs became extinct because they didn't have a space program.
-- Larry Niven
Re: Introspection - how?
Vincent Wrote: Hello, guys! I have a question related D's introspection. I try to solve serialization task (implementing JSON protocol) and stuck at very start: getting all class' fields with types, names and values. Just test code: Thread d; foreach(mi; d.classinfo.getMembers(null)) 13: writefln(mi.name); test.d(13): Error: function object.MemberInfo.name () does not match parameter types () test.d(13): Error: mi.name can only be called on a mutable object, not const(MemberInfo) I'm confused with such strange error: what is a problem with using MemberInfo? I just try to GET info, not WRITE! Anybody have idea how to get info about members? (see task above) Thanks. We face related problem; classinfo mutability. my post is article_id=90722. I have noticed that classinfo relates core of D's class system. http://www.digitalmars.com/d/2.0/phobos/object.html A pointer to this appears as the first entry in the class's vtbl[]. It seems that this problem must be treated carefully.
Re: Introspection - how?
Vincent wrote: Hello, guys! I have a question related D's introspection. I try to solve serialization task (implementing JSON protocol) and stuck at very start: getting all class' fields with types, names and values. Just test code: Thread d; foreach(mi; d.classinfo.getMembers(null)) 13: writefln(mi.name); test.d(13): Error: function object.MemberInfo.name () does not match parameter types () test.d(13): Error: mi.name can only be called on a mutable object, not const(MemberInfo) I'm confused with such strange error: what is a problem with using MemberInfo? I just try to GET info, not WRITE! Anybody have idea how to get info about members? (see task above) Thanks. It doesn't matter; getMembers doesn't currently DO anything. Even if you cast away the const-ness, you'd get no results. You have to do this at compile-time with a concrete type for now. -- Daniel
Re: While we're lynching features, how bout' them omittable parens?
Leandro Lucarella wrote: Steven Schveighoffer, el 19 de mayo a las 09:54 me escribiste: So for me, properties are way more than just syntax sugar. AFAIK, this is not enforced by the compiler... I write C# properties that have side effects. Well, in D2 it would make sense to make mandatory that properties are pure =) I think that's a dangerous and unnecessarily limiting road to go down. I don't see any benefit from doing this. For example, this would make it impossible to implement a property that lazilly initialised its storage. -- Daniel
Re: with still sucks + removing features + adding features
On Tue, May 19, 2009 at 8:37 AM, Georg Wrede georg.wr...@iki.fi wrote: So '1.' and '.1' are legal numbers in D? I would have assumed that any numerical literal with a decimal point would require at least one digit on both sides of the decimal point. Not sure I see a good reason for this not to be required. Agreed. Saving ink in 1. versus 1.0 and .1 versus 0.1 is stupid -- even if we don't consider the new space operator implications!! It really makes it hard to spot the odd decimal value when you're not expecting it there. That's mainly an American invention. In Europe, in most countries, you couldn't ever write .1 without everybody shouting typo! Had D been invented in Europe, .1 would never have crossed anybodys mind. After several decades, I'm still uncomfortable when anybody writes .1, be it in programming or on street billboards. For what it's worth, I'm American and have neither seen the 'one-sided floating-point number' used in public nor am I comfortable with it being in a programming language. It just doesn't look right.
Re: While we're lynching features, how bout' them omittable parens?
On Tue, 19 May 2009 11:12:13 -0300, Leandro Lucarella wrote:
class C
{
int no_prop() { return 1; }
property int prop() { return 2; }
}
C c = new C;
int x = c.no_prop; // error
x = x.prop; // ok
property should imply pure.
I actually wouldn't have an issue with this. And if we could get the
benefit Ary pointed out, I'd say it would be worth it.
Re: OT: on IDEs and code writing on steroids
Yigal Chripun wrote: Rainer Deyke wrote: ... 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. Ummm... IIRC, an .a file is just an archive of .o files. A .lib file in Windows is something similar. If you want to support C libraries, you need to support the object file format as well. -- Daniel
Re: While we're lynching features, how bout' them omittable parens?
On Tue, May 19, 2009 at 10:12 AM, Leandro Lucarella llu...@gmail.com wrote: Steven Schveighoffer, el 19 de mayo a las 09:54 me escribiste: So for me, properties are way more than just syntax sugar. AFAIK, this is not enforced by the compiler... I write C# properties that have side effects. Well, in D2 it would make sense to make mandatory that properties are pure =) How the hell do you write a pure setter?
Re: Switch - Full Circle
http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.Darticle_id=81519
Re: The Final(ize) Challenge
Daniel Keep wrote: Jarrett Billingsley wrote: On Mon, May 18, 2009 at 1:57 PM, Jarrett Billingsley jarrett.billings...@gmail.com wrote: On Mon, May 18, 2009 at 1:56 PM, Bill Baxter wbax...@gmail.com wrote: When did templated constructors start being allowed?! I see nothing about it in the change log. I was about to say the same thing. It doesn't work. Let me guess: 2.031. :P It's hardly fair to issue a challenge which can only be completed [1] with an unreleased compiler only you have seen. I don't have 2.031 and I don't know whether it will fix the template constructor bug. Actually, that *still* isn't going to cut it: it won't handle ref or out arguments correctly. I'm not sure what it'd do with scope. We *really* need to come up with a sane solution to generalising on storage class. Every time I have to generate functions, they make my life a complete pain in the arse. The only solution I've found is this hideous hack that parses ParameterTuple!(T).stringof and builds an array of enums... yech. It's much easier to parse ParameterTuple!(T)[n].stringof. If it starts with ref /out then it's a ref/out. ... and yeah, when were you gonna tell us about templated ctors?! -- Daniel [1] Qualification because I know if I don't, I'll regret it: I'm assuming the next compiler does support templated ctors (as otherwise your it's easy statement is bogus) and that this is the only way of solving the problem (I can't think of any other way of doing it.) You could for now comment out the constructor and leave it until the bug is fixed. Andrei
Re: with still sucks + removing features + adding features
Jarrett Billingsley wrote: On Tue, May 19, 2009 at 8:37 AM, Georg Wrede georg.wr...@iki.fi wrote: So '1.' and '.1' are legal numbers in D? I would have assumed that any numerical literal with a decimal point would require at least one digit on both sides of the decimal point. Not sure I see a good reason for this not to be required. Agreed. Saving ink in 1. versus 1.0 and .1 versus 0.1 is stupid -- even if we don't consider the new space operator implications!! It really makes it hard to spot the odd decimal value when you're not expecting it there. That's mainly an American invention. In Europe, in most countries, you couldn't ever write .1 without everybody shouting typo! Had D been invented in Europe, .1 would never have crossed anybodys mind. After several decades, I'm still uncomfortable when anybody writes .1, be it in programming or on street billboards. For what it's worth, I'm American and have neither seen the 'one-sided floating-point number' used in public nor am I comfortable with it being in a programming language. It just doesn't look right. Yeah. If it was up to me, it'd be forbidden.
Re: OT: on IDEs and code writing on steroids
On Tue, 19 May 2009 08:56:59 +1200, BCS a...@pathlink.com wrote: VS/MS/etc is a for profit ecosystem. They assume that your system and software is paid for by your boss and he's spending 10-20 time that much on your paycheck so who cares. At least that's the impression I get. I think vs express editions that can be used to make great software, sell the software and not pay MS a single cent is very generous of them and the .net cil is a genious idea. The most succefull compilers are the ones that recognize that there is multiple languages, multiple archictectures and that there should be something in the middle. CIL just leaves it in the middle code until the last minute. MS may not do the best operating systems but the whole .net thing is very good in my opinion and I think sun is better for there solaris than there java.
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.
There are other places in D that place an undue burden on the
programmer, but this is not IMHO one of them.
My pet peeve with case is that, since we don't seem to be getting rid of
break (and use some word for fall-through instead, which would save a
good deal of ink), we should at least try to make break more
conspicuous. I can name a hundred times I've forgotten a break from
somewhere. So the canonical indentation should be like this:
void classify(char c) {
write(You passed );
switch (c) {
case '#':
writeln(a hash sign.);
break;
case '0' .. case '9':
writeln(a digit.);
break;
case 'A' .. case 'Z':
case 'a' .. case 'z':
writeln(an ASCII character.);
break;
case '.', ',', ':', ';', '!', '?':
writeln(a punctuation mark.);
break;
default:
writeln(quite a character!);
break;
}
}
(It'd look better when the cases have more lines, but still.) Currently
in D, break is at least as important as case, therefore it deserves a
conspicuous place, hence my suggestion.
Full Circle...
http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.Darticle_id=81519
Re: with should be deprecated with extreme prejudice
Joel Lucsy wrote:
Andrei Alexandrescu wrote:
seewebsiteforem...@erdani.org wrote:
using(Foo x = new Foo()) {
// do stuff
}
It's basically equiv of
{
auto x = new Foo();
scope(exit) foo.Dispose;
// do stuff
}
That's not an equiv of. It's completely missing the point of. Each
using costs one new scope and one level of indentation which makes
it non-scalable. Indentation is *expensive*. I think the C# folks
missed the class when try/catch/finally showed with extensive examples
just how expensive extra indentation is.
You can mitigate this somewhat by realizing that multiple usings can be
wrapped into only one indentation level. Like:
using (Bar bar = new Bar())
using (Foo foo = new Foo())
using (Jim jim = new Jim())
{
//do something
}
Thanks, that's a good point.
(It's a limited option, though. My code uses scope() statements to do
things transactionally (e.g. search Phobos for scope) and the pattern
sometimes is to do some work, plant a scope(), then do some work, plan
another, etc. This would be difficult with using().)
Andrei
Re: with still sucks + removing features + adding features
Georg Wrede wrote: Jarrett Billingsley wrote: On Tue, May 19, 2009 at 8:37 AM, Georg Wrede georg.wr...@iki.fi wrote: After several decades, I'm still uncomfortable when anybody writes .1, be it in programming or on street billboards. For what it's worth, I'm American and have neither seen the 'one-sided floating-point number' used in public nor am I comfortable with it being in a programming language. It just doesn't look right. Yeah. If it was up to me, it'd be forbidden. Same here.
Re: OT: on IDEs and code writing on steroids
and the .net cil is a genious idea. The most succefull compilers are the ones that recognize that there is multiple languages, multiple archictectures and that there should be something in the middle. CIL just leaves it in the middle code until the last minute. MS may not do the best operating systems but the whole .net thing is very good in my And what exactly is good about byte code? It's portable? My D code is portable too. Sure, it requires recompilation, but it doesn't need a clusterfuck-VM just for running it. opinion and I think sun is better for there solaris than there java. .Net is just Microsoft's Java clone, and Sun didn't invent byte code either.
Re: While we're lynching features, how bout' them omittable parens?
On Tue, 19 May 2009 10:12:13 -0400, Leandro Lucarella llu...@gmail.com
wrote:
Steven Schveighoffer, el 19 de mayo a las 09:54 me escribiste:
So for me, properties are way more than just syntax sugar.
AFAIK, this is not enforced by the compiler...
I write C# properties that have side effects.
Well, in D2 it would make sense to make mandatory that properties are
pure
=)
I think the actual syntax is really nice and simple, the only thing
missing is a way to declare that you expect some function to be
a property.
Something like this should be enough for me:
class C
{
int no_prop() { return 1; }
property int prop() { return 2; }
}
C c = new C;
int x = c.no_prop; // error
x = x.prop; // ok
property should imply pure.
As Jarrett said, a pure setter is impossible. But, having pure getters
even seems like an unnecessary limitation.
Having setting and getting grouped together would be nice to me (for
documentation/lookup reasons), but not necessary. As long as there's a
way to denote property versus function, the scheme works.
-Steve
Re: with still sucks + removing features + adding features
Alexander Pánek: Same here. I too don't like .56, I add a zero when I see a literal like that in the code. But what about Walter? :-) Bye, bearophile
Re: While we're lynching features, how bout' them omittable parens?
Steven Schveighoffer wrote: On Tue, 19 May 2009 00:29:17 -0400, Ary Borenszweig a...@esperanto.org.ar wrote: Jesse Phillips escribió: On Mon, 18 May 2009 21:53:06 -0400, Nick Sabalausky wrote: Chad J chadj...@__spam.is.bad__gmail.com wrote in message news:gut1od$l5...@digitalmars.com... Lionello Lunesu wrote: Chad J chadj...@__spam.is.bad__gmail.com 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. AFAIK, this is not enforced by the compiler... I write C# properties that have side effects. That's what I said it's a contract on the semantic of properties. :) But now I'm curious: what kind of properties do you write?
Re: OT: on IDEs and code writing on steroids
Reply to Daniel, Yigal Chripun wrote: 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. Maybe you should back up your statements instead of just guessing. http://www.scons.org/wiki/CsharpBuilder Oh look, you have to list all the source files because C# source files *do not contain enough information*. A C# source file containing using Foo.Bar; tells you exactly ZERO about what other files it depends on. -- Daniel Exactly. The only practical way to deal with C# is an IDE or build system of some kind that is aware of C#. You /can/ deal with it by hand but IMHO that would be about half way from D to using C without even a make file or build script.
Re: While we're lynching features, how bout' them omittable parens?
Leandro Lucarella wrote:
Steven Schveighoffer, el 19 de mayo a las 09:54 me escribiste:
So for me, properties are way more than just syntax sugar.
AFAIK, this is not enforced by the compiler...
I write C# properties that have side effects.
Well, in D2 it would make sense to make mandatory that properties are pure
=)
I think the actual syntax is really nice and simple, the only thing
missing is a way to declare that you expect some function to be
a property.
Something like this should be enough for me:
class C
{
int no_prop() { return 1; }
property int prop() { return 2; }
}
C c = new C;
int x = c.no_prop; // error
x = x.prop; // ok
property should imply pure.
Well, maybe with pure I made a bad choice. The thing is that the
instance doesn't seem to change from the outside, from the callee side,
but from the inside it might cache something or lazily compute it. But
yes, pure wouldn't work here.
Re: OT: on IDEs and code writing on steroids
Reply to Lutger, BCS wrote: ... all LINQ is is a set of standard nameing conventions and sugar. I Add a Where function to some SQL tabel object and you get the above as well. ... Not really, LINQ is 'sugar' for the underlying libraries that As far as language features go, I'm even less impressed with sugar for libraries. implements querying. Instead of calling it just sugar, it is more proper to call it a language in it's own right. I still don't think it's anything to spectacular. The AST stuff on the other hand...
Re: with still sucks + removing features + adding features
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 bearophile wrote: Alexander Pánek: Same here. I too don't like .56, I add a zero when I see a literal like that in the code. But what about Walter? :-) Bye, bearophile I always use it, but I won't be bothered if it was outlawed. - -- My enormous talent is exceeded only by my outrageous laziness. http://www.ssTk.co.uk -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFKEvG/T9LetA9XoXwRAkIaAKCdqOLBL9X+KwRm/vAmtoxVR4KXCQCeOaQt Tsgo4JIuNIfP9UgiTaMLLtM= =eo39 -END PGP SIGNATURE-
Re: with still sucks + removing features + adding features
On Tue, May 19, 2009 at 10:51 AM, div0 d...@users.sourceforge.net wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 bearophile wrote: Alexander Pánek: Same here. I too don't like .56, I add a zero when I see a literal like that in the code. But what about Walter? :-) Bye, bearophile I always use it, but I won't be bothered if it was outlawed. I use it too. Looks fine to me. I also use the 3.f form on occasion to get an integral float. --bb
Re: While we're lynching features, how bout' them omittable parens?
Jarrett Billingsley, el 19 de mayo a las 11:31 me escribiste: On Tue, May 19, 2009 at 10:12 AM, Leandro Lucarella llu...@gmail.com wrote: Steven Schveighoffer, el 19 de mayo a las 09:54 me escribiste: So for me, properties are way more than just syntax sugar. AFAIK, this is not enforced by the compiler... I write C# properties that have side effects. Well, in D2 it would make sense to make mandatory that properties are pure =) How the hell do you write a pure setter? Ok, almost pure =P You should be able to modify this, of course. BTW, I'm not convinced about it yet, it just looked like something to think about. There is definitely a side of having a contract that a property can't do nasty things that I like, but I'm not convinced that it worth the lost in flexibility. For example, I like ORMs in Python that makes black magic behind the scene to get stuff lazily from the DB. -- Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/ GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05)
Re: While we're lynching features, how bout' them omittable parens?
How the hell do you write a pure setter? Ok, almost pure =P You should be able to modify this, of course. Properties could be automatically marked as const. Then a setter would not be allowed to change anything, except members explicitly marked with a mutable attribute. Oh wait, that doesn't make any sense.
Re: Switch - Full Circle
On one page: http://www.digitalmars.com/d/archives/digitalmars/D/Improvement_to_switch-case_statement_81519.html
Re: While we're lynching features, how bout' them omittable parens?
On Tue, 19 May 2009 13:32:35 -0400, Ary Borenszweig a...@esperanto.org.ar wrote: Steven Schveighoffer wrote: On Tue, 19 May 2009 00:29:17 -0400, Ary Borenszweig a...@esperanto.org.ar wrote: Jesse Phillips escribió: On Mon, 18 May 2009 21:53:06 -0400, Nick Sabalausky wrote: Chad J chadj...@__spam.is.bad__gmail.com wrote in message news:gut1od$l5...@digitalmars.com... Lionello Lunesu wrote: Chad J chadj...@__spam.is.bad__gmail.com 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. AFAIK, this is not enforced by the compiler... I write C# properties that have side effects. That's what I said it's a contract on the semantic of properties. :) But now I'm curious: what kind of properties do you write? Not all the properties I write have side effects :) Most are simply virtual data members. One I just wrote recently is something that returns a unique ID (which changes the next time you access it). I'm unsure what would happen if you read the property during debugging... I suppose I could have made this a function instead, but my point is, if the compiler doesn't enforce it, you can't really rely on the contract. -Steve
Re: with still sucks + removing features + adding features
Alexander Pánek schrieb: Andrei Alexandrescu wrote: bearophile wrote: Andrei Alexandrescu: Thank you for bringing a real example that gives something to work on. Awful! Well, one of your cases was wrong. Using the +1 at the end one of those cases become: case 'A' .. 'Z'+1, 'a' .. 'z'+1: Instead of what you have written: case 'A' .. 'Z'+1: case 'a' .. 'z'+1: I agree that that syntax with +1 isn't very nice looking. But the advantage of +1 is that it introduces (almost) no new syntax, it's not easy to miss, its meaning is easy to understand. AND you don't have to remember that in a case the .. is inclusive while in foreach is exclusive on the right, keeping the standard way in D to denote ranges. You don't understand. My point is not that people will dislike 'Z'+1. They will FORGET TO WRITE THE BLESSED +1. They'll write: case 'A' .. 'Z': You know, Ruby solves this by introducing a “seperate” range syntax for exclusive ranges: “...”. An inclusive range is written the same as an exclusive range in D: “..”. a[1 .. 2].length #= 1 ([a[1]]) a[1 ... 2].length #= 2 ([a[1], a[2]]) I see no reason not to include such a seperate syntax in D. “..” being exclusive and “...” being inclusive, not the other way round as in Ruby — see “Programmer’s Paradox” @ http://www.programmersparadox.com/2009/01/11/ruby-range-mnemonic/ . Kind regards, Alex Yes, this is useful for all use cases of ranges. I like '...'.
Re: with still sucks + removing features + adding features
Georg Wrede georg.wr...@iki.fi wrote in message news:guu95i$2p6...@digitalmars.com... That's mainly an American invention. In Europe, in most countries, you couldn't ever write .1 without everybody shouting typo! *shrug*, I've lived in the US all my life and it's never occurred to me to consider .1 anything but a typo (or at least laziness). Then we could go on (not that Andrei ever meant it, so I'm not serious here), and write 1.0..2.0 an all-inclusive floating range from 1.0 to 2.0 1.0 ..2.0 a right-inclusive floating range from 1.0 to 2.0 1.0.. 2.0 a left-inclusive floating range from 1.0 to 2.0 1.0 .. 2.0 a non-inclusive floating range from 1.0 to 2.0 1..2 an all-inclusive integer range from 1 to 2 1 ..2 a right-inclusive integer range from 1 to 2 1.. 2 a left-inclusive integer range from 1 to 2 1 .. 2 a non-iclusive integer range from 1 to 2 (And we didn't even need the triple-dot operator!) But this would break existing code, make white-space significant, choke Andrei, pop Walter's ulcer, and generally be reminiscent of interpreted languages (read: embarrassing). Hee hee hee :) (Not that whitespace isn't already significant in a way, otherwise we could write 1 . 2 and it would be the same thing as 1.2.) Or int foo vs intfoo.
Re: While we're lynching features, how bout' them omittable parens?
Reply to Ary, Steven Schveighoffer wrote: On Tue, 19 May 2009 00:29:17 -0400, Ary Borenszweig a...@esperanto.org.ar wrote: Jesse Phillips escribió: On Mon, 18 May 2009 21:53:06 -0400, Nick Sabalausky wrote: Chad J chadj...@__spam.is.bad__gmail.com wrote in message news:gut1od$l5...@digitalmars.com... Lionello Lunesu wrote: Chad J chadj...@__spam.is.bad__gmail.com 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). AFAIK, this is not enforced by the compiler... I write C# properties that have side effects. That's what I said it's a contract on the semantic of properties. :) But now I'm curious: what kind of properties do you write? You can have side effects, but it makes the code darn near impossible to debug. I've been there and don't plan on going back!
Re: with still sucks + removing features + adding features
Frank Benoit wrote: Alexander Pánek schrieb: Andrei Alexandrescu wrote: bearophile wrote: Andrei Alexandrescu: Thank you for bringing a real example that gives something to work on. Awful! Well, one of your cases was wrong. Using the +1 at the end one of those cases become: case 'A' .. 'Z'+1, 'a' .. 'z'+1: Instead of what you have written: case 'A' .. 'Z'+1: case 'a' .. 'z'+1: I agree that that syntax with +1 isn't very nice looking. But the advantage of +1 is that it introduces (almost) no new syntax, it's not easy to miss, its meaning is easy to understand. AND you don't have to remember that in a case the .. is inclusive while in foreach is exclusive on the right, keeping the standard way in D to denote ranges. You don't understand. My point is not that people will dislike 'Z'+1. They will FORGET TO WRITE THE BLESSED +1. They'll write: case 'A' .. 'Z': You know, Ruby solves this by introducing a “seperate” range syntax for exclusive ranges: “...”. An inclusive range is written the same as an exclusive range in D: “..”. a[1 .. 2].length #= 1 ([a[1]]) a[1 ... 2].length #= 2 ([a[1], a[2]]) I see no reason not to include such a seperate syntax in D. “..” being exclusive and “...” being inclusive, not the other way round as in Ruby — see “Programmer’s Paradox” @ http://www.programmersparadox.com/2009/01/11/ruby-range-mnemonic/ . Kind regards, Alex Yes, this is useful for all use cases of ranges. I like '...'. Indeed it's not a bad idea... But it might be easily mistyped, lead to strange off-by-one errors and be very difficult to find while debugging them. Hmmm...
Re: OT: on IDEs and code writing on steroids
BCS wrote: Reply to Daniel, Yigal Chripun wrote: 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. Maybe you should back up your statements instead of just guessing. http://www.scons.org/wiki/CsharpBuilder Oh look, you have to list all the source files because C# source files *do not contain enough information*. A C# source file containing using Foo.Bar; tells you exactly ZERO about what other files it depends on. -- Daniel Exactly. The only practical way to deal with C# is an IDE or build system of some kind that is aware of C#. You /can/ deal with it by hand but IMHO that would be about half way from D to using C without even a make file or build script. first, thanks Daniel for the evidence I missed. BCS wrote that a programmer needs to compile all the source files at once to make it work without an IDE. as I already said, he's wrong, and Daniel provided the proof above. sure, you don't get the full power of an IDE that can track all the source files in the project for you. That just means that it's worth the money you pay for it. you can write makefiles or what ever (scons, rake, ant, ...) in the same way you'd do for C and C++. In other words: if you prefer commnad line tools you get the same experience and if you do use an IDE you get a *much* better experience. same goes for D - either write your own makefile or use rebuild which uses the compiler front-end to parse the source files just like you suggested above for C#. where in all of that, do you see any contradiction to what I said? again, I said the D compilation model is ancient legacy and should be replaced and that has nothing to do with the format you prefer for your build scripts.
Re: with still sucks + removing features + adding features
Robert Fraser wrote: Frank Benoit wrote: Alexander Pánek schrieb: Andrei Alexandrescu wrote: bearophile wrote: Andrei Alexandrescu: Thank you for bringing a real example that gives something to work on. Awful! Well, one of your cases was wrong. Using the +1 at the end one of those cases become: case 'A' .. 'Z'+1, 'a' .. 'z'+1: Instead of what you have written: case 'A' .. 'Z'+1: case 'a' .. 'z'+1: I agree that that syntax with +1 isn't very nice looking. But the advantage of +1 is that it introduces (almost) no new syntax, it's not easy to miss, its meaning is easy to understand. AND you don't have to remember that in a case the .. is inclusive while in foreach is exclusive on the right, keeping the standard way in D to denote ranges. You don't understand. My point is not that people will dislike 'Z'+1. They will FORGET TO WRITE THE BLESSED +1. They'll write: case 'A' .. 'Z': You know, Ruby solves this by introducing a “seperate” range syntax for exclusive ranges: “...”. An inclusive range is written the same as an exclusive range in D: “..”. a[1 .. 2].length #= 1 ([a[1]]) a[1 ... 2].length #= 2 ([a[1], a[2]]) I see no reason not to include such a seperate syntax in D. “..” being exclusive and “...” being inclusive, not the other way round as in Ruby — see “Programmer’s Paradox” @ http://www.programmersparadox.com/2009/01/11/ruby-range-mnemonic/ . Kind regards, Alex Yes, this is useful for all use cases of ranges. I like '...'. Indeed it's not a bad idea... But it might be easily mistyped, lead to strange off-by-one errors and be very difficult to find while debugging them. Hmmm... It's an awful idea. It's a non-idea. If idea had an antonym, that would be it. I can't fathom what's on the mind of a person (not you, at least you foresee some potential problems) who, even after patiently explained the issues with this mental misfire, several times, still can bring themselves to think it's not that bad. Let me add one more, although more than sure someone will find a remedy for it, too. a...b vs. a.. .b and of course the beauty ab I don't plan to discuss minor features on this group anymore. Andrei
Re: with still sucks + removing features + adding features
On Tue, May 19, 2009 at 4:43 PM, Andrei Alexandrescu It's an awful idea. It's a non-idea. If idea had an antonym, that would be it. I can't fathom what's on the mind of a person (not you, at least you foresee some potential problems) who, even after patiently explained the issues with this mental misfire, several times, still can bring themselves to think it's not that bad. Let me add one more, although more than sure someone will find a remedy for it, too. a...b vs. a.. .b and of course the beauty ab I don't plan to discuss minor features on this group anymore. Maybe if you weren't prone to such humorous bouts of hyperbole, you wouldn't get your blood boiling so easily. This is the internet, and we're talking about programming languages. It's not like we're defusing a tense international arms conflict or something.
Re: with still sucks + removing features + adding features
On Tue, May 19, 2009 at 4:47 PM, Jarrett Billingsley jarrett.billings...@gmail.com wrote: On Tue, May 19, 2009 at 4:43 PM, Andrei Alexandrescu It's an awful idea. It's a non-idea. If idea had an antonym, that would be it. I can't fathom what's on the mind of a person (not you, at least you foresee some potential problems) who, even after patiently explained the issues with this mental misfire, several times, still can bring themselves to think it's not that bad. Let me add one more, although more than sure someone will find a remedy for it, too. a...b vs. a.. .b and of course the beauty ab I don't plan to discuss minor features on this group anymore. Maybe if you weren't prone to such humorous bouts of hyperbole, you wouldn't get your blood boiling so easily. This is the internet, and we're talking about programming languages. It's not like we're defusing a tense international arms conflict or something. Also, why does the puremagic mailing list software hate me so much when it comes to threading my replies?
Re: OT: on IDEs and code writing on steroids
Reply to Yigal, BCS wrote: Reply to Daniel, Yigal Chripun wrote: 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. Maybe you should back up your statements instead of just guessing. http://www.scons.org/wiki/CsharpBuilder Oh look, you have to list all the source files because C# source files *do not contain enough information*. A C# source file containing using Foo.Bar; tells you exactly ZERO about what other files it depends on. -- Daniel Exactly. The only practical way to deal with C# is an IDE or build system of some kind that is aware of C#. You /can/ deal with it by hand but IMHO that would be about half way from D to using C without even a make file or build script. first, thanks Daniel for the evidence I missed. BCS wrote that a programmer needs to compile all the source files at once to make it work without an IDE. as I already said, he's wrong, and Daniel provided the proof above. minor point; I said you have to give the compiler all the source files. You might not actually nned to compile them all, but without some external meta data, it still needs to be handled the full because it can't find them on it's own. And at that point you might as well compile them anyway. sure, you don't get the full power of an IDE that can track all the source files in the project for you. That just means that it's worth the money you pay for it. you can write makefiles or what ever (scons, rake, ant, ...) in the same way you'd do for C and C++. In other words: if you prefer commnad line tools you get the same experience and if you do use an IDE you get a *much* better experience. same goes for D - either write your own makefile or use rebuild which uses the compiler front-end to parse the source files just like you suggested above for C#. where did I suggest that? where in all of that, do you see any contradiction to what I said? again, I said the D compilation model is ancient legacy and should be replaced and that has nothing to do with the format you prefer for your build scripts. I think that you think I'm saying something other than what I'm trying to say. I'm struggling to make my argument clear but can't seem to put it in words. My thesis is that, in effect, C# is married to VS and that D is married only to the compiler. My argument is that a D project can be done as nothing but a collection of .d files with no extra project files of any kind. In c# this is theoretically possible, but from any practical standpoint it's not going to be done. There is going to be some extra files that list, in some form, extra information the compiler needs to resolve symbols and figure out where to look for stuff. In any practical environment this extra bit that c# more or less forces you to have (and the D doesn't) will be maintain by some sort of IDE. To put it quantitatively: productivity on a scale of 0 to whatever c# w/o IDE - ~1 D w/o IDE - 10 c# w/ IDE - 100+ D w/ IDE - 100+ Either C# or D will be lots more productive with an IDE but D without an IDE will be lots more productive than C# without an IDE. D is designed to be used however you want, IDE or not. C# is *designed* to be used from within VS. I rather suspect that the usability of C# without VS is very low on MS things we care about list.
Re: with still sucks + removing features + adding features
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jarrett Billingsley wrote: On Tue, May 19, 2009 at 4:47 PM, Jarrett Billingsley jarrett.billings...@gmail.com wrote: On Tue, May 19, 2009 at 4:43 PM, Andrei Alexandrescu It's an awful idea. It's a non-idea. If idea had an antonym, that would be it. I can't fathom what's on the mind of a person (not you, at least you foresee some potential problems) who, even after patiently explained the issues with this mental misfire, several times, still can bring themselves to think it's not that bad. Let me add one more, although more than sure someone will find a remedy for it, too. a...b vs. a.. .b and of course the beauty ab I don't plan to discuss minor features on this group anymore. Maybe if you weren't prone to such humorous bouts of hyperbole, you wouldn't get your blood boiling so easily. This is the internet, and we're talking about programming languages. It's not like we're defusing a tense international arms conflict or something. Also, why does the puremagic mailing list software hate me so much when it comes to threading my replies? You're probably breaching some volume of posts limit. ;) Thunderbird works nice. - -- My enormous talent is exceeded only by my outrageous laziness. http://www.ssTk.co.uk -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFKEybQT9LetA9XoXwRAkDXAKCo9PS0+GRCCyZibMe3WcbiZo5HlgCeMp92 fUcS3bLFqSaQ/Pk8KKVNzJM= =k/lq -END PGP SIGNATURE-
Re: with still sucks + removing features + adding features
Andrei Alexandrescu: I don't plan to discuss minor features on this group anymore. In about two years I've never heard Walter say something like that (even if may think similar things every day), he doesn't need a pedestal. Thank you, bearophile
Re: project oriented
davidl wrote: The module package system still stays in the state of the C age. It's file oriented. I think there's no more sound package system than C# one. The namespace and distributed packaging is a must nowadays and the compiler should be project oriented and take project information as the compiling base. Also an IDE is quite useful for providing project templates. The file system is a wonderful hierarchical database, that fits in neatly with package/module organization of D projects. I don't see a compelling advantage to try to layer another database on top of it.
Re: While we're lynching features, how bout' them omittable parens?
Robert Fraser wrote:
Chad J wrote:
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++;
}
Whatever solution to this is chosen *please* don't make get, set,
value or prop into keywords! in, out, body and shared used
to be common features of my coding style; I'm not sure it can take
another blow. As Andrei mentioned somewhere, keywords aren't cheap.
How about:
int x { setter, getter };
int setter();
void getter (int);
Where either one of the accessors may be null (or omitted):
int readonly { null, getter };
int writeonly { setter, null };
- It doesn't need a new keyword;
- It can't be confused with function declarations because those
need parentheses anyway;
- Ideally, the compiler would infer the type of the accessor from
its prototype (i.e if it doesn't take any arguments and returns T,
then it's the getter, if it takes a T and returns void then it's the
setter, otherwise it's an error).
Of course, this would *not* allocate any space in the class/struct.
Jerome
--
mailto:jeber...@free.fr
http://jeberger.free.fr
Jabber: jeber...@jabber.fr
signature.asc
Description: OpenPGP digital signature
Re: OT: on IDEs and code writing on steroids
Georg Wrede wrote: In the Good Old Days (when it was usual for an average programmer to write parts of the code in ASM (that was the time before the late eighties -- be it Basic, Pascal, or even C, some parts had to be done in ASM to help a bearable user experience when the mainframes had less power than today's MP3 players), the ASM programing was very different on, say, Zilog, MOS, or Motorola processors. The rumor was that the 6502 was made for hand coded ASM, whereas the 8088 was more geared towards automatic code generation (as in C commpilers, etc.). My experiences of both certainly seemed to support this. The 6502 is an 8 bit processor, the 8088 is 16 bits. All 8 bit processors were a terrible fit for C, which was designed for 16 bit CPUs. Everyone who coded professional apps for the 6502, 6800, 8080 and Z80 (all 8 bit CPUs) wrote in assembler. (Including myself.) If we were smart with D, we'd find out a way of leapfrogging this thinking. We have a language that's more powerful than any of C#, Java or C++, more practical than Haskell, Scheme, Ruby, co, and more maintainable than C or Perl, but which *still* is Human Writable. All we need is some outside-of-the-box thinking, and we might reap some overwhelming advantages when we combine *this* language with the IDEs and the horsepower that the modern drone takes for granted. Easier parsing, CTFE, actually usable templates, practical mixins, pure functions, safe code, you name it! We have all the bits and pieces to really make writing + IDE assisted program authoring, a superior reality. Right, but I can't think of any IDE feature that would be a bad fit for using the filesystem to store the D source modules.
Re: OT: on IDEs and code writing on steroids
Christopher Wright wrote: I really like IDEs. They let me think less when creating code. It wouldn't be hard to do a competent IDE for D. After all, D is designed to make that job easy.
Re: with still sucks + removing features + adding features
On Tue, May 19, 2009 at 5:38 PM, div0 d...@users.sourceforge.net wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jarrett Billingsley wrote: On Tue, May 19, 2009 at 4:47 PM, Jarrett Billingsley jarrett.billings...@gmail.com wrote: On Tue, May 19, 2009 at 4:43 PM, Andrei Alexandrescu It's an awful idea. It's a non-idea. If idea had an antonym, that would be it. I can't fathom what's on the mind of a person (not you, at least you foresee some potential problems) who, even after patiently explained the issues with this mental misfire, several times, still can bring themselves to think it's not that bad. Let me add one more, although more than sure someone will find a remedy for it, too. a...b vs. a.. .b and of course the beauty ab I don't plan to discuss minor features on this group anymore. Maybe if you weren't prone to such humorous bouts of hyperbole, you wouldn't get your blood boiling so easily. This is the internet, and we're talking about programming languages. It's not like we're defusing a tense international arms conflict or something. Also, why does the puremagic mailing list software hate me so much when it comes to threading my replies? You're probably breaching some volume of posts limit. ;) Thunderbird works nice. - -- My enormous talent is exceeded only by my outrageous laziness. http://www.ssTk.co.uk -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFKEybQT9LetA9XoXwRAkDXAKCo9PS0+GRCCyZibMe3WcbiZo5HlgCeMp92 fUcS3bLFqSaQ/Pk8KKVNzJM= =k/lq -END PGP SIGNATURE- I'd vastly prefer a newsreader. Sadly I've yet to encounter a newsreader that can store its state in a shared location, which is important for me as I need to be able to access the newsgroups from multiple computers. Cough, googlegroups, cough, but whatever. It might be the way I snip out parts of quoted posts. Maybe it doesn't like that.
Re: with still sucks + removing features + adding features
On Tue, 19 May 2009 16:48:41 -0400, Jarrett Billingsley jarrett.billings...@gmail.com wrote: Also, why does the puremagic mailing list software hate me so much when it comes to threading my replies? FWIW, your replies also sometimes thread your replies in a new thread in opera (and I recall this happening with Outlook Express before I switched). There must be something your client isn't transmitting properly to signal it's the continuation of a thread. Probably you should examine your headers closely on replies that do get threaded properly vs. replies that for some reason start a new thread. -Steve
Re: with still sucks + removing features + adding features
Andrei Alexandrescu wrote:
I personally still think it's a bad feature because it introduces
long-distance coupling between symbols defined in two different places,
both distinct from the place where the statement is used! Consider:
import wyda; // defines symbol write
import geeba; // defines struct S { ... }
void main()
{
S s;
with (s) {
write(5);
}
}
Machiavelly would jump in joy at such code. What did I achieve? I saved
a few s.. What did I lose? The ability so say anything, but absolutely
anything on what the code does.
I understand the problem you are pointing out even if I don't belive it's a
significant issue. The problem with your assumption that it saves a few
s. is that where I usualy use it is in cases like this.
with(listofdecentlysizedstructs[i].vector3d){
return x*x+y*y+z*z;
}
Maybe not an ideal example, usualy I have several lines of math algorithms
or physics formula in the with scope. The gain here is both that I dont
have to type long variable names (could be solved with an alias maybe) but
more importantly it allows me to keep pysics and math formula close to the
form they have in math or pysics. For example writing x y and z for the
parts of some point I'm currently working on instead of p[i].x p[i].y and
p[i].z can in a formula with lots of them make the code easier to read. For
a single use of symbols I see no important use of the with statement.
Re: OT: on IDEs and code writing on steroids
Walter Bright escribió:
Christopher Wright wrote:
I really like IDEs. They let me think less when creating code.
It wouldn't be hard to do a competent IDE for D. After all, D is
designed to make that job easy.
Like, for example, if you have this:
---
char[] someFunction(char[] name) {
return int ~ name ~ ;;
}
class Foo {
mixin(someFunction(variable));
}
void main() {
Foo foo = new Foo();
foo. -- I'd really like the IDE to suggest me variable
}
---
Do you really think implementing a *good* IDE for D is easy now? :-P
(of course Descent works in this case, but just because it has the full
dmdfe in it... so basically a good IDE will need to be able to do CTFE,
instantiante templates, etc., and all of those things are kind of
unclear in the specification of the D language, so if you don't use
dmdfe... well... I hope you get my point)
Re: with still sucks + removing features + adding features
bearophile wrote: Andrei Alexandrescu: I don't plan to discuss minor features on this group anymore. In about two years I've never heard Walter say something like that (even if may think similar things every day), he doesn't need a pedestal. This has nothing to do with a pedestal. It's simple pragmatics. We are fulfilling Wadler's law (http://www.haskell.org/haskellwiki/Wadlers_Law) around here, and that's counterproductive. Some of language design and most of syntax design are subjective. We all have a tendency to subjectively prefer features that we created and to be more critical of features that others have created. It's natural. They call it the better-than-average bias (http://en.wikipedia.org/wiki/Lake_Wobegon_effect). I have that tendency as much as the next guy, but I also like to believe I do not let that mask my reasoning too bad. That is, I wouldn't go at any length to defend a no-win case and argue against others while at the same time consistently ignoring any explanation given several times and in several forms. Case in point: omitting the trailing parens in function calls... I got destroyed on that one :o). Andrei
Re: While we're lynching features, how bout' them omittable parens?
Ary Borenszweig wrote: That's what I said it's a contract on the semantic of properties. :) But now I'm curious: what kind of properties do you write? A getter that does calculations and caches the results (rarely). A proxied getter that does lazy loading from a database table (like NHibernate). Mocks.
Re: OT: on IDEs and code writing on steroids
Walter Bright: The 6502 is an 8 bit processor, the 8088 is 16 bits. All 8 bit processors were a terrible fit for C, which was designed for 16 bit CPUs. Everyone who coded professional apps for the 6502, 6800, 8080 and Z80 (all 8 bit CPUs) wrote in assembler. (Including myself.) Forth interpreters can be very small, it's a very flexible language, you can metaprogram it almost as Lisp, and if implemented well it can be efficient (surely more than interpreter Basic, but less than handwritten asm. You can have an optimizing Forth in probably less than 4-5 KB). But the people was waiting/asking for the Basic Language, most people didn't know Forth, Basic was common in schools, so Basic was the language shipped inside the machine, instead of Forth: http://www.npsnet.com/danf/cbm/languages.html#FORTH The Commodore 64 with built-in Forth instead of Basic may have driven computer science in a quite different direction. Do you agree? Bye, bearophile
Re: OT: on IDEs and code writing on steroids
Ary Borenszweig wrote: Do you really think implementing a *good* IDE for D is easy now? :-P (of course Descent works in this case, but just because it has the full dmdfe in it... so basically a good IDE will need to be able to do CTFE, instantiante templates, etc., and all of those things are kind of unclear in the specification of the D language, so if you don't use dmdfe... well... I hope you get my point) The dmdfe is available, so one doesn't have to recreate it. That makes it easy :-)
Re: with still sucks + removing features + adding features
Andrei Alexandrescu wrote: Let me add one more, although more than sure someone will find a remedy for it, too. a...b vs. a.. .b and of course the beauty ab Oh, and this speaks more about the .b syntax than anything else. Does anyone actually use this...? If it was removed, b could still be accessed by its fully-qualified name, so its' removal not a huge loss.
Re: OT: on IDEs and code writing on steroids
bearophile wrote: Forth interpreters can be very small, it's a very flexible language, you can metaprogram it almost as Lisp, and if implemented well it can be efficient (surely more than interpreter Basic, but less than handwritten asm. You can have an optimizing Forth in probably less than 4-5 KB). But the people was waiting/asking for the Basic Language, most people didn't know Forth, Basic was common in schools, so Basic was the language shipped inside the machine, instead of Forth: http://www.npsnet.com/danf/cbm/languages.html#FORTH The Commodore 64 with built-in Forth instead of Basic may have driven computer science in a quite different direction. Do you agree? I remember lots of talk about Forth, and nobody using it.
Re: with still sucks + removing features + adding features
bearophile wrote: Andrei Alexandrescu: I don't plan to discuss minor features on this group anymore. In about two years I've never heard Walter say something like that (even if may think similar things every day), he doesn't need a pedestal. Walter hasn't done it in 10 years in this NG.
Re: with still sucks + removing features + adding features
Robert Fraser wrote:
Andrei Alexandrescu wrote:
bearophile wrote:
Andrei Alexandrescu:
I don't plan to discuss minor features on this group anymore.
In about two years I've never heard Walter say something like that
(even if may think similar things every day), he doesn't need a
pedestal.
This has nothing to do with a pedestal. It's simple pragmatics. We are
fulfilling Wadler's law
(http://www.haskell.org/haskellwiki/Wadlers_Law) around here, and
that's counterproductive.
Some of language design and most of syntax design are subjective. We
all have a tendency to subjectively prefer features that we created
and to be more critical of features that others have created. It's
natural. They call it the better-than-average bias
(http://en.wikipedia.org/wiki/Lake_Wobegon_effect). I have that
tendency as much as the next guy, but I also like to believe I do not
let that mask my reasoning too bad. That is, I wouldn't go at any
length to defend a no-win case and argue against others while at the
same time consistently ignoring any explanation given several times
and in several forms.
Case in point: omitting the trailing parens in function calls... I got
destroyed on that one :o).
Andrei
I think the other effect is we don't often have time to think about our
suggestions for very long... Design is a process and something often
sounds good at the time. Consider the A{} syntax for templates... a
whole newsgroup, a month of discussion, and it took until Walter started
implementing it to realize the syntactic ambiguity.
Having more heads to think about a syntactic change can't be a bad thing.
Good point. Think is key :o). I'm sure it's often happened to many of
us to share with a friend something we spent nights poring over, for
them to come with what they're convinced is a much better idea after
dignifying the matter with five seconds worth of thinking.
Andrei
Re: with still sucks + removing features + adding features
Robert Fraser escribió: Andrei Alexandrescu wrote: Let me add one more, although more than sure someone will find a remedy for it, too. a...b vs. a.. .b and of course the beauty ab Oh, and this speaks more about the .b syntax than anything else. Does anyone actually use this...? If it was removed, b could still be accessed by its fully-qualified name, so its' removal not a huge loss. But that will make porting C code harder Guess who'll say that. ;-)
Re: OT: on IDEs and code writing on steroids
Walter Bright escribió: Ary Borenszweig wrote: Do you really think implementing a *good* IDE for D is easy now? :-P (of course Descent works in this case, but just because it has the full dmdfe in it... so basically a good IDE will need to be able to do CTFE, instantiante templates, etc., and all of those things are kind of unclear in the specification of the D language, so if you don't use dmdfe... well... I hope you get my point) The dmdfe is available, so one doesn't have to recreate it. That makes it easy :-) Except if the IDE is not made in C++ ;-)
Re: with still sucks + removing features + adding features
Andrei Alexandrescu wrote: bearophile wrote: Andrei Alexandrescu: I don't plan to discuss minor features on this group anymore. In about two years I've never heard Walter say something like that (even if may think similar things every day), he doesn't need a pedestal. This has nothing to do with a pedestal. It's simple pragmatics. We are fulfilling Wadler's law (http://www.haskell.org/haskellwiki/Wadlers_Law) around here, and that's counterproductive. Yeah. But more important is, of course, that you are important to the development of D, even on your own. That means, that unless you are careful with the time spent on this newsgroup, it will unduely eat away from your time with actual development. (And even thinking, in some cases.) For example, spending copious amounts of ink on trying to explain some of the most esoteric features to some who have no chance of getting it with any amount of explanation, is a waste of time. Let the ideas trickle down. At the end of the day (er, actually, the month), the guys sitting next to him will explain it in more suitable terms anyway. Also, sometimes being too terse, only causes a flurry of (either misunderstandings, or) a barrage of questions, that you then have to answer, instead of answering properly the first time around. BUT, THIS IS not important, and please, don't take the above personally. It was just thoughts in response to not planning to discuss minor features. They're important too. AND I'm not perfect either. Definitely not.
Re: OT: on IDEs and code writing on steroids
Walter Bright wrote: Georg Wrede wrote: In the Good Old Days (when it was usual for an average programmer to write parts of the code in ASM (that was the time before the late eighties -- be it Basic, Pascal, or even C, some parts had to be done in ASM to help a bearable user experience when the mainframes had less power than today's MP3 players), the ASM programing was very different on, say, Zilog, MOS, or Motorola processors. The rumor was that the 6502 was made for hand coded ASM, whereas the 8088 was more geared towards automatic code generation (as in C commpilers, etc.). My experiences of both certainly seemed to support this. The 6502 is an 8 bit processor, the 8088 is 16 bits. All 8 bit processors were a terrible fit for C, which was designed for 16 bit CPUs. Everyone who coded professional apps for the 6502, 6800, 8080 and Z80 (all 8 bit CPUs) wrote in assembler. (Including myself.) Sloppy me, 8080 was what I meant, instead of the 8088. My bad. And you're right about ASM coding. But over here, with smaller software companies, stuff was done win S-Basic (does anyone even know that one anymore???), C-Basic, and Turbo Pascal. Ron Cain's SmallC wasn't really up to anything serious, and C wasn't all that well known around here then. But Turbo Pascal was already at 3.0 in 1985, and a good investment, because using it was the same on the pre-PC computers and the then new IBM-PC. If we were smart with D, we'd find out a way of leapfrogging this thinking. We have a language that's more powerful than any of C#, Java or C++, more practical than Haskell, Scheme, Ruby, co, and more maintainable than C or Perl, but which *still* is Human Writable. All we need is some outside-of-the-box thinking, and we might reap some overwhelming advantages when we combine *this* language with the IDEs and the horsepower that the modern drone takes for granted. Easier parsing, CTFE, actually usable templates, practical mixins, pure functions, safe code, you name it! We have all the bits and pieces to really make writing + IDE assisted program authoring, a superior reality. Right, but I can't think of any IDE feature that would be a bad fit for using the filesystem to store the D source modules. I remember writing something about it here, like 7 years ago. But today there are others who have newer opinions about it. I haven't thought about it since then. I wonder how a seasoned template author would describe what the most welcome help would be when writing serious templates?
Re: OT: on IDEs and code writing on steroids
Reply to Georg, I wonder how a seasoned template author would describe what the most welcome help would be when writing serious templates? Breakpoint debugging of template explanation. Pick a template, feed it values and see (as in syntax highlighting and foreach unrolling) what happens. Pick an invoked template and dive in. Real breakpoint debugging of CTFE where it will stop on the line that is not CTFEable. Oh and auto complete that works with meta but doesn't fall over on it's side twiching with larger systems.
Re: OT: on IDEs and code writing on steroids
On Tue, 19 May 2009 16:09:54 -0700, Walter Bright wrote: bearophile wrote: Forth interpreters can be very small, it's a very flexible language, you can metaprogram it almost as Lisp, and if implemented well it can be efficient (surely more than interpreter Basic, but less than handwritten asm. You can have an optimizing Forth in probably less than 4-5 KB). But the people was waiting/asking for the Basic Language, most people didn't know Forth, Basic was common in schools, so Basic was the language shipped inside the machine, instead of Forth: http://www.npsnet.com/danf/cbm/languages.html#FORTH The Commodore 64 with built-in Forth instead of Basic may have driven computer science in a quite different direction. Do you agree? I remember lots of talk about Forth, and nobody using it. It can quickly degenerate into a write-only language because it encourages one to extend the syntax, and even semantics, of the language. It takes extreme discipline to make a Forth program maintainable by anyone other than the original author. The other difficulty with it is that most people don't use Reverse Polish Notation often enough for it to become second nature, thus making it hard for people to read a Forth program and 'see' what its trying to do. However, it has its own elegance and simplicity that can be very alluring. I see it as the Circe of programming languages. -- Derek Parnell Melbourne, Australia skype: derek.j.parnell
Re: with still sucks + removing features + adding features
Ary Borenszweig wrote: Oh, and this speaks more about the .b syntax than anything else. Does anyone actually use this...? If it was removed, b could still be accessed by its fully-qualified name, so its' removal not a huge loss. But that will make porting C code harder Guess who'll say that. ;-) ??? C allows .x to access a global member? You learn something useless every day...
Re: OT: on IDEs and code writing on steroids
BCS wrote: Oh and auto complete that works with meta but doesn't fall over on it's side twiching with larger systems. :-) It's getting better, slowly.
Re: OT: on IDEs and code writing on steroids
Hello Robert, BCS wrote: Oh and auto complete that works with meta but doesn't fall over on it's side twiching with larger systems. :-) It's getting better, slowly. I can get you some test cases if you want... :-)
Re: with still sucks + removing features + adding features
Georg Wrede wrote: bearophile wrote: Andrei Alexandrescu: I don't plan to discuss minor features on this group anymore. In about two years I've never heard Walter say something like that (even if may think similar things every day), he doesn't need a pedestal. Walter hasn't done it in 10 years in this NG. There's only one Walter! Andrei
Re: with still sucks + removing features + adding features
Andrei Alexandrescu wrote:
Robert Fraser wrote:
Andrei Alexandrescu wrote:
bearophile wrote:
Andrei Alexandrescu:
I don't plan to discuss minor features on this group anymore.
In about two years I've never heard Walter say something like that
(even if may think similar things every day), he doesn't need a
pedestal.
This has nothing to do with a pedestal. It's simple pragmatics. We
are fulfilling Wadler's law
(http://www.haskell.org/haskellwiki/Wadlers_Law) around here, and
that's counterproductive.
Some of language design and most of syntax design are subjective. We
all have a tendency to subjectively prefer features that we created
and to be more critical of features that others have created. It's
natural. They call it the better-than-average bias
(http://en.wikipedia.org/wiki/Lake_Wobegon_effect). I have that
tendency as much as the next guy, but I also like to believe I do not
let that mask my reasoning too bad. That is, I wouldn't go at any
length to defend a no-win case and argue against others while at the
same time consistently ignoring any explanation given several times
and in several forms.
Case in point: omitting the trailing parens in function calls... I
got destroyed on that one :o).
Andrei
I think the other effect is we don't often have time to think about
our suggestions for very long... Design is a process and something
often sounds good at the time. Consider the A{} syntax for
templates... a whole newsgroup, a month of discussion, and it took
until Walter started implementing it to realize the syntactic ambiguity.
Having more heads to think about a syntactic change can't be a bad thing.
Good point. Think is key :o).
And another thing is, of course, that even a simple language can become
too hard for a normal programmer, if it becomes too elegant or assumes
too much generalizing, memorizing, and abstract thinking from the
programmer when he is coding.
Some of the vociferous things (well, like the trailing parens thing) may
be related to that.
So, this NG serves a purpose in helping the language stay near most
regular programmers' reach. Wich is a must, if we intend to take over
the world.
Re: with still sucks + removing features + adding features
Andrei Alexandrescu wrote: Georg Wrede wrote: bearophile wrote: Andrei Alexandrescu: I don't plan to discuss minor features on this group anymore. In about two years I've never heard Walter say something like that (even if may think similar things every day), he doesn't need a pedestal. Walter hasn't done it in 10 years in this NG. There's only one Walter! :-)
Re: with still sucks + removing features + adding features
Robert Fraser escribió: Ary Borenszweig wrote: Oh, and this speaks more about the .b syntax than anything else. Does anyone actually use this...? If it was removed, b could still be accessed by its fully-qualified name, so its' removal not a huge loss. But that will make porting C code harder Guess who'll say that. ;-) ??? C allows .x to access a global member? You learn something useless every day... Aaah... I thought they were talking about .1, .2, etc. I forgot about .foo
