Related: just made a few comments to
https://github.com/dlang/phobos/pull/4511. More work on range
formalization is welcome. Thanks! -- Andrei
On Tuesday, 14 June 2016 at 00:19:54 UTC, Andrei Alexandrescu
wrote:
On 06/12/2016 04:46 AM, Dicebot wrote:
That is matter of design philosophy. For me such basic library
primitives warrant C++ attitude of "don't pay for what you
don't ask
for" - and everything else, including actual feature
On Monday, 13 June 2016 at 13:59:06 UTC, Steven Schveighoffer
wrote:
So what it seems like you want is somerange.map(...).front to
evaluate the lambda only once, without caching. This doesn't
fit into the definition of ranges, which require the ability to
access the same front more than once.
On 06/12/2016 04:46 AM, Dicebot wrote:
That is matter of design philosophy. For me such basic library
primitives warrant C++ attitude of "don't pay for what you don't ask
for" - and everything else, including actual feature completeness, is of
negligible importance compared to that.
C++'s
On Monday, 13 June 2016 at 13:59:06 UTC, Steven Schveighoffer
wrote:
No, it's not. My advice is to understand the limitations and
expectations of the range wrappers you are using (i.e. read the
docs [1]). If you need caching for your purposes, then do that
by plopping cache at the end of your
On 6/12/16 4:46 AM, Dicebot wrote:
On Friday, 3 June 2016 at 12:03:26 UTC, Steven Schveighoffer wrote:
Yes, I can see good reason why you would want this. Hm... a set of
adapters which reduce a range to its lesser API would be useful here:
array.asInput.map
But an expectation for map should
On Friday, 3 June 2016 at 12:03:26 UTC, Steven Schveighoffer
wrote:
It only strengthens my opinion that Phobos is not a standard
library I
want. Really, many of those issue would have been solved if
basic input
range was defined as `empty` + `ElementType popFront()`
instead.
This doesn't
On 6/3/16 4:37 AM, Dicebot wrote:
On Wednesday, 1 June 2016 at 01:31:53 UTC, Steven Schveighoffer wrote:
If you want to use such "ranges", the compiler will not stop you. Just
don't expect any help from Phobos.
It only strengthens my opinion that Phobos is not a standard library I
want.
On 06/03/2016 01:49 PM, Andrei Alexandrescu wrote:
> On 6/3/16 4:37 AM, Dicebot wrote:
>> Really, many of those issue would have been solved if basic input range
>> was defined as `empty` + `ElementType popFront()` instead.
>
> FYI that was on the table, along with many other possible designs.
>
On 6/3/16 4:37 AM, Dicebot wrote:
Really, many of those issue would have been solved if basic input range
was defined as `empty` + `ElementType popFront()` instead.
FYI that was on the table, along with many other possible designs.
(popFront() should be allowed to return by reference, too.)
On Wednesday, 1 June 2016 at 01:31:53 UTC, Steven Schveighoffer
wrote:
If you want to use such "ranges", the compiler will not stop
you. Just don't expect any help from Phobos.
It only strengthens my opinion that Phobos is not a standard
library I want. Really, many of those issue would have
On 6/1/16 8:37 PM, Steven Schveighoffer wrote:
On 6/1/16 8:49 AM, Joseph Rushton Wakeling wrote:
The `Generator` range is an eager violator of this requirement:
https://github.com/dlang/phobos/blob/ca292ff78cd825f642eb58d586e2723ba14ae448/std/range/package.d#L3075-L3080
although I'd
On 6/1/16 10:05 AM, Patrick Schluter wrote:
On Tuesday, 31 May 2016 at 12:42:23 UTC, Steven Schveighoffer wrote:
There are 2 main issues with FILE *:
1) it does not provide buffer access, so you must rely on things like
getline if they exist. But these have their own problems (i.e. do not
On 6/1/16 8:49 AM, Joseph Rushton Wakeling wrote:
On Tuesday, 31 May 2016 at 18:31:05 UTC, Steven Schveighoffer wrote:
On 5/31/16 11:45 AM, Jonathan M Davis via Digitalmars-d wrote:
On Monday, May 30, 2016 09:57:29 H. S. Teoh via Digitalmars-d wrote:
I'd argue that range-based generic code
On Tuesday, 31 May 2016 at 12:42:23 UTC, Steven Schveighoffer
wrote:
There are 2 main issues with FILE *:
1) it does not provide buffer access, so you must rely on
things like getline if they exist. But these have their own
problems (i.e. do not support unicode, require C-malloc'd
buffer)
On Tuesday, 31 May 2016 at 18:31:05 UTC, Steven Schveighoffer
wrote:
On 5/31/16 11:45 AM, Jonathan M Davis via Digitalmars-d wrote:
On Monday, May 30, 2016 09:57:29 H. S. Teoh via Digitalmars-d
wrote:
I'd argue that range-based generic code that assumes
non-transience is
inherently buggy,
On 5/31/16 4:59 PM, Dicebot wrote:
On Tuesday, 31 May 2016 at 18:11:34 UTC, Steven Schveighoffer wrote:
1) Current definition of input range (most importantly, the fact `front`
has to be @property-like) implies `front` to always return the same
result until `popFront` is called.
Regardless of
On Tuesday, 31 May 2016 at 21:25:12 UTC, Timon Gehr wrote:
On 31.05.2016 22:59, Dicebot wrote:
I think we should be aware that the range API doesn't prevent
bugs of
all kinds. There's only so much analysis the compiler can do.
This is a totally valid code I want to actually work and not
On 31.05.2016 22:59, Dicebot wrote:
I think we should be aware that the range API doesn't prevent bugs of
all kinds. There's only so much analysis the compiler can do.
This is a totally valid code I want to actually work and not be
discarded as "bug".
map often allows random access. Do
On Tuesday, 31 May 2016 at 18:11:34 UTC, Steven Schveighoffer
wrote:
1) Current definition of input range (most importantly, the
fact `front`
has to be @property-like) implies `front` to always return the
same
result until `popFront` is called.
Regardless of property-like or not, this should
a bug in your range
construction.
That doesn't mean that we don't expect that ranges behave that way.
It's never been the case that we agreed that transient ranges were
acceptable.
I want to note here that transient ranges are different from what you
identified above (front returning different
g defensively caches front in case the next call to
front is different, unless that's specifically the reason for the range.
I don't really care about concept of transient ranges, it is the fact
there is no guarantee of front stability for plain input ranges which
worries me.
But this is inheren
e that it's called, because isInputRange can't possibly test
for it. That doesn't mean that we don't expect that ranges behave that way.
It's never been the case that we agreed that transient ranges were
acceptable. In fact, it's pretty much the opposite. There was some
discussion that maybe we'd cons
n't really care about concept of transient ranges, it is
the fact
there is no guarantee of front stability for plain input
ranges which
worries me.
But this is inherent in languages which support mutable data.
If you want data that doesn't change, require copied/unique
data, or immu
On 5/30/16 11:46 AM, Andrei Alexandrescu wrote:
On 05/30/2016 11:22 AM, Steven Schveighoffer wrote:
On Monday, 30 May 2016 at 15:12:41 UTC, Andrei Alexandrescu wrote:
On 05/30/2016 09:30 AM, Steven Schveighoffer wrote:
My iopipe library is 2x as fast.
Cool! What is the trick to the speedup?
On 5/30/16 2:32 PM, Alex Parrill wrote:
On Monday, 30 May 2016 at 12:53:07 UTC, Steven Schveighoffer wrote:
I'm trying to figure out which cases caching makes the solution
impossible.
One case is wrapping a network stream: a TCP input range that yields
ubyte[] chunks of data as they are
On Monday, 30 May 2016 at 12:53:07 UTC, Steven Schveighoffer
wrote:
On 5/30/16 5:35 AM, Dicebot wrote:
On Sunday, 29 May 2016 at 17:25:47 UTC, Steven Schveighoffer
wrote:
What problems are solvable only by not caching the front
element? I
can't think of any.
As far as I know, currently it
o not play well with that
> > behavior, and I don't think that it's reasonable to expect them to.
>
> I disagree. Most algorithms in std.algorithm are fine with transient
> ranges.
Yes, some years ago I submitted a series of PRs to fix poorly-written
code in Phobos that unnecessarily depend
On 05/30/2016 12:22 AM, Jack Stouffer wrote:
On Sunday, 29 May 2016 at 17:36:24 UTC, Steven Schveighoffer wrote:
Wholly disagree. If we didn't cache the element, D would be a
laughingstock of performance-minded tests.
byLine already is a laughingstock performance wise:
On 05/30/2016 11:22 AM, Steven Schveighoffer wrote:
On Monday, 30 May 2016 at 15:12:41 UTC, Andrei Alexandrescu wrote:
On 05/30/2016 09:30 AM, Steven Schveighoffer wrote:
My iopipe library is 2x as fast.
Cool! What is the trick to the speedup? -- Andrei
Direct buffer access and not using
On Monday, 30 May 2016 at 15:12:41 UTC, Andrei Alexandrescu wrote:
On 05/30/2016 09:30 AM, Steven Schveighoffer wrote:
My iopipe library is 2x as fast.
Cool! What is the trick to the speedup? -- Andrei
Direct buffer access and not using FILE * as a base.
-Steve
On 05/30/2016 09:26 AM, Steven Schveighoffer wrote:
Here is how I think about it: the front element is valid and stable
until you call popFront. After that, anything goes for the old front.
Yah, we should have formal language in the library reference about this.
-- Andrei
On 05/30/2016 09:30 AM, Steven Schveighoffer wrote:
My iopipe library is 2x as fast.
Cool! What is the trick to the speedup? -- Andrei
On 5/29/16 11:46 PM, Alex Parrill wrote:
On Sunday, 29 May 2016 at 17:45:00 UTC, Steven Schveighoffer wrote:
On 5/27/16 7:42 PM, Seb wrote:
So what about the convention to explicitely declare a `.transient` enum
member on a range, if the front element value can change?
enum isTransient(R) =
but I have yet to see a cost/benefit analysis that's pro transient
support. The amount of changes needed to support them is not
commensurate to any possible benefits.
Transient ranges are already supported. Removing the ability to have
transient ranges would be an unmitigated disaster. e.g
the convention to explicitely declare a
`.transient` enum member on a range, if the front element value
can change?
Honestly, I don't think that supporting transient ranges is worth it.
Every
single range-based function would have to either test that the "transient"
enum wasn't there or take transi
On 5/30/16 8:44 AM, Andrei Alexandrescu wrote:
On 05/30/2016 08:21 AM, Joseph Rushton Wakeling wrote:
On Sunday, 29 May 2016 at 17:29:35 UTC, Steven Schveighoffer wrote:
This doesn't help at all. I can still make a "transient" range with
all three range primitives.
There seems to be a
. You said "It is
impossible to correctly define input range without caching front which
may not be always possible and may have negative performance impact."
I'm trying to figure out which cases caching makes the solution impossible.
And there is no way to define "transient&q
On 05/30/2016 08:21 AM, Joseph Rushton Wakeling wrote:
On Sunday, 29 May 2016 at 17:29:35 UTC, Steven Schveighoffer wrote:
This doesn't help at all. I can still make a "transient" range with
all three range primitives.
There seems to be a misunderstanding about what a transient range is.
On 5/29/16 2:27 PM, default0 wrote:
On Sunday, 29 May 2016 at 18:09:29 UTC, Steven Schveighoffer wrote:
On 5/29/16 1:45 PM, Steven Schveighoffer wrote:
On 5/27/16 7:42 PM, Seb wrote:
So what about the convention to explicitely declare a `.transient` enum
member on a range, if the front
On Sunday, 29 May 2016 at 17:29:35 UTC, Steven Schveighoffer
wrote:
This doesn't help at all. I can still make a "transient" range
with all three range primitives.
There seems to be a misunderstanding about what a transient
range is.
byLine is a transient range that requires the front
On Friday, 27 May 2016 at 23:42:24 UTC, Seb wrote:
So what about the convention to explicitely declare a
`.transient` enum member on a range, if the front element value
can change?
An alternative solution is to extend data-flow/escape-analysis to
forbit references to `scope`d-variables from
to allocate stack space for the cache, or something like that.
One of most annoying examples is map which calls lambda on each
`front` call :
https://github.com/dlang/phobos/blob/master/std/algorithm/iteration.d#L587-L590
And there is no way to define "transient" ranges in a way other
than
On Sunday, May 29, 2016 18:27:53 default0 via Digitalmars-d wrote:
> On Sunday, 29 May 2016 at 18:09:29 UTC, Steven Schveighoffer
>
> wrote:
> > On 5/29/16 1:45 PM, Steven Schveighoffer wrote:
> >> On 5/27/16 7:42 PM, Seb wrote:
> >>> So what about the convention to explicitely declare a
> >>>
On Sunday, 29 May 2016 at 17:36:24 UTC, Steven Schveighoffer
wrote:
Wholly disagree. If we didn't cache the element, D would be a
laughingstock of performance-minded tests.
byLine already is a laughingstock performance wise:
https://issues.dlang.org/show_bug.cgi?id=11810
It's way faster to
t; `.transient` enum member on a range, if the front element value
> >> can change?
> >
> > Honestly, I don't think that supporting transient ranges is worth it.
> > Every
> > single range-based function would have to either test that the "trans
On Sunday, 29 May 2016 at 17:45:00 UTC, Steven Schveighoffer
wrote:
On 5/27/16 7:42 PM, Seb wrote:
So what about the convention to explicitely declare a
`.transient` enum
member on a range, if the front element value can change?
enum isTransient(R) = is(typeof(() {
static
On Sunday, 29 May 2016 at 18:09:29 UTC, Steven Schveighoffer
wrote:
On 5/29/16 1:45 PM, Steven Schveighoffer wrote:
On 5/27/16 7:42 PM, Seb wrote:
So what about the convention to explicitely declare a
`.transient` enum
member on a range, if the front element value can change?
enum
On 5/29/16 1:45 PM, Steven Schveighoffer wrote:
On 5/27/16 7:42 PM, Seb wrote:
So what about the convention to explicitely declare a `.transient` enum
member on a range, if the front element value can change?
enum isTransient(R) = is(typeof(() {
static assert(isInputRange!R);
static
On 5/27/16 7:42 PM, Seb wrote:
So what about the convention to explicitely declare a `.transient` enum
member on a range, if the front element value can change?
enum isTransient(R) = is(typeof(() {
static assert(isInputRange!R);
static assert(hasIndirections(ElementType!R));
static
transient ranges is worth it. Every
single range-based function would have to either test that the "transient"
enum wasn't there or take transient ranges into account, and realistically,
that isn't going to happen. For better or worse, we do have byLine in
std.stdio, which has a trans
the convention to explicitely declare a `.transient`
enum member on a range, if the front element value can change?
Honestly, I don't think that supporting transient ranges is worth it.
I have personally wondered if there was a case for a TransientRange
concept where the only primitives defined
member on a range, if the front element value can change?
Honestly, I don't think that supporting transient ranges is worth it.
I have personally wondered if there was a case for a TransientRange
concept where the only primitives defined are `empty` and `front`.
`popFront()` is not defined because
only seems
to work because most algorithms need to access `front` once.
I believe this is biggest issue in D ranges design right now,
by large margin.
+1
I think making popFront return a value for transient ranges is
a sound idea. It would allow to easily distinguish between
InputRange
only seems
to work because most algorithms need to access `front` once.
I believe this is biggest issue in D ranges design right now,
by large margin.
+1
I think making popFront return a value for transient ranges is
a sound idea. It would allow to easily distinguish between
InputRange
On Sunday, 29 May 2016 at 15:45:14 UTC, Joseph Rushton Wakeling
wrote:
What's the problem with introspecting that?
There is none :)
it could be implemented today.
.
I believe this is biggest issue in D ranges design right now,
by large margin.
+1
I think making popFront return a value for transient ranges is
a sound idea. It would allow to easily distinguish between
InputRange and TransientRange with very simple CT
introspection. The biggest blocker
wrote:
So what about the convention to explicitely declare a
`.transient` enum member on a range, if the front element
value can change?
Honestly, I don't think that supporting transient ranges is
worth it.
I have personally wondered if there was a case for a
TransientRange concept where
:
On Friday, May 27, 2016 23:42:24 Seb via Digitalmars-d
wrote:
So what about the convention to explicitely declare a
`.transient` enum member on a range, if the front element
value can change?
Honestly, I don't think that supporting transient ranges is
worth it.
I have personally wondered
wrote:
So what about the convention to explicitely declare a
`.transient` enum member on a range, if the front element
value can change?
Honestly, I don't think that supporting transient ranges is
worth it.
I have personally wondered if there was a case for a
TransientRange concept where
a
`.transient` enum member on a range, if the front element
value can change?
Honestly, I don't think that supporting transient ranges is
worth it.
I have personally wondered if there was a case for a
TransientRange concept where the only primitives defined are
`empty` and `front`.
`popFront
> enum member on a range, if the front element value can change?
>>
>> Honestly, I don't think that supporting transient ranges is worth it.
>
> I have personally wondered if there was a case for a TransientRange
> concept where the only primitives defined are `empty` and `front`.
&g
to explicitely declare a
`.transient`
enum member on a range, if the front element value can
change?
Honestly, I don't think that supporting transient ranges is
worth it.
I have personally wondered if there was a case for a
TransientRange
concept where the only primitives defined are `empty
, if the front element value can change?
Honestly, I don't think that supporting transient ranges is worth it.
I have personally wondered if there was a case for a TransientRange
concept where the only primitives defined are `empty` and `front`.
`popFront()` is not defined because the whole point
to explicitely declare a
`.transient` enum member on a range, if the front element
value can change?
Honestly, I don't think that supporting transient ranges is
worth it.
I have personally wondered if there was a case for a
TransientRange concept where the only primitives defined are
`empty
, if the front element
value can change?
Honestly, I don't think that supporting transient ranges is
worth it.
I have personally wondered if there was a case for a
TransientRange concept where the only primitives defined are
`empty` and `front`.
`popFront()` is not defined because the whole
that supporting transient ranges is
worth it.
I have personally wondered if there was a case for a
TransientRange concept where the only primitives defined are
`empty` and `front`.
`popFront()` is not defined because the whole point is that every
single call to `front` will produce a different value.
that supporting transient ranges is
worth it. Every single range-based function would have to
either test that the "transient" enum wasn't there or take
transient ranges into account, and realistically, that isn't
going to happen. For better or worse, we do have byLine in
std.stdio, which has a
On Friday, May 27, 2016 23:42:24 Seb via Digitalmars-d wrote:
> So what about the convention to explicitely declare a
> `.transient` enum member on a range, if the front element value
> can change?
Honestly, I don't think that supporting transient ranges is worth it. Every
single ra
A couple of weeks ago on the next/shift convenience wrapper
discussion [1], there was a nice discussion about transient
ranges. It didn't come to a conclusion, so let's revie it. I just
cite the best three quotes from the thread as a summary:
jmdavis:
The reality of the matter is that ranges
On Friday, 2 August 2013 at 05:35:28 UTC, H. S. Teoh wrote:
Recently, I discovered an interesting idiom for dealing with
transient
ranges, esp. w.r.t. strings / char[]. Many places in D require
string,
but sometimes what you have is char[] which can't be converted
to string
except by .idup
On Friday, 2 August 2013 at 05:35:28 UTC, H. S. Teoh wrote:
void func(S)(S input) if (isSomeString!S) {
string x = to!string(input);
... // use at will
}
+1. I saw this used recently, and I find it very clever.
On Friday, 2 August 2013 at 07:50:28 UTC, Jakob Ovrum wrote:
Places in D that require `string` either do so because they
need the immutable guarantee or they do so out of error (e.g.
should have used a string of const characters instead). The
latter can of course be worked around, but the only
On Friday, 2 August 2013 at 08:46:18 UTC, monarch_dodra wrote:
Without doing this, you face the eternal problem: Should I
return a string, to give my end user more guarantees, when in
fact my char array is perfectly mutable, or should I return a
char[], forcing my end user to make an idup(or
On Friday, 2 August 2013 at 11:19:05 UTC, Tobias Pankrath wrote:
On Friday, 2 August 2013 at 08:46:18 UTC, monarch_dodra wrote:
Without doing this, you face the eternal problem: Should I
return a string, to give my end user more guarantees, when
in fact my char array is perfectly mutable, or
On Friday, 2 August 2013 at 11:27:48 UTC, monarch_dodra wrote:
On Friday, 2 August 2013 at 11:19:05 UTC, Tobias Pankrath wrote:
On Friday, 2 August 2013 at 08:46:18 UTC, monarch_dodra wrote:
Without doing this, you face the eternal problem: Should I
return a string, to give my end user more
On Friday, 2 August 2013 at 08:37:50 UTC, monarch_dodra wrote:
On Friday, 2 August 2013 at 05:35:28 UTC, H. S. Teoh wrote:
void func(S)(S input) if (isSomeString!S) {
string x = to!string(input);
... // use at will
}
+1. I saw this used
Recently, I discovered an interesting idiom for dealing with transient
ranges, esp. w.r.t. strings / char[]. Many places in D require string,
but sometimes what you have is char[] which can't be converted to string
except by .idup. But you don't want to .idup in generic code, because
78 matches
Mail list logo
