Re: So bat, DMD crashed!
Yonggang Luo wrote: I was trying to compile a file comes from ddmd of dsouce.org. But the dmd 2.36 is crashed!. C:\CI\bld\ddmd>dmd.exe -c -odobjs @C:\CI\bld\ddmd\strange\commands.txt C:\CI\bld\ddmd\dmd\FuncDeclaration.d dmd\Declaration.d(155): Error: function __ensure forward declaration Assertion failure: '0' on line 396 in file 'tocsym.c' It's also turn out a assertion failure:) C:\CI\bld\ddmd>rem grep -irnl --include=*.d STC . Just to be clear this is not necessarily a dmd bug but the d port of dmd? If you can reproduce it in dmd then report here: http://d.puremagic.com/issues/
Re: Safety, undefined behavior, @safe, @trusted
Christopher Wright wrote: Yigal Chripun wrote: In .Net land, MS uses .net to implement parts of their OS so no surprise there that those OS APIs are available to .net code. Really? What parts? There are a bajillion APIs that you can use from .NET that aren't written in .NET. Microsoft just made it easier to use native code from .NET than Java does. WPF for one. yes, it uses an unmanaged low-level engine called MIL to improve performance and interoperability but the windowing APIs themselves are .NET only and it's not just wrappers, it contains over 3000 classes according to MSDN. Of course there are bajillion Non .net APIs that are accessible from .NET. That's because MS has backward compatibility support starting from the DOS era. New technology is however done in .NET
Re: opPow, opDollar
On Sat, 07 Nov 2009 16:53:01 -0500, Andrei Alexandrescu
wrote:
Robert Jacques wrote:
On Sat, 07 Nov 2009 12:56:35 -0500, Andrei Alexandrescu
wrote:
Robert Jacques wrote:
I'd recommend rolling that into a basic statistics struct containing
common single pass metrics: i.e. sum, mean, variance, min, max, etc.
Well the problem is that if you want to compute several one-pass
statistics in one pass, you'd have to invent means to combine these
functions. That ability is already present in reduce, e.g. reduce(min,
max)(range) yields a pair containing the min and the max element after
exactly one pass through range.
Andrei
Yes, but reduce(mean, std)(range) doesn't work.
From std.algorithm's doc:
// Compute sum and sum of squares in one pass
r = reduce!("a + b", "a + b * b")(tuple(0.0, 0.0), a);
// Compute average and standard deviation from the above
auto avg = r.field[0] / a.length;
auto stdev = sqrt(r.field[1] / a.length - avg * avg);
I'm not saying there's no need for a more specialized library, just that
I purposely designed reduce to be no slouch either.
Even reduce(count) would require the range to be mapped.
(This I don't get.)
Besides, in my use case I need lazy evaluation, and I'd much rather add
elements to a statistics struct, than write a range wrapper.
Well if you go for surgery on an existing struct then the opportunity
for reuse is diminished.
Andrei
Thanks. BTW the behavior of a tuple as input to a multiple function
reduce, although in the example, doesn't seem to be in the doc text.
Re: Safety, undefined behavior, @safe, @trusted
Yigal Chripun wrote: In .Net land, MS uses .net to implement parts of their OS so no surprise there that those OS APIs are available to .net code. Really? What parts? There are a bajillion APIs that you can use from .NET that aren't written in .NET. Microsoft just made it easier to use native code from .NET than Java does.
Re: opPow, opDollar
On Sat, 07 Nov 2009 21:31:46 -0500, Phil Deets wrote: On Sat, 07 Nov 2009 13:37:33 -0500, Andrei Alexandrescu wrote: In order for everyone to air an informed opinion, a related question is: will loop fusion be allowed with function calls? Loop fusion currently only works with operators, and adding ^^ would allow: a[] = b[] ^^ 3; But with pow you can't do that: a[] = pow(b[], 3); Andrei If a function is marked pure, I don't see any reason why this would be a bad idea. Make that pure and nothrow (and possibly safe).
Re: opPow, opDollar
On Sat, 07 Nov 2009 13:37:33 -0500, Andrei Alexandrescu wrote: In order for everyone to air an informed opinion, a related question is: will loop fusion be allowed with function calls? Loop fusion currently only works with operators, and adding ^^ would allow: a[] = b[] ^^ 3; But with pow you can't do that: a[] = pow(b[], 3); Andrei If a function is marked pure, I don't see any reason why this would be a bad idea.
Re: opPow, opDollar
Andrei Alexandrescu wrote: Matti Niemenmaa wrote: Don wrote: Yes, ^^ hasn't been used for exponentiation before. Fortran used ** because it had such a limited character set, but it's not really a natural choice; the more mathematically-oriented languages use ^. Obviously C-family languages don't have that possibility. Haskell has three exponentiation operators in the standard library: ^, ^^, and **. They are for non-negative integral exponents, integral exponents, and floating-point exponents respectively. I wonder whether that's an illustration of the power or of the failure of function overloading. (Seriously.) I'm not sure either. I don't speak Haskell, but my guess is that ^ and ^^ were meant to cut out the confusion that would happen if Word32 ^ Word32 (what weird naming conventions Haskell has!) returned an integer type but Int32 ^ Int32 returned a floating point type. But why it needs yet another for floating-point exponents, I don't know. Maybe Haskell supports only IFTI rather than true function overloading. Stewart.
Re: Safety, undefined behavior, @safe, @trusted
grauzone wrote: Walter Bright wrote: grauzone wrote: Walter Bright wrote: grauzone wrote: If you mean memory safety, then yes and will probably forever be for all practical uses (unless D gets implemented on a Java or .net like VM). A VM is neither necessary nor sufficient to make a language memory safe. It's all in the semantics of the language. Yes, but VM bytecode is a much smaller language than D, which makes it far easier to verify for safety. In practice, SafeD will gradually become actually safe as people use it, see it break, and you fix the bugs. That's why I said for "all practical uses". The Java VM didn't start out as completely safe, either, as people found the holes they were fixed. Because the bytecode language is much smaller than a high level language like D, it's easier for Java. Also, Java was planned to be safe right from the beginning, while SafeD is a rather unnatural feature added on the top of a complex existing language. To make it safe, you need to forbid a set of features, which inconveniences the programmer and will possibly reduce code efficiency. I'm not even opposed to the idea of SafeD, I'm just worrying that forcing all D code to adhere to SafeD by default will cause more trouble than gain. On the other hand, Java has had a much larger ambition, i.e. executing untrusted code in a sandbox, so that balances things a bit. I may as well be wrong, but my intuition is that there are no insurmountable holes that would make D unusable for safe programs. I can clearly see the exact reasons why C++ cannot have a reasonably well-defined safe subset: you can't do anything of significance in C++ without using pointers and pointer arithmetic. (That could be mitigated by a library.) Anyhow, here are a few elements that I think contribute to D's ability to approach memory safety: * garbage collection * built-in arrays * reference semantics for classes * pass-by-reference (ref) * safe approach to variadic functions Without some or all of these, a safe subset of D would be more difficult to define and less expressive. Andrei
Re: Safety, undefined behavior, @safe, @trusted
grauzone wrote: Because the bytecode language is much smaller than a high level language like D, it's easier for Java. I don't agree that has anything to do with it. The VM is compiled down to the same old CPU instructions that D is compiled to. What matters is the semantics. Also, Java was planned to be safe right from the beginning, while SafeD is a rather unnatural feature added on the top of a complex existing language. To make it safe, you need to forbid a set of features, which inconveniences the programmer and will possibly reduce code efficiency. I'm not even opposed to the idea of SafeD, I'm just worrying that forcing all D code to adhere to SafeD by default will cause more trouble than gain. Only time will tell, of course, but D has a lot of inherently safe constructs (such as length-delimited arrays) that obviate most of the need for manipulating pointers. C++ users have also discovered that if they stick to writing in certain ways and using the STL, their programs are memory safe. The problem with C++ is, once again, this is by convention and is not checkable by the compiler.
Re: Safety, undefined behavior, @safe, @trusted
Walter Bright wrote: grauzone wrote: Walter Bright wrote: grauzone wrote: If you mean memory safety, then yes and will probably forever be for all practical uses (unless D gets implemented on a Java or .net like VM). A VM is neither necessary nor sufficient to make a language memory safe. It's all in the semantics of the language. Yes, but VM bytecode is a much smaller language than D, which makes it far easier to verify for safety. In practice, SafeD will gradually become actually safe as people use it, see it break, and you fix the bugs. That's why I said for "all practical uses". The Java VM didn't start out as completely safe, either, as people found the holes they were fixed. Because the bytecode language is much smaller than a high level language like D, it's easier for Java. Also, Java was planned to be safe right from the beginning, while SafeD is a rather unnatural feature added on the top of a complex existing language. To make it safe, you need to forbid a set of features, which inconveniences the programmer and will possibly reduce code efficiency. I'm not even opposed to the idea of SafeD, I'm just worrying that forcing all D code to adhere to SafeD by default will cause more trouble than gain.
Re: Safety, undefined behavior, @safe, @trusted
grauzone wrote: Walter Bright wrote: grauzone wrote: If you mean memory safety, then yes and will probably forever be for all practical uses (unless D gets implemented on a Java or .net like VM). A VM is neither necessary nor sufficient to make a language memory safe. It's all in the semantics of the language. Yes, but VM bytecode is a much smaller language than D, which makes it far easier to verify for safety. In practice, SafeD will gradually become actually safe as people use it, see it break, and you fix the bugs. That's why I said for "all practical uses". The Java VM didn't start out as completely safe, either, as people found the holes they were fixed.
Re: opPow, opDollar
dsimcha wrote:
== Quote from Andrei Alexandrescu (seewebsiteforem...@erdani.org)'s article
Robert Jacques wrote:
On Sat, 07 Nov 2009 12:56:35 -0500, Andrei Alexandrescu
wrote:
Robert Jacques wrote:
I'd recommend rolling that into a basic statistics struct containing
common single pass metrics: i.e. sum, mean, variance, min, max, etc.
Well the problem is that if you want to compute several one-pass
statistics in one pass, you'd have to invent means to combine these
functions. That ability is already present in reduce, e.g. reduce(min,
max)(range) yields a pair containing the min and the max element after
exactly one pass through range.
Andrei
Yes, but reduce(mean, std)(range) doesn't work.
From std.algorithm's doc:
// Compute sum and sum of squares in one pass
r = reduce!("a + b", "a + b * b")(tuple(0.0, 0.0), a);
// Compute average and standard deviation from the above
auto avg = r.field[0] / a.length;
auto stdev = sqrt(r.field[1] / a.length - avg * avg);
I'm not saying there's no need for a more specialized library, just that
I purposely designed reduce to be no slouch either.
Don't get me wrong, I love reduce and it's definitely the right tool for some
jobs. It's just that computing standard deviations isn't one of them. Finding
the sum of the squares explicitly is an absolutely **horrible** way to find the
standard deviation because it's numerically unstable. What if you have a few
billion numbers being read in lazily from a file and you want to find the
standard
deviation of them? Heck, summing explicitly isn't even a very good way to find
the mean.
I'm sure you could implement a proper algorithm for this using reduce, but it
would be really awkward. IMHO reduce's place is as a convenience for simple
things like finding the max and min of a range. Once you're trying to shoehorn
something into reduce that doesn't fit nicely, it's time to give up using reduce
and just write a "real" function.
I agree.
Andrei
Re: opPow, opDollar
== Quote from Andrei Alexandrescu (seewebsiteforem...@erdani.org)'s article
> Robert Jacques wrote:
> > On Sat, 07 Nov 2009 12:56:35 -0500, Andrei Alexandrescu
> > wrote:
> >
> >> Robert Jacques wrote:
> >>> I'd recommend rolling that into a basic statistics struct containing
> >>> common single pass metrics: i.e. sum, mean, variance, min, max, etc.
> >>
> >> Well the problem is that if you want to compute several one-pass
> >> statistics in one pass, you'd have to invent means to combine these
> >> functions. That ability is already present in reduce, e.g. reduce(min,
> >> max)(range) yields a pair containing the min and the max element after
> >> exactly one pass through range.
> >>
> >> Andrei
> >
> > Yes, but reduce(mean, std)(range) doesn't work.
> From std.algorithm's doc:
> // Compute sum and sum of squares in one pass
> r = reduce!("a + b", "a + b * b")(tuple(0.0, 0.0), a);
> // Compute average and standard deviation from the above
> auto avg = r.field[0] / a.length;
> auto stdev = sqrt(r.field[1] / a.length - avg * avg);
> I'm not saying there's no need for a more specialized library, just that
> I purposely designed reduce to be no slouch either.
Don't get me wrong, I love reduce and it's definitely the right tool for some
jobs. It's just that computing standard deviations isn't one of them. Finding
the sum of the squares explicitly is an absolutely **horrible** way to find the
standard deviation because it's numerically unstable. What if you have a few
billion numbers being read in lazily from a file and you want to find the
standard
deviation of them? Heck, summing explicitly isn't even a very good way to find
the mean.
I'm sure you could implement a proper algorithm for this using reduce, but it
would be really awkward. IMHO reduce's place is as a convenience for simple
things like finding the max and min of a range. Once you're trying to shoehorn
something into reduce that doesn't fit nicely, it's time to give up using reduce
and just write a "real" function.
Re: opPow, opDollar
Robert Jacques wrote:
On Sat, 07 Nov 2009 12:56:35 -0500, Andrei Alexandrescu
wrote:
Robert Jacques wrote:
I'd recommend rolling that into a basic statistics struct containing
common single pass metrics: i.e. sum, mean, variance, min, max, etc.
Well the problem is that if you want to compute several one-pass
statistics in one pass, you'd have to invent means to combine these
functions. That ability is already present in reduce, e.g. reduce(min,
max)(range) yields a pair containing the min and the max element after
exactly one pass through range.
Andrei
Yes, but reduce(mean, std)(range) doesn't work.
From std.algorithm's doc:
// Compute sum and sum of squares in one pass
r = reduce!("a + b", "a + b * b")(tuple(0.0, 0.0), a);
// Compute average and standard deviation from the above
auto avg = r.field[0] / a.length;
auto stdev = sqrt(r.field[1] / a.length - avg * avg);
I'm not saying there's no need for a more specialized library, just that
I purposely designed reduce to be no slouch either.
Even reduce(count) would
require the range to be mapped.
(This I don't get.)
Besides, in my use case I need lazy
evaluation, and I'd much rather add elements to a statistics struct,
than write a range wrapper.
Well if you go for surgery on an existing struct then the opportunity
for reuse is diminished.
Andrei
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: opPow, opDollar
On Sat, 07 Nov 2009 13:37:33 -0500, Andrei Alexandrescu
wrote:
Walter Bright wrote:
KennyTM~ wrote:
Nice. Meanwhile, I'd like an opSum() operator (∑ range) as well. It's
primarily about syntax sugar: reduce!("a+b")(range) is so ugly. In
practice, the most important case is the sum from 1 to n, which is an
extremely common operation. reduce!("a+b")(iota(1,n+1)) is horribly
ugly for something so fundamental. It's so ugly that noone uses it:
you always change it to n*(n+1)/2. But then, n gets evaluated twice.
As amply illustrated, one can make this argument pro and con about any
builtin operator. The waterfront real estate of builtin operators is
extremely limited, so we need to be very parsimonious in allocating it.
Candidates for builtin operators need to have a very high bar.
The question is, does ^^ clear that bar or not?
In order for everyone to air an informed opinion, a related question is:
will loop fusion be allowed with function calls?
Loop fusion currently only works with operators, and adding ^^ would
allow:
a[] = b[] ^^ 3;
But with pow you can't do that:
a[] = pow(b[], 3);
Andrei
P.S. FWIW, I'm ambivalent on the issue; if functions were allowed for
automatic loop fusion that would tilt my opinion in disfavor of ^^, and
if not, it would tilt my opinion in favor of ^^.
Actually, if you look at Matlab, a[] = b[] ^^ 3; is well defined.
Also, given
real foo(real r) { return r*r; }
providing syntactic sugar for
a[] = foo(b[], 3); => a[] = map!foo(b[],3);
might be nice.
Re: opPow, opDollar
On Sat, 07 Nov 2009 14:22:01 -0500, dsimcha wrote: == Quote from Robert Jacques (sandf...@jhu.edu)'s article I'd recommend rolling that into a basic statistics struct containing common single pass metrics: i.e. sum, mean, variance, min, max, etc. I've been wondering for a while if something like this is general enough for non-statisticians and a good candidate for Phobos: http://svn.dsource.org/projects/dstats/docs/summary.html Good? Overkill? Too niche? Looks good.
Re: opPow, opDollar
On Sat, 07 Nov 2009 12:56:35 -0500, Andrei Alexandrescu wrote: Robert Jacques wrote: I'd recommend rolling that into a basic statistics struct containing common single pass metrics: i.e. sum, mean, variance, min, max, etc. Well the problem is that if you want to compute several one-pass statistics in one pass, you'd have to invent means to combine these functions. That ability is already present in reduce, e.g. reduce(min, max)(range) yields a pair containing the min and the max element after exactly one pass through range. Andrei Yes, but reduce(mean, std)(range) doesn't work. Even reduce(count) would require the range to be mapped. Besides, in my use case I need lazy evaluation, and I'd much rather add elements to a statistics struct, than write a range wrapper.
Re: Safety, undefined behavior, @safe, @trusted
Walter Bright wrote: grauzone wrote: If you mean memory safety, then yes and will probably forever be for all practical uses (unless D gets implemented on a Java or .net like VM). A VM is neither necessary nor sufficient to make a language memory safe. It's all in the semantics of the language. Yes, but VM bytecode is a much smaller language than D, which makes it far easier to verify for safety. In practice, SafeD will gradually become actually safe as people use it, see it break, and you fix the bugs. That's why I said for "all practical uses".
Re: opPow, opDollar
Walter Bright wrote: Andrei Alexandrescu wrote: In order for everyone to air an informed opinion, a related question is: will loop fusion be allowed with function calls? Loop fusion currently only works with operators, and adding ^^ would allow: a[] = b[] ^^ 3; But with pow you can't do that: a[] = pow(b[], 3); Andrei P.S. FWIW, I'm ambivalent on the issue; if functions were allowed for automatic loop fusion that would tilt my opinion in disfavor of ^^, and if not, it would tilt my opinion in favor of ^^. I don't think this is a valid argument for making pow() an operator, because what about sin()? cos()? It's all the same issue, and they all can't be operators. It's another case where pow(x, 2) is not the same as x ^^ 2. The argument for excluding exponentiation is largely, "pow does the same thing, without introducing an operator".
Re: opPow, opDollar
Andrei Alexandrescu wrote: In order for everyone to air an informed opinion, a related question is: will loop fusion be allowed with function calls? Loop fusion currently only works with operators, and adding ^^ would allow: a[] = b[] ^^ 3; But with pow you can't do that: a[] = pow(b[], 3); Andrei P.S. FWIW, I'm ambivalent on the issue; if functions were allowed for automatic loop fusion that would tilt my opinion in disfavor of ^^, and if not, it would tilt my opinion in favor of ^^. I don't think this is a valid argument for making pow() an operator, because what about sin()? cos()? It's all the same issue, and they all can't be operators.
Re: opPow, opDollar
Mo Chen wrote: Suppose we have a matrix library, I'd like to have two product operators, one is for matrix product, the other is for element wise product, just like what we do in matlab (A*B and A.*B). I'd like to save ** to that scenario. Btw I'm no Fortran user. ^^ is fine by me. The D forms are A*B for matrix product, A[]*B[] for element-wise product. .
Re: opPow, opDollar
Walter Bright wrote:
KennyTM~ wrote:
Nice. Meanwhile, I'd like an opSum() operator (∑ range) as well. It's
primarily about syntax sugar: reduce!("a+b")(range) is so ugly. In
practice, the most important case is the sum from 1 to n, which is an
extremely common operation. reduce!("a+b")(iota(1,n+1)) is horribly
ugly for something so fundamental. It's so ugly that noone uses it:
you always change it to n*(n+1)/2. But then, n gets evaluated twice.
As amply illustrated, one can make this argument pro and con about any
builtin operator. The waterfront real estate of builtin operators is
extremely limited, so we need to be very parsimonious in allocating it.
Candidates for builtin operators need to have a very high bar.
The question is, does ^^ clear that bar or not?
Yes, that's exactly the question. From an old post by Bill Baxter,
here's a list of languages with an exponentiation operator:
# x ↑ y: Algol, Commodore BASIC
# x ^ y: BASIC, J, Matlab, R, Microsoft Excel, TeX (and its
derivatives), Haskell (for non-negative integer exponents), and most
computer algebra systems
# x ^^ y: Haskell (for integer exponents)
# x ** y: Ada, Bash, Fortran, FoxPro, Perl, Python, Ruby, SAS, ABAP,
Haskell (for floating-point exponents), Turing
# x * y: APL
None of the languages derived from C and Pascal include exponentiation.
(I suspect that if it had been included in C, there would be very few
languages without it: since Algol and Fortran both had it).
Note that D currently has <>, <>=, !<>, !<>=, !>=, !<=, !>, !<, which
would have to be lower down the list than exponentiation. As one of the
very few users who actually uses them, I'd happily sacrifice them in
exchange for exponentiation.
And BTW, there is another issue with pow(), relating to implicit conversion.
Given an int x, x * x is also an int. But pow(x, 2) is a double, so they
are not at all equivalent. (and pow() definitely needs to return float
for general exponents). The recently introduced integer range tracking
for implicit conversions could fix this nicely.
Re: opPow, opDollar
Suppose we have a matrix library, I'd like to have two product operators, one is for matrix product, the other is for element wise product, just like what we do in matlab (A*B and A.*B). I'd like to save ** to that scenario. Btw I'm no Fortran user. ^^ is fine by me. On Sat, Nov 7, 2009 at 5:56 PM, Walter Bright wrote: > Don wrote: > >> A little while ago I said I'd create a patch for ^^ as an exponentiation. >> A couple of people had requested that I make a post to the ng so they'd know >> when it happens. Here it is. >> >> This is opPow(), x ^^ y >> >> http://d.puremagic.com/issues/show_bug.cgi?id=3481 >> > > I don't understand the rationale for an exponentiation operator. It isn't > optimization, because pow() could become an intrinsic that the compiler > knows about. pow() is well known, ^^ isn't. (Fortran uses **) >
Re: opPow, opDollar
== Quote from Robert Jacques (sandf...@jhu.edu)'s article > I'd recommend rolling that into a basic statistics struct containing > common single pass metrics: i.e. sum, mean, variance, min, max, etc. I've been wondering for a while if something like this is general enough for non-statisticians and a good candidate for Phobos: http://svn.dsource.org/projects/dstats/docs/summary.html Good? Overkill? Too niche?
Re: opPow, opDollar
Andrei Alexandrescu wrote:
> Walter Bright wrote:
>> KennyTM~ wrote:
>>> Nice. Meanwhile, I'd like an opSum() operator (∑ range) as well. It's
>>> primarily about syntax sugar: reduce!("a+b")(range) is so ugly. In
>>> practice, the most important case is the sum from 1 to n, which is an
>>> extremely common operation. reduce!("a+b")(iota(1,n+1)) is horribly
>>> ugly for something so fundamental. It's so ugly that noone uses it:
>>> you always change it to n*(n+1)/2. But then, n gets evaluated twice.
>>
>> As amply illustrated, one can make this argument pro and con about any
>> builtin operator. The waterfront real estate of builtin operators is
>> extremely limited, so we need to be very parsimonious in allocating
>> it. Candidates for builtin operators need to have a very high bar.
>>
>> The question is, does ^^ clear that bar or not?
>
> In order for everyone to air an informed opinion, a related question is:
> will loop fusion be allowed with function calls?
>
> Loop fusion currently only works with operators, and adding ^^ would allow:
>
> a[] = b[] ^^ 3;
>
> But with pow you can't do that:
>
> a[] = pow(b[], 3);
>
>
> Andrei
>
> P.S. FWIW, I'm ambivalent on the issue; if functions were allowed for
> automatic loop fusion that would tilt my opinion in disfavor of ^^, and
> if not, it would tilt my opinion in favor of ^^.
Does ^^ really even need to be a builtin operator to be overloadable?
I remember a discussion where we considered adding abstract operators
that have no inherent meaning in the language (not builtins), but are
overloadable to allow better exploitation of infix notation. Things
like (+), (*), (%), (&), [+], [*], [%], and so on.
Re: opPow, opDollar
Walter Bright wrote:
KennyTM~ wrote:
Nice. Meanwhile, I'd like an opSum() operator (∑ range) as well. It's
primarily about syntax sugar: reduce!("a+b")(range) is so ugly. In
practice, the most important case is the sum from 1 to n, which is an
extremely common operation. reduce!("a+b")(iota(1,n+1)) is horribly
ugly for something so fundamental. It's so ugly that noone uses it:
you always change it to n*(n+1)/2. But then, n gets evaluated twice.
As amply illustrated, one can make this argument pro and con about any
builtin operator. The waterfront real estate of builtin operators is
extremely limited, so we need to be very parsimonious in allocating it.
Candidates for builtin operators need to have a very high bar.
The question is, does ^^ clear that bar or not?
In order for everyone to air an informed opinion, a related question is:
will loop fusion be allowed with function calls?
Loop fusion currently only works with operators, and adding ^^ would allow:
a[] = b[] ^^ 3;
But with pow you can't do that:
a[] = pow(b[], 3);
Andrei
P.S. FWIW, I'm ambivalent on the issue; if functions were allowed for
automatic loop fusion that would tilt my opinion in disfavor of ^^, and
if not, it would tilt my opinion in favor of ^^.
Re: opPow, opDollar
KennyTM~ wrote:
Nice. Meanwhile, I'd like an opSum() operator (∑ range) as well. It's
primarily about syntax sugar: reduce!("a+b")(range) is so ugly. In
practice, the most important case is the sum from 1 to n, which is an
extremely common operation. reduce!("a+b")(iota(1,n+1)) is horribly ugly
for something so fundamental. It's so ugly that noone uses it: you
always change it to n*(n+1)/2. But then, n gets evaluated twice.
As amply illustrated, one can make this argument pro and con about any
builtin operator. The waterfront real estate of builtin operators is
extremely limited, so we need to be very parsimonious in allocating it.
Candidates for builtin operators need to have a very high bar.
The question is, does ^^ clear that bar or not?
Re: Safety, undefined behavior, @safe, @trusted
Don wrote: In practice, the big disadvantage which D has is that it can make calls to C libraries which are not necessarily memory safe -- and this is an important feature of the language. Dealing with the external, uncheckable libraries is always going to be a weak point. Both Java and .net have mitigated this by rewriting a fair chunk of an OS in their libraries. That's probably never going to happen for D. Java has the jni interface where one can execute arbitrary C code. Obviously, that isn't memory safe, either. Some of the standard C library functions are safe, some of them aren't. We'll mark them appropriately in the std.c.* headers. I expect there will be a lot of pressure for 3rd party D libraries to be marked as safe, so I think this problem will sort itself out over time.
Re: opPow, opDollar
Robert Jacques wrote: I'd recommend rolling that into a basic statistics struct containing common single pass metrics: i.e. sum, mean, variance, min, max, etc. Well the problem is that if you want to compute several one-pass statistics in one pass, you'd have to invent means to combine these functions. That ability is already present in reduce, e.g. reduce(min, max)(range) yields a pair containing the min and the max element after exactly one pass through range. Andrei
Re: opPow, opDollar
On Nov 8, 09 00:15, Robert Jacques wrote:
On Sat, 07 Nov 2009 10:48:11 -0500, KennyTM~ wrote:
On Nov 7, 09 18:43, Don wrote:
Walter Bright wrote:
Don wrote:
A little while ago I said I'd create a patch for ^^ as an
exponentiation. A couple of people had requested that I make a post
to the ng so they'd know when it happens. Here it is.
This is opPow(), x ^^ y
http://d.puremagic.com/issues/show_bug.cgi?id=3481
I don't understand the rationale for an exponentiation operator. It
isn't optimization, because pow() could become an intrinsic that the
compiler knows about. pow() is well known, ^^ isn't. (Fortran uses **)
It's primarily about syntax sugar: pow() is so ugly. In practice, the
most important case is squaring, which is an extremely common operation.
pow(xxx,2) is horribly ugly for something so fundamental. It's so ugly
that noone uses it: you always change it to xxx * xxx. But then, xxx
gets evaluated twice.
Nice. Meanwhile, I'd like an opSum() operator (∑ range) as well. It's
primarily about syntax sugar: reduce!("a+b")(range) is so ugly. In
practice, the most important case is the sum from 1 to n, which is an
extremely common operation. reduce!("a+b")(iota(1,n+1)) is horribly
ugly for something so fundamental. It's so ugly that noone uses it:
you always change it to n*(n+1)/2. But then, n gets evaluated twice.
Yes, ^^ hasn't been used for exponentiation before. Fortran used **
because it had such a limited character set, but it's not really a
natural choice; the more mathematically-oriented languages use ^.
Obviously C-family languages don't have that possibility.
Well, since D supports unicode, you can always define: alias
reduce!("a+b") ∑;
Or
pure nothrow T ²(T)(T x) { return x*x; }
alias sqrt √;
:p
(OK ²(xxx) is still odd.)
Re: Primary D Website Dilapidated?
On Fri, 06 Nov 2009 23:57:24 -0600, AJ wrote: > Steven Schveighoffer wrote: >> Oh, and BTW, invariant is deprecated, use immutable instead. >> I assume you are referring to the use of 'invariant' in the documentation? If so, you should report it as a bug. http://d.puremagic.com/issues/
Re: opPow, opDollar
dsimcha wrote:
== Quote from Robert Jacques (sandf...@jhu.edu)'s article
On Sat, 07 Nov 2009 10:48:11 -0500, KennyTM~ wrote:
On Nov 7, 09 18:43, Don wrote:
Walter Bright wrote:
Don wrote:
A little while ago I said I'd create a patch for ^^ as an
exponentiation. A couple of people had requested that I make a post
to the ng so they'd know when it happens. Here it is.
This is opPow(), x ^^ y
http://d.puremagic.com/issues/show_bug.cgi?id=3481
I don't understand the rationale for an exponentiation operator. It
isn't optimization, because pow() could become an intrinsic that the
compiler knows about. pow() is well known, ^^ isn't. (Fortran uses **)
It's primarily about syntax sugar: pow() is so ugly. In practice, the
most important case is squaring, which is an extremely common operation.
pow(xxx,2) is horribly ugly for something so fundamental. It's so ugly
that noone uses it: you always change it to xxx * xxx. But then, xxx
gets evaluated twice.
Nice. Meanwhile, I'd like an opSum() operator (∑ range) as well. It's
primarily about syntax sugar: reduce!("a+b")(range) is so ugly. In
practice, the most important case is the sum from 1 to n, which is an
extremely common operation. reduce!("a+b")(iota(1,n+1)) is horribly ugly
for something so fundamental. It's so ugly that noone uses it: you
always change it to n*(n+1)/2. But then, n gets evaluated twice.
Yes, ^^ hasn't been used for exponentiation before. Fortran used **
because it had such a limited character set, but it's not really a
natural choice; the more mathematically-oriented languages use ^.
Obviously C-family languages don't have that possibility.
Well, since D supports unicode, you can always define: alias
reduce!("a+b") ∑;
On a more serious note, I'm starting to think that Phobos needs a specific
convenience function for sum, not because reduce!"a + b" is ugly (it isn't) or
too
much typing (it isn't) but because reduce!"a + b" doesn't work on zero-length
ranges. Obviously, the sum of a zero-length range is zero, but reduce is too
general to know this. This bit me a few times in some code I was debugging last
week. Rather than inserting extra checks or passing an explicit start value in
(which requires you to remember the element type of your range; is it an int or
a
float?), I simply handwrote a sum function and replaced all my reduce!"a + b"
with
sum.
Just in case it helps, the two-arguments version of reduce is meant
exactly to make it work with an empty array and seed the accumulation.
Namely, reduce!"a+b"(range) throws on an empty range, but
reduce!"a+b"(0.0, range) returns 0.0 on an empty range.
Andrei
Re: opPow, opDollar
On Sat, 07 Nov 2009 11:26:36 -0500, dsimcha wrote:
== Quote from Robert Jacques (sandf...@jhu.edu)'s article
On Sat, 07 Nov 2009 10:48:11 -0500, KennyTM~ wrote:
> On Nov 7, 09 18:43, Don wrote:
>> Walter Bright wrote:
>>> Don wrote:
A little while ago I said I'd create a patch for ^^ as an
exponentiation. A couple of people had requested that I make a post
to the ng so they'd know when it happens. Here it is.
This is opPow(), x ^^ y
http://d.puremagic.com/issues/show_bug.cgi?id=3481
>>>
>>> I don't understand the rationale for an exponentiation operator. It
>>> isn't optimization, because pow() could become an intrinsic that the
>>> compiler knows about. pow() is well known, ^^ isn't. (Fortran uses
**)
>>
>> It's primarily about syntax sugar: pow() is so ugly. In practice, the
>> most important case is squaring, which is an extremely common
operation.
>> pow(xxx,2) is horribly ugly for something so fundamental. It's so
ugly
>> that noone uses it: you always change it to xxx * xxx. But then, xxx
>> gets evaluated twice.
>>
>
> Nice. Meanwhile, I'd like an opSum() operator (∑ range) as well. It's
> primarily about syntax sugar: reduce!("a+b")(range) is so ugly. In
> practice, the most important case is the sum from 1 to n, which is an
> extremely common operation. reduce!("a+b")(iota(1,n+1)) is horribly
ugly
> for something so fundamental. It's so ugly that noone uses it: you
> always change it to n*(n+1)/2. But then, n gets evaluated twice.
>
>> Yes, ^^ hasn't been used for exponentiation before. Fortran used **
>> because it had such a limited character set, but it's not really a
>> natural choice; the more mathematically-oriented languages use ^.
>> Obviously C-family languages don't have that possibility.
>>
>
Well, since D supports unicode, you can always define: alias
reduce!("a+b") ∑;
On a more serious note, I'm starting to think that Phobos needs a
specific
convenience function for sum, not because reduce!"a + b" is ugly (it
isn't) or too
much typing (it isn't) but because reduce!"a + b" doesn't work on
zero-length
ranges. Obviously, the sum of a zero-length range is zero, but reduce
is too
general to know this. This bit me a few times in some code I was
debugging last
week. Rather than inserting extra checks or passing an explicit start
value in
(which requires you to remember the element type of your range; is it an
int or a
float?), I simply handwrote a sum function and replaced all my reduce!"a
+ b" with
sum.
I'd recommend rolling that into a basic statistics struct containing
common single pass metrics: i.e. sum, mean, variance, min, max, etc.
P.S. Don't forget to vote for the patches in bugzilla.
Re: opPow, opDollar
dsimcha wrote:
== Quote from Robert Jacques (sandf...@jhu.edu)'s article
On Sat, 07 Nov 2009 10:48:11 -0500, KennyTM~ wrote:
On Nov 7, 09 18:43, Don wrote:
Walter Bright wrote:
Don wrote:
A little while ago I said I'd create a patch for ^^ as an
exponentiation. A couple of people had requested that I make a post
to the ng so they'd know when it happens. Here it is.
This is opPow(), x ^^ y
http://d.puremagic.com/issues/show_bug.cgi?id=3481
I don't understand the rationale for an exponentiation operator. It
isn't optimization, because pow() could become an intrinsic that the
compiler knows about. pow() is well known, ^^ isn't. (Fortran uses **)
It's primarily about syntax sugar: pow() is so ugly. In practice, the
most important case is squaring, which is an extremely common operation.
pow(xxx,2) is horribly ugly for something so fundamental. It's so ugly
that noone uses it: you always change it to xxx * xxx. But then, xxx
gets evaluated twice.
Nice. Meanwhile, I'd like an opSum() operator (∑ range) as well. It's
primarily about syntax sugar: reduce!("a+b")(range) is so ugly. In
practice, the most important case is the sum from 1 to n, which is an
extremely common operation. reduce!("a+b")(iota(1,n+1)) is horribly ugly
for something so fundamental. It's so ugly that noone uses it: you
always change it to n*(n+1)/2. But then, n gets evaluated twice.
Yes, ^^ hasn't been used for exponentiation before. Fortran used **
because it had such a limited character set, but it's not really a
natural choice; the more mathematically-oriented languages use ^.
Obviously C-family languages don't have that possibility.
Well, since D supports unicode, you can always define: alias
reduce!("a+b") ∑;
On a more serious note, I'm starting to think that Phobos needs a specific
convenience function for sum, not because reduce!"a + b" is ugly (it isn't) or
too
much typing (it isn't) but because reduce!"a + b" doesn't work on zero-length
ranges. Obviously, the sum of a zero-length range is zero, but reduce is too
general to know this. This bit me a few times in some code I was debugging last
week. Rather than inserting extra checks or passing an explicit start value in
(which requires you to remember the element type of your range; is it an int or
a
float?), I simply handwrote a sum function and replaced all my reduce!"a + b"
with
sum.
I am all in favor of adding convenience functions sum and product to
phobos. I use them both often enough.
Re: opPow, opDollar
== Quote from Robert Jacques (sandf...@jhu.edu)'s article
> On Sat, 07 Nov 2009 10:48:11 -0500, KennyTM~ wrote:
> > On Nov 7, 09 18:43, Don wrote:
> >> Walter Bright wrote:
> >>> Don wrote:
> A little while ago I said I'd create a patch for ^^ as an
> exponentiation. A couple of people had requested that I make a post
> to the ng so they'd know when it happens. Here it is.
>
> This is opPow(), x ^^ y
>
> http://d.puremagic.com/issues/show_bug.cgi?id=3481
> >>>
> >>> I don't understand the rationale for an exponentiation operator. It
> >>> isn't optimization, because pow() could become an intrinsic that the
> >>> compiler knows about. pow() is well known, ^^ isn't. (Fortran uses **)
> >>
> >> It's primarily about syntax sugar: pow() is so ugly. In practice, the
> >> most important case is squaring, which is an extremely common operation.
> >> pow(xxx,2) is horribly ugly for something so fundamental. It's so ugly
> >> that noone uses it: you always change it to xxx * xxx. But then, xxx
> >> gets evaluated twice.
> >>
> >
> > Nice. Meanwhile, I'd like an opSum() operator (∑ range) as well. It's
> > primarily about syntax sugar: reduce!("a+b")(range) is so ugly. In
> > practice, the most important case is the sum from 1 to n, which is an
> > extremely common operation. reduce!("a+b")(iota(1,n+1)) is horribly ugly
> > for something so fundamental. It's so ugly that noone uses it: you
> > always change it to n*(n+1)/2. But then, n gets evaluated twice.
> >
> >> Yes, ^^ hasn't been used for exponentiation before. Fortran used **
> >> because it had such a limited character set, but it's not really a
> >> natural choice; the more mathematically-oriented languages use ^.
> >> Obviously C-family languages don't have that possibility.
> >>
> >
> Well, since D supports unicode, you can always define: alias
> reduce!("a+b") ∑;
On a more serious note, I'm starting to think that Phobos needs a specific
convenience function for sum, not because reduce!"a + b" is ugly (it isn't) or
too
much typing (it isn't) but because reduce!"a + b" doesn't work on zero-length
ranges. Obviously, the sum of a zero-length range is zero, but reduce is too
general to know this. This bit me a few times in some code I was debugging last
week. Rather than inserting extra checks or passing an explicit start value in
(which requires you to remember the element type of your range; is it an int or
a
float?), I simply handwrote a sum function and replaced all my reduce!"a + b"
with
sum.
Re: opPow, opDollar
On Sat, 07 Nov 2009 10:48:11 -0500, KennyTM~ wrote:
On Nov 7, 09 18:43, Don wrote:
Walter Bright wrote:
Don wrote:
A little while ago I said I'd create a patch for ^^ as an
exponentiation. A couple of people had requested that I make a post
to the ng so they'd know when it happens. Here it is.
This is opPow(), x ^^ y
http://d.puremagic.com/issues/show_bug.cgi?id=3481
I don't understand the rationale for an exponentiation operator. It
isn't optimization, because pow() could become an intrinsic that the
compiler knows about. pow() is well known, ^^ isn't. (Fortran uses **)
It's primarily about syntax sugar: pow() is so ugly. In practice, the
most important case is squaring, which is an extremely common operation.
pow(xxx,2) is horribly ugly for something so fundamental. It's so ugly
that noone uses it: you always change it to xxx * xxx. But then, xxx
gets evaluated twice.
Nice. Meanwhile, I'd like an opSum() operator (∑ range) as well. It's
primarily about syntax sugar: reduce!("a+b")(range) is so ugly. In
practice, the most important case is the sum from 1 to n, which is an
extremely common operation. reduce!("a+b")(iota(1,n+1)) is horribly ugly
for something so fundamental. It's so ugly that noone uses it: you
always change it to n*(n+1)/2. But then, n gets evaluated twice.
Yes, ^^ hasn't been used for exponentiation before. Fortran used **
because it had such a limited character set, but it's not really a
natural choice; the more mathematically-oriented languages use ^.
Obviously C-family languages don't have that possibility.
Well, since D supports unicode, you can always define: alias
reduce!("a+b") ∑;
Re: opPow, opDollar
Matti Niemenmaa wrote: Don wrote: Yes, ^^ hasn't been used for exponentiation before. Fortran used ** because it had such a limited character set, but it's not really a natural choice; the more mathematically-oriented languages use ^. Obviously C-family languages don't have that possibility. Haskell has three exponentiation operators in the standard library: ^, ^^, and **. They are for non-negative integral exponents, integral exponents, and floating-point exponents respectively. I wonder whether that's an illustration of the power or of the failure of function overloading. (Seriously.) Andrei
Re: opPow, opDollar
On Nov 7, 09 18:43, Don wrote:
Walter Bright wrote:
Don wrote:
A little while ago I said I'd create a patch for ^^ as an
exponentiation. A couple of people had requested that I make a post
to the ng so they'd know when it happens. Here it is.
This is opPow(), x ^^ y
http://d.puremagic.com/issues/show_bug.cgi?id=3481
I don't understand the rationale for an exponentiation operator. It
isn't optimization, because pow() could become an intrinsic that the
compiler knows about. pow() is well known, ^^ isn't. (Fortran uses **)
It's primarily about syntax sugar: pow() is so ugly. In practice, the
most important case is squaring, which is an extremely common operation.
pow(xxx,2) is horribly ugly for something so fundamental. It's so ugly
that noone uses it: you always change it to xxx * xxx. But then, xxx
gets evaluated twice.
Nice. Meanwhile, I'd like an opSum() operator (∑ range) as well. It's
primarily about syntax sugar: reduce!("a+b")(range) is so ugly. In
practice, the most important case is the sum from 1 to n, which is an
extremely common operation. reduce!("a+b")(iota(1,n+1)) is horribly ugly
for something so fundamental. It's so ugly that noone uses it: you
always change it to n*(n+1)/2. But then, n gets evaluated twice.
Yes, ^^ hasn't been used for exponentiation before. Fortran used **
because it had such a limited character set, but it's not really a
natural choice; the more mathematically-oriented languages use ^.
Obviously C-family languages don't have that possibility.
Re: opPow, opDollar
Don wrote: Yes, ^^ hasn't been used for exponentiation before. Fortran used ** because it had such a limited character set, but it's not really a natural choice; the more mathematically-oriented languages use ^. Obviously C-family languages don't have that possibility. Haskell has three exponentiation operators in the standard library: ^, ^^, and **. They are for non-negative integral exponents, integral exponents, and floating-point exponents respectively.
Re: opPow, opDollar
> the more mathematically-oriented languages use ^ And BASIC ;-) -=mike=-
Re: Safety, undefined behavior, @safe, @trusted
On 07/11/2009 11:53, Don wrote: Walter Bright wrote: grauzone wrote: If you mean memory safety, then yes and will probably forever be for all practical uses (unless D gets implemented on a Java or .net like VM). A VM is neither necessary nor sufficient to make a language memory safe. It's all in the semantics of the language. In practice, the big disadvantage which D has is that it can make calls to C libraries which are not necessarily memory safe -- and this is an important feature of the language. Dealing with the external, uncheckable libraries is always going to be a weak point. Both Java and .net have mitigated this by rewriting a fair chunk of an OS in their libraries. That's probably never going to happen for D. Sun pretty much implemented a full OS inside the JVM. At least their RT offering contains a scheduler in order to provide guaranties regarding collection time. In .Net land, MS uses .net to implement parts of their OS so no surprise there that those OS APIs are available to .net code. I wouldn't say that it's part of their libraries but rather parts of the OS itself. What parts of the OS are still missing in D's standard library? Isn't tango/phobos already provide all the common parts like i/o and networking and a few other major libs provide bindings/implementation for UI, 3d & multimedia, db bindings, etc? I think that the big disadvantage you claim D has isn't that big and it is well underway to go away compared to .net/java. Both Java and .net also provide ways to use unsafe C code (e.g. JNI, COM), It just a matter of what's the default, what's easier to do and what can be done without choosing the unsafe option. I think that D isn't that far off behind and could and should catch up.
So bat, DMD crashed!
I was trying to compile a file comes from ddmd of dsouce.org. But the dmd 2.36 is crashed!. C:\CI\bld\ddmd>dmd.exe -c -odobjs @C:\CI\bld\ddmd\strange\commands.txt C:\CI\bld\ddmd\dmd\FuncDeclaration.d dmd\Declaration.d(155): Error: function __ensure forward declaration Assertion failure: '0' on line 396 in file 'tocsym.c' It's also turn out a assertion failure:) C:\CI\bld\ddmd>rem grep -irnl --include=*.d STC .
Re: opPow, opDollar
Walter Bright wrote: Don wrote: A little while ago I said I'd create a patch for ^^ as an exponentiation. A couple of people had requested that I make a post to the ng so they'd know when it happens. Here it is. This is opPow(), x ^^ y http://d.puremagic.com/issues/show_bug.cgi?id=3481 I don't understand the rationale for an exponentiation operator. It isn't optimization, because pow() could become an intrinsic that the compiler knows about. pow() is well known, ^^ isn't. (Fortran uses **) It's primarily about syntax sugar: pow() is so ugly. In practice, the most important case is squaring, which is an extremely common operation. pow(xxx,2) is horribly ugly for something so fundamental. It's so ugly that noone uses it: you always change it to xxx * xxx. But then, xxx gets evaluated twice. Yes, ^^ hasn't been used for exponentiation before. Fortran used ** because it had such a limited character set, but it's not really a natural choice; the more mathematically-oriented languages use ^. Obviously C-family languages don't have that possibility.
Re: opPow, opDollar
Walter Bright wrote: Don wrote: A little while ago I said I'd create a patch for ^^ as an exponentiation. A couple of people had requested that I make a post to the ng so they'd know when it happens. Here it is. This is opPow(), x ^^ y http://d.puremagic.com/issues/show_bug.cgi?id=3481 AWESOME! Thanks a lot, Don! I've been hoping for this since I started using D. Walter Bright wrote: I don't understand the rationale for an exponentiation operator. It isn't optimization, because pow() could become an intrinsic that the compiler knows about. pow() is well known, ^^ isn't. (Fortran uses **) I don't understand the rationale for a concatenation operator. It isn't optimization, because strcat() could become an intrinsic that the compiler knows about. strcat() is well known, ~ isn't. (Java uses +) I'm not trying to be rude, I'm just trying to illustrate that the first point doesn't make a good case against an exponentiation operator. I can only speak for myself, but I use exponentiation a lot. I mostly write numerical code, and as I understand it, I'm not the only one in the community doing so. Being able to overload the exponentiation operator also makes a lot of sense. Matrices and BigInts are the first things that come to mind. -Lars
Re: opPow, opDollar
Don wrote: A little while ago I said I'd create a patch for ^^ as an exponentiation. A couple of people had requested that I make a post to the ng so they'd know when it happens. Here it is. This is opPow(), x ^^ y http://d.puremagic.com/issues/show_bug.cgi?id=3481 I don't understand the rationale for an exponentiation operator. It isn't optimization, because pow() could become an intrinsic that the compiler knows about. pow() is well known, ^^ isn't. (Fortran uses **)
Re: Safety, undefined behavior, @safe, @trusted
Walter Bright wrote: grauzone wrote: If you mean memory safety, then yes and will probably forever be for all practical uses (unless D gets implemented on a Java or .net like VM). A VM is neither necessary nor sufficient to make a language memory safe. It's all in the semantics of the language. In practice, the big disadvantage which D has is that it can make calls to C libraries which are not necessarily memory safe -- and this is an important feature of the language. Dealing with the external, uncheckable libraries is always going to be a weak point. Both Java and .net have mitigated this by rewriting a fair chunk of an OS in their libraries. That's probably never going to happen for D.
Re: Safety, undefined behavior, @safe, @trusted
grauzone wrote: If you mean memory safety, then yes and will probably forever be for all practical uses (unless D gets implemented on a Java or .net like VM). A VM is neither necessary nor sufficient to make a language memory safe. It's all in the semantics of the language.
Re: Please join me...
"div0" wrote in message news:hd2ges$n2...@digitalmars.com... > > I'm not joining you. You are ugly and your mother smells of elderberries. > Just don't fart in my general direction. I'd get so mad I might club a baby sycophant. Meh, the heck with it all, I'm going panning for chickens... AAALLBATROSS!!
Re: Regarding compiler switches
"div0" wrote in message news:hd2n6e$135...@digitalmars.com... > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Nick Sabalausky wrote: > > Ok fair dos, I agree with you that warnings should [not exist at all] be > warnings not errors. > Ok, I'm glad that we at least agree on that. > But if you like warnings so much please provide a concrete example of a > compilation run that's given you a useful warning that you've then used > to correct a problem with your code. > First of all, not all of it is necessarily about identifying a problem that already exists. Some of it, like getting a "switch statement has no default" when switching on an enum has more to do with defensive coding and making sure the code properly handles a non-local change sometime in the future (ie, adding an new enum value). Secondly, see below... > For every situation I believe that there is a simple and unambiguous > right/wrong choice and D's design pretty much does away with all those > pointless warnings and it makes stupid things errors. > I think that's overly idealistic. I absolutely agree that warnings should be minimized in favor of a clearly defined "ok" vs "error" whenever reasonably possible, and that D has done great in this regard, but I definitely don't think it's always reasonably possible. Sometimes deciding "that is allowed" will cause potential problems to go unnoticed and deciding that the same thing should be an error instead just simply causes more trouble than it's worth. There isn't always a good decision, or, if there is, it might just not be practical for other reasons. For instance: DMD's "no return at end of function" warning. That definitely has saved me from runtime bugs. There have been times when I got that warning, and saw that I had built up a return value but forgot to return it, and definitely didn't want to be returning T.init. "Ok, so the language definition should require a return at the end of a non-void function, and to omit it would be an error." Nice try, but then the language becomes a pain in the ass whenever you have something that's guaranteed to either throw or return a value before the final closing curly brace. "The obvious correct solution is flow analysis." Great, except 1. Perfect flow analysis can be impractically slow, and 2. It a big feature that'll take time to implement, plus there are more pressing matters on the table, so what are you supposed to do in the meantime? "Then for the meantime, just pick 'ok' or 'error'." First of all, at that point, the whole idea that "for every situation [...] there is a simple and unambiguous right/wrong choice" has pretty much already come crashing down. It was a great idea while it lasted, just like "everyone should always get along", but the real world just doesn't work that way, even as much as I would love for it to. Secondly, nobody's going to agree which way to go anyway, so...you call the damn thing a warning and move on. And that's pretty much just what happened. An unenviable, but nevertheless good, move on Walter's part. I can make a similar case for "statement is not reachable": There *have been* times when I've had code that needed to get executed, but was within a section that, due to an oversight, was dead code. The language could have just outlawed such dead code, but that's just a serious pain when debugging. There *have been* times when I deliberately stuck a premature, unconditional and temporary return statement (or throw) in the middle of a function for the sake of debugging. I knew it caused dead code, and I didn't care, and a non-fatal warning wouldn't have bothered anyone because I knew damn well I was just going to remove it in a minute or two anyway (I have ways to make sure such temporary things actually do get removed). So if dead code had been declared an error, I would have had to temporarily comment it all out just to shut the stupid compiler up. > > I've spent 100s of hours over the past 8 years where I work fixing > shitty code written by dribbling morons who couldn't be bothered to fix > the warnings that their code generated and who quite frankly should > never have been employed in the first place. > > Given the fact that you are a NG posting, D loving weirdo your code is > probably very good and well documented and probably it compiles with out > generating any warnings at all, but you and the code you write is rare & > odd. > > Most of the code that's done out there by 'normal programmers' whose > only concern is getting paid at the end of the month basically sucks, so > making things errors, which they have to fix rather than warnings is the > way to go, from my pragmatic working coders point of view. > > Though I suppose you can throw the lint tool argument right back at me > and say that people that employee morons should run a lint tool. > I've worked at such places as well. It really is very depressing :(. Although I don't think "lint tool"
opPow, opDollar
A little while ago I said I'd create a patch for ^^ as an exponentiation. A couple of people had requested that I make a post to the ng so they'd know when it happens. Here it is. This is opPow(), x ^^ y http://d.puremagic.com/issues/show_bug.cgi?id=3481 And this is opDollar!(int dim) for multi-dimensional indexing http://d.puremagic.com/issues/show_bug.cgi?id=3474 There have been long bikeshed discussions about the naming of both of these several times in the past. Please don't ask for name changes to x ^ y, x ** y, opLength, or opSize: there are known problems with all of those. And opEnd has the problem that you expect it to be paired with an opBegin. opDollar is not as aesthetically pleasing as you might wish, but it's obvious and completely unambiguous. I think they're the best options we have.
