Re: assert(obj) is an atrocity
On 11/09/2011 04:52 AM, bcs wrote: On 11/08/2011 04:28 PM, Timon Gehr wrote: On 11/09/2011 01:21 AM, Timon Gehr wrote: On 11/09/2011 01:18 AM, Martin Nowak wrote: On Tue, 08 Nov 2011 23:35:33 +0100, Alex Rønne Petersen wrote: Hi, As the title suggests, I'm going to be rather blunt about this. assert(obj) testing the invariant *without* doing a null check is insane for the following reasons: 1) It is not what a user expects. It is *unintuitive*. 2) assert(!obj) does an is-null check. assert(obj) is a completely broken opposite of this. 3) No AssertError is thrown, which is the entire point of the built-in assert(). 4) The few added instructions for the null check hardly matter in a *debug* build of all things. I don't mind assert(obj) testing the invariant of obj. In fact, that very much makes sense. But please, please, *please* check the object for null first. This is a random inconsistency in the language with no other justification than "seg faults are convenient in a debugger". By the same logic, we might as well not have array bounds checks. However, the state of things is that array bounds checks are emitted by default and users can disable them for e.g. a release build. I don't see why this case is any different. - Alex It does check for null. Only it's a runtime support function (_d_invariant) and druntime is likely compiled without assertions. Are you really suggesting to add a null check before every method call? martin No, he is suggesting to add a null check for assert(objref);, a construct that *looks* as if it was a null check, but does something almost unrelated. BTW, the number of occurrences of assert(objref && 1); in my code is huge. I would have used assert(!!obj) because it's shorter. If you have already typed 'assert(obj', it is not shorter.
Re: assert(obj) is an atrocity
On 11/09/2011 01:46 AM, Martin Nowak wrote:
On Wed, 09 Nov 2011 01:28:06 +0100, Timon Gehr wrote:
On 11/09/2011 01:21 AM, Timon Gehr wrote:
On 11/09/2011 01:18 AM, Martin Nowak wrote:
On Tue, 08 Nov 2011 23:35:33 +0100, Alex Rønne Petersen
wrote:
Hi,
As the title suggests, I'm going to be rather blunt about this.
assert(obj) testing the invariant *without* doing a null check is
insane for the following reasons:
1) It is not what a user expects. It is *unintuitive*.
2) assert(!obj) does an is-null check. assert(obj) is a completely
broken opposite of this.
3) No AssertError is thrown, which is the entire point of the built-in
assert().
4) The few added instructions for the null check hardly matter in a
*debug* build of all things.
I don't mind assert(obj) testing the invariant of obj. In fact, that
very much makes sense. But please, please, *please* check the object
for null first. This is a random inconsistency in the language with no
other justification than "seg faults are convenient in a debugger". By
the same logic, we might as well not have array bounds checks.
However, the state of things is that array bounds checks are emitted
by default and users can disable them for e.g. a release build. I
don't see why this case is any different.
- Alex
It does check for null.
Only it's a runtime support function (_d_invariant) and druntime is
likely
compiled without assertions. Are you really suggesting to add a null
check before
every method call?
martin
No, he is suggesting to add a null check for assert(objref);, a
construct that *looks* as if it was a null check, but does something
almost unrelated.
BTW, the number of occurrences of assert(objref && 1); in my code is
huge.
Just as a side note.
I personally consider this as harmful. All too often an assert(obj !is
null) is misused
as disclaimer. It pretends false safety, while the obscure case where
something is called
with null is not found during testing.
What exactly do you consider harmful? If a function cannot deal with
null it cannot. I like to have an assertion failure during debugging
rather than a segfault. There is no "false safety", or
"true safety" for that matter, it is just as safe as not asserting
before dereferencing the null pointer.
//...
this(Class cc)in{assert(cc&&1);}body{c=cc;}
invariant(){ assert(c&&1); }
void foo(){/* rely on c !is null. */}
//...
(Btw, I tried to verify my statement, but actually there were only about
30 of those asserts in >6000 LOC.)
It also creates a coupling of the caller and the callee, because not
calling something with null
is now part of the in contract.
You make it sound like that is a bad thing?
Re: assert(obj) is an atrocity
Agreed. It would be nice to have an error thrown instead of just a segfault that you may or may not get a reliable backtrace for and then spend the next few days trying to find out where it is. -_- On 08/11/2011 6:19 PM, dsimcha wrote: On 11/8/2011 7:05 PM, Timon Gehr wrote: On 11/08/2011 11:35 PM, Alex Rønne Petersen wrote: Hi, As the title suggests, I'm going to be rather blunt about this. assert(obj) testing the invariant *without* doing a null check is insane for the following reasons: 1) It is not what a user expects. It is *unintuitive*. 2) assert(!obj) does an is-null check. assert(obj) is a completely broken opposite of this. 3) No AssertError is thrown, which is the entire point of the built-in assert(). 4) The few added instructions for the null check hardly matter in a *debug* build of all things. I don't mind assert(obj) testing the invariant of obj. In fact, that very much makes sense. But please, please, *please* check the object for null first. +1. +1. **AND** in debug mode all pointers should be checked for null. Conceptually, I fail to see how a null pointer dereference is different from an array bounds error. A null pointer is effectively an array with length zero.
Global immutable AA literals
Is it possible to modify DMD to allow a program like:
immutable int[int] aa = [1:15, 2: 7];
void main() {}
With the latest DMD it gives:
test.d(1): Error: non-constant expression [1:15,2:7]
Global immutable associative arrays are handy in script-like programs, I use
them now and then in Python (despite they are not immutable).
This is a workaround for script-like programs, that I sometimes use:
immutable int[int] aa;
static this() {
aa = [1:15, 2: 7];
}
void main() {}
But when possible I try to avoid using static this.
Bye,
bearophile
Damn - again!
I use the Pan newsreader. In the mornings when I'm looking at digitalmars.D I regularly make the mistake of editing the panel that displays the individual posts. I'll mark some of the older text and hit delete. At that point you are hosed. The article disappears, and there's no obvious way to get it back. Any recommendations for a different reader? Steve
Re: [OT] Damn - again!
On Wed, 09 Nov 2011 07:25:55 +0200, Steve Teale wrote: I use the Pan newsreader. In the mornings when I'm looking at digitalmars.D I regularly make the mistake of editing the panel that displays the individual posts. I'll mark some of the older text and hit delete. At that point you are hosed. The article disappears, and there's no obvious way to get it back. Any recommendations for a different reader? The Opera web browser has a nice newsreader. (Deleted items are sent to the trash, from where you can restore them.) I think Thunderbird is decent as well, but I've never used it. For the future, consider prefixing D-unrelated posts with [OT] per newsgroup netiquette. -- Best regards, Vladimirmailto:vladi...@thecybershadow.net
Re: assert(obj) is an atrocity
I don't get it -- why is this even necessary? Please don't answer here. Swing over to D.learn, where I am starting an "assert(obj) is a mystery" thread... ...because answers that start with "because..." belong in a "learn" newsgroup. Thanks in advance. -- Davidson On 11/8/2011 2:35 PM, Alex Rønne Petersen wrote: Hi, As the title suggests, I'm going to be rather blunt about this. assert(obj) testing the invariant *without* doing a null check is insane for the following reasons: 1) It is not what a user expects. It is *unintuitive*. 2) assert(!obj) does an is-null check. assert(obj) is a completely broken opposite of this. 3) No AssertError is thrown, which is the entire point of the built-in assert(). 4) The few added instructions for the null check hardly matter in a *debug* build of all things. I don't mind assert(obj) testing the invariant of obj. In fact, that very much makes sense. But please, please, *please* check the object for null first. This is a random inconsistency in the language with no other justification than "seg faults are convenient in a debugger". By the same logic, we might as well not have array bounds checks. However, the state of things is that array bounds checks are emitted by default and users can disable them for e.g. a release build. I don't see why this case is any different. - Alex
Re: assert(obj) is an atrocity
On 11/08/2011 04:28 PM, Timon Gehr wrote: On 11/09/2011 01:21 AM, Timon Gehr wrote: On 11/09/2011 01:18 AM, Martin Nowak wrote: On Tue, 08 Nov 2011 23:35:33 +0100, Alex Rønne Petersen wrote: Hi, As the title suggests, I'm going to be rather blunt about this. assert(obj) testing the invariant *without* doing a null check is insane for the following reasons: 1) It is not what a user expects. It is *unintuitive*. 2) assert(!obj) does an is-null check. assert(obj) is a completely broken opposite of this. 3) No AssertError is thrown, which is the entire point of the built-in assert(). 4) The few added instructions for the null check hardly matter in a *debug* build of all things. I don't mind assert(obj) testing the invariant of obj. In fact, that very much makes sense. But please, please, *please* check the object for null first. This is a random inconsistency in the language with no other justification than "seg faults are convenient in a debugger". By the same logic, we might as well not have array bounds checks. However, the state of things is that array bounds checks are emitted by default and users can disable them for e.g. a release build. I don't see why this case is any different. - Alex It does check for null. Only it's a runtime support function (_d_invariant) and druntime is likely compiled without assertions. Are you really suggesting to add a null check before every method call? martin No, he is suggesting to add a null check for assert(objref);, a construct that *looks* as if it was a null check, but does something almost unrelated. BTW, the number of occurrences of assert(objref && 1); in my code is huge. I would have used assert(!!obj) because it's shorter.
Re: Type Qualifiers and Wild Cards
On Wed, 09 Nov 2011 01:20:44 +0200, Walter Bright wrote: On 11/8/2011 9:37 AM, Gor Gyolchanyan wrote: Polluting keyword space is not a good idea unless it's impossible to interfere with identifiers. If keywords used a special syntax, like starting with a special character, then this wouldn't be an issue The whole "too many keywords" issue strikes me as strange. English has over a million words in it. Who cares if a language uses 80 or 100 of them? What difference can it possibly make? How can an extra 20 words pollute the million word namespace (and not including any non-word identifiers (like inout))? Another silly aspect of this issue is all keywords could be replaced by a sequence of special characters. For example, we could replace inout with ##. Voila! Less keywords! But is that better? Keywords exist to make the language more readable. That's why we use inout instead of ##, and it's why we use + instead of add. D is a rich language. That means it's going to have more syntax, more keywords and more symbols. My only concern with keywords is that to me a keyword must lift its own weight, For specific issues such as this, if there is a library solution (which i think is not applicable here), or a solution which requires an overload to an already defined keyword, it would be IMO a better choice. I can see why we have a keyword for it, and why it is not @inout. I suggested "return" because it semantically fits the definition of inout. Yet, you are again right, i didn't think about neither local/variable usage nor tuple syntax.
Re: assert(obj) is an atrocity
"Jesse Phillips" wrote in message news:j9cikj$t8a$1...@digitalmars.com... > Alex Rønne Petersen Wrote: > >> Hi, > > http://d.puremagic.com/issues/show_bug.cgi?id=6913 > > +1 This is nearly 5 years old: http://d.puremagic.com/issues/show_bug.cgi?id=796 And has a patch on github.
Re: Version Identifiers for Platforms / Architectures not supported byDMD
There is always one backwards compatible solution:
We could make version identifiers case insensitive.
It's a change from everywhere else in the language, but...
There is no 'correct' casing for os/architecture etc
windows vs Windows, linux vs Linux, x86 vs X86 are meaningless distinctions.
Invalid identifiers are _silently_ accepted.
eg.
version(Linux) {}
Would anybody ever _actually_ mean Linux here?
Because it works on a is/is not defined basis, this is one case where case
sensitivity harms usability. You never get an error for messing up the
casing, unless you explicitly add a static assert in an else clause.
Does anybody really define both 'MyVersion' and 'myVersion' and expect them
to do different things?
I think the inconsistency and the small addition to the spec are worth it to
have the compiler silently and automatically do the right thing, and remove
the impact of some incredibly inconsistent and arbirtary casing choices.
Re: assert(obj) is an atrocity
On Wed, 09 Nov 2011 01:21:47 +0100, Timon Gehr wrote:
On 11/09/2011 01:18 AM, Martin Nowak wrote:
On Tue, 08 Nov 2011 23:35:33 +0100, Alex Rønne Petersen
wrote:
Hi,
As the title suggests, I'm going to be rather blunt about this.
assert(obj) testing the invariant *without* doing a null check is
insane for the following reasons:
1) It is not what a user expects. It is *unintuitive*.
2) assert(!obj) does an is-null check. assert(obj) is a completely
broken opposite of this.
3) No AssertError is thrown, which is the entire point of the built-in
assert().
4) The few added instructions for the null check hardly matter in a
*debug* build of all things.
I don't mind assert(obj) testing the invariant of obj. In fact, that
very much makes sense. But please, please, *please* check the object
for null first. This is a random inconsistency in the language with no
other justification than "seg faults are convenient in a debugger". By
the same logic, we might as well not have array bounds checks.
However, the state of things is that array bounds checks are emitted
by default and users can disable them for e.g. a release build. I
don't see why this case is any different.
- Alex
It does check for null.
Only it's a runtime support function (_d_invariant) and druntime is
likely
compiled without assertions. Are you really suggesting to add a null
check before
every method call?
martin
No, he is suggesting to add a null check for assert(objref);, a
construct that *looks* as if it was a null check, but does something
almost unrelated.
Then just for reference, apply this patch to druntime and you'll get an
assertion instead.
diff --git a/src/rt/invariant.d b/src/rt/invariant.d
index 71337f1..bc5e53a 100644
--- a/src/rt/invariant.d
+++ b/src/rt/invariant.d
@@ -16,13 +16,16 @@
/**
*
*/
+import core.exception;
+
void _d_invariant(Object o)
{ ClassInfo c;
//printf("__d_invariant(%p)\n", o);
// BUG: needs to be filename/line of caller, not library routine
-assert(o !is null); // just do null check, not invariant check
+if (o is null)
+throw new AssertError("_d_invariant called with null reference.");
c = o.classinfo;
do
Re: assert(obj) is an atrocity
Alex Rønne Petersen Wrote: > Hi, http://d.puremagic.com/issues/show_bug.cgi?id=6913 +1
Re: assert(obj) is an atrocity
On Wed, 09 Nov 2011 01:28:06 +0100, Timon Gehr wrote: On 11/09/2011 01:21 AM, Timon Gehr wrote: On 11/09/2011 01:18 AM, Martin Nowak wrote: On Tue, 08 Nov 2011 23:35:33 +0100, Alex Rønne Petersen wrote: Hi, As the title suggests, I'm going to be rather blunt about this. assert(obj) testing the invariant *without* doing a null check is insane for the following reasons: 1) It is not what a user expects. It is *unintuitive*. 2) assert(!obj) does an is-null check. assert(obj) is a completely broken opposite of this. 3) No AssertError is thrown, which is the entire point of the built-in assert(). 4) The few added instructions for the null check hardly matter in a *debug* build of all things. I don't mind assert(obj) testing the invariant of obj. In fact, that very much makes sense. But please, please, *please* check the object for null first. This is a random inconsistency in the language with no other justification than "seg faults are convenient in a debugger". By the same logic, we might as well not have array bounds checks. However, the state of things is that array bounds checks are emitted by default and users can disable them for e.g. a release build. I don't see why this case is any different. - Alex It does check for null. Only it's a runtime support function (_d_invariant) and druntime is likely compiled without assertions. Are you really suggesting to add a null check before every method call? martin No, he is suggesting to add a null check for assert(objref);, a construct that *looks* as if it was a null check, but does something almost unrelated. BTW, the number of occurrences of assert(objref && 1); in my code is huge. Just as a side note. I personally consider this as harmful. All too often an assert(obj !is null) is misused as disclaimer. It pretends false safety, while the obscure case where something is called with null is not found during testing. It also creates a coupling of the caller and the callee, because not calling something with null is now part of the in contract.
Re: assert(obj) is an atrocity
On 09-11-2011 01:19, dsimcha wrote: On 11/8/2011 7:05 PM, Timon Gehr wrote: On 11/08/2011 11:35 PM, Alex Rønne Petersen wrote: Hi, As the title suggests, I'm going to be rather blunt about this. assert(obj) testing the invariant *without* doing a null check is insane for the following reasons: 1) It is not what a user expects. It is *unintuitive*. 2) assert(!obj) does an is-null check. assert(obj) is a completely broken opposite of this. 3) No AssertError is thrown, which is the entire point of the built-in assert(). 4) The few added instructions for the null check hardly matter in a *debug* build of all things. I don't mind assert(obj) testing the invariant of obj. In fact, that very much makes sense. But please, please, *please* check the object for null first. +1. +1. **AND** in debug mode all pointers should be checked for null. Conceptually, I fail to see how a null pointer dereference is different from an array bounds error. A null pointer is effectively an array with length zero. I agree on that point. Though right now I'd just be happy to have sane asserts. - Alex
Re: assert(obj) is an atrocity
On 09-11-2011 01:28, Timon Gehr wrote: On 11/09/2011 01:21 AM, Timon Gehr wrote: On 11/09/2011 01:18 AM, Martin Nowak wrote: On Tue, 08 Nov 2011 23:35:33 +0100, Alex Rønne Petersen wrote: Hi, As the title suggests, I'm going to be rather blunt about this. assert(obj) testing the invariant *without* doing a null check is insane for the following reasons: 1) It is not what a user expects. It is *unintuitive*. 2) assert(!obj) does an is-null check. assert(obj) is a completely broken opposite of this. 3) No AssertError is thrown, which is the entire point of the built-in assert(). 4) The few added instructions for the null check hardly matter in a *debug* build of all things. I don't mind assert(obj) testing the invariant of obj. In fact, that very much makes sense. But please, please, *please* check the object for null first. This is a random inconsistency in the language with no other justification than "seg faults are convenient in a debugger". By the same logic, we might as well not have array bounds checks. However, the state of things is that array bounds checks are emitted by default and users can disable them for e.g. a release build. I don't see why this case is any different. - Alex It does check for null. Only it's a runtime support function (_d_invariant) and druntime is likely compiled without assertions. Are you really suggesting to add a null check before every method call? martin No, he is suggesting to add a null check for assert(objref);, a construct that *looks* as if it was a null check, but does something almost unrelated. BTW, the number of occurrences of assert(objref && 1); in my code is huge. Just for the record, someone on the D IRC channel suggested using assert(!!obj); as another workaround. Obviously still ugly as hell, but less so. - Alex
Re: Bartosz about Chapel
On Tue, 08 Nov 2011 05:39:07 +0100, Caligo wrote: On Mon, Nov 7, 2011 at 7:51 PM, bearophile wrote: Bartosz talks a bit about the very nicely designed Chapel language: http://bartoszmilewski.wordpress.com/2011/11/07/supercomputing-in-seattle/ (But my appreciation for Chapel design is on other things). Bye, bearophile Interesting (maybe useless) facts: Chapel has 59 keywords. D has, I think, 107 keywords. C++11, I think, 81. Python has 33. Interesting, questionably. Useless, indeed.
Re: assert(obj) is an atrocity
On 11/09/2011 01:21 AM, Timon Gehr wrote: On 11/09/2011 01:18 AM, Martin Nowak wrote: On Tue, 08 Nov 2011 23:35:33 +0100, Alex Rønne Petersen wrote: Hi, As the title suggests, I'm going to be rather blunt about this. assert(obj) testing the invariant *without* doing a null check is insane for the following reasons: 1) It is not what a user expects. It is *unintuitive*. 2) assert(!obj) does an is-null check. assert(obj) is a completely broken opposite of this. 3) No AssertError is thrown, which is the entire point of the built-in assert(). 4) The few added instructions for the null check hardly matter in a *debug* build of all things. I don't mind assert(obj) testing the invariant of obj. In fact, that very much makes sense. But please, please, *please* check the object for null first. This is a random inconsistency in the language with no other justification than "seg faults are convenient in a debugger". By the same logic, we might as well not have array bounds checks. However, the state of things is that array bounds checks are emitted by default and users can disable them for e.g. a release build. I don't see why this case is any different. - Alex It does check for null. Only it's a runtime support function (_d_invariant) and druntime is likely compiled without assertions. Are you really suggesting to add a null check before every method call? martin No, he is suggesting to add a null check for assert(objref);, a construct that *looks* as if it was a null check, but does something almost unrelated. BTW, the number of occurrences of assert(objref && 1); in my code is huge.
Re: How about a 100% CTFE?
On 11/08/2011 07:35 PM, Martin Nowak wrote:
On Tue, 08 Nov 2011 09:08:49 +0100, Don wrote:
On 07.11.2011 21:36, Martin Nowak wrote:
On Mon, 07 Nov 2011 20:42:17 +0100, Trass3r wrote:
version(ARM)
{
immutable X = armSpecificCode(); // you want to run this on an
X86???
}
I've always thought that it would be worthwhile to experiment with
LLVM's JIT engine here.
But as has been said quite some care will be necessary for cross
compilation.
Allowing arbitrary non-pure functions would cause lots troubles.
Yeah, I think JIT for CTFE would be *very* interesting. But mainly
for reasons of speed rather than functionality.
How would JIT work in the above case?
You would need to do JIT a target agnostic IR.
Yeah, it's only the glue layer which needs to change. The main
complexity is dealing with pointers.
Currently it only seems viable for strongly pure functions.
The JIT could just translate impure and unsafe constructs to
exceptions/errors being thrown (or similar). It would then work the same
way as it does now.
One would still need to be very careful about target dependencies
through libc calls (sinl et.al.),
marshalling the arguments and the result is necessary and dmd doesn't
have a virtual machine, does it?
One could try to fake the latter by compiling to executables, but it
would require a target specific runtime/stdlib.
Overall I don't have too much performance issues with CTFE.
I've more issues with badly scaling compiler algorithms now that they
are used with magnitudes bigger input, i.e. unrolled loops or huge array
literals.
Especially considering that they performance impact mostly stems from
codegen
and sometime the generated code is only used for compile time
initialization.
A lot of garbage is created during CTFE as in-place changes don't always
work.
For example I haven't yet succeeded in writing an in-place CTFE quicksort,
so I ended up with 'sort(left) ~ pivot ~ sort(right)'.
martin
Re: assert(obj) is an atrocity
On 11/09/2011 01:18 AM, Martin Nowak wrote: On Tue, 08 Nov 2011 23:35:33 +0100, Alex Rønne Petersen wrote: Hi, As the title suggests, I'm going to be rather blunt about this. assert(obj) testing the invariant *without* doing a null check is insane for the following reasons: 1) It is not what a user expects. It is *unintuitive*. 2) assert(!obj) does an is-null check. assert(obj) is a completely broken opposite of this. 3) No AssertError is thrown, which is the entire point of the built-in assert(). 4) The few added instructions for the null check hardly matter in a *debug* build of all things. I don't mind assert(obj) testing the invariant of obj. In fact, that very much makes sense. But please, please, *please* check the object for null first. This is a random inconsistency in the language with no other justification than "seg faults are convenient in a debugger". By the same logic, we might as well not have array bounds checks. However, the state of things is that array bounds checks are emitted by default and users can disable them for e.g. a release build. I don't see why this case is any different. - Alex It does check for null. Only it's a runtime support function (_d_invariant) and druntime is likely compiled without assertions. Are you really suggesting to add a null check before every method call? martin No, he is suggesting to add a null check for assert(objref);, a construct that *looks* as if it was a null check, but does something almost unrelated.
Re: assert(obj) is an atrocity
On 11/8/2011 7:05 PM, Timon Gehr wrote: On 11/08/2011 11:35 PM, Alex Rønne Petersen wrote: Hi, As the title suggests, I'm going to be rather blunt about this. assert(obj) testing the invariant *without* doing a null check is insane for the following reasons: 1) It is not what a user expects. It is *unintuitive*. 2) assert(!obj) does an is-null check. assert(obj) is a completely broken opposite of this. 3) No AssertError is thrown, which is the entire point of the built-in assert(). 4) The few added instructions for the null check hardly matter in a *debug* build of all things. I don't mind assert(obj) testing the invariant of obj. In fact, that very much makes sense. But please, please, *please* check the object for null first. +1. +1. **AND** in debug mode all pointers should be checked for null. Conceptually, I fail to see how a null pointer dereference is different from an array bounds error. A null pointer is effectively an array with length zero.
Re: assert(obj) is an atrocity
On Tue, 08 Nov 2011 23:35:33 +0100, Alex Rønne Petersen wrote: Hi, As the title suggests, I'm going to be rather blunt about this. assert(obj) testing the invariant *without* doing a null check is insane for the following reasons: 1) It is not what a user expects. It is *unintuitive*. 2) assert(!obj) does an is-null check. assert(obj) is a completely broken opposite of this. 3) No AssertError is thrown, which is the entire point of the built-in assert(). 4) The few added instructions for the null check hardly matter in a *debug* build of all things. I don't mind assert(obj) testing the invariant of obj. In fact, that very much makes sense. But please, please, *please* check the object for null first. This is a random inconsistency in the language with no other justification than "seg faults are convenient in a debugger". By the same logic, we might as well not have array bounds checks. However, the state of things is that array bounds checks are emitted by default and users can disable them for e.g. a release build. I don't see why this case is any different. - Alex It does check for null. Only it's a runtime support function (_d_invariant) and druntime is likely compiled without assertions. Are you really suggesting to add a null check before every method call? martin
Re: Type Qualifiers and Wild Cards
On 11/08/2011 08:10 PM, Martin Nowak wrote: On Tue, 08 Nov 2011 02:08:27 +0100, Walter Bright wrote: http://drdobbs.com/blogs/cpp/231902461 Anyone want to do the reddit honors? I personally find it much more astonishing that inout methods finally work. All of this with one method definition, without const_cast macros, without overload ambiguities but with transitive qualifier safety. Actually, we don't have the transitive qualifier safety yet: http://d.puremagic.com/issues/show_bug.cgi?id=6912 But it should be a fairly easy fix to do.
Re: assert(obj) is an atrocity
On 11/08/2011 11:35 PM, Alex Rønne Petersen wrote: Hi, As the title suggests, I'm going to be rather blunt about this. assert(obj) testing the invariant *without* doing a null check is insane for the following reasons: 1) It is not what a user expects. It is *unintuitive*. 2) assert(!obj) does an is-null check. assert(obj) is a completely broken opposite of this. 3) No AssertError is thrown, which is the entire point of the built-in assert(). 4) The few added instructions for the null check hardly matter in a *debug* build of all things. I don't mind assert(obj) testing the invariant of obj. In fact, that very much makes sense. But please, please, *please* check the object for null first. +1.
Re: Type Qualifiers and Wild Cards
On 11/8/2011 3:57 PM, Martin Nowak wrote:
Yeah, the two common C++ solutions are either overload macros or non-transitive
const.
Remarkably enough it's hardly understood in a C++ context that transitive
qualifiers offer much stronger guarantees.
Take shared_ptr as a prominent example for the disaster.
_Tp*
get() const // never throws
{ return _M_ptr; }
With the even worse C++ solution to this being const_iterator.
Many top shelf C++ programmers do understand these issues. They've complained to
me about the unattractiveness of the various C++ solutions to the inout problem.
D's solution seems obvious only in retrospect.
Re: Type Qualifiers and Wild Cards
On 11/8/2011 3:57 PM, bearophile wrote: On the other handpaw, D2 has done a bit of mess with some of its tags name choice, it has "@safe" and "pure", but this choice looks arbitrary, why it isn't "safe" and "@pure"? Because of pure came first and @safe came much, much later.
Re: Type Qualifiers and Wild Cards
Walter: > The whole "too many keywords" issue strikes me as strange. English has over a > million words in it. Who cares if a language uses 80 or 100 of them? What > difference can it possibly make? How can an extra 20 words pollute the > million > word namespace (and not including any non-word identifiers (like inout))? I agree. This is also why I have suggested "auto_ref" instead of "auto ref", that I think is a bit confusing. On the other handpaw, D2 has done a bit of mess with some of its tags name choice, it has "@safe" and "pure", but this choice looks arbitrary, why it isn't "safe" and "@pure"? Bye, bearophile
Re: Type Qualifiers and Wild Cards
On Wed, 09 Nov 2011 00:01:09 +0100, Walter Bright
wrote:
On 11/8/2011 11:10 AM, Martin Nowak wrote:
I personally find it much more astonishing that inout methods finally
work.
I literally meant methods as in member functions.
Being able to use inout as method qualifier is way more
important than achieving the same for free functions as it
makes transitive qualifiers almost hassle free in simple cases.
In retrospect, it seems like a fairly straightforward solution, but it
took us many, many hours and gallons of coffee. And, as far as I know,
this solution has not been seen before in any other language, though
there is a crying need for it in C++.
Yeah, the two common C++ solutions are either overload macros or
non-transitive const.
Remarkably enough it's hardly understood in a C++ context that transitive
qualifiers offer much stronger guarantees.
Take shared_ptr as a prominent example for the disaster.
_Tp*
get() const // never throws
{ return _M_ptr; }
With the even worse C++ solution to this being const_iterator.
Re: Type Qualifiers and Wild Cards
The problem is, that by adding a new keyword we could accidentally invalidate lots of identifiers. Everything else is true, i agree :-) On Wed, Nov 9, 2011 at 3:20 AM, Walter Bright wrote: > On 11/8/2011 9:37 AM, Gor Gyolchanyan wrote: >> >> Polluting keyword space is not a good idea unless it's impossible to >> interfere with identifiers. >> If keywords used a special syntax, like starting with a special >> character, then this wouldn't be an issue > > > The whole "too many keywords" issue strikes me as strange. English has over > a million words in it. Who cares if a language uses 80 or 100 of them? What > difference can it possibly make? How can an extra 20 words pollute the > million word namespace (and not including any non-word identifiers (like > inout))? > > Another silly aspect of this issue is all keywords could be replaced by a > sequence of special characters. For example, we could replace inout with ##. > Voila! Less keywords! But is that better? > > Keywords exist to make the language more readable. That's why we use inout > instead of ##, and it's why we use + instead of add. > > D is a rich language. That means it's going to have more syntax, more > keywords and more symbols. >
Re: assert(obj) is an atrocity
+1
Re: Type Qualifiers and Wild Cards
On Tue, Nov 8, 2011 at 4:20 PM, Walter Bright wrote: > On 11/8/2011 9:37 AM, Gor Gyolchanyan wrote: > >> Polluting keyword space is not a good idea unless it's impossible to >> interfere with identifiers. >> If keywords used a special syntax, like starting with a special >> character, then this wouldn't be an issue >> > > > The whole "too many keywords" issue strikes me as strange. English has > over a million words in it. Who cares if a language uses 80 or 100 of them? > What difference can it possibly make? How can an extra 20 words pollute the > million word namespace (and not including any non-word identifiers (like > inout))? > > Another silly aspect of this issue is all keywords could be replaced by a > sequence of special characters. For example, we could replace inout with > ##. Voila! Less keywords! But is that better? > > Keywords exist to make the language more readable. That's why we use inout > instead of ##, and it's why we use + instead of add. > > D is a rich language. That means it's going to have more syntax, more > keywords and more symbols. > I've always thought "defenestrate" should have been used as a keyword instead of the more general "throw".
Re: assert(obj) is an atrocity
Alex R. Petersen: > But please, please, *please* check the object for null first. I tend to agree with this idea. Bye, bearophile
Re: Type Qualifiers and Wild Cards
On 11/8/2011 9:37 AM, Gor Gyolchanyan wrote: Polluting keyword space is not a good idea unless it's impossible to interfere with identifiers. If keywords used a special syntax, like starting with a special character, then this wouldn't be an issue The whole "too many keywords" issue strikes me as strange. English has over a million words in it. Who cares if a language uses 80 or 100 of them? What difference can it possibly make? How can an extra 20 words pollute the million word namespace (and not including any non-word identifiers (like inout))? Another silly aspect of this issue is all keywords could be replaced by a sequence of special characters. For example, we could replace inout with ##. Voila! Less keywords! But is that better? Keywords exist to make the language more readable. That's why we use inout instead of ##, and it's why we use + instead of add. D is a rich language. That means it's going to have more syntax, more keywords and more symbols.
Re: DSQLite a libraryri using sqlite
Le lundi 07 novembre 2011 à 12:27 +0100, mta`chrono a écrit : > > I recognized you'd used "Variant" as datatype. Did you define your own > Variant Type or is that the default one? But neverthenless your code > simplyfiecs using sqlite. > > - mta`chrono Thanks mta`chrono i have use Variot from std.variant (default) Currently this code is released to GPLv3 but i could give this code to phobos is not a problem or to anyone who would like doing std.database. Take the code and enhance it kind regards
Re: Type Qualifiers and Wild Cards
On 11/8/2011 11:10 AM, Martin Nowak wrote: I personally find it much more astonishing that inout methods finally work. In retrospect, it seems like a fairly straightforward solution, but it took us many, many hours and gallons of coffee. And, as far as I know, this solution has not been seen before in any other language, though there is a crying need for it in C++.
assert(obj) is an atrocity
Hi, As the title suggests, I'm going to be rather blunt about this. assert(obj) testing the invariant *without* doing a null check is insane for the following reasons: 1) It is not what a user expects. It is *unintuitive*. 2) assert(!obj) does an is-null check. assert(obj) is a completely broken opposite of this. 3) No AssertError is thrown, which is the entire point of the built-in assert(). 4) The few added instructions for the null check hardly matter in a *debug* build of all things. I don't mind assert(obj) testing the invariant of obj. In fact, that very much makes sense. But please, please, *please* check the object for null first. This is a random inconsistency in the language with no other justification than "seg faults are convenient in a debugger". By the same logic, we might as well not have array bounds checks. However, the state of things is that array bounds checks are emitted by default and users can disable them for e.g. a release build. I don't see why this case is any different. - Alex
Re: Type Qualifiers and Wild Cards
On 11/8/11 1:45 PM, deadalnix wrote: Le 08/11/2011 20:33, Andrei Alexandrescu a écrit : On 11/8/11 10:42 AM, so wrote: On Tue, 08 Nov 2011 16:39:35 +0200, so wrote: auto fun(return(type) a, ...) return(T) fun(return(S) a, ...) Damn, nobody likes it, and i was expecting at least a nobel prize on math. If it makes you feel better, this was on the table. We settled for inout. It's water under the bridge. Let's not waste time on this. Andrei You should definitively communicate more on that. There was discussion about it. That is a very old decision - it was made years before you joined this newsgroup. Especially, what are the points that made inout the « winning » solution ? We felt it sits better. That particular subjective decision can be questioned, but there is little point to it right now. Andrei
Re: Phobos examples and auto
Am 08.11.2011, 20:28 Uhr, schrieb Tobias Pankrath : Jonathan M Davis wrote: It's bad practice on both counts. Creating an unnecessary alias (especially for a built-in type) just serves to obfuscate code and confuse other programmers. Regardless of the name chosen, it shouldn't be done. And as cool as it may be to be able to use unicode in a .d file, unicode characters are not typeable on most keyboards, so using unicode characters for anything outside of strings is generally a bad idea. Exactly what I mean. My point was, that unicode names wouldn't be bad practice if everyone could easily write them, which is not the case :-( I fully agree on the "no alias of build-ins" thing. Nah, DDOC can help with the obfuscation: http://img805.imageshack.us/img805/5646/hinton.png I would not use this in anything that is supposed to end up as a library for anyone to use. Maybe in an "open-source" project where I don't actually want others to mess with my code, but use GitHub's free services. ;)
Re: Phobos examples and auto
On Tuesday, November 08, 2011 21:09:00 Marco Leise wrote: > With module boundaries I meant that it could have been that modules work > only with stuff defined inside of them. I'm really surprised that any time > or duration type works with all the others. In other words I wouldn't even > have *tried* to do that and instead rolled my own conversion code. Sorry > for the ignorance and so on... If you look at the API, Duration and TickDuration can clearly cast to one another and can intermix with binary operators. It does look like it's not as clear in std.datetime though that both types of durations work with the time point types, since the docs just say duration - not Duration or TickDuration - so I should probably make them clearer. But the date/time stuff is quite interoperable in general. It was designed to work together. You shouldn't need to write any conversion code yourself. - Jonathan M Davis
Re: Phobos examples and auto
Am 08.11.2011, 19:16 Uhr, schrieb Jonathan M Davis : On Tuesday, November 08, 2011 09:03 Marco Leise wrote: Am 07.11.2011, 14:09 Uhr, schrieb Kagamin : > All you need to know is that it's a time, and you don't need to know > anything else. The design makes sure the type supports idiomatic > operations, and the type system makes sure the operations are ok. The > docs also demonstrate how easy it is to write D: you don't need to know > the type name and everything still works. It takes a while for a person to build up so much faith into the library. And after all there are different 'times' in the wild, like file times, local/UTC time, dates without times, times without dates, hardware tick counts. I'm not sure I can use the current system time and subtract a TickDuration from it. Does this work, or only as long as you don't cross module boundaries? std.datetime publicly imports core.time, and both a Duration and a TickDuration can be added or subtracted from the various time point types (including SysTime). If it didn't though, you could just cast it to Duration (or even better, use std.conv.to do that) and add or subtract that. Module boundaries have nothing to do with it, and I don't see how they could. If std.datetime uses something, it imports it. If it doesn't publicly import it, and a function in std.datetime takes it as an argument or returns it, you have to import it in your code which uses that function. It's the same with any other module. - Jonathan M Davis With module boundaries I meant that it could have been that modules work only with stuff defined inside of them. I'm really surprised that any time or duration type works with all the others. In other words I wouldn't even have *tried* to do that and instead rolled my own conversion code. Sorry for the ignorance and so on... - Marco
Re: Type Qualifiers and Wild Cards
On 08-11-2011 15:02, Gor Gyolchanyan wrote: Well use of auto can be ambiguous here I think. I'm not sure, frankly. We should consult with Walter and co. because they have a better idea about syntax readability. I know I wouldn't enjoy typing three keywords on a single parameter. :) What about auto const ref ? That will force you to have both auto const and auto ref at the same time. On Tue, Nov 8, 2011 at 5:48 PM, deadalnix wrote: Le 08/11/2011 14:36, Gor Gyolchanyan a écrit : I agree with _inout_ being a bad choice. I'd rather use something involving _auto_, because this kind of use of _auto_ is already employed in _auto ref_ parameters and is visually unambiguous. Probably _auto const_ would do the trick. The actual _inout_ keyword could be flagged as deprecated and removed during the next breaking change in D (along with all other wonderful breaking changes that were proposed). Well use of auto can be ambiguous here I think. What about auto const ref ? - Alex
Re: Type Qualifiers and Wild Cards
Le 08/11/2011 20:33, Andrei Alexandrescu a écrit : On 11/8/11 10:42 AM, so wrote: On Tue, 08 Nov 2011 16:39:35 +0200, so wrote: auto fun(return(type) a, ...) return(T) fun(return(S) a, ...) Damn, nobody likes it, and i was expecting at least a nobel prize on math. If it makes you feel better, this was on the table. We settled for inout. It's water under the bridge. Let's not waste time on this. Andrei You should definitively communicate more on that. Especially, what are the points that made inout the « winning » solution ?
Re: Asking a const-related fix [Was: Re: DMD workforce contribution]
On 11/8/11 11:17 AM, Brad Anderson wrote: On Tue, Nov 8, 2011 at 1:52 AM, Walter Bright mailto:newshou...@digitalmars.com>>wrote: On 11/7/2011 4:57 AM, kenji hara wrote: I have call this concept "transitively modifiable", and I have implemented it with dmd/pull/166. For those who don't yet know, Kenji is a very prolific and high quality contributor to dmd. About half of the currently open dmd pull requests are from him (34 of 69). Very prolific is right. I swear I met a guy who knows Kenji. He exists!! Andrei
Re: Type Qualifiers and Wild Cards
On 11/8/11 10:42 AM, so wrote: On Tue, 08 Nov 2011 16:39:35 +0200, so wrote: auto fun(return(type) a, ...) return(T) fun(return(S) a, ...) Damn, nobody likes it, and i was expecting at least a nobel prize on math. If it makes you feel better, this was on the table. We settled for inout. It's water under the bridge. Let's not waste time on this. Andrei
Re: Type Qualifiers and Wild Cards
On 11/8/2011 6:39 AM, so wrote: auto fun(return(type) a, ...) return(T) fun(return(S) a, ...) Thought about using 'return', but it just looked confusing as hell (think about lambdas).
Re: Phobos examples and auto
Jonathan M Davis wrote: > It's bad practice on both counts. Creating an unnecessary alias > (especially for a built-in type) just serves to obfuscate code and confuse > other programmers. Regardless of the name chosen, it shouldn't be done. > And as cool as it may be to be able to use unicode in a .d file, unicode > characters are not typeable on most keyboards, so using unicode characters > for anything outside of strings is generally a bad idea. > Exactly what I mean. My point was, that unicode names wouldn't be bad practice if everyone could easily write them, which is not the case :-( I fully agree on the "no alias of build-ins" thing.
Re: Type Qualifiers and Wild Cards
On Tue, 08 Nov 2011 02:08:27 +0100, Walter Bright
wrote:
http://drdobbs.com/blogs/cpp/231902461
Anyone want to do the reddit honors?
I personally find it much more astonishing that inout methods finally work.
All of this with one method definition, without const_cast macros, without
overload ambiguities
but with transitive qualifier safety.
import std.stdio;
class C
{
inout(int) foo() inout
{
return a;
}
int a;
}
void printType(T)(T t)
{
writeln(typeid(t.foo()));
}
void main()
{
auto a = new immutable(C)();
auto b = new C();
printType!(immutable C)(a);
printType!(const C)(a);
printType!(const C)(b);
printType!(C)(b);
}
Re: Asking a const-related fix [Was: Re: DMD workforce contribution]
Am 08.11.2011, 09:52 Uhr, schrieb Walter Bright : On 11/7/2011 4:57 AM, kenji hara wrote: I have call this concept "transitively modifiable", and I have implemented it with dmd/pull/166. For those who don't yet know, Kenji is a very prolific and high quality contributor to dmd. Yep! I really wonder where that skill comes from, i.e. is he working in the compiler business or something like that? For me it's quite hard to figure out the most generic/appropriate way to fix a bug in dmd. But he seemed immediately knowledgeable about dmd's internals. Furthermore I wonder why he is that dedicated. I haven't seen him actually use D for some project ;)
Re: Phobos examples and auto
On Tuesday, November 08, 2011 10:43 Tobias Pankrath wrote: > Jonathan M Davis wrote: > > On Tuesday, November 08, 2011 17:25:57 Marco Leise wrote: > >> After some hacking into the keyboard layout file, I now use the alias ℕ > >> (the mathematical symbol for the non-negative integral number) > >> everywhere instead of the ugly size_t. It is even shorter than 'auto'. > >> > >> ℕ i = 5; > >> ℕ j = i; > >> ℕ k = j; > >> ℕ l = k; > >> > >> ;) > > No need for hacking, if you use www.neo-layout.org. I've learned it last > year. Biggest improvement of my human-computer interface for years. > > > but that's really bad practice > > if you intend anyone else to ever read your code. If it's just for you, > > then you obviously can do whatever you want, but size_t is the correct name > > > and what others are going to expect if they ever read your code. > > Only because it's an alias for an build-in type, that is unnecessary. You > could say the same thing about every other typedef. The reason, why this is > bad practice is, that almost no one can easily write that type with a > QWERTY keyboard. It's bad practice on both counts. Creating an unnecessary alias (especially for a built-in type) just serves to obfuscate code and confuse other programmers. Regardless of the name chosen, it shouldn't be done. And as cool as it may be to be able to use unicode in a .d file, unicode characters are not typeable on most keyboards, so using unicode characters for anything outside of strings is generally a bad idea. - Jonathan M Davis
Re: Phobos examples and auto
Jonathan M Davis wrote: > On Tuesday, November 08, 2011 17:25:57 Marco Leise wrote: >> After some hacking into the keyboard layout file, I now use the alias ℕ >> (the mathematical symbol for the non-negative integral number) everywhere >> instead of the ugly size_t. It is even shorter than 'auto'. >> >> ℕ i = 5; >> ℕ j = i; >> ℕ k = j; >> ℕ l = k; >> >> ;) No need for hacking, if you use www.neo-layout.org. I've learned it last year. Biggest improvement of my human-computer interface for years. > but that's really bad practice > if you intend anyone else to ever read your code. If it's just for you, then you obviously can do whatever you want, but size_t is the correct name > and what others are going to expect if they ever read your code. Only because it's an alias for an build-in type, that is unnecessary. You could say the same thing about every other typedef. The reason, why this is bad practice is, that almost no one can easily write that type with a QWERTY keyboard.
Re: How about a 100% CTFE?
On Tue, 08 Nov 2011 09:08:49 +0100, Don wrote:
On 07.11.2011 21:36, Martin Nowak wrote:
On Mon, 07 Nov 2011 20:42:17 +0100, Trass3r wrote:
version(ARM)
{
immutable X = armSpecificCode(); // you want to run this on an
X86???
}
I've always thought that it would be worthwhile to experiment with
LLVM's JIT engine here.
But as has been said quite some care will be necessary for cross
compilation.
Allowing arbitrary non-pure functions would cause lots troubles.
Yeah, I think JIT for CTFE would be *very* interesting. But mainly
for reasons of speed rather than functionality.
How would JIT work in the above case?
You would need to do JIT a target agnostic IR.
Yeah, it's only the glue layer which needs to change. The main
complexity is dealing with pointers.
Currently it only seems viable for strongly pure functions.
One would still need to be very careful about target dependencies through
libc calls (sinl et.al.),
marshalling the arguments and the result is necessary and dmd doesn't have
a virtual machine, does it?
One could try to fake the latter by compiling to executables, but it would
require a target specific runtime/stdlib.
Overall I don't have too much performance issues with CTFE.
I've more issues with badly scaling compiler algorithms now that they
are used with magnitudes bigger input, i.e. unrolled loops or huge array
literals.
Especially considering that they performance impact mostly stems from
codegen
and sometime the generated code is only used for compile time
initialization.
A lot of garbage is created during CTFE as in-place changes don't always
work.
For example I haven't yet succeeded in writing an in-place CTFE quicksort,
so I ended up with 'sort(left) ~ pivot ~ sort(right)'.
martin
Re: Asking a const-related fix [Was: Re: DMD workforce contribution]
All i ever heard from him is pull requests. He basically makes DMD's evolution possible :-) Without any jokes, we should throw a party in his honor :-) On Tue, Nov 8, 2011 at 10:16 PM, Jonathan M Davis wrote: > On Tuesday, November 08, 2011 09:17 Brad Anderson wrote: >> On Tue, Nov 8, 2011 at 1:52 AM, Walter Bright > wrote: >> > On 11/7/2011 4:57 AM, kenji hara wrote: >> >> I have call this concept "transitively modifiable", and I have >> >> implemented it with dmd/pull/166. >> > >> > For those who don't yet know, Kenji is a very prolific and high quality >> > contributor to dmd. >> >> About half of the currently open dmd pull requests are from him (34 of 69). >> Very prolific is right. > > And he's actually one of the few who actively does work on both dmd and > Phobos. We're definitely lucky to have him. > > - Jonathan M Davis >
Re: Asking a const-related fix [Was: Re: DMD workforce contribution]
On Tuesday, November 08, 2011 09:17 Brad Anderson wrote: > On Tue, Nov 8, 2011 at 1:52 AM, Walter Bright wrote: > > On 11/7/2011 4:57 AM, kenji hara wrote: > >> I have call this concept "transitively modifiable", and I have > >> implemented it with dmd/pull/166. > > > > For those who don't yet know, Kenji is a very prolific and high quality > > contributor to dmd. > > About half of the currently open dmd pull requests are from him (34 of 69). > Very prolific is right. And he's actually one of the few who actively does work on both dmd and Phobos. We're definitely lucky to have him. - Jonathan M Davis
Re: Phobos examples and auto
On Tuesday, November 08, 2011 09:03 Marco Leise wrote: > Am 07.11.2011, 14:09 Uhr, schrieb Kagamin : > > All you need to know is that it's a time, and you don't need to know > > anything else. The design makes sure the type supports idiomatic > > operations, and the type system makes sure the operations are ok. The > > docs also demonstrate how easy it is to write D: you don't need to know > > the type name and everything still works. > > It takes a while for a person to build up so much faith into the library. > And after all there are different 'times' in the wild, like file times, > local/UTC time, dates without times, times without dates, hardware tick > counts. I'm not sure I can use the current system time and subtract a > TickDuration from it. Does this work, or only as long as you don't cross > module boundaries? std.datetime publicly imports core.time, and both a Duration and a TickDuration can be added or subtracted from the various time point types (including SysTime). If it didn't though, you could just cast it to Duration (or even better, use std.conv.to do that) and add or subtract that. Module boundaries have nothing to do with it, and I don't see how they could. If std.datetime uses something, it imports it. If it doesn't publicly import it, and a function in std.datetime takes it as an argument or returns it, you have to import it in your code which uses that function. It's the same with any other module. - Jonathan M Davis
Re: Type Qualifiers and Wild Cards
Polluting keyword space is not a good idea unless it's impossible to interfere with identifiers. If keywords used a special syntax, like starting with a special character, then this wouldn't be an issue On Tue, Nov 8, 2011 at 9:28 PM, so wrote: > On Tue, 08 Nov 2011 19:21:50 +0200, Gor Gyolchanyan > wrote: > >> Actually, I can make it a library solution right now. >> Just provide a template, which takes a symbolic representation of >> constness and a type and constructs the appropriately const type. >> And a template, which extracts the const-ness of a type. >> It's gonna look ugly, but it will work. > > How ugly it can get, it is a keyword of its own, for single purpose! :) >
Re: Type Qualifiers and Wild Cards
On Tue, 08 Nov 2011 19:20:49 +0200, RivenTheMage wrote: auto fun(return(type) a, ...) auto fun(ret a, ...) ? Don't dare take my ret away, unless you give back something that really counts.
Re: Type Qualifiers and Wild Cards
On Tue, 08 Nov 2011 19:21:50 +0200, Gor Gyolchanyan wrote: Actually, I can make it a library solution right now. Just provide a template, which takes a symbolic representation of constness and a type and constructs the appropriately const type. And a template, which extracts the const-ness of a type. It's gonna look ugly, but it will work. How ugly it can get, it is a keyword of its own, for single purpose! :)
Re: Type Qualifiers and Wild Cards
> auto fun(return(type) a, ...) auto fun(ret a, ...) ?
Re: Type Qualifiers and Wild Cards
Actually, I can make it a library solution right now. Just provide a template, which takes a symbolic representation of constness and a type and constructs the appropriately const type. And a template, which extracts the const-ness of a type. It's gonna look ugly, but it will work. On Tue, Nov 8, 2011 at 9:02 PM, so wrote: > On Tue, 08 Nov 2011 18:56:59 +0200, Gor Gyolchanyan > wrote: > >> Unless you write a template constraint, this will force you to use the >> same type, instead of the same storage class. >> >> On Tue, Nov 8, 2011 at 8:42 PM, so wrote: >>> >>> On Tue, 08 Nov 2011 16:39:35 +0200, so wrote: >>> auto fun(return(type) a, ...) return(T) fun(return(S) a, ...) >>> >>> Damn, nobody likes it, and i was expecting at least a nobel prize on >>> math. >>> > > return(T) fun(return(S) a, ...) > > Functions just like inout right now, and with: > > auto fun(return(type) a, ...) > > I meant to suggest if not said otherwise (as in the case above) we can just > go return what it was passed. > (I am not sure, probably inout already does this too) >
Re: Type Qualifiers and Wild Cards
On Tue, 08 Nov 2011 19:09:40 +0200, deadalnix wrote:
You'll face a problem when it come to define variable within the
function and not in its definition.
I'm affraid this will become very confusing in this case.
inout fun(inout) {
inout var; // This is what you are saying i believe.
}
You are definitely right, if this use case was intended.
Re: Asking a const-related fix [Was: Re: DMD workforce contribution]
On Tue, Nov 8, 2011 at 1:52 AM, Walter Bright wrote: > On 11/7/2011 4:57 AM, kenji hara wrote: > >> I have call this concept "transitively modifiable", and I have >> implemented it with dmd/pull/166. >> > > For those who don't yet know, Kenji is a very prolific and high quality > contributor to dmd. > About half of the currently open dmd pull requests are from him (34 of 69). Very prolific is right.
Re: How about a 100% CTFE?
Agreed. The drawbacks must be studies completely. That's why I appreciate all your criticism :-) About inconsistency. True, this is a bit confusing from one perspective. But i think we can define a straight-forward way of doing this. Here's what I'm thinking about. We currently have two stages of compilation: * translate to object files * link into executable files I suggest separating compile-time preparation into third stage, that would look like this: * translate into "run-time code" * translate into object files * link into executable files With this scenario, the compiler will run the first stage on ALL files first, which will reflect the changes in all files. Then, the run-time code could be arbitrarily compiled and linked as it's done ATM. The key feature is, that when you compile your code (even if you do it with separate compile passes), you always run the CTFE for all files before you do anything else. And the exact logic of CTFE can be defined in a single consistent manner. If the import tree implies a certain dependencies, then the order of evaluation will honor it, otherwise it will rearrange at will. After all, if you increment a compile-time value and you don't specify any relationship with other files, you must either make it private (don't provide a public incrementing) or be ready to get arbitrarily incremented value. On Tue, Nov 8, 2011 at 6:56 PM, deadalnix wrote: > Le 08/11/2011 14:54, Gor Gyolchanyan a écrit : >>> >>> Which assert will fail ? Does one will fail ? Note that two different >>> instances of the compiler will compile b and c, and they are exscluded of >>> one another import tree so each instance isn't aware of the other. >> >> Both will succeed and on both cases a will be 1 because both run >> independently. It's similar to asking if two different runs of the >> same program, which increment a global variable will see each others' >> results. The answer is: no. >> > > Ok I seen your point. The problem is that a is a global variable and is > incremented 2 times. But at the end, it will ends up that it is incremented > only one time. Maybe 0. > > I think this behaviour should be avoided because of the oinconsistency of > what is happening at compile time and what you get as a result at run time. > Some limitation should be added to the solution to not end up in thoses kind > of behaviour IMO. > >>> YOU are comming with a solution, YOU have to explain how it solves every >>> problems. Everything else is flawed logic. >> >> Nothing ever solves every problem. That's a very unwise thing to say >> for someone, who claims to be logical. problems come and go depending >> on how the features are used. Each problem (or bunches of problems) >> must be dealt with explicitly (using inductive logic to account for >> other possible problems). As i said before, if you have problems, i'll >> help resolve them. If i don't - i'll withdraw my proposal. > > Sorry my mistake, I didn't express myself the right way. I should have saud > how it solve or do not solve every problems. Obviously, the solution to > every problem usually do not exists. > > The point is that every problems related to the solution must be considered > to know if the solution is really solving something usefull and if its > drawback (problem that are not solved or created by the given solution). >
Re: Type Qualifiers and Wild Cards
Le 08/11/2011 18:02, so a écrit : On Tue, 08 Nov 2011 18:56:59 +0200, Gor Gyolchanyan wrote: Unless you write a template constraint, this will force you to use the same type, instead of the same storage class. On Tue, Nov 8, 2011 at 8:42 PM, so wrote: On Tue, 08 Nov 2011 16:39:35 +0200, so wrote: auto fun(return(type) a, ...) return(T) fun(return(S) a, ...) Damn, nobody likes it, and i was expecting at least a nobel prize on math. return(T) fun(return(S) a, ...) Functions just like inout right now, and with: auto fun(return(type) a, ...) I meant to suggest if not said otherwise (as in the case above) we can just go return what it was passed. (I am not sure, probably inout already does this too) You'll face a problem when it come to define variable within the function and not in its definition. I'm affraid this will become very confusing in this case.
Re: Phobos examples and auto
Am 07.11.2011, 14:09 Uhr, schrieb Kagamin : All you need to know is that it's a time, and you don't need to know anything else. The design makes sure the type supports idiomatic operations, and the type system makes sure the operations are ok. The docs also demonstrate how easy it is to write D: you don't need to know the type name and everything still works. It takes a while for a person to build up so much faith into the library. And after all there are different 'times' in the wild, like file times, local/UTC time, dates without times, times without dates, hardware tick counts. I'm not sure I can use the current system time and subtract a TickDuration from it. Does this work, or only as long as you don't cross module boundaries? It may be a minor issue or personal taste, but I also like to be able to jump to the declaration of a type by ctrl-clicking on its name or get auto-completion that - despite its name - works only with variables not declared as auto for now in the most sophisticated D2 IDE on Linux. And since often you only have to type two or three letters of a type name for it to be auto-completed, it isn't even often a time saver to write auto. I accept the "easier to refactor the used type" argument though :)
Re: Type Qualifiers and Wild Cards
On Tue, 08 Nov 2011 18:56:59 +0200, Gor Gyolchanyan wrote: Unless you write a template constraint, this will force you to use the same type, instead of the same storage class. On Tue, Nov 8, 2011 at 8:42 PM, so wrote: On Tue, 08 Nov 2011 16:39:35 +0200, so wrote: auto fun(return(type) a, ...) return(T) fun(return(S) a, ...) Damn, nobody likes it, and i was expecting at least a nobel prize on math. return(T) fun(return(S) a, ...) Functions just like inout right now, and with: auto fun(return(type) a, ...) I meant to suggest if not said otherwise (as in the case above) we can just go return what it was passed. (I am not sure, probably inout already does this too)
Re: Type Qualifiers and Wild Cards
Unless you write a template constraint, this will force you to use the same type, instead of the same storage class. On Tue, Nov 8, 2011 at 8:42 PM, so wrote: > On Tue, 08 Nov 2011 16:39:35 +0200, so wrote: > >> auto fun(return(type) a, ...) >> return(T) fun(return(S) a, ...) > > Damn, nobody likes it, and i was expecting at least a nobel prize on math. >
Re: Phobos examples and auto
On Tuesday, November 08, 2011 17:25:57 Marco Leise wrote: > After some hacking into the keyboard layout file, I now use the alias ℕ > (the mathematical symbol for the non-negative integral number) everywhere > instead of the ugly size_t. It is even shorter than 'auto'. > > ℕ i = 5; > ℕ j = i; > ℕ k = j; > ℕ l = k; > > ;) LOL. And no one but you will have any idea what your code is doing. It _is_ kind of cool to see unicode like that in D, but that's _really_ bad practice if you intend anyone else to ever read your code. If it's just for you, then you obviously can do whatever you want, but size_t is the correct name and what others are going to expect if they ever read your code. - Jonathan M Davis
Re: Phobos examples and auto
Am 07.11.2011, 13:18 Uhr, schrieb Steven Schveighoffer : On Sat, 05 Nov 2011 20:53:25 -0400, Andrej Mitrovic wrote: On 11/6/11, Steven Schveighoffer wrote: 2. If the user hovers the mouse over auto, display a tooltip with the auto-determined name That would scare people away when they see the name of a sophisticated template instantiation. :) I would think the opposite. "whoa! auto makes it so I don't have to type all that junk? Awesome!" -Steve Or "Omg! D's templates generates all this junk that can only be coped with using auto?", hehe. I remember when I first looked into std.algorithm _without_ any functional programming background or reading Andrei's book. It was absolutely incomprehensible to me, what these functions like 'filter' could return or how I can make use of it. I wanted to put an array into it and get back a filtered array. I imagined that the return value must be some obscure language internal called a 'Result' and found no other way to use it except for wrapping any functions from std.algorithm in another call to array(...). Only recently I understood enough of CTFE to recognize that the return values are still conventional structs offering an implicit interface and no black magic. Now I quite like what is possible with - for example - map in one line of code.
Re: How about a 100% CTFE?
On Tue, 08 Nov 2011 13:51:28 +0100, Kagamin wrote: Martin Nowak Wrote: > How would JIT work in the above case? You would need to do JIT a target agnostic IR. AFAIK, target-agnostic LLVM IR is impossible. It's in FAQ. http://www.llvm.org/docs/FAQ.html#platformindependent ? Transforming a source file to platform independent IR is not needed. You need to interpret the IR that is emitted after semantic reduction, not the one before. martin
Re: Type Qualifiers and Wild Cards
On Tue, 08 Nov 2011 16:39:35 +0200, so wrote: auto fun(return(type) a, ...) return(T) fun(return(S) a, ...) Damn, nobody likes it, and i was expecting at least a nobel prize on math.
Re: Phobos examples and auto
Am 07.11.2011, 18:36 Uhr, schrieb Jonathan M Davis : On Monday, November 07, 2011 08:55 Steven Schveighoffer wrote: On Mon, 07 Nov 2011 11:51:36 -0500, Steve Teale wrote: > On Mon, 07 Nov 2011 07:17:59 -0500, Steven Schveighoffer wrote: >> uint i = 5; >> uint j = i; >> uint k = j; >> uint l = k; >> >> If I want to make this code 64-bit aware, I need to change all 4 lines. >> If these lines are scattered throughout the code, I have to play the >> cyclical compiler game, where I change the first one, then compile, >> change the second one, compile, etc. > > Steve, > > OK, you've uncovered a stark example of my ignorance there. The Types > documentation does not as far as I can see mention any differences > between a 32 bit and a 64 bit environment. It says simply that a uint is > 32 bits unsigned. > > What is the change that has to be made in your example? Sorry, that is my fault. My example was too devoid of context :) Try this instead: int[] arr; uint i = arr.length; ... i.e. the change that should be made is uint => size_t. Yeah, all of those examples would be typed to int. size_t is actually a prime example of when you actually need to use the type. The length property on an array is one of the few cases where the type will be inferred as size_t. - Jonathan M Davis After some hacking into the keyboard layout file, I now use the alias ℕ (the mathematical symbol for the non-negative integral number) everywhere instead of the ugly size_t. It is even shorter than 'auto'. ℕ i = 5; ℕ j = i; ℕ k = j; ℕ l = k; ;)
Re: How about a 100% CTFE?
Le 08/11/2011 14:54, Gor Gyolchanyan a écrit : Which assert will fail ? Does one will fail ? Note that two different instances of the compiler will compile b and c, and they are exscluded of one another import tree so each instance isn't aware of the other. Both will succeed and on both cases a will be 1 because both run independently. It's similar to asking if two different runs of the same program, which increment a global variable will see each others' results. The answer is: no. Ok I seen your point. The problem is that a is a global variable and is incremented 2 times. But at the end, it will ends up that it is incremented only one time. Maybe 0. I think this behaviour should be avoided because of the oinconsistency of what is happening at compile time and what you get as a result at run time. Some limitation should be added to the solution to not end up in thoses kind of behaviour IMO. YOU are comming with a solution, YOU have to explain how it solves every problems. Everything else is flawed logic. Nothing ever solves every problem. That's a very unwise thing to say for someone, who claims to be logical. problems come and go depending on how the features are used. Each problem (or bunches of problems) must be dealt with explicitly (using inductive logic to account for other possible problems). As i said before, if you have problems, i'll help resolve them. If i don't - i'll withdraw my proposal. Sorry my mistake, I didn't express myself the right way. I should have saud how it solve or do not solve every problems. Obviously, the solution to every problem usually do not exists. The point is that every problems related to the solution must be considered to know if the solution is really solving something usefull and if its drawback (problem that are not solved or created by the given solution).
Re: Type Qualifiers and Wild Cards
Le 08/11/2011 15:16, Gor Gyolchanyan a écrit : Makes sense, but it looks ugly. I don't know about others, but for me underscores in names are associated with things, that you shouldn't touch (including private data and functions). Uppercase, on the other hand is associated with high-level constructs (which are usually in user-space only). This leads to the conclusion, that keywords should be short lowercase one-word identifiers. Agreed. To resolve the accurately noticed "ugly space" we could require parenthesis. const, shared and immutable use parentheses and it looks very elegant. auto(const) and auto(ref) looks better, then auto const and auto ref, IMO. Parenthesis are painful to write on some keyboard. We should use them only to desembiguate when appropriate, not as a main syntax. This is why I advocate for this construct having its own keyword.
Re: Type Qualifiers and Wild Cards
On Tue, 08 Nov 2011 15:08:19 +0200, deadalnix wrote: Le 08/11/2011 02:08, Walter Bright a écrit : http://drdobbs.com/blogs/cpp/231902461 Anyone want to do the reddit honors? Great article. The only point I would raise is the choice of inout as a keyword for this. This make no sens whatsoever. Here is why : - inout did exist in D1 and is different. - in and out qualifier already exists and have nothing to do with inout. - in and out are used for contracts and have nothing to do with inout. - the inout term has nothing to do with const/immutable/mutable. This is in a totally different lexical field. Another keyword should be choosen. vconst, as suggested here : http://prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP2 is way more appropriate. On external details, but still important, I face the need of inout few days ago and did knew about it. The documentation on const/immutable ( http://www.d-programming-language.org/const3.html ) doesn't mention it. The page on fucntion mention it, but it would be nice to have at least a link on the const/immutable page. auto fun(return(type) a, ...) return(T) fun(return(S) a, ...)
Re: Type Qualifiers and Wild Cards
Makes sense, but it looks ugly. I don't know about others, but for me underscores in names are associated with things, that you shouldn't touch (including private data and functions). Uppercase, on the other hand is associated with high-level constructs (which are usually in user-space only). This leads to the conclusion, that keywords should be short lowercase one-word identifiers. To resolve the accurately noticed "ugly space" we could require parenthesis. const, shared and immutable use parentheses and it looks very elegant. auto(const) and auto(ref) looks better, then auto const and auto ref, IMO. On Tue, Nov 8, 2011 at 6:05 PM, bearophile wrote: > Gor Gyolchanyan: > >> I agree with _inout_ being a bad choice. >> I'd rather use something involving _auto_, because this kind of use of >> _auto_ is already employed in _auto ref_ parameters and is visually >> unambiguous. > > I rather hate a tag name that contains a space in the middle like "auto ref". > I like "auto_ref" much better. > > Bye, > bearophile >
Re: Type Qualifiers and Wild Cards
Gor Gyolchanyan: > I agree with _inout_ being a bad choice. > I'd rather use something involving _auto_, because this kind of use of > _auto_ is already employed in _auto ref_ parameters and is visually > unambiguous. I rather hate a tag name that contains a space in the middle like "auto ref". I like "auto_ref" much better. Bye, bearophile
Re: GC for pure functions -- implementation ideas
> __traits(gcallocates, someFunction) This would be an AWESOME idea, because it would allow to specialize functions based on the way, let's say, delegates behave and if they don't use GC, the specialized function would also restrain from using it making it follow the behavior pattern and making it much more usable in performance-critical environments, while keeping it usable in GC-aware environment too. On Tue, Nov 8, 2011 at 5:53 PM, bearophile wrote: > Robert Jacques: > >> I really like this general concept (It feels a lot like young/old >> generational collecting, but without the overhead), both for non-leaky >> pure functions and ctfe. > > As first step to implement Don's GC idea I think it will be useful a > __traits(gcallocates, someFunction) that returns true at compile-time if > someFunction performs allocations from the GC heap or if it calls functions > where __traits(gcallocates, otherFunction) returns true. > > Bye, > bearophile >
Re: Type Qualifiers and Wild Cards
> Well use of auto can be ambiguous here I think. I'm not sure, frankly. We should consult with Walter and co. because they have a better idea about syntax readability. > What about auto const ref ? That will force you to have both auto const and auto ref at the same time. On Tue, Nov 8, 2011 at 5:48 PM, deadalnix wrote: > Le 08/11/2011 14:36, Gor Gyolchanyan a écrit : >> >> I agree with _inout_ being a bad choice. >> I'd rather use something involving _auto_, because this kind of use of >> _auto_ is already employed in _auto ref_ parameters and is visually >> unambiguous. >> Probably _auto const_ would do the trick. >> >> The actual _inout_ keyword could be flagged as deprecated and removed >> during the next breaking change in D (along with all other wonderful >> breaking changes that were proposed). >> > > Well use of auto can be ambiguous here I think. > > What about auto const ref ? >
Re: [D-Programming-Deimos] Review process?
> Walter's original CAPI Manifesto wanted straight translations of C headers. > Is that still the boundary? Yes. The entire idea of Deimos is to provide an interface to original C libraries with absolutely minimum amount of modifications. > I have done mysql.d and that would be close to fitting in there, but I also > did mysqld.d, and that is way off. It's not Phobos material because of > license considerations, but it's considerably beyond being a translation of a > C header file. Where would that go? Those kind of wrappers are very useful in general. I think it would be a good idea to also have a place to keep adapted and safe versions of the Deimos. On Tue, Nov 8, 2011 at 5:47 PM, Steve Teale wrote: > On Tue, 08 Nov 2011 11:00:30 +0100, mta`chrono wrote: > >> Does anyone know the last state of Deimos? What are we going to use now. >> >> This: https://github.com/D-Programming-Language/deimos Or that: >> https://github.com/D-Programming-Deimos/ > > I still have more fundamental questions. Maybe they've been answered, but > if so I missed it. > > Walter's original CAPI Manifesto wanted straight translations of C > headers. Is that still the boundary? > > I have done mysql.d and that would be close to fitting in there, but I > also did mysqld.d, and that is way off. It's not Phobos material because > of license considerations, but it's considerably beyond being a > translation of a C header file. Where would that go? > > There are other pretty basic questions - who is the Deimos admin? How do > you go about getting things in there? > > Steve >
Re: GC for pure functions -- implementation ideas
Robert Jacques: > I really like this general concept (It feels a lot like young/old > generational collecting, but without the overhead), both for non-leaky > pure functions and ctfe. As first step to implement Don's GC idea I think it will be useful a __traits(gcallocates, someFunction) that returns true at compile-time if someFunction performs allocations from the GC heap or if it calls functions where __traits(gcallocates, otherFunction) returns true. Bye, bearophile
Re: How about a 100% CTFE?
> Which assert will fail ? Does one will fail ? Note that two different
> instances of the compiler will compile b and c, and they are exscluded of one
> another import tree so each instance isn't aware of the other.
Both will succeed and on both cases a will be 1 because both run
independently. It's similar to asking if two different runs of the
same program, which increment a global variable will see each others'
results. The answer is: no.
> Well that my whole point. You are not aware of the problem on the topic you
> try to solve. You are not qualified for the job. I have no responsability on
> educating you.
I'm well-aware of what I'm dealing with. What I'm not aware of is the
list of things you don't understand in my proposals (which I'm
currently resolving). You don't understand how _this_ feature would
work with _that_ feature without conflicting and I explain how
(proposing one or more way to do it). If your misunderstandings are
not over yet, it's not reasonable to assume, that my explanations
won't follow them. If, however, i fail to explain something, I'll
withdraw my proposal and restore it if and when i find an answer.
> YOU are comming with a solution, YOU have to explain how it solves every
> problems. Everything else is flawed logic.
Nothing ever solves every problem. That's a very unwise thing to say
for someone, who claims to be logical. problems come and go depending
on how the features are used. Each problem (or bunches of problems)
must be dealt with explicitly (using inductive logic to account for
other possible problems). As i said before, if you have problems, i'll
help resolve them. If i don't - i'll withdraw my proposal.
On Tue, Nov 8, 2011 at 5:44 PM, deadalnix wrote:
> Le 08/11/2011 14:31, Gor Gyolchanyan a écrit :
>>>
>>> Well except that module can modify a and not be in the tree.
>>
>> A single compilation includes only two parts: compiling D source code
>> and linking in object files or static libraries. object files and
>> static libraries are by no means involved in compile-time activity,
>> which leaves us with with compiling D source code. A single
>> compilation of D source code can be viewed as a list of import trees,
>> originating from the enlisted modules to be compiled. After
>> eliminating duplicates we have a list of small trees, which can be
>> rooted together to form a single tree, which in turn can be processed
>> as described above. Optionally, in order to allow separate
>> compilations, a cache can be maintained to hold the results of
>> previous compile-time computations to be used in the next ones inside
>> a "project" (to be defined).
>>
>
> module a;
>
> int a = 0;
>
> ---
>
> module b;
>
> import a;
>
> int somefunction() {
> return ++a;
> }
>
> static assert(somefunction() = 1);
>
> ---
>
> module c;
>
> import a;
>
> int somefunction() {
> return ++a;
> }
>
> static assert(somefunction() = 1);
>
> Which assert will fail ? Does one will fail ? Note that two different
> instances of the compiler will compile b and c, and they are exscluded of
> one another import tree so each instance isn't aware of the other.
>
>>> If you have hard time to figure out what the problems are, it is unlikely
>>> that you come up with a satisfying solution, except by being lucky.
>>
>> When i say, i don't see problems, that means, that you didn't present
>> me a problem, which i could not resolve. You point to a problem, i
>> resolve it and vice verse until one of us fails. This is called a
>> discussion.
>>
>
> Well that my whole point. You are not aware of the problem on the topic you
> try to solve. You are not qualified for the job. I have no responsability on
> educating you.
>
> YOU are comming with a solution, YOU have to explain how it solves every
> problems. Everything else is flawed logic.
>
Re: Type Qualifiers and Wild Cards
Le 08/11/2011 14:36, Gor Gyolchanyan a écrit : I agree with _inout_ being a bad choice. I'd rather use something involving _auto_, because this kind of use of _auto_ is already employed in _auto ref_ parameters and is visually unambiguous. Probably _auto const_ would do the trick. The actual _inout_ keyword could be flagged as deprecated and removed during the next breaking change in D (along with all other wonderful breaking changes that were proposed). Well use of auto can be ambiguous here I think. What about auto const ref ?
Re: [D-Programming-Deimos] Review process?
On Tue, 08 Nov 2011 11:00:30 +0100, mta`chrono wrote: > Does anyone know the last state of Deimos? What are we going to use now. > > This: https://github.com/D-Programming-Language/deimos Or that: > https://github.com/D-Programming-Deimos/ I still have more fundamental questions. Maybe they've been answered, but if so I missed it. Walter's original CAPI Manifesto wanted straight translations of C headers. Is that still the boundary? I have done mysql.d and that would be close to fitting in there, but I also did mysqld.d, and that is way off. It's not Phobos material because of license considerations, but it's considerably beyond being a translation of a C header file. Where would that go? There are other pretty basic questions - who is the Deimos admin? How do you go about getting things in there? Steve
Re: How about a 100% CTFE?
Le 08/11/2011 14:31, Gor Gyolchanyan a écrit :
Well except that module can modify a and not be in the tree.
A single compilation includes only two parts: compiling D source code
and linking in object files or static libraries. object files and
static libraries are by no means involved in compile-time activity,
which leaves us with with compiling D source code. A single
compilation of D source code can be viewed as a list of import trees,
originating from the enlisted modules to be compiled. After
eliminating duplicates we have a list of small trees, which can be
rooted together to form a single tree, which in turn can be processed
as described above. Optionally, in order to allow separate
compilations, a cache can be maintained to hold the results of
previous compile-time computations to be used in the next ones inside
a "project" (to be defined).
module a;
int a = 0;
---
module b;
import a;
int somefunction() {
return ++a;
}
static assert(somefunction() = 1);
---
module c;
import a;
int somefunction() {
return ++a;
}
static assert(somefunction() = 1);
Which assert will fail ? Does one will fail ? Note that two different
instances of the compiler will compile b and c, and they are exscluded
of one another import tree so each instance isn't aware of the other.
If you have hard time to figure out what the problems are, it is unlikely that
you come up with a satisfying solution, except by being lucky.
When i say, i don't see problems, that means, that you didn't present
me a problem, which i could not resolve. You point to a problem, i
resolve it and vice verse until one of us fails. This is called a
discussion.
Well that my whole point. You are not aware of the problem on the topic
you try to solve. You are not qualified for the job. I have no
responsability on educating you.
YOU are comming with a solution, YOU have to explain how it solves every
problems. Everything else is flawed logic.
Re: Type Qualifiers and Wild Cards
I agree with _inout_ being a bad choice. I'd rather use something involving _auto_, because this kind of use of _auto_ is already employed in _auto ref_ parameters and is visually unambiguous. Probably _auto const_ would do the trick. The actual _inout_ keyword could be flagged as deprecated and removed during the next breaking change in D (along with all other wonderful breaking changes that were proposed). On Tue, Nov 8, 2011 at 5:08 PM, deadalnix wrote: > Le 08/11/2011 02:08, Walter Bright a écrit : >> >> http://drdobbs.com/blogs/cpp/231902461 >> >> Anyone want to do the reddit honors? > > Great article. The only point I would raise is the choice of inout as a > keyword for this. > > This make no sens whatsoever. Here is why : > - inout did exist in D1 and is different. > - in and out qualifier already exists and have nothing to do with inout. > - in and out are used for contracts and have nothing to do with inout. > - the inout term has nothing to do with const/immutable/mutable. This is in > a totally different lexical field. > > Another keyword should be choosen. vconst, as suggested here : > http://prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP2 is way more > appropriate. > > On external details, but still important, I face the need of inout few days > ago and did knew about it. The documentation on const/immutable ( > http://www.d-programming-language.org/const3.html ) doesn't mention it. The > page on fucntion mention it, but it would be nice to have at least a link on > the const/immutable page. >
Re: How about a 100% CTFE?
> Well except that module can modify a and not be in the tree. A single compilation includes only two parts: compiling D source code and linking in object files or static libraries. object files and static libraries are by no means involved in compile-time activity, which leaves us with with compiling D source code. A single compilation of D source code can be viewed as a list of import trees, originating from the enlisted modules to be compiled. After eliminating duplicates we have a list of small trees, which can be rooted together to form a single tree, which in turn can be processed as described above. Optionally, in order to allow separate compilations, a cache can be maintained to hold the results of previous compile-time computations to be used in the next ones inside a "project" (to be defined). > If you have hard time to figure out what the problems are, it is unlikely > that you come up with a satisfying solution, except by being lucky. When i say, i don't see problems, that means, that you didn't present me a problem, which i could not resolve. You point to a problem, i resolve it and vice verse until one of us fails. This is called a discussion. On Tue, Nov 8, 2011 at 4:56 PM, deadalnix wrote: > Le 07/11/2011 17:00, Gor Gyolchanyan a écrit : >>> >>> Well and somefunction ? It does modify teh value of a too. Is it executed >>> before ? after ? What is the value at the end of all that ? >> >> Obviously it will be incremented first. >> The order is dependent of the rules by which the conditions are >> evaluated at compile-time. For example, the compiler will build a >> depth-first list of the import tree and evaluate code sequentially in >> each module. As i already said, it works just like at run-time. >> Is it so hard to imagine taking the compile-time code, run it during >> compilation separately with the exact same rules as it would during >> compilation? >> > > Well except that module can modify a and not be in the tree. > >>> Well, if you don't see any problem, you should probably just stop trying >>> to provide a solution. >> >> Ok, this is just ridiculous. Are you serious about this question or >> are you trolling to say the least? In either way, I don't see any >> problem in _having mutable compile-time values_. >> > > I'm not trolling, I'm dead serious ! If you have hard time to figure out > what the problems are, it is unlikely that you come up with a satisfying > solution, except by being lucky. >
Re: Type Qualifiers and Wild Cards
Le 08/11/2011 02:08, Walter Bright a écrit : http://drdobbs.com/blogs/cpp/231902461 Anyone want to do the reddit honors? Great article. The only point I would raise is the choice of inout as a keyword for this. This make no sens whatsoever. Here is why : - inout did exist in D1 and is different. - in and out qualifier already exists and have nothing to do with inout. - in and out are used for contracts and have nothing to do with inout. - the inout term has nothing to do with const/immutable/mutable. This is in a totally different lexical field. Another keyword should be choosen. vconst, as suggested here : http://prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP2 is way more appropriate. On external details, but still important, I face the need of inout few days ago and did knew about it. The documentation on const/immutable ( http://www.d-programming-language.org/const3.html ) doesn't mention it. The page on fucntion mention it, but it would be nice to have at least a link on the const/immutable page.
Re: How about a 100% CTFE?
Le 07/11/2011 17:00, Gor Gyolchanyan a écrit : Well and somefunction ? It does modify teh value of a too. Is it executed before ? after ? What is the value at the end of all that ? Obviously it will be incremented first. The order is dependent of the rules by which the conditions are evaluated at compile-time. For example, the compiler will build a depth-first list of the import tree and evaluate code sequentially in each module. As i already said, it works just like at run-time. Is it so hard to imagine taking the compile-time code, run it during compilation separately with the exact same rules as it would during compilation? Well except that module can modify a and not be in the tree. Well, if you don't see any problem, you should probably just stop trying to provide a solution. Ok, this is just ridiculous. Are you serious about this question or are you trolling to say the least? In either way, I don't see any problem in _having mutable compile-time values_. I'm not trolling, I'm dead serious ! If you have hard time to figure out what the problems are, it is unlikely that you come up with a satisfying solution, except by being lucky.
Re: How about a 100% CTFE?
Martin Nowak Wrote: > > How would JIT work in the above case? > > You would need to do JIT a target agnostic IR. AFAIK, target-agnostic LLVM IR is impossible. It's in FAQ.
Re: DMD workforce contribution
On 2011-11-08 11:32, Don wrote: On 08.11.2011 10:40, Gor Gyolchanyan wrote: I think that a programming language that declares itself as a "System Language" should be able to build and use native shared libraries. You're completely right. Just as D supports extern(C) to support C-function, it should support C-libraries. But this doesn't mean, that this is the way it should work always. At the end, all shared libraries are always usable, because they need a C API and D can interface with C APIs. There can even be neat high-level wrappers around those APIs to ease the access to C shared libraries. But I think encouraging programmers to wrote _new_ libraries in _D_ using those shared library formats is a bad idea. Too many workarounds, too much danger. There is the DDL project with that approach: http://www.dsource.org/projects/ddl/wiki I knew about DDL a long time ago. But it's D1 only and doesn't seem to be willing to add D2 support. If and when it supports D2, I'll take a look at it, test it for various traits and if it passes the tests I'll make a pull request to add it to Phobos. Last serious update seems to be 4 years ago. D2 barely existed back then. There's a fork available that is a bit more recent: http://h3.gd/devlog/?p=12 -- /Jacob Carlborg
Re: DMD workforce contribution
Yes. The idea is awesome. Being able to embed almost all of D's constructs in a shared library is a great idea. Unfortunately it stopped it's development right before it would actually become useful. Why don't we take it, refactor it for Phobos and include it? On Tue, Nov 8, 2011 at 2:32 PM, Don wrote: > On 08.11.2011 10:40, Gor Gyolchanyan wrote: >>> >>> I think that a programming language that declares itself as a "System >>> Language" should be able to build and use native shared libraries. >> >> You're completely right. Just as D supports extern(C) to support >> C-function, it should support C-libraries. But this doesn't mean, that >> this is the way it should work always. >> At the end, all shared libraries are always usable, because they need >> a C API and D can interface with C APIs. There can even be neat >> high-level wrappers around those APIs to ease the access to C shared >> libraries. >> But I think encouraging programmers to wrote _new_ libraries in _D_ >> using those shared library formats is a bad idea. Too many >> workarounds, too much danger. >> >>> There is the DDL project with that approach: >>> http://www.dsource.org/projects/ddl/wiki >> >> I knew about DDL a long time ago. But it's D1 only and doesn't seem to >> be willing to add D2 support. If and when it supports D2, I'll take a >> look at it, test it for various traits and if it passes the tests I'll >> make a pull request to add it to Phobos. > > Last serious update seems to be 4 years ago. D2 barely existed back then. >
Re: [D-Programming-Deimos] Review process?
Using SWIG for porting C libraries to D is like using a chainsaw for vascular incisions: It's extremely heavy and unproductive. This is all because SWIG generates intermediate binary, which forwards calls to C functions, which is completely unnecessary. Furthermore, It translates macro constants into lists of const variables. This is very unproductive as well, because macro definitions don't have addresses and const variables do. A human translator would've put those in a single enum (providing a whole bunch of extra functionality, like obtaining the string of the enum symbols). On Tue, Nov 8, 2011 at 2:47 PM, Andrea Fontana wrote: > Could the same idea (of a single repository) be extended to support swig > based portings? > I've tried to port one of my project (quite complex data access layer) to D > using swig, and it works fine (and it's quite easy to do). > It would be useful for c++ class-based libraries... > > Il giorno mar, 08/11/2011 alle 14.08 +0400, Gor Gyolchanyan ha scritto: > > The first one is handy because you can have everything you want in a > single place and don't need to clone every lib separately. > The second one is handy because you don't have to carry around tons of > unneeded code. > > For that reason, I propose us to keep the code in separate > repositories and refer to them from a single repository in the form of > submodules. > > On Tue, Nov 8, 2011 at 2:00 PM, mta`chrono > wrote: >> Does anyone know the last state of Deimos? What are we going to use now. >> >> This: https://github.com/D-Programming-Language/deimos >> Or that: https://github.com/D-Programming-Deimos/ >> >> >
Re: [D-Programming-Deimos] Review process?
Could the same idea (of a single repository) be extended to support swig based portings? I've tried to port one of my project (quite complex data access layer) to D using swig, and it works fine (and it's quite easy to do). It would be useful for c++ class-based libraries... Il giorno mar, 08/11/2011 alle 14.08 +0400, Gor Gyolchanyan ha scritto: > The first one is handy because you can have everything you want in a > single place and don't need to clone every lib separately. > The second one is handy because you don't have to carry around tons of > unneeded code. > > For that reason, I propose us to keep the code in separate > repositories and refer to them from a single repository in the form of > submodules. > > On Tue, Nov 8, 2011 at 2:00 PM, mta`chrono > wrote: > > Does anyone know the last state of Deimos? What are we going to use now. > > > > This: https://github.com/D-Programming-Language/deimos > > Or that: https://github.com/D-Programming-Deimos/ > > > >
Re: DMD workforce contribution
On 08.11.2011 10:40, Gor Gyolchanyan wrote: I think that a programming language that declares itself as a "System Language" should be able to build and use native shared libraries. You're completely right. Just as D supports extern(C) to support C-function, it should support C-libraries. But this doesn't mean, that this is the way it should work always. At the end, all shared libraries are always usable, because they need a C API and D can interface with C APIs. There can even be neat high-level wrappers around those APIs to ease the access to C shared libraries. But I think encouraging programmers to wrote _new_ libraries in _D_ using those shared library formats is a bad idea. Too many workarounds, too much danger. There is the DDL project with that approach: http://www.dsource.org/projects/ddl/wiki I knew about DDL a long time ago. But it's D1 only and doesn't seem to be willing to add D2 support. If and when it supports D2, I'll take a look at it, test it for various traits and if it passes the tests I'll make a pull request to add it to Phobos. Last serious update seems to be 4 years ago. D2 barely existed back then.
Re: [D-Programming-Deimos] Review process?
The first one is handy because you can have everything you want in a single place and don't need to clone every lib separately. The second one is handy because you don't have to carry around tons of unneeded code. For that reason, I propose us to keep the code in separate repositories and refer to them from a single repository in the form of submodules. On Tue, Nov 8, 2011 at 2:00 PM, mta`chrono wrote: > Does anyone know the last state of Deimos? What are we going to use now. > > This: https://github.com/D-Programming-Language/deimos > Or that: https://github.com/D-Programming-Deimos/ > >
Re: [D-Programming-Deimos] Review process?
Does anyone know the last state of Deimos? What are we going to use now. This: https://github.com/D-Programming-Language/deimos Or that: https://github.com/D-Programming-Deimos/
Re: DSQLite a libraryri using sqlite
> .I am afraid that Phobos will take another 3 years to consolidate. > std.database is just another indication for that.. > my 2 Euro cents ( pretty weak nowadays :) > Bjoern. Yes, you're right there is no coordination in development. Some are talking about CAPI Manifesto and some others are talking about deimos. There is https://github.com/D-Programming-Language/deimos And there is: https://github.com/D-Programming-Deimos/ There are pending pull requests, so what are we waiting for?
Re: DMD workforce contribution
> I think that a programming language that declares itself as a "System > Language" should be able to build and use native shared libraries. You're completely right. Just as D supports extern(C) to support C-function, it should support C-libraries. But this doesn't mean, that this is the way it should work always. At the end, all shared libraries are always usable, because they need a C API and D can interface with C APIs. There can even be neat high-level wrappers around those APIs to ease the access to C shared libraries. But I think encouraging programmers to wrote _new_ libraries in _D_ using those shared library formats is a bad idea. Too many workarounds, too much danger. > There is the DDL project with that approach: > http://www.dsource.org/projects/ddl/wiki I knew about DDL a long time ago. But it's D1 only and doesn't seem to be willing to add D2 support. If and when it supports D2, I'll take a look at it, test it for various traits and if it passes the tests I'll make a pull request to add it to Phobos. On Tue, Nov 8, 2011 at 10:45 AM, Rainer Schuetze wrote: > There is the DDL project with that approach: > http://www.dsource.org/projects/ddl/wiki > > I think that a programming language that declares itself as a "System > Language" should be able to build and use native shared libraries. > > On 08.11.2011 07:32, Gor Gyolchanyan wrote: >> >> Is there any ready plan, that will describe what exactly do we want to >> get in the end? >> I'm starting to think, that it would be great to have our own format >> for shared libraries. >> >> On Tue, Nov 8, 2011 at 10:25 AM, Rainer Schuetze >> wrote: >>> >>> >>> On 07.11.2011 13:36, Gor Gyolchanyan wrote: > > 1. Making shared libraries under Linux work would be a big improvement. I think you meant "Making shared libraries, written in D, under Linux work would be a big improvement.", because everything else works fine (i tested it) using core.sys.posix.dlfn; Since druntime needs some serious initialization, core.sys.windows.dll was invented to hide away all this and, if I'm not mistaken, this is precisely what it means to "support DLLs". since .so files don't have any auto-called functions, like DllMain, some additional shenanigans are required to get it to work as in Windows. There will still be helper functions that would be put inside some "main" function in .so functions, that should be called explicitly when loaded (probably inside a standard library loader). DllMain also has thread/process attach/detach routine callbacks, which are, AFAIK, are not necessary to simulate in .so files (otherwise, it'll go inside that pseudo-main function). Regarding the above information, all I have to do to make "shared libraries work under linux" is to make linux analogs for the dll helper functions, define the pseudo-main function requirement in D docs and make a specialization of LoadLibrary routine in druntime to call that function. >>> >>> There are different ways to use and implement shared libraries written in >>> D: >>> 1. the shared library interfaces to any other library as a C library >>> does, >>> i.e. without any shared resources (e.g. it has its own heap and its own >>> thread list). >>> 2. the shared library shares resources with other libraries and the >>> executable. >>> >>> The DLL support on windows covers the first case. I think such a shared >>> library should work in any host application, even if it is not aware that >>> it >>> is written in D. >>> >>> There is limited support for the second case that only forwards calls to >>> the >>> GC into another shared library, but it won't work with other resources or >>> in >>> a multi threading environment. >>> >>> Some attempts have been made to put the phobos runtime library into a >>> shared >>> library on Windows (and OSX): >>> >>> http://d.puremagic.com/issues/show_bug.cgi?id=4071 >>> >
Re: Asking a const-related fix [Was: Re: DMD workforce contribution]
On 11/7/2011 4:57 AM, kenji hara wrote: I have call this concept "transitively modifiable", and I have implemented it with dmd/pull/166. For those who don't yet know, Kenji is a very prolific and high quality contributor to dmd.
Re: Type Qualifiers and Wild Cards
On 11/8/2011 12:44 AM, Don wrote:
This compiles:
inout(int *) foo(inout(int *) a)
{
inout x = a;
return x;
}
and it doesn't compile if you replace 'inout x' with 'const x'.
inout can implicitly convert to const, but const cannot implicitly convert to
inout, hence the error on the return x;
But you're right, use inout in the body, and it is treated much like const.
