On Saturday, 11 August 2012 at 11:24:35 UTC, Marco Leise wrote:
Can you quickly explain the use of scope here? Does that mean
"I wont keep a reference to e"?
What are the implications? Does scope change the method
signature? Does the compiler enforce something? Will generated
code differ? Does
On Sat, 2012-08-04 at 16:13 +0200, Alex Rønne Petersen wrote:
> On 04-08-2012 15:52, Russel Winder wrote:
> > On Sat, 2012-08-04 at 15:11 +0200, Alex Rønne Petersen wrote:
> > […]
> >> Yeah, that's because DMD has -m32 to cross-compile for 32-bit. It's a
> >> bit silly that it's not optional.
> >
>
On Sat, 2012-08-11 at 02:24 +0200, dsimcha wrote:
[…]
> serialization is added, though, because I'm probably past the
> MPI-using stage of my life (my Ph.D. research is basically
> finished, I'm just revising my dissertation and preparing to
> defend) so I wouldn't get to eat my own dogfood.
Go
On Sat, 2012-08-11 at 02:19 +0200, David Piepgrass wrote:
[…]
> I hope someday to have a programming system whose features are
> not limited to whatever features the language designers saw fit
> to include -- a language where the users can add their own
> features, all the while maintaining "nat
On Sat, 2012-08-11 at 03:12 +0200, Andrew wrote:
> On Saturday, 11 August 2012 at 00:24:40 UTC, dsimcha wrote:
> > I was considering writing one, but I wanted it to be high-level
> > and easy-to-use. I ended up not doing it, initially because I
> > was waiting for serialization to be added to P
On 8/10/2012 9:55 PM, F i L wrote:
On the first condition, without an 'else z = ...', or if the condition was
removed at a later time, then you'll get a compiler error and be forced to
explicitly assign 'z' somewhere above using it. So C# and D work in "similar"
ways in this respect except that C
While working on project using COM I noticed that the win32 bindings
project declares its own version of IUnknown and all the classes in the
project derive from this.
So I set out to see the feasibility of modifying the win32 module to
use std.c.windows.com.IUnknown. This was a bit of work
Walter Bright wrote:
That is a good solution, but in my experience programmers just
throw in an =0, as it is simple and fast, and they don't
normally think about NaN's.
See! Programmers just want usable default values :-P
It's too bad that ints don't have a NaN value, but
interestingly enou
On 8/11/2012 1:50 AM, Sean Cavanaugh wrote:
While working on project using COM I noticed that the win32 bindings
project declares its own version of IUnknown and all the classes in the
project derive from this.
So I set out to see the feasibility of modifying the win32 module to use
std.c.window
On Saturday, 11 August 2012 at 04:33:38 UTC, Walter Bright wrote:
It's too bad that ints don't have a NaN value, but
interestingly enough, valgrind does default initialize them to
some internal NaN, making it a most excellent bug detector.
The compiler could always have flags specifying if va
Le 03/08/2012 02:22, Robert a écrit :
Hi all,
im a c++/c# developper and i really want to try D.
I am currently developing a MMORPG, client part is in c++ and
server in c#, i want to know if D language is "ok" for the client
side ?
Its a simple 2d isometric game using opengl 3.X (with shaders)
On Friday, 10 August 2012 at 23:22:03 UTC, Walter Bright wrote:
On 8/10/2012 3:50 PM, Paulo Pinto wrote:
If you cared to follow the discussion up to the JPL documents,
you
would see that the majority of C code is actually generated
via Python.
Then I stand corrected.
I think this goes into
On 8/11/2012 1:30 AM, Era Scarecrow wrote:
On Saturday, 11 August 2012 at 04:33:38 UTC, Walter Bright wrote:
It's too bad that ints don't have a NaN value, but interestingly enough,
valgrind does default initialize them to some internal NaN, making it a most
excellent bug detector.
The compi
On 8/11/2012 1:57 AM, Jakob Ovrum wrote:
The compiler in languages like C# doesn't try to prove that the variable is NOT
set and then emits an error. It tries to prove that the variable IS set, and if
it can't prove that, it's an error.
It's not an incorrect diagnostic, it does exactly what it's
On Saturday, 11 August 2012 at 09:40:39 UTC, Walter Bright wrote:
On 8/11/2012 1:57 AM, Jakob Ovrum wrote:
Because experience shows that even the yellers tend to do the
short, convenient one rather than the longer, correct one.
Bruce Eckel wrote an article about this years ago in reference
to
All I have is a very ad-hoc wrapper that does just what I needed
for my purposes. It basically has function prototypes for the
parts of the API I actually care about and a few high-level
wrappers for passing primitives and arrays to other nodes of the
same architecture.
On Saturday, 11 Augus
On 8/11/12 3:11 AM, F i L wrote:
I still prefer float class members to be defaulted to a usable value,
for the sake of consistency with ints.
Actually there's something that just happened two days ago to me that's
relevant to this, particularly because it's in a different language
(SQL) and d
Am Fri, 10 Aug 2012 15:56:53 +0200
schrieb Timon Gehr :
> int eval(scope Expr* e){
> final switch(e.tag) with(Expr.Tag){
> case val: return e.i;
> case plus: return eval(e.a) + eval(e.b);
> case minus: return eval(e.a) - eval(e.b);
> }
> }
Can you quickly e
On Saturday, 11 August 2012 at 07:44:34 UTC, ponce wrote:
Le 03/08/2012 02:22, Robert a écrit :
Hi all,
im a c++/c# developper and i really want to try D.
I am currently developing a MMORPG, client part is in c++ and
server in c#, i want to know if D language is "ok" for the
client
side ?
I
On Saturday, 11 August 2012 at 09:26:42 UTC, Walter Bright wrote:
On 8/11/2012 1:30 AM, Era Scarecrow wrote:
The compiler could always have flags specifying if variables
were used, and if they are false they are as good as NaN. Only
downside is a performance hit unless you Mark it as a releas
On Friday, 10 August 2012 at 08:38:18 UTC, Walter Bright wrote:
Take a look at bearophile's list of Ada features advertised as
making Ada code less buggy. Then look at, for example, dmd's
bugzilla list.
How many of those bugs would have been prevented by Ada's
features?
I'd say about 0.
I
On Friday, 10 August 2012 at 22:01:46 UTC, Walter Bright wrote:
It catches only a subset of these at compile time. I can craft
any number of ways of getting it to miss diagnosing it.
Consider this one:
float z;
if (condition1)
z = 5;
... lotsa code ...
if (condition2)
On Sat, 11 Aug 2012 13:24:12 +0200, Marco Leise wrote:
Am Fri, 10 Aug 2012 15:56:53 +0200
schrieb Timon Gehr :
int eval(scope Expr* e){
final switch(e.tag) with(Expr.Tag){
case val: return e.i;
case plus: return eval(e.a) + eval(e.b);
case minus: return eval
On Saturday, 11 August 2012 at 11:47:43 UTC, simendsjo wrote:
If I'm not mistaken, scope will enforce that the reference
never escapes the function.
So you cannot pass it to other functions that might keep it's
reference or store it in any way.
It _should_ enforce that, but its implementation
Walter Bright:
As for the remaining handwritten part, it follows the JPL
strict C coding
standard, which is an extension of MISRA C, with so many
restrictions that
it kind of turns C into a Pascal like language.
I read that document, and it isn't that strict. In fact, I
thought a lot of it
-1 % 16 = -1
Shouldn't that be 15? It seems like the sign is ignored for the modulo.
Is this a bug or intended behaviour? The Python implementation returns
here, as expected, 15.
On Saturday, 11 August 2012 at 13:48:16 UTC, David wrote:
-1 % 16 = -1
Shouldn't that be 15? It seems like the sign is ignored for the
modulo.
Is this a bug or intended behaviour? The Python implementation
returns here, as expected, 15.
From the language spec:
"For integral operands of th
On Saturday, 11 August 2012 at 13:48:16 UTC, David wrote:
-1 % 16 = -1
Shouldn't that be 15? It seems like the sign is ignored for the
modulo.
Is this a bug or intended behaviour? The Python implementation
returns here, as expected, 15.
http://en.wikipedia.org/wiki/Modulo_operation
David
Am 11.08.2012 16:00, schrieb Peter Alexander:
On Saturday, 11 August 2012 at 13:48:16 UTC, David wrote:
-1 % 16 = -1
Shouldn't that be 15? It seems like the sign is ignored for the modulo.
Is this a bug or intended behaviour? The Python implementation returns
here, as expected, 15.
From the
On Saturday, 11 August 2012 at 09:40:39 UTC, Walter Bright wrote:
Of course it is doing what the language requires, but it is an
incorrect diagnostic because a dead assignment is required.
And being a dead assignment, it can lead to errors when the
code is later modified, as I explained. I als
On Sat, Aug 11, 2012 at 2:19 AM, David Piepgrass wrote:
> I must say though, that while ADTs are useful for simple ASTs, I am not
> convinced that they scale to big and complex ASTs, let alone extensible
> ASTs, which I care about more.
You mean AST for D code?
> Nevertheless ADTs are at least
On 08/10/12 14:32, bearophile wrote:
> (Repost from D.learn.)
>
> Through Reddit I've found a page that shows a small example of Rust code:
>
> http://www.reddit.com/r/programming/comments/xyfqg/playing_with_rust/
> https://gist.github.com/3299083
>
> The code:
> https://gist.github.com/3307450
David:
Thanks! I thought modulo should alawys yield the same ... seems
like I was wrong ;)
It's C design that's wrong.
Bye,
bearophile
David:
-1 % 16 = -1
Shouldn't that be 15? It seems like the sign is ignored for the
modulo.
Is this a bug or intended behaviour? The Python implementation
returns here, as expected, 15.
It's a localized but important design bug of languages like C
that D has carried over for backward com
On Saturday, 11 August 2012 at 14:45:55 UTC, Russel Winder wrote:
On Sat, 2012-08-11 at 02:19 +0200, David Piepgrass wrote:
[…]
I hope someday to have a programming system whose features are
not limited to whatever features the language designers saw
fit to include -- a language where the users
On 11.08.2012 18:13, bearophile wrote:
David:
Thanks! I thought modulo should alawys yield the same ... seems like I
was wrong ;)
It's C design that's wrong.
And it's the processor design that makes it inefficient to correct it
nowadays.
Python's definition of modulo is far more useful t
Norbert Nemec:
And it's the processor design that makes it inefficient to
correct it nowadays.
Python's definition of modulo is far more useful than C's.
Implemented in machine code, however, it takes several
additional commands because the integer division is hardwired
to the C definition.
On Saturday, 11 August 2012 at 16:12:14 UTC, Peter Alexander
wrote:
On Saturday, 11 August 2012 at 14:45:55 UTC, Russel Winder
wrote:
On Sat, 2012-08-11 at 02:19 +0200, David Piepgrass wrote:
[…]
I hope someday to have a programming system whose features
are not limited to whatever features the
On Sat, 2012-08-11 at 18:12 +0200, Peter Alexander wrote:
> On Saturday, 11 August 2012 at 14:45:55 UTC, Russel Winder wrote:
[…]
> >
> > Isn't that language Lisp?
> >
>
> You missed the native efficiency part :-)
Most modern Lisp implementations employ JITing one way or another, so
you do get
On Saturday, 11 August 2012 at 18:04:29 UTC, Paulo Pinto wrote:
On Saturday, 11 August 2012 at 16:12:14 UTC, Peter Alexander
wrote:
On Saturday, 11 August 2012 at 14:45:55 UTC, Russel Winder
wrote:
On Sat, 2012-08-11 at 02:19 +0200, David Piepgrass wrote:
[…]
I hope someday to have a programmin
On Saturday, 11 August 2012 at 17:15:21 UTC, Norbert Nemec wrote:
On 11.08.2012 18:13, bearophile wrote:
David:
Thanks! I thought modulo should alawys yield the same ...
seems like I
was wrong ;)
It's C design that's wrong.
And it's the processor design that makes it inefficient to
corre
I've asked for this before:
http://www.digitalmars.com/d/archives/digitalmars/D/Could_we_have_mod_in_std.math_152977.html
On Sat, Aug 11, 2012 at 11:12 AM, bearophile
wrote:
>
> It's a localized but important design bug of languages like C that D has
> carried over for backward compatibility rea
Thiez:
A few extra instructions (a CMOV followed by ADD should
suffice, yes?) seems like a small price to pay if it can
prevent bugs. Why hasn't the Python-modulo been made the
default back when D was designed?
Maybe because C99 requires that kind of modulus, and D tries to
act as C99 where
Andrei Alexandrescu wrote:
[ ... ]
Although this case is not about default values but about the
result of a computation (in this case 0.0/0.0), I think it
still reveals the usefulness of having a singular value in the
floating point realm.
My argument was never against the usefulness of NaN
A few extra instructions (a CMOV followed by ADD should
suffice, yes?) seems like a small price to pay if it can
prevent bugs.
The price would really be quite insignificant since IDIV takes
tens of cycles and the additional work needed to make module
behave intuitively would be just a few cyc
On 8/11/2012 11:04 AM, Paulo Pinto wrote:
On Saturday, 11 August 2012 at 16:12:14 UTC, Peter Alexander wrote:
You missed the native efficiency part :-)
You mean like the Common Lisp compilers that are able to beat FORTRAN compilers
in floating point computations?
Floating point code is a rat
On 8/11/2012 12:33 PM, F i L wrote:
In D we have a bit of a conceptual double standard within the
number community. I have to remember these rules when I'm creating something,
not just when I'm debugging it. As often as D may have caught a construction
mistake specifically related to floats in my
F i L:
Walter Bright wrote:
3. Floating point values are default initialized to NaN.
This isn't a good feature, IMO. C# handles this much more
conveniently
An alternative possibility is to:
1) Default initialize variables just as currently done in D, with
0s, NaNs, etc;
2) Where the compi
Walter Bright wrote:
I'd rather have a 100 easy to find bugs than 1 unnoticed one
that went out in the field.
That's just the thing, bugs are arguably easier to hunt down when
things default to a consistent, usable value. When variables are
defaulted to Zero, I have a guarantee that any propa
On 08/11/2012 01:24 PM, Marco Leise wrote:
Am Fri, 10 Aug 2012 15:56:53 +0200
schrieb Timon Gehr:
int eval(scope Expr* e){
final switch(e.tag) with(Expr.Tag){
case val: return e.i;
case plus: return eval(e.a) + eval(e.b);
case minus: return eval(e.a) - eva
On 2012-08-11 12:30, Russel Winder wrote:
Marshalling and unmarshalling data structures is a real pain. On the
other hand isn't it something that has to be explicit when working with
MPI since the MPI API works solely in machine level data types.
Probably not exactly what's needed but:
https:
On Saturday, 11 August 2012 at 22:17:44 UTC, Timon Gehr wrote:
Will generated code differ?
Only the mangled symbol name will differ. (unlike when scope is
used on
delegate parameters, in this case it prevents closure
allocation at the call site.)
The code for callee stays the same, yes, but
On 08/12/2012 12:34 AM, David Nadlinger wrote:
On Saturday, 11 August 2012 at 22:17:44 UTC, Timon Gehr wrote:
Will generated code differ?
Only the mangled symbol name will differ. (unlike when scope is used on
delegate parameters, in this case it prevents closure allocation at
the call site.)
N.B. I haven't yet reviewed the proposal.
There's been a lot of discussion about the behavior of hash
accumulators, and I've just have a chat with Walter about such.
There are two angles in the discussion:
1. One is, the hash accumulator should work as an operand in an
accumulation expressio
On 8/11/2012 2:41 PM, bearophile wrote:
2) Where the compiler is certain a variable is read before any possible
initialization, it generates a compile-time error;
This has been suggested repeatedly, but it is in utter conflict with the whole
notion of default initialization, which nobody compl
On 8/11/2012 3:01 PM, F i L wrote:
Walter Bright wrote:
I'd rather have a 100 easy to find bugs than 1 unnoticed one that went out in
the field.
That's just the thing, bugs are arguably easier to hunt down when things default
to a consistent, usable value.
Many, many programming bugs trace b
On Saturday, August 11, 2012 19:29:53 Andrei Alexandrescu wrote:
> I also wonder whether there exists a better name than
> finish()
finish is what I've used for similar functions in the past. It seems like a
fine
name to me.
> and how to handle cases in which e.g. you finish() an output
> range
On 08/10/2012 06:01 PM, Walter Bright wrote:
On 8/10/2012 1:38 AM, F i L wrote:
Walter Bright wrote:
3. Floating point values are default initialized to NaN.
This isn't a good feature, IMO. C# handles this much more conveniently
with just
as much optimization/debugging benefit (arguably more
On Saturday, 11 August 2012 at 23:49:18 UTC, Chad J wrote:
On 08/10/2012 06:01 PM, Walter Bright wrote:
It catches only a subset of these at compile time. I can craft
any number of ways of getting it to miss diagnosing it.
Consider this one:
float z;
if (condition1)
z = 5;
... lotsa code ...
Walter Bright wrote:
That's just the thing, bugs are arguably easier to hunt down
when things default
to a consistent, usable value.
Many, many programming bugs trace back to assumptions that
floating point numbers act like ints. There's just no way to
avoid knowing and understanding the dif
See the new thread Andrei started entitled "finish function for output ranges".
I think this discussion has clearly discovered a shortcoming in the current
range design, and Andrei has a proposed solution.
On 8/11/2012 5:48 AM, Peter Alexander wrote:
Here's what I perceive to be the most common causes of bugs in things I write:
It's a good list. I know that the kinds of bugs my own code has has changed over
the years, clearly due to experience. I'm just not so plagued with low level
mistakes li
Walter Bright:
The problems I'm left with are:
1. incomplete understanding of the problem I'm trying to solve
2. changes in the design breaking the existing code's
assumptions
I don't really know what to do about (1). But with (2), I'm
thinking that a design that focuses better on encapsul
On 8/11/12 7:33 PM, Walter Bright wrote:
[snip]
Allow me to insert an opinion here. This post illustrates quite well how
opinionated our community is (for better or worse).
The OP has asked a topical question in a matter that is interesting and
also may influence the impact of the language to
I just got a bit frustrated and wanted to say that I like working with
Exceptions in Java a lot more. That has to do first but not foremost with the
declaration:
---Java->>
class MyException extends Exception {
public MyException(String msg) {
super(msg);
}
public MyException(String m
Am Sun, 12 Aug 2012 05:02:25 +0200
schrieb Marco Leise :
> ---D->>
>
> /**
> * Receives a response from the server.
> *
> * Some explanation of what
> * the function does in detail.
> *
> * Params:
> *response = receives the whole response
> * Throws:
> *UnexpectedResponseExce
Andrei Alexandrescu:
- The language's superior modeling power and level of control
comes at an increase in complexity compared to languages such
as e.g. Python. So the statistician would need a larger upfront
investment in order to reap the associated benefits.
Statistician often use the R l
On Sunday, August 12, 2012 05:02:25 Marco Leise wrote:
> I know that the Java way isn't perfect, because some lazy people write dummy
> exception handlers to silence the errors, but its a worse solution to _not_
> notify the user of a function, that it potentially throws exceptions, I
> think. So I
As far as I can tell, there's nothing technically stopping an infinite range
from being bidirectional, but I can't think of any case where such a range
makes any sense at all.
isRandomAccessRange is written specifically to allow infinite forward ranges be
random access without being bidirection
On 08/12/2012 05:02 AM, Marco Leise wrote:
I just got a bit frustrated and wanted to say that I like working with
Exceptions in Java a lot more. That has to do first but not foremost with the
declaration:
---Java->>
class MyException extends Exception {
public MyException(String msg) {
On 8/11/2012 8:02 PM, Marco Leise wrote:
I know that the Java way isn't perfect, because some lazy people write dummy
exception handlers to silence the errors, but its a worse solution to _not_
notify the user of a function, that it potentially throws exceptions, I
think. So I wish D was explicit
On Saturday, August 11, 2012 21:27:43 Walter Bright wrote:
> Anyhow, that article is why D does not have exception specifications. Also,
> please note that C++ dropped exception specifications.
Though it should be noted that exception specifications are _far_ worse than
checked exceptions, becaus
On Sunday, 12 August 2012 at 02:28:44 UTC, Andrei Alexandrescu
wrote:
On 8/11/12 7:33 PM, Walter Bright wrote:
[snip]
Allow me to insert an opinion here. This post illustrates quite
well how opinionated our community is (for better or worse).
The OP has asked a topical question in a matter th
Am 12.08.2012 02:43, schrieb F i L:
Yes, and this is an excellent argument for using NaN as a
debugging practice in general, but I don't see anything in favor
of defaulting to NaN. If you don't do some kind of check against
code, especially with such large data sets, bugs of various kinds
are goi
I read both articles and while Bruce Eckel's text read a bit like repeated
"swallow exception" to "avoid reams of code" I found the interview insightful.
Both aren't entirely negative on checked exceptions and Hejlsberg actually
wants them:
[Anders Hejlsberg]: "And so, when you take all of th
On Sun, Aug 12, 2012 at 6:11 AM, Jonathan M Davis wrote:
> Can anyone think of any situation where an infinite bidirectional range would
> make any sense at all?
I find infinite ranges useful mainly to represent mathematical objects.
I used them only twice:
* to represent integers: front/popF
76 matches
Mail list logo
