Steve Teale:
I realize that some people with an IQ of 580 will find my questions naive and
misguided - not to mention impertinent, but it seems to me that one of the
responsibilities of being a leader is to explain to less gifted followers what the
fuck is going on.<
If you read the book by Andrei you will probably find enough explanations. But
we can also write a Wiki page (see at end of this post).
---------------------
Robert Fraser:
I was just suggesting we need a better syntax, but I realized we have one:
__traits(compiles).<
__traits() isn't a good looking syntax, and its semantic looks almost like a
random conflation/accretion of too many different things (and some of them can
be done better in other ways).
For example in my dlibs I have templates for the following purposes (and most
of them are present in Tango too):
isAssociativeArray
isFloating
isIntegral
isStaticArray
isUnsigned
So instead of writing:
__traits(isStaticArray, x)
I write in D1:
IsStaticArray!(x)
In D2 you can write:
IsStaticArray!x
That looks better than the traits.
(The syntax of is() too looks like an accretion of mixed things).
Why Andrei isn't using this is the real mystery.<
Maybe he agrees with me that __traits is not nice looking :-) Those underscores
make it look like a temporary functionality.
is(typeof()) has purposes similar to __traits(compiles, ). Having two syntaxes
to do the same thing may be bad.
Let's try using traits as you suggest. This it he original written by Steve
Teale (copied from elsewhere):
template isInputRange(R) {
enum bool isInputRange = is(typeof(
{
R r; // can define a range object
if (r.empty) {} // can test for empty
r.popFront; // can invoke next
auto h = r.front; // can get the front of the range
}()));
}
This may be the traits version (there is no () after the {} after the
"compiles"):
template isInputRange(R) {
enum bool isInputRange = __traits(compiles, {
R r; // can define a range object
if (r.empty) {} // can test for empty
r.popFront; // can invoke next
auto h = r.front; // can get the front of the range
});
}
I don't know if this is correct, but if it's correct, is it better looking? It
looks almost the same to me.
Both traits() and is() need a more clean and logic redesign, to move elsewhere
some of their purposes, and to avoid duplication in their purposes.
Andrei has shown to be able to improve the API of the regex module, so maybe he
can find a better design for is() and traits().
If types become first-class at compile time, of type "type", then you can
remove some purposes from is() too, you can do:
type t1 = int;
type t2 = float;
static if (t1 != t2) {...
Instead of:
alias int t1;
alias float t2;
static if (!is(t1 == t2)) {...
--------------------------
Derek Parnell:
Thank you Derek Parnell for your nice summary about ranges: with to your post
my understanding of this topic has gone from 10% to 15% :-)
There are things I don't understand from what you have written:
OutputRange - This is an InputRange with the extra capability of being able to add
elements to the range. In addition to the InputRange methods, it must also provide
a method that adds a new element to the range, such that it becomes the current
element. That method must be called 'put(E)' where 'E' is the new element.<
I guess a single linked list can be seen as an OutputRange then. You can add an
item where you are and scan it forward (unfortunately linked listes today are
dead, they are never an efficient solution on modern CPUs)
In what othr situations you may use/need an OutputRange? In a file, as in a stack, you can only add in a very specific point (the end, in files, or replace the current item).
ForwardRange - This is an InputRange with the extra capability of being able
checkpoint the current first 'cursor' position simply by copying the range. When
you copy an plain InputRange the copied range starts again from the absolute first
element, but a copied ForwardRange starts at whatever was the current first
element in the source range.<
I don't understand and I don't know what checkpointing may mean there.
I suggest to explain those things better, and then add 3 or more examples (very
different from each other, complete, real-world and
ready-to-be-copied-pasted-and-run, like you can find in every page of Borland
Delphi documentation) for each kind of range. And then to put the page on the D
Wiki :-)
Now I admit that these are not method names I would have choosen, as I would have
preferred names more like<
Andrei has shown that inventing very good names for those methods isn't easy...
And putting lot of uppercase letters in the middle of those names isn't nice,
nor handy, and it's visually noisy.
Bye,
bearophile
