On Thu, 14 Oct 2010 09:44:19 -0400, Steven Schveighoffer wrote:
> On Thu, 14 Oct 2010 06:53:35 -0400, Gerrit Wichert
> wrote:
>
>> Am 13.10.2010 22:07, schrieb Andrei Alexandrescu:
>>>
>>> Good point. On the other hand, an overly simplified documentation
>>> might hinder a good deal of legit use
On 10/14/10 21:03 CDT, Brad Roberts wrote:
On 10/14/2010 7:53 AM, Andrei Alexandrescu wrote:
I've asked Walter many times for
Doesn't need to be walter to implement it...
Yup, could be Don :o).
Andrei
On 10/14/2010 7:53 AM, Andrei Alexandrescu wrote:
>
> I've asked Walter many times for
>
Doesn't need to be walter to implement it...
On Thursday, October 14, 2010 07:53:24 Andrei Alexandrescu wrote:
> On 10/14/10 8:44 CDT, Steven Schveighoffer wrote:
> > On Thu, 14 Oct 2010 06:53:35 -0400, Gerrit Wichert
> >
> > wrote:
> >> Am 13.10.2010 22:07, schrieb Andrei Alexandrescu:
> >>> Good point. On the other hand, an overly simplif
On 10/14/10 8:44 CDT, Steven Schveighoffer wrote:
On Thu, 14 Oct 2010 06:53:35 -0400, Gerrit Wichert
wrote:
Am 13.10.2010 22:07, schrieb Andrei Alexandrescu:
Good point. On the other hand, an overly simplified documentation
might hinder a good deal of legit uses for advanced users. I wonder
On Thu, 14 Oct 2010 06:53:35 -0400, Gerrit Wichert
wrote:
Am 13.10.2010 22:07, schrieb Andrei Alexandrescu:
Good point. On the other hand, an overly simplified documentation
might hinder a good deal of legit uses for advanced users. I wonder
how to please everyone.
I think the best way to
Am 13.10.2010 22:07, schrieb Andrei Alexandrescu:
>
> Good point. On the other hand, an overly simplified documentation
> might hinder a good deal of legit uses for advanced users. I wonder
> how to please everyone.
>
I think the best way to explain the usage of a feature are *working*
code-example
On Thu, 14 Oct 2010 01:30:42 +0200, Juanjo Alvarez
wrote:
signatures. Adding more (or just adding some where they're missing).
Truncated sentence, I wanted to say that adding more asserts would
not hurt.
On Wed, 13 Oct 2010 16:42:35 -0400, "Steven Schveighoffer"
wrote:
Even though I consider myself a reasonable parser of function
templates,
sometimes in std.algorithm, I'll stare at a function signature for
about
10 minutes trying to figure out whether I can do what I want, give
up and
f
On Wed, 13 Oct 2010 16:07:46 -0400, Andrei Alexandrescu
wrote:
It's not a problem with phobos, it's a problem with documentation. There
is a fundamental issue with documenting complex templates which makes
function signatures very difficult to understand. The doc generator can
and should simp
On 10/13/10 14:03 CDT, Steven Schveighoffer wrote:
On Mon, 11 Oct 2010 20:33:27 -0400, Andrei Alexandrescu
T[] join(T)(in T[][] items, T[] sep);
This doesn't quite work if T is not a value type (actually, I think it
does, but only because there are bugs in the compiler).
My focus in this dis
On Mon, 11 Oct 2010 20:33:27 -0400, Andrei Alexandrescu
wrote:
I'm looking at http://d.puremagic.com/issues/show_bug.cgi?id=3313 and
that got me looking at std.string.join, which currently has the sig:
string join(in string[] words, string sep);
A narrow fix:
Char[] join(Char)(in Char[][
On 13/10/2010 2:02 AM, Andrei Alexandrescu wrote:
On 10/12/10 9:35 CDT, Justin Johansson wrote:
On 13/10/2010 1:28 AM, Justin Johansson wrote:
Yes, "do the darn string version already and cut all that crap".
This is probably the thing to do to make for familiarity among
library users [of other
On 10/12/10 9:35 CDT, Justin Johansson wrote:
On 13/10/2010 1:28 AM, Justin Johansson wrote:
Yes, "do the darn string version already and cut all that crap".
This is probably the thing to do to make for familiarity among
library users [of other languages].
However, if you have an urge to back-
On 10/12/2010 03:09 AM, Daniel Gibson wrote:
I don't like the name "join" - especially for general ranges.
When I hear join I think of database like joins. These may not be
horribly interesting for strings but certainly are for general ranges (*).
union() or concat() would be better names for doi
On 13/10/2010 1:28 AM, Justin Johansson wrote:
Yes, "do the darn string version already and cut all that crap".
This is probably the thing to do to make for familiarity among
library users [of other languages].
However, if you have an urge to back-end the implementation
of the colloquial "join"
On 12/10/2010 11:33 AM, Andrei Alexandrescu wrote:
I'm looking at http://d.puremagic.com/issues/show_bug.cgi?id=3313 and
that got me looking at std.string.join, which currently has the sig:
string join(in string[] words, string sep);
A narrow fix:
Char[] join(Char)(in Char[][] words, in Char[]
On 10/12/2010 01:25 AM, Pelle wrote:
I think the function signature should be more of isInputRange!R1 &&
isInputRange(ElementType!R1), same with the is(). As the first one
should be a range of ranges.
Correct. I figured out my mistake when I started playing with an
implementation.
I think t
On 10/11/10 23:00 CDT, Daniel Gibson wrote:
Of course indexes would speed things up, but as mentioned before join()
would work ok on almost(*) all ranges (with O(n^2) complexity) and a lot
better on std.range.SortedRange.
Because the user would provide a predicate (that should use the same
compar
On 10/11/10 23:37 CDT, Daniel Gibson wrote:
Btw: Is "join" not just a (rather trivial) generalization of reduce?
auto inRange = ...; // range of char[]
char[] sep = " ";
auto joined = reduce!( (char[] res, char[] x) {return res~sep~x;})
(inRange);
It is, but things are a bit messed up by empty
On 10/11/10 21:05 CDT, Philippe Sigaud wrote:
On Tue, Oct 12, 2010 at 02:33, Andrei Alexandrescu
wrote:
One thing is still bothering me: the array output type. Why would the
"default" output range be an array? What can be done to make join() at the
same time a general function and also one tha
Daniel Gibson wrote:
inner join is the "normal" join, outer join means that, if a
to-be-joined element has no "partner" in the other set (range), it's
included in the output anyway with the partner having a NULL value.
(This can be done for either the first, the second or both partners).
On 10/12/2010 02:33 AM, Andrei Alexandrescu wrote:
I'm looking at http://d.puremagic.com/issues/show_bug.cgi?id=3313 and
that got me looking at std.string.join, which currently has the sig:
string join(in string[] words, string sep);
A narrow fix:
Char[] join(Char)(in Char[][] words, in Char[]
On Mon, 11 Oct 2010 23:34:41 -0400, Daniel Gibson
wrote:
Andrei Alexandrescu schrieb:
On 10/11/2010 08:57 PM, Daniel Gibson wrote:
But right now the point is: join() does something completely different
and should be renamed (or deprecated in std.string and replaced by
union() - a real join
On Tue, 12 Oct 2010 00:47:33 -0400, Daniel Gibson
wrote:
On Tue, Oct 12, 2010 at 6:37 AM, Daniel Gibson
wrote:
Btw: Is "join" not just a (rather trivial) generalization of reduce?
auto inRange = ...; // range of char[]
char[] sep = " ";
auto joined = reduce!( (char[] res, char[] x) {retu
On Tue, Oct 12, 2010 at 6:37 AM, Daniel Gibson wrote:
>
> Btw: Is "join" not just a (rather trivial) generalization of reduce?
>
> auto inRange = ...; // range of char[]
> char[] sep = " ";
> auto joined = reduce!( (char[] res, char[] x) {return res~sep~x;})
> (inRange);
>
Not generalization, I m
Andrei Alexandrescu schrieb:
I'm looking at http://d.puremagic.com/issues/show_bug.cgi?id=3313 and
that got me looking at std.string.join, which currently has the sig:
string join(in string[] words, string sep);
A narrow fix:
Char[] join(Char)(in Char[][] words, in Char[] sep)
if (isSomeChar!
Andrei Alexandrescu schrieb:
On 10/11/2010 10:34 PM, Daniel Gibson wrote:
Andrei Alexandrescu schrieb:
On 10/11/2010 08:57 PM, Daniel Gibson wrote:
But right now the point is: join() does something completely different
and should be renamed (or deprecated in std.string and replaced by
union()
On 10/11/2010 10:34 PM, Daniel Gibson wrote:
Andrei Alexandrescu schrieb:
On 10/11/2010 08:57 PM, Daniel Gibson wrote:
But right now the point is: join() does something completely different
and should be renamed (or deprecated in std.string and replaced by
union() - a real join isn't needed in
Jonathan M Davis schrieb:
On Monday 11 October 2010 20:34:41 Daniel Gibson wrote:
Andrei Alexandrescu schrieb:
On 10/11/2010 08:57 PM, Daniel Gibson wrote:
But right now the point is: join() does something completely different
and should be renamed (or deprecated in std.string and replaced by
On Monday 11 October 2010 20:34:41 Daniel Gibson wrote:
> Andrei Alexandrescu schrieb:
> > On 10/11/2010 08:57 PM, Daniel Gibson wrote:
> >> But right now the point is: join() does something completely different
> >> and should be renamed (or deprecated in std.string and replaced by
> >> union() -
Andrei Alexandrescu schrieb:
On 10/11/2010 08:57 PM, Daniel Gibson wrote:
But right now the point is: join() does something completely different
and should be renamed (or deprecated in std.string and replaced by
union() - a real join isn't needed in std.string anyway, but when join()
is deprecat
On 10/11/2010 08:57 PM, Daniel Gibson wrote:
But right now the point is: join() does something completely different
and should be renamed (or deprecated in std.string and replaced by
union() - a real join isn't needed in std.string anyway, but when join()
is deprecated in std.string you can imple
On 10/11/2010 10:08 PM, bearophile wrote:
Daniel Gibson:
But right now the point is: join() does something completely different and
should be renamed (or
deprecated in std.string and replaced by union() - a real join isn't needed in
std.string anyway,
but when join() is deprecated in std.stri
bearophile schrieb:
Daniel Gibson:
But right now the point is: join() does something completely different and should be renamed (or
deprecated in std.string and replaced by union() - a real join isn't needed in std.string anyway,
but when join() is deprecated in std.string you can implement a
Philippe Sigaud schrieb:
On Tue, Oct 12, 2010 at 03:28, Simen kjaeraas wrote:
Daniel Gibson wrote:
(*) Something like
Range!(Tuple!(T1, T2)) join(T1, T2)(Range!(T1) r1, Range!(T2) r2,
BinaryPredicate!(T1, T2) joinPred)
just pseudo-code, I'm not really familiar with D2 and std.algorithm.
The
Daniel Gibson:
> But right now the point is: join() does something completely different and
> should be renamed (or
> deprecated in std.string and replaced by union() - a real join isn't needed
> in std.string anyway,
> but when join() is deprecated in std.string you can implement a real join
On Tue, Oct 12, 2010 at 02:33, Andrei Alexandrescu
wrote:
> ElementType!R1[] join(R1, R2)(R1 items, R2 sep)
> if (isInputRange!R1 && isForwardRange!R2
> && is(ElementType!R2 : ElementType!R1);
> Notice how the separator must be a forward range because it gets spanned
> multiple times, whereas
Simen kjaeraas schrieb:
Daniel Gibson wrote:
(*) Something like
Range!(Tuple!(T1, T2)) join(T1, T2)(Range!(T1) r1, Range!(T2) r2,
BinaryPredicate!(T1, T2) joinPred)
just pseudo-code, I'm not really familiar with D2 and std.algorithm.
The idea is you have a Range r1 with elements of type T1,
On Tue, Oct 12, 2010 at 03:28, Simen kjaeraas wrote:
> Daniel Gibson wrote:
>
>> (*) Something like
>> Range!(Tuple!(T1, T2)) join(T1, T2)(Range!(T1) r1, Range!(T2) r2,
>> BinaryPredicate!(T1, T2) joinPred)
>> just pseudo-code, I'm not really familiar with D2 and std.algorithm.
>> The idea is you
Daniel Gibson Wrote:
> bearophile schrieb:
> > Andrei:
> >
> >> One thing is still bothering me: the array output type. Why would the
> >> "default" output range be an array?
> >
> > The chain() function that returns a range is already present.
> >
> >
> >> What can be done to make join() at
Daniel Gibson wrote:
(*) Something like
Range!(Tuple!(T1, T2)) join(T1, T2)(Range!(T1) r1, Range!(T2) r2,
BinaryPredicate!(T1, T2) joinPred)
just pseudo-code, I'm not really familiar with D2 and std.algorithm.
The idea is you have a Range r1 with elements of type T1, a Range r1
with elemen
bearophile schrieb:
Andrei:
One thing is still bothering me: the array output type. Why would the
"default" output range be an array?
The chain() function that returns a range is already present.
What can be done to make join() at
the same time a general function and also one that works fo
On 10/11/2010 08:02 PM, bearophile wrote:
You may implement a generic std.algorithm.join, and then implement the
std.string.join that uses just strings (the second argument may be a single
char too) and calls std.algorithm.join for its implementation.
If you don't like that name collision, th
> You may implement a generic std.algorithm.join, and then implement the
> std.string.join that uses just strings (the second argument may be a single
> char too) and calls std.algorithm.join for its implementation.
If you don't like that name collision, the std.algorithm one may be named
joinR
Andrei:
> One thing is still bothering me: the array output type. Why would the
> "default" output range be an array?
The chain() function that returns a range is already present.
> What can be done to make join() at
> the same time a general function and also one that works for strings the
I'm looking at http://d.puremagic.com/issues/show_bug.cgi?id=3313 and
that got me looking at std.string.join, which currently has the sig:
string join(in string[] words, string sep);
A narrow fix:
Char[] join(Char)(in Char[][] words, in Char[] sep)
if (isSomeChar!Char);
I think it's reasonabl
47 matches
Mail list logo
