On Thursday, 8 May 2014 at 17:46:06 UTC, Andrei Alexandrescu
wrote:
A discussion is building around
https://github.com/D-Programming-Language/phobos/pull/2149,
which is a nice initiative by Walter to allow Phobos users to
avoid or control memory allocation.
First instance of the pull request
On Thursday, 8 May 2014 at 21:38:12 UTC, Andrei Alexandrescu
wrote:
Interesting. So then the range returned by format() will save
everything passed to it, which means...
int fun(int[] a)
{
auto before = format("Before: %s", a);
foreach (ref e; a) ++e;
auto after = format("After: %s", a
On Thursday, 8 May 2014 at 22:27:11 UTC, Luís Marques wrote:
(I guess that's one
drawback of providing functional programming without
immutability?)
Another issue is iteration might be not repeatable, especially if
a closure accidentally slips into the range. In C# iteration is
not destructin
On 08/05/14 23:33, Walter Bright wrote:
It's true that when I first encountered C#'s LINQ, I was surprised that
it was lazy.
It's also true that most of std.algorithm is lazy. Apart from coming up
with a new naming convention (and renaming algorithms in Phobos), I
don't see any obvious solution
Classification of functions in http://dlang.org/phobos/std_path.html:
1. Functions that allocate GC memory and return an array:
dirName, setExtension, defaultExtension, buildPath, buildNormalizedPath,
absolutePath, relativePath, expandTilde
These are prime candidates to be converted into al
On 5/8/2014 4:24 PM, Nick Sabalausky wrote:
On 5/8/2014 4:13 PM, Walter Bright wrote:
8/2014 12:22 PM, Nick Sabalausky wrote:
On 5/8/2014 2:46 PM, Walter Bright wrote:
But to make a lazy version from an eager one means reimplementing it.
Or yield()-ing inside the eager one's sink.
The da
On 5/8/2014 4:13 PM, Walter Bright wrote:
8/2014 12:22 PM, Nick Sabalausky wrote:
On 5/8/2014 2:46 PM, Walter Bright wrote:
But to make a lazy version from an eager one means reimplementing it.
Or yield()-ing inside the eager one's sink.
The data is still supplied to it.
I think I've lo
On 5/8/14, 3:33 PM, Andrei Alexandrescu wrote:
Of these, only a fraction (maybe 60-70%) are actually used with strings.
Still that leaves a significant amount of work to do if we want
std.algorithm to work smoothly with ranges of char/wchar. Here
"smoothly" means "if it compiles and runs it won't
On 5/8/14, 10:46 AM, Andrei Alexandrescu wrote:
[snip]
Here's a list of algorithms in std.algorithm that would need to be
looked at if we want to handle ranges of char and wchar properly (at
least versions with predicates). When I say "looked at" I mean "modified
app
On Thursday, 8 May 2014 at 21:38:12 UTC, Andrei Alexandrescu
wrote:
int fun(int[] a)
{
auto before = format("Before: %s", a);
foreach (ref e; a) ++e;
auto after = format("After: %s", a);
writeln(before, "\n--->\n", after);
}
*ouch*
You might think that's bad, but there's nothing in
On Thu, May 08, 2014 at 02:54:32PM -0700, H. S. Teoh via Digitalmars-d wrote:
> On Thu, May 08, 2014 at 02:38:18PM -0700, Andrei Alexandrescu via
> Digitalmars-d wrote:
> > On 5/8/14, 1:41 PM, "Luís Marques" " wrote:
[...]
> > >I agree with H. S. Teoh. Indeed, I was thinking of trying to create
>
On Thu, May 08, 2014 at 02:38:18PM -0700, Andrei Alexandrescu via Digitalmars-d
wrote:
> On 5/8/14, 1:41 PM, "Luís Marques" " wrote:
> >On Thursday, 8 May 2014 at 18:21:32 UTC, H. S. Teoh via
> >Digitalmars-d wrote:
> >>I've thought about input ranges vs. output ranges for a bit. I
> >>think it d
On 5/8/14, 1:41 PM, "Luís Marques" " wrote:
On Thursday, 8 May 2014 at 18:21:32 UTC, H. S. Teoh via
Digitalmars-d wrote:
I've thought about input ranges vs. output ranges for a bit. I think it
doesn't make sense for functions that process data to take an output
range: output ranges are data sin
On 5/8/2014 2:20 PM, Andrei Alexandrescu wrote:
Some may be surprised that auto c = setExtension(a, b) doesn't actually just do
it. So changing a and/or b before using c would yield surprising result for
someone coming from a background of eager-string languages.
It's true that when I first enc
On 5/8/14, 11:27 AM, Walter Bright wrote:
On 5/8/2014 10:46 AM, Andrei Alexandrescu wrote:
A discussion is building around
https://github.com/D-Programming-Language/phobos/pull/2149, which is a
nice
initiative by Walter to allow Phobos users to avoid or control memory
allocation.
The setExtens
On Thursday, 8 May 2014 at 18:21:32 UTC, H. S. Teoh via
Digitalmars-d wrote:
I've thought about input ranges vs. output ranges for a bit. I
think it
doesn't make sense for functions that process data to take an
output
range: output ranges are data sinks, and should only be used
for the
endpoin
On 5/8/2014 12:22 PM, Nick Sabalausky wrote:
On 5/8/2014 2:46 PM, Walter Bright wrote:
But to make a lazy version from an eager one means reimplementing it.
Or yield()-ing inside the eager one's sink.
The data is still supplied to it.
On Thursday, 8 May 2014 at 17:46:06 UTC, Andrei Alexandrescu
wrote:
A discussion is building around
https://github.com/D-Programming-Language/phobos/pull/2149,
which is a nice initiative by Walter to allow Phobos users to
avoid or control memory allocation.
First instance of the pull request
On 5/8/2014 2:46 PM, Walter Bright wrote:
But to make a lazy version from an eager one means reimplementing it.
Or yield()-ing inside the eager one's sink.
And note also there is such as thing as a stackless "fiber", so I'm not
certain a full-fledged context-switching fiber would necessaril
On 5/8/2014 2:19 PM, H. S. Teoh via Digitalmars-d wrote:
This way, you maximize the usability of the function -- it can
participate in UFCS chains, compose with other std.algorithm functions,
etc..
I think that actually raises an issue worth considering. I posit that
the results of an InputR
On 5/8/2014 11:19 AM, H. S. Teoh via Digitalmars-d wrote:
In case 1, the user has to manually create various intermediate buffers
to store intermediate results. I used a trivial example here, but in
application code, the processing you need is usually far more complex.
This means creating lots of
On 5/8/2014 10:46 AM, Andrei Alexandrescu wrote:
However output range means the string operation will be done eagerly, whereas
lazy has advantages (nice piping, saving on work etc).
The lazy vs eager issue seems at first blush to be an esoteric, potayto-potahto
bikeshed.
But I think it's mo
On 5/8/2014 1:46 PM, Andrei Alexandrescu wrote:
However output range means the string operation will be done eagerly,
whereas lazy has advantages (nice piping, saving on work etc).
Isn't eagerness what we have array() for?
Also, while naming is often just bikeshedding, in this case I think we
On Thu, May 08, 2014 at 11:27:54AM -0700, Walter Bright via Digitalmars-d wrote:
> On 5/8/2014 10:46 AM, Andrei Alexandrescu wrote:
> >A discussion is building around
> >https://github.com/D-Programming-Language/phobos/pull/2149, which is a nice
> >initiative by Walter to allow Phobos users to avoi
On 5/8/2014 10:46 AM, Andrei Alexandrescu wrote:
A discussion is building around
https://github.com/D-Programming-Language/phobos/pull/2149, which is a nice
initiative by Walter to allow Phobos users to avoid or control memory
allocation.
The setExtension() function is itself not very importan
On Thu, May 08, 2014 at 10:46:12AM -0700, Andrei Alexandrescu via Digitalmars-d
wrote:
> A discussion is building around
> https://github.com/D-Programming-Language/phobos/pull/2149, which is a
> nice initiative by Walter to allow Phobos users to avoid or control
> memory allocation.
>
> First in
A discussion is building around
https://github.com/D-Programming-Language/phobos/pull/2149, which is a
nice initiative by Walter to allow Phobos users to avoid or control
memory allocation.
First instance of the pull request copied the inputs into an output range.
The second instance (right n
27 matches
Mail list logo
