Re: DConf 2013 Call for Submissions: deadline on January 28
On Thu, 17 Jan 2013 08:19:32 +1100, Era Scarecrow rtcv...@yahoo.com wrote: On Wednesday, 16 January 2013 at 18:55:03 UTC, Jesse Phillips wrote: On Wednesday, 16 January 2013 at 02:21:34 UTC, John Colvin wrote: The problem is, I live in the UK. It would cost upwards of $800 for flights alone, which is way outside the sort of money I can afford to spend at the moment, so I don't see it happening. As a future note, east coast USA would be a lot easier for us Europeans. $800 for round trip? Why can't I get that to Japan!! QQ from Melbourne, Australia. I'm looking at $1100 - $1300 for the flight. -- Derek Parnell
Re: Dynamic language
On Thu, 15 Mar 2012 18:09:37 +1100, so s...@so.so wrote: Hello, Not related to D but this is a community which i can find at least a few objective person. I want to invest some quality time on a dynamic language but i am not sure which one. Would you please suggest one? To give you an idea what i am after: Of all one-liners i have heard only one gets me. The programmable programming language. Is it true? If so Lisp will be my first choice. I'm not so objective, but don't let that dissuade you. For a programmable language, you might want to look at Forth. I use it as an embedded scripting language in a couple of my programs. For a language that has built-in static types and built-in dynamic types, you might want to check out the Euphoria language at http://www.openeuphoria.org and also as a web language: http://openeuphoria.org/forum/117802.wc?last_id=117805 -- Derek
Re: Multiple return values...
On Thu, 15 Mar 2012 08:52:26 +1100, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
On 3/14/12 3:00 PM, Simen Kjærås wrote:
template to(T...) {
alias T to;
}
auto from(T...)(T t) {
struct Result { T t; alias t this; }
return Result( t );
}
void main( ) {
int a = 3;
int b = 4;
to!(a, b) = from(b, a);
assert( a == 4 );
assert( b == 3 );
}
I got reborn inside a little when seeing this code. Congratulations!
And I died a little ... I have no idea what this code is doing. What is
the generated code produced by this and why?
I'd like to break the nexus between science and magic here.
--
Derek
Re: Tuple unpacking syntax [Was: Re: Multiple return values...]
On Wed, 14 Mar 2012 13:33:18 +1100, Kevin Cox kevincox...@gmail.com
wrote:
Kind of unrelated but I think that it is important to have a way to
ignore
values also. Leaving them bank would sufice.
(int i,,float f) = intBoringFloat();
For what its worth, the Euphoria Programming Language uses ? to signify
ignored values.
eg.
integer i
atomf
{i, ?, f} = intBoringFloat()
We felt that leaving a blank could be a source of human error (can be
missed when reading code) and also a result of human error (accidentally
put in a double comma). Using an unusual glyph to signify omission was
the compromise we came up with.
--
Derek Parnell
Re: About switch case statements...
On Tue, 17 Nov 2009 09:05:48 +0100, Don wrote: Your other two comments aren't worth responding to. I apologize. I also don't know what I said to offend you. I've taken steps to make sure it doesn't happen again. -- Derek Parnell Melbourne, Australia skype: derek.j.parnell
Re: About switch case statements...
On Mon, 16 Nov 2009 14:34:37 +0100, Don wrote: bearophile wrote: Don: (providing that empty fall-through case statements remain valid; disallowing them would be really annoying). What's bad about forcing people to write: case A, B, C: Instead of: case A: case B: case C: ? Bye, bearophile (1) case A, B, C: implies a relationship between A, B, and C, which might not exist. They may have nothing in common. (2) it's an extremely common coding style in C, C++. (3) it's more difficult to read. (1) case A: case B: case C: implies that there is no relationship between A,B, and C, but which might actually exist. They may have something common. (2) it's an extremely common writing style in human languages, thus aids readability. (3) case A: case B: case C: is ambiguous. It looks like the coder put in place markers for intended code but forgot the code. -- Derek Parnell Melbourne, Australia skype: derek.j.parnell
Re: Making alloca more safe
On Mon, 16 Nov 2009 12:48:51 -0800, Walter Bright wrote: bearophile wrote: Walter Bright: I just wished to point out that it was not a *safety* issue. A safe system is not a program that switches itself off as soon as there's a small problem. Computers cannot know whether a problem is small or not. But designers who make the system can. Pretending a program hasn't failed when it has, and just soldiering on, is completely unacceptable behavior in a system that must be reliable. ... If you've got a system that relies on the software continuing to function after an unexpected null seg fault, you have a VERY BADLY DESIGNED and COMPLETELY UNSAFE system. I really cannot emphasize this enough. What is the 'scope' of system? Is that if any component in a system fails, then all other components are also in an unknown, and therefore potentially unsafe, state too? For example, can one describe this scenario below as a single system or multiple systems... A software failure causes the cabin lights to be permanently turned on, so should the 'system' also assume that the toilets must no longer be flushed? Is the system the entire aircraft, i.e. all its components, or is there a set of systems involved here? In the set of systems concept, is it possible that a failure of one system can have no impact on another system in the set, or must it be assumed that every system is reliant on all other systems in the same set? -- Derek Parnell Melbourne, Australia skype: derek.j.parnell
Re: D: at Borders soon?
On Sat, 14 Nov 2009 23:06:10 -0600, AJ wrote: I'm a prick, of course By George! I think he's right. -- Derek Parnell Melbourne, Australia skype: derek.j.parnell
Re: About switch case statements...
On Sun, 15 Nov 2009 12:49:01 -0500, Chad J wrote: So, switch-case statements are a frequent source of nasty bugs. Fixing them (well) requires breaking backwards compatibility. Any chance this will happen for D2? The phrase snowball in hell comes to mind. (This is intended as more of a reminder and simple curiosity than a discussion.) And in spite of your good intentions (~ not a discussion ~) this will be one ;-) The Euphoria Programming language, which I'm helping to implement, has 'solved' this issue. This language is not a C-derived one so don't be alarmed at its apparent verbosity. The default 'case' in a 'switch' is to not fall through; an implied 'break' is assumed at the end of each 'case' clause. switch Foo do case 1 then ... whatever for 1 ... ... does not fall through to the next case ... case 2, 3 then ... whatever for 2 and 3 ... ... does not fall through to the next case ... case 4 then ... whatever for 4 ... ... does not fall through to the next case ... end switch However, the coder can change the default behaviour on a 'switch' statement by including the phrase 'with fallthru', thus changing the default behaviour such that each 'case' clause will fall through to the next case unless the coder uses an explicit 'break' statement. This, as you can see, is the DPL behaviour. switch Foo with fallthru do case 1 then ... whatever for 1 ... ... falls through to the next case ... case 2, 3 then ... whatever for 2 and 3 ... break /* explicitly required to prevent falling through */ case 4 then ... whatever for 4 ... ... falls through to the next case ... end switch Further more, whatever the default behaviour for the 'switch', it can be adjusted on any of the 'case' clauses. This means that a by-default-break switch, can use the 'fallthru' statement to explicitly override the break default and fall through to the next case. switch Foo do /* by default, break */ case 1 then ... whatever for 1 ... fallthru /* explicitly falls through */ case 2, 3 then ... whatever for 2 and 3 ... ... implied break here ... case 4 then ... whatever for 4 ... ... implied break here ... end switch In short, Euphoria allows for both ideologies to exist, and in fact to co-exist in peace. The standard default gives most protection from mistakes, but for those coders that like to keep on the edge, they can code with the level of risk that is acceptable to themselves. I can see good reason for DPL to adopt a similar stance. I would suggest a new keyword to make things easier for coders (after all, that's why we have programming languages), but for those who see keywords as evil, I'm sure that someone can come up with another syntax that avoids a new keyword (at the expense of clarity) eg. ! break or the old standby, static LOL. -- Derek Parnell Melbourne, Australia skype: derek.j.parnell
Re: About switch case statements...
On Sun, 15 Nov 2009 15:03:39 -0600, Andrei Alexandrescu wrote: I'm not sure where that leaves us. Others - please add your experience. Once Euphoria had implemented the 'fallthru' statement, it was like a weight lifted from the code. It just looked better and was far easier to write code. A small change, but an wonderfully liberating change. A bit like the effect of using [$] rather than [length]. -- Derek Parnell Melbourne, Australia skype: derek.j.parnell
Re: Personal thoughts about D2 release, D, the Universe and everything
On Sat, 7 Nov 2009 03:31:02 + (UTC), dsimcha wrote: == Quote from hasenj (hasan.alj...@gmail.com)'s article Look at dsource, why is everything there almost dead? Probably because most projects on most open-source hosting sites, like Sourceforge, never really get off the ground. The problem with dsource is that there's no quick, easy way to tell what projects are alive and what ones aren't. What we really need is for dsource projects to be organized by last commit. Stuff that hasn't had a commit in over, say, 2 months, gets pushed toward the bottom. Why are commits made to a projects? I would offer that most commits fall into one of four categories... 1) Bug fixes to (correctly) implement existing design goals 2) New code to implement existing design goals 3) New code to implement updated design goals. 4) Refactoring that is irrelevant to design goals. What is an alive project? Again I suggest it is either one that is having significant commits (reasons 1 thru 3), or one that is feature complete and stable. To me, this means that projects that are not feature complete and are having no significant commits are those that might be worthy of relegation. Your suggestions implies that only active incomplete projects (or ones that are constantly being beautified) are worthwhile. Projects that are complete, or at least stable in terms of bug fixing, would drop off the list even though they maybe still a worthwhile product. -- Derek Parnell Melbourne, Australia skype: derek.j.parnell
Re: Proposal: Replace __traits and is(typeof(XXX)) with a 'magic namespace'.
On Mon, 02 Nov 2009 17:47:53 +0100, Don wrote: is(typeof(XXX)) is infamously ugly and unintuitive __traits(compiles, XXX) is more comprehensible, but just as ugly. They are giving metaprogramming in D a bad name. I think we need to get rid of both of them. A very easy way of doing this is to replace them with a 'magic namespace' -- so that they _look_ as though they're functions in a normal module. Names which have been suggested include 'meta', 'traits', 'scope', 'compiler'. Personally I think 'meta' is the nicest (and I suggested two of the others g). Thank you Don for this voice of reason. A specific keyword for the concept of compile-time activity/functionality is totally justified. meta is very suitable. Short and to the point. compiler I could live with. traits is unsuitable, as it is too limiting a concept. scope is unsuitable, as it is already too highly overloaded with semantics. static is extremely unsuitable. This word should, at best, be only used for things that do not change value or location during run-time. ... and slightly off topic ... now if only we could get the 'bang' out of template instantiation syntax as well. When I see the '!' in something like Foo!(X)(), my mind first says we are about to negate something and then has to switch tracks oh no, this actually means we are using a template this time. I'm *so* over the amount of symbol and keyword overloading that goes on in D and C-like languages. It's as if they were devised by academics during the days when data transmission times were slow and only they looked at source code. -- Derek Parnell Melbourne, Australia skype: derek.j.parnell
Re: Null references redux
On Mon, 28 Sep 2009 19:27:03 -0500, Andrei Alexandrescu wrote: language_fan wrote: int min; foreach(int value; list) if (value min) min = value; Oops, you forgot to define a flag variable or initialize to int.min You mean int.max :o). if (list.length == 0) throw( some exception); // An empty or null list has no minimum int min = list[0]; foreach(int value; list[1..$]) if (value min) min = value; I'm still surprised by Walter's stance. For the purposes of this discussion... * Null only applies to the memory address portion of reference types and not to value types. The discussion is not about non-nullable value types. * There are two types of reference types: (1) Those that can be initialized on declaration because the coder knows what to initialize them to; a.k.a. non-nullable. If the coder does not know what to initialize them to at declaration time, then either the design is wrong, the coder doesn't understand the algorithm or application, or it is truly a complex run-time decision. (2) Those that aren't in set (1); a.k.a. nullable. * The standard declaration should imply non-nullable. And if not initialized the compiler should complain. This encourages protection, but does not guarantee it, of course. * To declare a nullable type, use a special syntax to denote that the coder is deliberately choosing to declare a nullable reference. * The compiler will prevent non-nullable types being simply set to null. As D is a system language too, there will be a rare cases that need to subvert this compiler protection, so there will need to be a method to explicitly set a non-nullable type to a null. The point is that such a method should be a visible warning beacon to maintenance coders. Priority should be given to coders that prefer safe coding. If a coder, for whatever reason, chooses to use nullable references or initialize non-nullable reference to rubbish data, then the responsibility is on them to ensure safe applications. Safe coding practices should not be penalized. The C/C++ programming language is inherently unsafe in this regard, and that is not news to anyone. The D programming language does not have to follow this paradigm. I'm still not ready to use D for anything, but I watch it in hope. -- Derek Parnell Melbourne, Australia skype: derek.j.parnell
Re: dmd 1.046 and 2.031 releases
On Mon, 06 Jul 2009 21:29:43 -0700, Walter Bright wrote: Derek Parnell wrote: However, that aside, the syntax you have chosen will have a rational explanation for its superiority. So can you explain in simple terms why CaseLabelInt .. CaseLabelInt eg. case 1: .. case 9: is superior than case CaseRange: eg. case 1 .. 9: given that CaseLabelInt == case IntegerExpression : CaseRange== IntegerExpression .. IntegerExpression Because 1.case X..Y: looks like 2.foreach(e; X..Y) 3.array[X..Y] yet the X..Y has a VERY DIFFERENT meaning. (1) is inclusive of Y, and (2) and (3) are exclusive of Y. Having a very different meaning means it should have a distinctly different syntax. Thank you, but now I am confused ... Andrei just got through lecturing us that the meaning of punctuation is dependant upon context. So I think your example must be more like ... Because 1. case X..Y: looks like 2. foreach(e; X..Y) 3. array[X..Y] 4. case X:..caseY: yet the X..Y has a VERY DIFFERENT meaning. (1) is inclusive of Y, and (2) and (3) are exclusive of Y, and (4) is inclusive of Y ... oh, hang on... Sorry, but I'm just not getting the VERY DIFFERENT part yet. Right now, D has .. meaning exclude-end value (2. and 3.) AND it also has .. meaning include-end value (4.), depending on context. Ok, I admit that there is one subtle difference. Examples 2 and 3 are of the form IntExpression .. IntExpression and example 4 is CaseLabelInt .. CaseLabelInt but seriously, people are not going to notice that. We see double-dot and think range. I know that this is not ever going to be changed so I'm not arguing that it should. (One of the most frequent bugs I have in my D programs is that I forget that X..Y excludes Y because it's not natural to me to see text that looks like the range X to Y but means the range X to Y-1.) It seems that D would benefit from having a standard syntax format for expressing various range sets; a. Include begin Include end, i.e. [] b. Include begin Exclude end, i.e. [) c. Exclude begin Include end, i.e. (] d. Exclude begin Exclude end, i.e. () -- Derek Parnell Melbourne, Australia skype: derek.j.parnell
Re: dmd 1.046 and 2.031 releases
On Tue, 07 Jul 2009 20:13:45 +0200, Jérôme M. Berger wrote: Andrei Alexandrescu wrote: Derek Parnell wrote: It seems that D would benefit from having a standard syntax format for expressing various range sets; a. Include begin Include end, i.e. [] b. Include begin Exclude end, i.e. [) c. Exclude begin Include end, i.e. (] d. Exclude begin Exclude end, i.e. () I'm afraid this would majorly mess with pairing of parens. I think Derek's point was to have *some* syntax to mean this, not necessarily the one he showed Thank you, Jérôme. I got too frustrated to explain it well enough. -- Derek Parnell Melbourne, Australia skype: derek.j.parnell
Re: dmd 1.046 and 2.031 releases
On Tue, 07 Jul 2009 14:05:33 -0400, Robert Jacques wrote: Well, how often does everyone else use bytes? Cryptography, in my case. -- Derek Parnell Melbourne, Australia skype: derek.j.parnell
Re: dmd 1.046 and 2.031 releases
On Tue, 07 Jul 2009 13:16:14 -0500, Andrei Alexandrescu wrote: Safe D is concerned with memory safety only. That's a pity. Maybe it should be renamed to Partially-Safe D, or Safe-ish D, Memory-Safe D, or ... well you get the point. Could be misleading for the great unwashed. -- Derek Parnell Melbourne, Australia skype: derek.j.parnell
Re: dmd 1.046 and 2.031 releases
On Tue, 07 Jul 2009 21:20:42 +0200, Jérôme M. Berger wrote: Andrei Alexandrescu wrote: Jérôme M. Berger wrote: Andrei Alexandrescu wrote: Jérôme M. Berger wrote: Andrei Alexandrescu wrote: Derek Parnell wrote: It seems that D would benefit from having a standard syntax format for expressing various range sets; a. Include begin Include end, i.e. [] b. Include begin Exclude end, i.e. [) c. Exclude begin Include end, i.e. (] d. Exclude begin Exclude end, i.e. () I'm afraid this would majorly mess with pairing of parens. I think Derek's point was to have *some* syntax to mean this, not necessarily the one he showed (which he showed because I believe that's the standard mathematical way to express it for English speakers). For example, we could say that [] is always inclusive and have another character which makes it exclusive like: a. Include begin Include end, i.e. [ a .. b ] b. Include begin Exclude end, i.e. [ a .. b ^] c. Exclude begin Include end, i.e. [^ a .. b ] d. Exclude begin Exclude end, i.e. [^ a .. b ^] I think Walter's message really rendered the whole discussion moot. Post of the year: = I like: a .. b+1 to mean inclusive range. = Consider +1] a special symbol that means the range is to be closed to the right :o). Ah, but: - This is inconsistent between the left and right limit; - This only works for integers, not for floating point numbers. How does it not work for floating point numbers? Is that a trick question? Depending on the actual value of b, you might have b+1 == b (if b is large enough). Conversely, range a .. b+1 may contain a lot of extra numbers I may not want to include (like b+0.5)... Jerome If Andrei is not joking (the smiley notwithstanding) the +1 doesn't mean add one to the previous expression, instead it means that the previous expression's value is the last value in the range set. Subtle, no? -- Derek Parnell Melbourne, Australia skype: derek.j.parnell
Re: dmd 1.046 and 2.031 releases
On Tue, 07 Jul 2009 18:26:36 -0700, Walter Bright wrote: All the messages from the dawn of time are online and available at http://www.digitalmars.com/d/archives/digitalmars/D/ and are searchable from the search box in the upper left. Okaaayy ... I see that this (checking for integer overflow) has been an issue since at least 2003. http://www.digitalmars.com/d/archives/19850.html At this rate, D v2 will be released some time after C++0X :-) -- Derek Parnell Melbourne, Australia skype: derek.j.parnell
Re: Case Range Statement ..
On Tue, 07 Jul 2009 04:35:56 -0400, Mike James wrote: Or you introduce a new keyword :-) Ooooh you said the 'k' word, naughty boy. -- Derek Parnell Melbourne, Australia skype: derek.j.parnell
Re: Case Range Statement ..
On Tue, 07 Jul 2009 11:01:12 -0500, Andrei Alexandrescu wrote:
To me they look the same, but if people are happier with wasting
vertical space, sure.
I think I've finally worked out why I don't like this syntax. Consider this
...
switch (X) {
case 1: funcA(); break;
case 2,5,7,10 .. 17, 24, 32: funcB(); break;
case 3,6,8,18 .. 23: funcC(); break;
}
In other words, allowing a range of value inside a list of values.
How is this possible in today's D?
--
Derek Parnell
Melbourne, Australia
skype: derek.j.parnell
Re: Case Range Statement ..
On Tue, 07 Jul 2009 10:50:08 -0700, Walter Bright wrote: I like: a .. b+1 to mean inclusive range. LOL, now that *is* funny. And I like the Euphoria language's version ... case X to Y but so what, eh? -- Derek Parnell Melbourne, Australia skype: derek.j.parnell
Re: Case Range Statement ..
On Tue, 07 Jul 2009 12:38:49 -0700, Walter Bright wrote: Nick Sabalausky wrote: Someone else said it's also an expression that evaluates to 3, but that seems beyond useless to me. It's handy when you want to prefix one expression to another, as in: (foo(), x + 3) I took what Nick said to mean that expressions in the form ( integerA , integerB ) were useless as they always evaluate to integerB, so why bother to code them as expressions. Whereas such an expression *in* the context of a case clause could be made to mean that an inclusive range was being requested by the coder. Walter's example, using a function call, could be useful as the function can have side-effects that influence the next sub-expression x + 3. -- Derek Parnell Melbourne, Australia skype: derek.j.parnell
Re: Case Range Statement ..
On Wed, 8 Jul 2009 07:48:07 +1000, Derek Parnell wrote: On Tue, 07 Jul 2009 10:50:08 -0700, Walter Bright wrote: I like: a .. b+1 to mean inclusive range. LOL, now that *is* funny. And I like the Euphoria language's version ... case X to Y but so what, eh? OMG! ... having read the rest of the posts I see that you were serious. Sorry, didn't mean to show disrespect; I really thought it was a joke. Are you honestly suggesting that the sequence of Expression .. Expression +1 be recognized by the tokenizer as meaning Inclusive-End-Range? -- Derek Parnell Melbourne, Australia skype: derek.j.parnell
Re: Case Range Statement ..
On Tue, 07 Jul 2009 14:47:06 -0500, Andrei Alexandrescu wrote: The .name syntax and the number. syntax are confusing. Using ... as a separator multiplies confusion by a billion. A billion - really? And yet I'm not confused by it, so does that make me very clever or very stupid ... h? By the way, I don't like triple-dot either, but just making a point. -- Derek Parnell Melbourne, Australia skype: derek.j.parnell
Re: Case Range Statement ..
On Tue, 07 Jul 2009 19:29:21 -0500, Andrei Alexandrescu wrote:
There is no need for a right-closed range in the language. It can be
defined with ease as a library, although I'm not finding myself in need
of one.
Process all the characters from 'a' to 'z' inclusive.
Currently, ('a' .. 'z'+1)
Logically, ('a' .. 'z')
--
Derek Parnell
Melbourne, Australia
skype: derek.j.parnell
Re: Number literals (Was: Re: Case Range Statement ..)
On Tue, 07 Jul 2009 20:08:55 -0400, bearophile wrote: Nick Sabalausky: why in the world is anyone defending the continued existance of 5. and .5? I'm for disallowing them; 5.0 ad 0.5 are better. Anyone else pro/against this idea? I would not complain if trailing dot and leading dot were disallowed. -- Derek Parnell Melbourne, Australia skype: derek.j.parnell
Re: Case Range Statement ..
On Tue, 07 Jul 2009 19:42:00 -0500, Andrei Alexandrescu wrote:
Derek Parnell wrote:
On Tue, 07 Jul 2009 19:29:21 -0500, Andrei Alexandrescu wrote:
There is no need for a right-closed range in the language. It can be
defined with ease as a library, although I'm not finding myself in need
of one.
Process all the characters from 'a' to 'z' inclusive.
Currently, ('a' .. 'z'+1)
Logically, ('a' .. 'z')
Do we need a language feature for that?
Would any answer make a difference?
--
Derek Parnell
Melbourne, Australia
skype: derek.j.parnell
Re: Number literals (Was: Re: Case Range Statement ..)
On Tue, 07 Jul 2009 20:20:28 -0700, Walter Bright wrote:
Or just drop octal altogether. Outside of chmod, when is there any
legitimate need for it these days?
Translating C code to D.
On Tue, 07 Jul 2009 20:29:40 -0700, Walter Bright wrote:
Sometimes I run across someone else's code that does:
for (i = 0; i = 10; i++)
{
... array[i] ...
}
and I'll always rewrite it as i11, because the former confuses my brain
into creating bugs.
On Tue, 07 Jul 2009 21:06:11 -0700, Walter Bright wrote:
I've translated code, and a tool isn't really necessary. But translating
octal constants to hex like 077733 is very error prone. And yes, I ran
into a bunch of them just recently in the OSX system header files. So
they exist. I don't see a good reason to make things difficult to translate.
So ...
Octal literals are so common that we need compiler/language support.
Character ranges are so rare that we do not need compiler/language support.
Compatibility with C is paramount, except when it's not.
Technical merit trumps human interface.
I think that I'm not ready for the D programming language after all. I'll
drop by the sandbox from time to time out of curiosity, I suppose. Good
luck and thanks for all the fish.
--
Derek Parnell
Melbourne, Australia
skype: derek.j.parnell
Re: dmd 1.046 and 2.031 releases
On Sun, 05 Jul 2009 22:05:10 -0700, Walter Bright wrote: Something for everyone here. http://www.digitalmars.com/d/1.0/changelog.html http://ftp.digitalmars.com/dmd.1.046.zip http://www.digitalmars.com/d/2.0/changelog.html http://ftp.digitalmars.com/dmd.2.031.zip The -deps= switch is helpful, but can we also have a -nogen switch so that a compile is done but no object files are created. Kind of like the -c switch which does a compile but no linking. Then we can use -deps=dep.txt -nogen to get the dependency data so build tools can then work out what needs to actually be compiled. And in that vein, a hash (eg CRC32, MD5, SHA256) of the file's used by DMD would be nice to see in the 'deps' file. Would help build tools detect which files have been modified. May I make a small syntax suggestion for the deps format. Instead of enclosing a path in parentheses, and using ':' as a field delimiter, have the first (and last) character of each line be the field delimiter to use in that line. The delimiter would be guaranteed to never be part of any of the fields' characters. That way, we don't need escape characters and parsing the text is greatly simplified. Also, simplifying the paths by resolving the .. and . would be nice. eg. !std.stdio!c:\dmd\dmd\src\phobos\std\stdio.d!public!std.format!c:\dmd\dmd\src\phobos\std\format.d! If this is ok can I submit a patch? -- Derek Parnell Melbourne, Australia skype: derek.j.parnell
Re: dmd 1.046 and 2.031 releases
On Sun, 05 Jul 2009 22:05:10 -0700, Walter Bright wrote:
Something for everyone here.
http://www.digitalmars.com/d/1.0/changelog.html
http://ftp.digitalmars.com/dmd.1.046.zip
http://www.digitalmars.com/d/2.0/changelog.html
http://ftp.digitalmars.com/dmd.2.031.zip
One of the very much appreciated updates here is Implicit integral
conversions that could result in loss of significant bits are no longer
allowed.. An excellent enhancement, thank you.
But I am confused as this below compiles without complaint...
---
import std.stdio;
void main()
{
byte iii;
ubyte uuu = 250;
iii = uuu;
writefln(%s %s, iii, uuu);
}
---
Output is ...
-6 250
But I expected the compiler to complain that an unsigned value cannot by
implicitly converted to a signed value as that results in loss of
*significant* bits.
--
Derek Parnell
Melbourne, Australia
skype: derek.j.parnell
Re: dmd 1.046 and 2.031 releases
On Sun, 05 Jul 2009 23:35:24 -0700, Walter Bright wrote:
Derek Parnell wrote:
One of the very much appreciated updates here is Implicit integral
conversions that could result in loss of significant bits are no longer
allowed.. An excellent enhancement, thank you.
Thank Andrei for that, he was the prime mover behind it.
Yes, our English language is poor. I should have said thank yous ;-)
But I am confused as this below compiles without complaint...
---
import std.stdio;
void main()
{
byte iii;
ubyte uuu = 250;
iii = uuu;
writefln(%s %s, iii, uuu);
}
---
Output is ...
-6 250
But I expected the compiler to complain that an unsigned value cannot by
implicitly converted to a signed value as that results in loss of
*significant* bits.
We tried for a long time to come up with a sensible way to deal with the
signed/unsigned dichotomy. We finally gave that up as unworkable.
Instead, we opted for a method of significant bits, *not* how those bits
are interpreted. -6 and 250 are the same bits in byte and ubyte, the
difference is interpretation.
I am disappointed. I hope that you haven't stopped working on a solution to
this though, as allowing D to silently permit bugs it could prevent is not
something we are hoping for.
I can see that the argument so far hinges on the meaning of significant.
I was hoping that a 'sign' bit would have been significant.
As for the same bits in X and Y, the different is interpretation, this is
something that can be selective. For example ...
--
short iii;
struct U {align (1) byte a; byte b;}
U uuu;
iii = uuu;
--
The bits in 'uuu' can be accommodated in 'iii' so why not allow implicit
conversion? Yes, that is a rhetorical question. Because we know that the
struct means something different to the scalar 'short', conversion via
bit-mapping is not going to be valid in most cases. However, we also know
that a signed value is not the same as an unsigned value even though they
have the same number of bits; that is the compiler already knows how to
interpret those bits.
I'm struggling to see why the compiler cannot just disallow any
signed-unsigned implicit conversion? Is it a matter of backward
compatibility again?
--
Derek Parnell
Melbourne, Australia
skype: derek.j.parnell
Re: dmd 1.046 and 2.031 releases
On Mon, 06 Jul 2009 00:11:26 -0700, Walter Bright wrote: Derek Parnell wrote: I'm struggling to see why the compiler cannot just disallow any signed-unsigned implicit conversion? Is it a matter of backward compatibility again? What's the signed-ness of 5? Positive. A positive number can be assigned to an 'int' if there is no size issue. What's the problem that I'm obviously missing? When you index a pointer, is the index signed or unsigned? An index can be either. What's the problem here? -- Derek Parnell Melbourne, Australia skype: derek.j.parnell
Re: dmd 1.046 and 2.031 releases
On Mon, 06 Jul 2009 03:13:45 -0700, Walter Bright wrote: Derek Parnell wrote: On Mon, 06 Jul 2009 00:11:26 -0700, Walter Bright wrote: Derek Parnell wrote: I'm struggling to see why the compiler cannot just disallow any signed-unsigned implicit conversion? Is it a matter of backward compatibility again? What's the signed-ness of 5? Positive. A positive number can be assigned to an 'int' if there is no size issue. It can also be an unsigned. Which is a positive value, right? Can you think of any unsigned value which is also negative? What's the problem that I'm obviously missing? When you index a pointer, is the index signed or unsigned? An index can be either. What's the problem here? auto x = p1 - p2; What's the type of x? Is that what you meant by index a pointer? Anyhow, it is a signed value. The difference between any two random memory addresses can be positive or negative. Whatever the 'signedness' of 'x' is, the expression p2 + x == p1 must be true. If p1 is 0 and p2 is uint.max then 'x' must still be able to hold (-uint.max) Denis Koroskin wrote: auto x = p1 - p2; What's the type of x? ptrdiff_t, signed counterpart of size_t Do you really want an error if you go: size_t y = p1 - p2; Yes I do. size_t y = cast(size_t)p1 - p2; -- No error. ptrdiff_t y = p1 - p2; -- No error. size_t y = p1 - p2; -- Error. Safety is supposed to be enhance by using D, is it not? -- Derek Parnell Melbourne, Australia skype: derek.j.parnell
Re: dmd 1.046 and 2.031 releases
On Mon, 6 Jul 2009 15:03:20 + (UTC), BCS wrote: Hello Derek, The -deps= switch is helpful, but can we also have a -nogen switch so that a compile is done but no object files are created. look at: -o- Thanks, I've never noticed that switch before. Excellent. -- Derek Parnell Melbourne, Australia skype: derek.j.parnell
Re: dmd 1.046 and 2.031 releases
On Mon, 06 Jul 2009 11:02:12 -0700, Walter Bright wrote: Derek Parnell wrote: Safety is supposed to be enhance by using D, is it not? See my post to Denis. Requiring too many casts reduces safety by essentially disabling the static type checking system. I totaly agree that cast() should be avoided, almost at all costs. A better way in this situation is to use a variable that can accommodate the range of possible values. Only use the cast() construct if you are deliberately doing something other than normal. For example, if you know that the different between two addresses will always be less than a 16-bit value AND you are deliberately storing the difference in a 'short' then using a cast() is a good idea as it alerts the code reader to this unusual situation. short x = cast(short)(p1 - p2); However, auto x = p1 - p2; should imply that 'x' is able to hold any value from -(uintptr_t.max) to uintptr_t.max inclusive. -- Derek Parnell Melbourne, Australia skype: derek.j.parnell
Re: switch ( Expression ) ScopeStatement
On Mon, 06 Jul 2009 22:10:20 -0400, bearophile wrote:
Derek Parnell:
is valid syntax! Why is that?
To allow train-wrecks like this one:
version(Tango) import tango.stdc.stdio;
void main(char[][] args) {
if (args.length 1)
switch (args[1]) {
int x = 1; // This initialization to 1 doesn't happen,
// it's the same as int x = void;
case 1: printf(1! x=%d\n, x); break;
case 2: printf(2! x=%d\n, x); break;
}
}
No quite the same thing, actually. You have highlighted another quirk with
switch though.
My question was really about why is it that the first token after the (
Expression ) did not have to be a left-brace, but could be any statement
at all.
switch(x) funcA();
switch(x) switch (y) {};
Just seems wrong somehow but I'm positive that the experts have a perfectly
rational answer. I just hope I can understand it.
--
Derek Parnell
Melbourne, Australia
skype: derek.j.parnell
Re: Usage of -deps
On Mon, 06 Jul 2009 22:19:40 -0400, bearophile wrote: But the 'deps.txt' file is empty. Can you tell me what's wrong? The changelog of D1 and D2 says that both have -deps, and indeed both compilers accept such flag, but DMD1 doesn't seem to work with it. While I've just seen DMD2 produces an output file. Is this a D1 bug? I get exactly the same thing. Running with D1 gives an empty file and running with D2 gives a file with content. I'd say it looks like a bug, so bugzilla, here I come :-) -- Derek Parnell Melbourne, Australia skype: derek.j.parnell
Re: [Issue 2865] RandomCover not random.
On Mon, 6 Jul 2009 17:17:27 + (UTC), d-bugm...@puremagic.com wrote: I'm not sure how this change escaped from the changelog ... May I suggest ... manual process? -- Derek Parnell Melbourne, Australia skype: derek.j.parnell
Re: Have language researchers gotten it all wrong?
On Sun, 05 Jul 2009 14:02:54 -0700, Walter Bright wrote: Certainly, this is a very interesting topic for D's development. http://www.reddit.com/r/programming/comments/8yeb0/cacm_almost_the_entire_software_community_has/ Yes, it is interesting and no, language researchers have not got it /all/ wrong. If /bug/ is defined as application behaviour that is contrary to its specification, then what we developers need when creating applications is a toolset that enables us to translate specifications into programs. Currently, a large part of that //toolset// is human skill - understanding a specification, selecting the appropriate algorithm, selecting the appropriate implementation of algorithms, avoiding scope creep, manually copying specification excerpts to code (eg. text of error messages, scalar factors, etc...) ... and the list goes on. These are areas in which research is sorely needed. Writing code is a minor part of application development. One can write code which works 100% correctly, according to the developer's understanding of the issue being addressed, but it doesn't mean that the application will satisfy the people who commissioned it. Static typing can help us avoid a specific subset of bug-types, and unit testing can also help us avoid another specific subset of bugs. These two sub-sets are not disjoint. They are also not the entire set of bug-types possible. Another important consideration, and this comes from over 30 years in the development world, many programs are not required to be 100% correct. Customers are often happy to trade-off time and cost for a small number of known bugs. The existence of bugs is not the main issue, but the impact of those bugs are. If they are trivial (from the point of view of the people paying for the development) then spending money on avoiding them is not rational. This is often hard for us quality purists to accept, and I grate every time I'm asked to compromise. But that's how the system works. This I suspect is why dynamic typed languages are proving popular, because you can get a 99% correct program shipped without having to spend 200% of the money available. -- Derek Parnell Melbourne, Australia skype: derek.j.parnell
Re: Linker problem
On Sun, 05 Jul 2009 18:55:57 -0700, David B. Held wrote: I just upgraded to 2.029 and now I have this problem: I have this too, and I'm using 2.030. It works fine with v1.045. -- Derek Parnell Melbourne, Australia skype: derek.j.parnell
Re: Give me a break
On Thu, 02 Jul 2009 13:55:56 -0700, Walter Bright wrote: Jason House wrote: Walter Bright Wrote: My general experience with posted compiler patches is about half of them are good, the other half are incorrect and require more for the bad half, do you comment in the bug reports about why you think the patches are bad? Sometimes, but not usually. I doubted anyone cared as long as they got fixed one way or another. Bzzzt ... wrong answer. -- Derek Parnell Melbourne, Australia skype: derek.j.parnell
Re: optlink on multicore machines
On Tue, 30 Jun 2009 20:54:55 +0200, dennis luehring wrote: Walter Bright schrieb: BCS wrote: I IS running fine on 3 or 4 multicore machines around here. That's a mystery, then. thats the wonderfull world of hard to catch and reproduce multithreading problems - hope D will help here in the future Ok then ... so optlink is going to be rewritten in D - excellent! And good luck to the brave developer too. -- Derek Parnell Melbourne, Australia skype: derek.j.parnell
Re: Dejavu
On Fri, 26 Jun 2009 01:12:34 -0700, Walter Bright wrote: Robert Clipsham wrote: I'd like to know what you think on each of these matters, and hopefully inspire us to take some action to make sure D succeeds. Pick one of the items you find the most interesting, and work on it! I've picked the docs. I'm attempting to remove all hardcoded HTML tags from the .dd files. To what address do I send the updated files? -- Derek Parnell Melbourne, Australia skype: derek.j.parnell
Re: Dejavu
On Tue, 30 Jun 2009 23:08:02 + (UTC), BCS wrote: Reply to Derek, On Fri, 26 Jun 2009 01:12:34 -0700, Walter Bright wrote: Robert Clipsham wrote: I'd like to know what you think on each of these matters, and hopefully inspire us to take some action to make sure D succeeds. Pick one of the items you find the most interesting, and work on it! I've picked the docs. I'm attempting to remove all hardcoded HTML tags from the .dd files. To what address do I send the updated files? I'd e-mail patches to Walter or attach them to an issue in the issue tracker. Either way make sure Walter knows about them. I've tried (twice) to email them to newshou...@digitalmars.com but have not receive any acknowledgement that they have been received so I don't actually know if Mr B is getting them. What I'd like is Walter to tell me/us where to send such things. I've scanned the website for information but can't find anything there. -- Derek Parnell Melbourne, Australia skype: derek.j.parnell
Re: Dejavu
On Tue, 30 Jun 2009 23:08:02 + (UTC), BCS wrote: Reply to Derek, On Fri, 26 Jun 2009 01:12:34 -0700, Walter Bright wrote: Robert Clipsham wrote: I'd like to know what you think on each of these matters, and hopefully inspire us to take some action to make sure D succeeds. Pick one of the items you find the most interesting, and work on it! I've picked the docs. I'm attempting to remove all hardcoded HTML tags from the .dd files. To what address do I send the updated files? I'd e-mail patches to Walter or attach them to an issue in the issue tracker. Either way make sure Walter knows about them. By the way, I'm using Windows so I don't know how to do a 'patch' file. I don't know of any Microsoft supplied tool distributed with XP that creates patch files. Any idea of how I can do this? -- Derek Parnell Melbourne, Australia skype: derek.j.parnell
Re: Dejavu
On Tue, 30 Jun 2009 23:37:56 + (UTC), BCS wrote: Hello Derek, By the way, I'm using Windows so I don't know how to do a 'patch' file. I don't know of any Microsoft supplied tool distributed with XP that creates patch files. Any idea of how I can do this? Use SVN. I'm assuming you got the .dd files that way. I think the command line tools will do it and I know tortoiseSVN can. It even tags the result with the version it's off of. Thanks, that worked perfectly. -- Derek Parnell Melbourne, Australia skype: derek.j.parnell
Re: Give me a break
On Mon, 29 Jun 2009 09:21:29 +0300, Yigal Chripun wrote: Jarrett Billingsley wrote: With four or five people having voiced concerns over the future of D in the past week or so, what's the busiest discussion? int.nan, of course. Come on. Get with the program. Enough already with the bikeshed bullshit. There are far more important issues at hand. if you do not want to discuss a particular topic than by all means do not participate in it. do not tell other people what to think and what to write. this is not china and you are not the great firewall. grow up. if you want a moderated NG than ask Walter to create one. This is *not* such a NG and people *will* discuss whatever they want, whether you like it or not. I agree with both of you. -- Derek Parnell Melbourne, Australia skype: derek.j.parnell
Re: Give me a break
On Mon, 29 Jun 2009 23:05:29 +0200, Tom S wrote: thirdly, D has a dictator, Walter Bright, which decides its fate and we have almost zero influence on this. I thought The needs and contributions of the D programming community form the direction it goes.. LOL ... yeah, right. -- Derek Parnell Melbourne, Australia skype: derek.j.parnell
Re: Dejavu
On Thu, 25 Jun 2009 20:44:04 +0100, Robert Clipsham wrote: Bud hasn’t been updated in a long time, which is annoying, since there are some really irritating bugs. Like what? Have these been reported? -- Derek Parnell Melbourne, Australia skype: derek.j.parnell
Re: Dejavu
On Thu, 25 Jun 2009 18:28:53 -0400, Jarrett Billingsley wrote: All of the bugs I've run into in bud have already been reported by others. I think I know what I'm doing this weekend ;-) -- Derek Parnell Melbourne, Australia skype: derek.j.parnell
Re: Dejavu
On Fri, 26 Jun 2009 12:55:32 +1200, Tim Matthews wrote: Did you take note of what I said in d.learn under a subject named Tango Jake or other build system for Linux. Actually I tried hard to ingore that one ... just kidding :-) I might have to come back to you on this one. I'll try to reproduce it but not sure if I can yet. I don't really want to download gtk or tango if I can help it. -- Derek Parnell Melbourne, Australia skype: derek.j.parnell
Re: D2 vs D1
On Thu, Jun 18, 2009 at 11:56 AM, BCSn...@anon.com wrote: Hello steel, build tools: ??? haven't followed that much. I use a command prompt for simple stuff and for the rest I need make. you: dmd main.d me: bud main you: dmd main.d foo.d me: bud main you: dmd main.d foo.d and.d lots.d of.d other.d stuff.d me: bud main you: 90% of the time that I need more than that, I'm getting into non D build steps so nothing short of a fully general system able to run arbitrary command will cut it. me: bud main :-) -- Derek Parnell Melbourne, Australia skype: derek.j.parnell
Re: Ranges
On Thu, 18 Jun 2009 21:00:08 -0400, bearophile wrote: Thank you Derek Parnell for your nice summary about ranges: with to your post my understanding of this topic has gone from 10% to 15% :-) LOL ... glad to have helped a tiny bit. There are things I don't understand from what you have written: OutputRange ... In what othr situations you may use/need an OutputRange? I haven't got a clue. I'm only trying to put into simpler words what I read in the official documentation. ForwardRange ... I don't understand and I don't know what checkpointing may mean there. It's just a way to save your place in an iteration so that presumably you can come back to that spot later on. I suggest to explain those things better, and then add 3 or more examples (very different from each other, complete, real-world and ready-to-be-copied-pasted-and-run, like you can find in every page of Borland Delphi documentation) for each kind of range. And then to put the page on the D Wiki :-) That would be nice. Hmmm... I'll see if I can do something ... Now I admit that these are not method names I would have choosen ... Andrei has shown that inventing very good names for those methods isn't easy... Yes, he certainly has. And putting lot of uppercase letters in the middle of those names isn't nice, nor handy, and it's visually noisy. Eye-of-the-beholder situation. Whether one uses getelement, get_element, GetElement, Get_Element, getElement, GETELEMENT, element.get, ... is beside the point. What I was trying to show was that the current names do not intuitively tell me what is the purpose of the methods. Does 'empty()' return a Boolean that tells me if the set is empty or not, or does it return an empty set, or does it cause the set to become empty, ??? A method name that consists of a single word that can be interpreted as an adjective or a verb or a noun, etc, is ambiguous, IMO. That is why in imperative languages I prefer to see method names that reduce the potential for ambiguous interpretations by using the form verb[adjective]noun is_empty get_front add_element get_background_color etc ... Of course, if an unambiguous name exists it should be used, and there are also abbreviations that can be employed. But anyhow, I digress as this is just a personal style issue and not worth discussing at this point. -- Derek Parnell Melbourne, Australia skype: derek.j.parnell
Re: Ranges
On Thu, 18 Jun 2009 19:07:06 -0700, Robert Fraser wrote: I think an OutputRange doesn't have to be an InputRange. It just needs put(). You're right. I misread the documentation on that one. -- Derek Parnell Melbourne, Australia skype: derek.j.parnell
Re: Tango Jake or other build system for Linux
On Sun, 14 Jun 2009 15:16:51 + (UTC), Michal Minich wrote: Is there any tool for Linux that can parse imports of files and invoke compiler with all project files? (And preferably one which does not require any configuration, except choosing compiler). http://www.dsource.org/projects/build -- Derek Parnell Melbourne, Australia skype: derek.j.parnell
Re: why implicitly allowing compare ubyte and byte sucks
On Fri, 12 Jun 2009 02:08:14 +0200, Don wrote:
Walter Bright wrote:
davidl wrote:
It seems that comparing two different operands with different size
makes no sense. The compiler should issue an error against that.
Consider:
byte b;
if (b == 1)
here you're comparing two different sizes, a byte and an int.
Disallowing such (in its various incarnations) is a heavy burden, as the
user will have to insert lots of ugly casts.
There really isn't any escaping from the underlying representation of
2's complement arithmetic with its overflows, wrap-arounds, sign
extensions, etc.
The problem is a lot more specific than that.
The unexpected behaviour comes from the method used to promote two types
to a common type, when both are smaller than int, but of different
signedness. Intuitively, you expect the common type of {byte, ubyte} to
be ubyte, by analogy to {int, uint}-uint, and {long, ulong}-ulong. But
instead, the common type is int!
I think that the common type for byte and ubyte is short. Byte and ubyte
have overlapping ranges of values (-127 to 127) and (0 to 255) so a common
type would have to be able to hold both these ranges at least, and short
(16-bit signed integer) does that.
--
Derek Parnell
Melbourne, Australia
skype: derek.j.parnell
Re: Inside the switch statement
On Tue, 9 Jun 2009 16:28:58 + (UTC), BCS wrote:
Hello grauzone,
http://groups.google.com/group/net.lang.c/msg/66008138e07aa94c
Many people (even Brian Kernighan?) have said that the worst feature
of C is that switches don't break automatically before each case
label.
Oh god, that's from 1984, and even today we're struggling with this
bullshit in the most modern dialect of C, D.
I'm sorry, you don't have my sympathy on this one. There are to many place
I've used fall throught to chuck it out.
It is not an either-or situation.
We achieved both models in the up-coming version of Euphoria, at the minor
cost of a new keyword.
By default, it does not do fallthru. Each case is its own master and the
physical placement inside the switch is not relevant.
switch EXPR do
case VAL1 then
STATEMENTS...
case VAL2 then
STATEMENTS...
case VAL3 then
STATEMENTS...
end switch
But, if for some good reason you need to do fallthru ...
switch EXPR with fallthru do
case VAL1 then
STATEMENTS...
case VAL2 then
STATEMENTS...
case VAL3 then
STATEMENTS...
end switch
It that situation, the absence of a 'break' means that program flow falls
through to the next case. You can still insert 'break' at any point to skip
to the end of the switch statement, even in the default format. However,
additionally in the default format you can use 'fallthru' to let flow drop
to the next case
switch EXPR do
case VAL1 then
STATEMENTS...
case VAL2 then
STATEMENTS...
fallthru -- This makes flow fall through.
case VAL3 then
STATEMENTS...
end switch
So, if one considers improving D's switch, it is possible to have both
models if one is not frightened of new keywords.
For example ...
select (EXPR) {
case VAL1:
STATEMENTS...
case VAL2:
STATEMENTS...
case VAL3:
STATEMENTS...
}
would only execute ONE of the selected cases.
--
Derek Parnell
Melbourne, Australia
skype: derek.j.parnell
Re: Porting 1.x libraries to 2.x
On Wed, 10 Jun 2009 04:30:53 -0400, John C wrote:
What strategies do library authors have for maintaining two
versions of a their code - one for D 1.0 and another for 2.0?
When they make changes to one version, do they manually copy
them into the other branch? Or is there a way of automating
the process?
Version blocks don't seem to help much.
I'm finding it very tedious and somewhat haphazard going the
manual route - it's easy to forget, and sometimes I get so
carried away adding new code to my 1.0 library that it's a
struggle to recall every line I've changed.
Ideally, I'd just update the 1.0 branch and run a script to
make the necessary changes for it to compile with DMD 2.0. Do
Unix/Linix people use the patch command for this (and is there
a Windows equivalent)?
You're correct in that version{} is no help at all. I use a text macro
program to help me.
--
Derek Parnell
Melbourne, Australia
skype: derek.j.parnell
Re: DMD 2.030 doesn't exist
On Thu, 04 Jun 2009 19:42:52 -0400, superdan wrote: my philosophy lesson's worth wut u paid fer it. Yes it is. -- Derek Parnell Melbourne, Australia skype: derek.j.parnell
Re: Why are void[] contents marked as having pointers?
On Fri, 5 Jun 2009 07:15:11 + (UTC), BCS wrote: Hello Vladimir, I don't see why you'd want to work with arrays of signed bytes. I can think of a number of cases where I would expect numbers to be in a range like [-20,+20], for instance, delta of small integral value or golf scores relative to par. Or sound wave sample points [-127, 127] -- Derek Parnell Melbourne, Australia skype: derek.j.parnell
Re: Operator overloading, structs
On Thu, 04 Jun 2009 10:06:45 +0300, Yigal Chripun wrote:
Andrei Alexandrescu wrote:
Yigal Chripun wrote:
your abstraction inversion example doesn't apply here. The problem I
see is the narrowing implicit cast, i.e. int values behave like
booleans. I have no problem with the reverse which is what your
example is about.
An int does not convert to bool implicitly. An int can be tested with
if, which is a different thing.
Andrei
that is an implicit cast.
what I'm saying is that:
int a = .. ;
if (a) { .. }
this should be a compiler error IMO.
I'm not agreeing with you, Yigal.
I think that the idiom you described is not equivalent to
if (a == TRUE) { .. }
but really
if (a != 0) { .. }
when 'a' is an integer of any size or sign.
This should *not* be a compiler error as it is a convenient shorthand for
some coders. Personally, I try not to code this idiom because I find it
misleading in terms of self documentation ... but then I'm against using
goto as well ;-)
--
Derek Parnell
Melbourne, Australia
skype: derek.j.parnell
Re: DMD 2.030 doesn't exist
On Thu, 04 Jun 2009 05:58:30 -0400, A.M. wrote: Nick Sabalausky Wrote: A.M. ama...@gmail.com wrote in message news:h083sf$h7...@digitalmars.com... Christopher Wright Wrote: A.M. wrote: please correct that, as it gives a bad picture of ur project. The Ur-Project has arrived! Photos at 11 -- we're waiting on a replacement lens. what is that?? are u making fun of me, or u misunderstood what I was saying? if u think I was wrong when I said so, correct me rather than just laughing at me. You is spelled y-o-u, and your is spelled y-o-u-r. This isn't kindergarten, garbage like ur doesn't belong here. I didn't know it would make such a difference.PERIOD Well, it turns out that it does. No one is criticizing you personally, just trying to help with your education. Correct spelling and grammar are indications that the person does not tolerate mediocrity. Spelling variations that are cute or modern, are fine in other contexts but not really in a technical forum where there are readers from many different cultures and spoken languages. Using the standard form of English is also a sign of politeness and inclusiveness. In general, we are attempting to communicate our thoughts here so we need to do that in a way that makes it easy for all potential readers in the forum. -- Derek Parnell Melbourne, Australia skype: derek.j.parnell
Re: DMD 2.030 doesn't exist
On Thu, 04 Jun 2009 11:48:24 -0400, superdan wrote: I can spell and capitalize and shit. It's just not fun. I have no doubt about that at all. You appear to be very intelligent and nearly always have something useful to contribute. And of course you having fun is much more important that you trying to help others understand ... now I understand you a bit more. -- Derek Parnell Melbourne, Australia skype: derek.j.parnell
Re: static this sucks, we should deprecate it
On Sat, 30 May 2009 03:52:44 +1200, Tim Matthews wrote:
Walter Bright wrote:
It's unreliable because how do you specify the load order? And how does
the user relate that to the source semantics?
grauzone suggested this earlier:
static this {} //full dependencies (all import statements)
static this : a, b {} //only dependent from module a and b
static this : void {} //no dependencies at all
Is there a situation in which the dependancies are not known by the coder
writer? For example, linking in some object code that has a static this{}
section and not having the source code for that object code.
--
Derek Parnell
Melbourne, Australia
skype: derek.j.parnell
Re: going beyond your bounds
On Thu, 21 May 2009 04:51:16 -0400, MLT wrote:
After a discussion on digitalmars.D I played with arrays a bit. Look at the
following code:
int[] a = [1,2,3,4,5,6,7,8,9] ;
int[] b = a ;
a ~= 10 ;
b ~= 11 ;
b[0] = 12 ;
Stdout(b).newline ;
Stdout(a).newline ;
The result is:
[12, 2, 3, 4, 5, 6, 7, 8, 9, 11]
[12, 2, 3, 4, 5, 6, 7, 8, 9, 11]
Which means that even though b was set only to a[0..10], after expanding b,
also has direct access to element a[10]. But
int[] a = [1,2,3,4,5,6,7,8,9] ;
int[] b = a ;
a ~= 10 ;
b.length = b.length+1 ;
b[0] = 11 ;
Stdout(b).newline ;
Stdout(a).newline ;
Gives
[11, 2, 3, 4, 5, 6, 7, 8, 9, 0]
[11, 2, 3, 4, 5, 6, 7, 8, 9, 0]
Now b is expanded in length, but a side effect is that a[10] is set to 0
(i.e. initialized).
In the end, I think b can only see things that happen to a[10] after it
expanded, but not before. It seems there is no way for the following to work:
int[] a = [1,2,3,4,5,6,7,8,9] ;
int[] b = a ;
a ~= 10 ;
At this point, element a[10]=10 will never be visible to b. b can expand to
it, but by doing that, a[10] will be overwritten.
Is this on purpose? It could also be useful to have b.length=b.length+1 which
only initializes memory that has not been initialized before.
Yes it is on purpose.
Here is what is happening ...
The contents of the array variable is actually a 2-element struct {addr,
length}. When you assign one array to another, that struct is what is
copied, not the array data itself.
int[] a = [1,2,3,4,5,6,7,8,9] ;
// Now 'a' contains {adr, 9}
int[] b = a ;
// Now 'b' contains {adr, 9}
a ~= 10 ;
// Now 'a' contains {adr, 10} -- The address doesn't change
-- because the buffer allocation
-- still enough room for another element.
b ~= 11 ;
// Now 'b' contains {adr, 10} -- The address doesn't change
-- because the buffer allocation
-- still enough room for another element
-- And that new element overwrote the '10'
-- appended to 'a'.
b[0] = 12 ;
// The element at address 'adr' is modified.
// As both 'a' and 'b' point to the same area
// it appears that updating 'b' changes 'a'.
The safe way to copy the data of an array is to do ...
int[] a = [1,2,3,4,5,6,7,8,9] ;
int[] b = a.dup ; // COPY a's data to to b.
a ~= 10 ;
b ~= 11 ;
b[0] = 12 ;
The result should now be:
[1, 2, 3, 4, 5, 6, 7, 8, 9, 10]
[12, 2, 3, 4, 5, 6, 7, 8, 9, 11]
So remember, assigning one array to another is just creating an alias to
the original array. You end up with two arrays pointing to the same data
buffer.
--
Derek Parnell
Melbourne, Australia
skype: derek.j.parnell
Re: going beyond your bounds
On Thu, 21 May 2009 05:58:04 -0400, MLT wrote:
Because new elements are pre-initialized in D.
Just by increasing the length, you 'create' a new element (from the 'b'
point of view) so D initializes it.
(We were talking about something like
int a[] = [1,2,3,4,5] ;
b = a ;
a ~= 6 ;
b.length = b.length+1;)
Hmmm... yes, that has some logic to it.
D does keep track of the actual array of integers that both a and b point to
Not really. The original data is a literal so it is supposed to be
unmodifiable (I think Linux enforces it but not sure).
and knows when to allocate new memory for the array.
It allocates new RAM when the current buffer allocation will not be large
enough to hold the new elements. When it does this, it allocates the new
buffer and copies the old data to it. This means that you cannot rely on
the alias 'feature' to work all the time.
For example ...
int[] a = [ some data ];
int[] b = a; // Ok, so both 'a' and 'b' point to the data now.
a ~= newone; // This can't fit in so an allocation occurs
// and the data copied, then 'a' is set to the
// the new buffer.
// BUT 'b' still points to the old buffer.
So in theory it could be possible that when b.length increases,
initialization only happens if this memory is uninitialized.
Theoreticaly yes, but it isn't going to happen.
On the other hand, I guess that if you get an array, say b,
in a function, you might rely on the fact that when you
extend b.length, the area will be initialized...
This is also a trap. If the function increases the length of the array
passed to it, there will be so initialization happening, but when the
function returns, the array variable passed to the function is unchanged.
Its length is not modified so the new initialized data is not part of the
array. This is because when you pass an array to a function, it's that
small struct that is passedon the stack, so changing that will not change
the argument's properties.
eg.
void func(int[] x)
{
x.length = x.length + 1;
}
int a[] = [1,2,3];
func(a);
writefln(%s, a) //-- [1,2,3] and not [1,2,3,0]
--
Derek Parnell
Melbourne, Australia
skype: derek.j.parnell
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: 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 should be deprecated with extreme prejudice
On Mon, 18 May 2009 12:59:08 -0400, bearophile wrote:
Or nicer:
alias somevery.long.struct.or.class[17].name as p {
y += p.x;
++p.x;
}
Yeah, that's nice too.
--
Derek Parnell
Melbourne, Australia
skype: derek.j.parnell
Re: with should be deprecated with extreme prejudice
On Mon, 18 May 2009 09:55:42 -0700, Sean Kelly wrote:
Derek Parnell wrote:
I guess the reason for using with() is to avoid typing repetitive stuff.
Would this work instead ...
int x, y;
with (p as somevery.long.struct.or.class[17].name)
{
y += p.x;
++p.x;
}
{
ref p = somevery.long.struct.or.class[17].name;
y += p.x;
++p.x;
}
Yes that would work too, and probably better code generation too.
The difference being that my suggestion is a compile-time behaviour and
yours is a run time behaviour.
--
Derek Parnell
Melbourne, Australia
skype: derek.j.parnell
Re: with still sucks + removing features + adding features
On Mon, 18 May 2009 14:33:29 -0400, bearophile wrote: 3) If you want to add a second kind of switch, then let's add a truly safer one, with no fall-through, etc. **WARNING** an off-topic aside follows ... The next version of the Euphoria programming language has implemented 'switch'. The language only had 'if-elsif-' constructs before. The new 'switch' has this syntax ... 'switch' ['with fallthru'] 'do' 'case' EXPRESSION 'then' STATEMENTS [( 'break' | 'fallthru')] . . . 'end' 'switch' Yeah, I know is not a punctuation-heavy language like D, but get over that for now. The point is that by default the cases do not fallthru. If you want cases to fallthru by default you need to add the 'with fallthru' qualifier. Furthermore, each case can have 'break' to explicitly prevent it falling thru to the next case, or 'fallthru' to explicitly cause it to fall thru to the next case. If you have neither, then it does the default action indicated on the 'switch' line. procedure classify(char c) write(You passed ) switch c do case '#' then writeln(a hash sign.) case in 012345679 then writeln(a digit.) case 'A' to 'Z', 'a' to 'z' then writeln(an ASCII character.) case '.', ',', ':', ';', '!', '?' then writeln(a punctuation mark.) case else writeln(quite a character!) end switch end procedure -- Derek Parnell Melbourne, Australia skype: derek.j.parnell
Re: with still sucks + removing features + adding features
On Mon, 18 May 2009 19:53:51 -0400, bearophile wrote: Bill Baxter: Thinking about it more, I guess you must actually be seeing it as a rule of'..' always does the most useful thing, Such attitude/purposes have created the monkey mess named Perl :-] I submit the D words 'static', 'auto' and 'scope' as examples of this too. -- Derek Parnell Melbourne, Australia skype: derek.j.parnell
Re: with still sucks + removing features + adding features
On Mon, 18 May 2009 19:38:05 -0500, Andrei Alexandrescu wrote:
I like my syntax better than all you mentioned, by a mile.
Problem: Define a syntax that indicates a specific range of values for a
single case statement.
Constraints:
(1) No new keywords permitted.
(2) No new operators permitted.
(3) Must indicate an *inclusive* range
(4) A range has an explicit starting value and ending value
(5) A range has an implicit step value of 1.
(6) Must not be keystroke-heavy
(7) Must be easy to read
(8) Must be easy to remember while writing
(9) Must not be ambiguous with existing syntax
(10) Must be consistent with existing syntax
(11) Must take the general form ...
'case' RANGE ':'
Andrei ...
case FIRST .. case LAST :
[[ -(8)- The second 'case' is easy to forget to write ]]
[[ -(10)- The .. means exclusive range elsewhere but not here ]]
bearophile ...
case FIRST .. LAST+1 :
[[ -(8)- The +1 is easy to forget to write ]]
JB (first pass)
case FIRST .. LAST :
[[ -(10)- inconsistent with exclusive range syntax]]
So just as a thought without a lot of adademic introspection
derek ...
case [FIRST ; LAST] :
sample code ...
void classify(char c) {
write(You passed );
switch (c) {
case '#':
writeln(a hash sign.);
break;
case ['0' ; '9']:
writeln(a digit.);
break;
case ['A' ; 'Z'], ['a' ; 'z']:
writeln(an ASCII character.);
break;
case '.', ',', ':', ';', '!', '?':
writeln(a punctuation mark.);
break;
default:
writeln(quite a character!);
break;
}
}
--
Derek Parnell
Melbourne, Australia
skype: derek.j.parnell
Re: with still sucks + removing features + adding features
On Mon, 18 May 2009 21:47:01 -0500, Andrei Alexandrescu wrote: Derek Parnell wrote: On Mon, 18 May 2009 19:31:23 -0500, Andrei Alexandrescu wrote: I completely disagree that that's a special case. .. is punctuation. You can't pretend punctuation has the same meaning everywhere in a programming language. I'm a bit confused. Are you saying that one must expect that the meaning of punctuation in a programming language depends on the context the punctuation is found in? How many meanings does '[' have in your favorite programming language? One. But how is your question an answer to my question? -- Derek Parnell Melbourne, Australia skype: derek.j.parnell
Re: with still sucks + removing features + adding features
On Mon, 18 May 2009 21:58:19 -0500, Andrei Alexandrescu wrote:
Derek Parnell wrote:
On Mon, 18 May 2009 19:53:51 -0400, bearophile wrote:
Bill Baxter:
Thinking about it more, I guess you must actually be seeing it as a
rule of'..' always does the most useful thing,
Such attitude/purposes have created the monkey mess named Perl :-]
I submit the D words 'static', 'auto' and 'scope' as examples of this too.
When was the last time you had trouble with static? Can you show a
snippet of code that's confusing because of it?
not having a trouble and not being consistant are two different things.
For example, I have no trouble with .. meaning exclusive range inside a
'[' ']' pair, and an inclusive range in a 'case' statement. That does not
trouble me at all and yet it is an inconsistancy.
But back to your question ... here is 'static' used with three different
meanings within three lines of code.
---
module xyzzy;
import std.stdio;
version(X) const int y = 1;
else const int y = -1;
static this() {
static if (y == 1)
static int x = 0;
else
static int x = 42;
writefln(X=%d Y=%d, x,y);
}
void main()
{
}
--
But maybe that's just me?
--
Derek Parnell
Melbourne, Australia
skype: derek.j.parnell
Re: with still sucks + removing features + adding features
On Mon, 18 May 2009 20:05:14 -0600, Rainer Deyke wrote: Bill Baxter wrote: Although non-inclusive ranges are common enough that they deserve their own syntax, I think inclusive ranges are *also* important enough to deserve their own syntax. Writing '+1' is often error-prone or even just plain wrong (such as when it leads to integer overflow). Agreed. I favor the syntax 'a ... b' for inclusive ranges. It's easy to read and similar to 'a .. b' without being too similar. It does require the programmer to pay attention, but that's unavoidable. From there, it naturally follows that 'case's in a 'switch' statement should follow the same convention. Sorry, but I don't share your sense of easy to read here. The eye can glaze over the third dot very easily and just not notice it. -- Derek Parnell Melbourne, Australia skype: derek.j.parnell
Re: with still sucks + removing features + adding features
On Mon, 18 May 2009 23:15:17 -0400, Jeremie Pelletier wrote: Derek Parnell Wrote: case [FIRST ; LAST] : Personally I feel that your syntax breaks the condition (6) Must not be keystroke-heavy Huh?? By keystroke-heavy I meant the number of keyboard presses the finger would have to do to write it. Ignoring FIRST/LAST, I have 3 (three) keystrokes and Andrei has 8 keystrokes? Me = [ ; ] Andrei = SHIFT : .. case I like Andei's syntax best but as previously stated, its ambiguous with exclusive ranges. Maybe the solution is a second range operator that is inclusive, such as: case FIRST ... LAST: Which is 3 keystrokes too. Sorry, I don't understand what you mean by saying my suggestion breaks (6). -- Derek Parnell Melbourne, Australia skype: derek.j.parnell
Re: with still sucks + removing features + adding features
On Mon, 18 May 2009 19:24:13 -0400, bearophile wrote: Christopher Wright: The more common suggestion is: alias bar = foo; This is acceptable, thank you :-) Now I'd like to know what others think about that. But does that mean 'when I write bar I really mean foo' or visa versa? Just pointing out that the '=' sign doesn't really automatically make it fully intuitive. -- Derek Parnell Melbourne, Australia skype: derek.j.parnell
Re: with still sucks + removing features + adding features
On Mon, 18 May 2009 23:09:21 -0500, Andrei Alexandrescu wrote: I'm now sorry I even mentioned the blessed thing. This must have been the worst discussion on language design, ever. LOL ... especially when these discussions have no influence on whatever the outcome will eventually be. -- Derek Parnell Melbourne, Australia skype: derek.j.parnell
Re: with still sucks + removing features + adding features
On Mon, 18 May 2009 23:20:11 -0500, Andrei Alexandrescu wrote: Derek Parnell wrote: But you never asked for the name of my favourite language? Yah, I realized my flawed supposition after sending :o). So, what is it? Actually I have two - Forth and Euphoria, but D comes a close second. Anyways ... back to the actually question that I asked and you haven't got around to answering yet -- (you're not doing politian training are you :-)) On Mon, 18 May 2009 19:31:23 -0500, Andrei Alexandrescu wrote: I completely disagree that that's a special case. .. is punctuation. You can't pretend punctuation has the same meaning everywhere in a programming language. I'm a bit confused. Are you saying that one must expect that the meaning of punctuation in a programming language depends on the context the punctuation is found in? If so, then .. in [a .. b] can mean exclusive range and .. in case a .. b: can mean inclusive range, no? -- Derek Parnell Melbourne, Australia skype: derek.j.parnell
Re: with should be deprecated with extreme prejudice
On Sun, 17 May 2009 20:56:14 -0500, Andrei Alexandrescu wrote: Andrei Alexandrescu Wrote: I think with is a very dangerous feature due to the way it hides symbols. Jason House wrote: This. Just issue an error/warning if something in the with shadows something outside. That way, if the struct/class/template/whatever changes, affected code will be notified. On Sun, 17 May 2009 20:56:14 -0500, Andrei Alexandrescu wrote: No warning, error! This is a great idea Jason. Wow, that's they way I thought it already worked. I never use 'with' because of the reasons that Andrei has already cited, but if it doesn't trip such syntax-mines already then I'm even more glad that I haven't used it. So yes Jason, that idea has my support too ... though I still can't see me using the construct anytime soon. -- Derek Parnell Melbourne, Australia skype: derek.j.parnell
Re: OT: on IDEs and code writing on steroids
On Mon, 18 May 2009 12:43:34 +1000, Daniel Keep wrote: You realise that in order to be using rebuild, I HAVE to also have DSSS, right? I'm pretty sure Gregor stopped releasing rebuild-only packages quite some time ago. Not to trumpet my own horn, but have you considered my build tool called 'Bud'? And if you have then what is missing from it that you need? http://www.dsource.org/projects/build Gregor derived DSSS from my project. -- Derek Parnell Melbourne, Australia skype: derek.j.parnell
Re: with should be deprecated with extreme prejudice
On Sun, 17 May 2009 19:33:35 -0500, Andrei Alexandrescu wrote:
I think with is a very dangerous feature due to the way it hides
symbols. It essentially makes the feeblest attempt at modular reasoning
utterly impossible:
int x, y;
with (whatever)
{
y += x;
++x;
}
I guess the reason for using with() is to avoid typing repetitive stuff.
Would this work instead ...
int x, y;
with (p as somevery.long.struct.or.class[17].name)
{
y += p.x;
++p.x;
}
--
Derek Parnell
Melbourne, Australia
skype: derek.j.parnell
Re: std.string and std.algorithm: what to do?
On Sat, 16 May 2009 04:36:29 +0300, Georg Wrede wrote: Well, if you wrote funcA(find(needle, haystack) haystack.length, xyzzy) then it is you, who decided to use funcA. Now, if that wasn't to your liking, you'd of course write your own funcA (or use another function), that works as you want. Therefore, you're in control of funcA() here. Thank you, Georg. That is a conclusion I would never have come to. -- Derek Parnell Melbourne, Australia skype: derek.j.parnell
Re: std.string and std.algorithm: what to do?
On Thu, 14 May 2009 16:59:32 -0400, Steven Schveighoffer wrote: I guess I understand the mentality of picking -1 or uint.max as a reasonable failure return, but what I don't understand is why you would do so when you could use the length of the string, which is useful for many other purposes. -1 or uint.max just is a failure, and needs to be checked, it can't be used to do any slicing operations. A problem with .length is that it requires the knowledge of the string for it to be meaningful. If find() can return any integer, we can only know if that integer represents WasFound or WasNotFound if we have the string in context. Currently we can do this ... funcA( find(needle, haystack), xyzzy); and 'funcA' doesn't need to know anything more about the 'haystack' to work. If find/indexOf() can return any integer we would have to code ... funcA( indexOf(needle, haystack) != haystack.length ? uint.max : 0, xyzzy); (assuming that funcA is expecting uint.max to mean WasNotFound). So there are really arguments for employing both methods. It just depends on why you are trying to 'find' stuff. -- Derek Parnell Melbourne, Australia skype: derek.j.parnell
Re: std.string and std.algorithm: what to do?
On Thu, 14 May 2009 17:33:40 -0400, Steven Schveighoffer wrote: On Thu, 14 May 2009 17:21:02 -0400, Derek Parnell de...@psych.ward wrote: Not really. What could funcA possibly do with the index without the string itself? If it's just a flag (uint.max or not), then funcA should be: funcA(bool found, ...) and you call it with funcA(find(needle, haystack) haystack.length, xyzzy) This doesn't cause any problems with people who use Tango, which returns the length if not found. In other words, if you find yourself writing code to morph the length into uint.max or -1, you are thinking about the problem incorrectly. Who said that I had control of how funcA() was implemented? -- Derek Parnell Melbourne, Australia skype: derek.j.parnell
Re: Please Vote: Exercises in TDPL?
On Thu, 14 May 2009 19:05:04 -0500, Andrei Alexandrescu wrote: A chunky fragment of TDPL will hit Rough Cuts soon enough. I'm pondering whether I should be adding exercises to the book. Some books have them, some don't. Pros: As I'm writing, I've come up with some pretty darn cool exercise ideas. Won't hurt to put those in then :-) I remember working through some of Knuth's exercises and enjoying the challenge, even though I failed to solve some of the advanced ones. I think any exercises you put in should be incidental to the book's purpose. I mean, that the book should be just as useful with or without those exercises; they would exist for the curious or adventurous. And in any case, not only should the solutions be provided, a way to /get/ to the solutions should also be shown; I can remember seeing some exercises' solution and thinking Huh? How did he get that? -- Derek Parnell Melbourne, Australia skype: derek.j.parnell
Re: struct opCmp?
On Thu, 14 May 2009 18:21:14 -0400, Nick Sabalausky wrote: Lars T. Kyllingstad pub...@kyllingen.nospamnet wrote in message news:gui4ml$2g0...@digitalmars.com... I think you have to use opEquals to overload ==. opCmp only applies to , =, , and =. Oh, I figured either opEquals would be defined in terms of opCmp or an overloaded opCmp would imply a new opEquals defined in terms of it, or something like that. See http://www.digitalmars.com/d/1.0/operatoroverloading.html for actual list. -- Derek Parnell Melbourne, Australia skype: derek.j.parnell
Re: D users in Munich, Rome, Venice, or Frankfurt?
On Wed, 13 May 2009 16:04:49 -0400, Nick Sabalausky wrote: BCS n...@anon.com wrote in message news:a6268ff5b338cba14afe6ac...@news.digitalmars.com... I have more problems with singular they making it hard to exclude the plural than anything else. It's right up there with (but not as common as) some neutral statements being promoted to negative ones: I don't like cheese vs. I dislike cheese, making it hard to state some things. That's a *HUGE* pet peeve of mine. I get sooo frustrated when attempting make a neutral statement around people who just simply will not accept that neutral statements exist. A similar thing that also drives me absolutely crazy is when people take a *comparison* and automatically assume that absolute statements are being made about one or both of the things being compared. I have the same personality disorder ;-) But if people behaved as you suggested, then what would lawyers, politicians and union bosses be doing for a lot of their time? -- Derek Parnell Melbourne, Australia skype: derek.j.parnell
Re: Wrt. threadlocal by default: shared module constructors
On Wed, 13 May 2009 18:31:57 -0700, Brad Roberts wrote: Which argues for the globals to be immutable, so the cost goes away and we're back where we started. :) Which actually brings back memories of my COBOL and IBM/360 assembler days. The mantra then was everything must be reenterant so the norm was that mutable globals were seen as evil. However, later I worked at a place where assembler abuse was taken to the artform level - self-modifying code was encouraged! -- Derek Parnell Melbourne, Australia skype: derek.j.parnell
Re: Split digitalmars.D newsgroup into .D and .D2 newsgroups?
On Tue, 12 May 2009 15:59:05 -0500, Andrei Alexandrescu wrote: Walter Bright wrote: BLS wrote: No, promoting D also means having a couple of newsgroup entries each day. Otherwise you'll have several 10 entries a month D newsgroups and this imo not very appealing to new visitors. In other words, Bier erm, quantity rulez. Yeah, I had second thoughts along those same lines. I think -users and -developers should work. It works for Boost very well. I'm not used to Boost groups, so who is expected to post to -users? Are they users of D (that is, application developers)? Who posts to -developers? Are they the people developing D itself or application/tool/library developers (otherwise known as users of D)? -- Derek Parnell Melbourne, Australia skype: derek.j.parnell
Re: Off topic
On Wed, 13 May 2009 00:46:25 +0200, BLS wrote: Derek, may I contact you by Skype ? Sure. -- Derek Parnell Melbourne, Australia skype: derek.j.parnell
Re: Migrating to Shared
On Tue, 12 May 2009 10:47:02 -0700, Walter Bright wrote: I wrote a brief article which should help: http://www.digitalmars.com/d/2.0/migrate-to-shared.html Good article. This is an exciting enhancment to an already exciting programming language. -- Derek Parnell Melbourne, Australia skype: derek.j.parnell
Re: D users in Munich, Rome, Venice, or Frankfurt?
On Wed, 13 May 2009 01:04:19 + (UTC), BCS wrote: Ah! One of my favorite qwerks of the English language, how to refer to a specific single someone of unknown gender without insulting them: it? I hate it but what can I do? Use they. Sure, its wrong but everyone knows what you mean. As in ... A good coder will write useful comments because *they* care. -- Derek Parnell Melbourne, Australia skype: derek.j.parnell
Re: Split digitalmars.D newsgroup into .D and .D2 newsgroups?
On Mon, 11 May 2009 17:26:54 -0700, Walter Bright wrote: Is this a good idea? Leave digitalmars.D as it is and just add digitalmars.D.future I suppose you could also add digitalmars.D.v1 for discussion just about that edition of D. -- Derek Parnell Melbourne, Australia skype: derek.j.parnell
Re: assignment: left-to-right or right-to-left evaluation?
On Mon, 11 May 2009 16:03:39 -0400, Nick Sabalausky wrote: I was giving a little bit of thought to assignment chaining the other day. Unless someone can point out why I'm wrong, I think some of the functional-style stuff we've been getting into can make assignment chaining obsolete. Hypothetical example: [mydic[x], mydic[y], mydic[z]].fill(mydic.length); I think something like that would be more clear than both the tmp and assignment chaining versions, and perhaps allow any language complexities that arise from the assignment chaining feature to be removed. This is close to what we are going to do for the Euphoria language. Currently, Euphoria does not allow assignment chaining (an assignment is not an expression) so the proposed syntax is ... (mydic[x], mydic[y], mydic[z]) = length(mydic) Plus that language evaluates the source expression before tackling the target expression, so your idea is not unheared of. -- Derek Parnell Melbourne, Australia skype: derek.j.parnell
Re: When will D1 be finished?
On Mon, 11 May 2009 14:43:58 -0700, Walter Bright wrote: Georg Wrede wrote: That day, there will not be a single person on Earth who knows such changes. Just like when we started on D2, nobody could have had any notion of how D2 looks today. And we still have an unpredictable amount of changes ahead of us in D2. For example, who can predict if Andrei or somebody else writes a post here that turns half of D2 on its head, and then we postpone everything to get that done. It's happened before, you know. I don't know of any language revision project that wound up where they said they were going at the outset. LOL, I can attest to that! The road trip that has been the next version of Euphoria has taken a few sudden and unexpected turns, plus a couple of dead-ends. Even now as we are about to release the first beta edition, we are finding that certain aspects might need a total redesign - yuck. Thankfully, releasing a series of alpha editions has enabled the user community to generate great feedback that has guided the road trip (including telling us that we went the wrong way occasionally). D1 is not complete. That has nothing to do with the bugs it still contains. It is not complete because there is documented functionality for which no implementation has yet been attempted. This assumes that the documentation is complete and accurate. The D-Team should be dedicating resources to ensuring that the D1 implementation and D1 documentation are in alignment with each other. By dedicating, I mean that is all that this D1-subteam of the D-Team work on - no D2 work at all. Any D1 fixes that need to be propagated to D2 should be done by the D2-subteam. Priority should be given to getting D1 completed. Getting D1 stable can be a focus once D1 is complete. Unless of course, D1 is just a prototype for D2 and will thus be discarded the instant that D2 is released. What are the support plans for D1 after D2 is released? (I consider current D2 releases as beta editions at best). -- Derek Parnell Melbourne, Australia skype: derek.j.parnell
Re: When will D1 be finished?
On Mon, 11 May 2009 16:25:24 -0700, Walter Bright wrote: Derek Parnell wrote: D1 is not complete. That has nothing to do with the bugs it still contains. It is not complete because there is documented functionality for which no implementation has yet been attempted. This assumes that the documentation is complete and accurate. The D-Team should be dedicating resources to ensuring that the D1 implementation and D1 documentation are in alignment with each other. By dedicating, I mean that is all that this D1-subteam of the D-Team work on - no D2 work at all. Any D1 fixes that need to be propagated to D2 should be done by the D2-subteam. Priority should be given to getting D1 completed. Please help me understand - why is contract inheritance preventing you from using D1? Exported templates haven't stopped anyone from using C++ compilers from Microsoft/Sun/Intel/etc. I don't think anyone has made a feature complete C99 compiler, either. Contract inheritance is NOT preventing me use D1. I have never, not once, said that it has. Is Contract Inheritance documented as being a part of D1's functionality? If yes, then is it implemented? If yes, then well done. If no, then is the documentation wrong or is DMD v1 incomplete? If Contract Inheritance is not documented as being a part of D1's functionality then why are we talking about it? I do NOT automatically associate completeness with worthiness. D1 is stable enough to use for production applications. I have never, not once, said otherwise. My thinking re completeness is just this ... Docs say X is a function point of D1. DMD v1 does not implement X. Therefore, DMD v1 is not a complete implementation of D1. That has NOTHING WHATSOEVER to do with deciding to use DMD v1 for important applications. It is an observation, not a criticism or a complaint. If was to complain, and I'm not, I might mention that sometimes the impression I get is that the D-team feels that DMD v1 is as complete as its ever going to be but won't admit it. If DMD v1 is intending to ever be a complete implementation of D1, then IMO there needs to be a concerted effort to reach a completed stage in DMD v1, independently of any work happening in the D2 arena. If this is not the intention, IMO, it ought to be stated clearly in the DMD v1 documentation that DMD v1 is not the definitive D1 implementation. That would slow down the rate of people complaining about it being incomplete. Unless of course, D1 is just a prototype for D2 and will thus be discarded the instant that D2 is released. What are the support plans for D1 after D2 is released? (I consider current D2 releases as beta editions at best). D1 will continue to be supported as long as there is a significant userbase for it. I've said this many times. Times change. People change. Policies change. Readers of this newsgroup change. I just wanted confirmation of what the current policy was. Is this policy recorded in the DMD v1 documentation? I couldn't find it. I also fail to understand this perception that D1 is abandoned. Every month an update is released for it that fixes a load of problems. D1 has led the way in ports to other platforms. I have never said, not once, that D1 *is* abandoned. Stability and completeness are not the same thing, as you well know. In fact, I'm amazed at the amount of repairs that you are able to achieve, given the small resource pool that is available. All kudos to your good selves. What I have said was that D1 /might/ be abandoned in the future, if and only if, D1 is to be considered as merely a prototype for D2. However, from your recent comments I'm now convinced that you do not see D1 as merely a prototype. D2 is evolving from D1. D2 will be so significantly different from D1 as to almost class it as a different language. I'm sure that a lot of D1 code will not compile under D2, or if it does will have changed semantics. But that is not an issue for me either; just an observation and not a complaint. What isn't being done with D1 is adding a boatload of new features - because that would destroy any pretense of it being a stable release. Of course. Totally justifiable too. I am not asking for anything 'new' to be added to D1. But I do see that D1 and DMD v1 are not the same thing (yet). Ok, so what is stopping me using D1? Below are some off-the-cuff ideas and it may be that I'm mistaken in my beliefs, so take that into consideration. * I like what D2 has to offer, so I'll wait for that. I'm not in a hurry to use D as there is no current or approaching project that requires it. * Phobos has missing functionality, which means I have needed to write that code myself. (Adding the functionality to D1 Phobos is not an option because D1 is 'closed' for additions.) * Tango is too 'weird' for me to use. I'm not keen about the Everything-Is-An-Object style of coding. A personal preference, to be sure. * Tango means I need to do a special
Re: When will D1 be finished?
On Mon, 11 May 2009 18:28:22 -0500, Andrei Alexandrescu wrote: Derek Parnell wrote: The D-Team should be dedicating resources to ensuring that the D1 implementation and D1 documentation are in alignment with each other. By dedicating, I mean that is all that this D1-subteam of the D-Team work on - no D2 work at all. Any D1 fixes that need to be propagated to D2 should be done by the D2-subteam. Priority should be given to getting D1 completed. Well thank you General :o). In spite of the smiley, I'm still feel that your General comment is out-of-line and not fair. If one cannot give opinions here then why do we bother. Derek, I have all respect for you and your contributions to D. The response below does not have the slightest intent to pick on you but to rein in an unhelpful pattern in this group. Thank you and I understand. I invite you to see the paragraph quoted above through a different pair of eyes - the eyes of someone with a different vision of what should be done for D, and also (most importantly) who believes in it strongly enough to invest their own non-existing free time in effecting that vision. (btw, what exactly is that vision, and why do you think that it is different from mine?) I confess that this couch quarterbacking is mightily frustrating for both Walter and myself. All the pieces are there for anyone with a vision to make it happen. I understand you wanted to share your opinion on what would be best for the future of D, and that's laudable in and by itself, but such opinions have lately become a choir of whines fulfilling a if I want something from D, and I expect Walter to do it pattern. We need the exact opposite - if you care, what can *you* do to make D better? D needs action and leadership. I can only speak for myself here but I am not expecting Walter to do it all. In fact, I expect Walter to delegate tasks to others, but I get the feeling that is not the norm. I cannot influence in any practical manner what happens to D1. I cannot code in C++ (effectively) so I'm unable to contribute to fixing bugs. I cannot add to Phobos as 'additions' are closed. I could improve the unit tests and documentation, but ... well, I might be a little behind the times, for the mechanisms for contributing code changes to Phobos and the documentation have been, for me, counter-productive. It is not a simple process and there is no feeling that my efforts will even make a difference. Your phrase All the pieces are there needs to be fleshed out, I think. Are you referring to the process that enables one to submit work for consideration into D? If so, what exactly is that process - Bugzilla is fine for issues and bugs, but is that also the method that we need to use for documentation updates and unit tests? And why is D1 not finished? Most finished languages have implementation insufficiencies. I've read a couple of days ago that D1 is unfinished (and unusable by implication) because contracts aren't inherited. If I were Walter, that would be the exact kind of claim that causes high blood pressure. This is ridiculous! Is *that* the feature that the building of a system hinges on? Is that really what's stopping you? Then go back and use contracts in C++, Java, or C#. My guess is, if anyone is whining that D1 is unusable because it doesn't have contract inheritance, tomorrow (should contract inheritance be fixed) they'll whine that it doesn't have named arguments, template virtuals, or a gorram cherry on top. Sheesh. I realize your remarks above were not specifically directed towards myself, however I feel the need to respond. I am not saying that D1 is not finished, but I am saying that DMD-v1 is not finished. D1 documentation says X is a function of D1. DMD-v1 does not implement X. Therefore DMD-v1 is not a complete implementation of D1. Even though D1 is finished, DMD-v1 might not be finished. Either the documentation is wrong or DMD-v1 is not complete yet. I do not automatically associate incompleteness with unusable. They are not the same thing. There exists complete things that are unusable and incomplete things that are usable. I believe that D1 is very suitable for production applications today. DMD-v1 has a level of stability and completeness that enables it to be used for important works right now. I choose not to use D1 for totally different reasons that have nothing to do with functionality or defect rates. -- Derek Parnell Melbourne, Australia skype: derek.j.parnell
