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 lost track of what you mean here. What data is still supplied to what, and what point does that illustrate?

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 data is still supplied to it.
>
> I think I've lost track of what you mean here. What data is still supplied to
> what, and what point does that illustrate?
>

When creating an engine vs calculating the result, the former does not require the actual data to be supplied.

regex is a classic example of that.

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 algorithms.


2. Functions that return a slice of their input arrays:

  baseName, rootName, driveName, stripDrive, extension,

Should be enhanced to accept RandomAccessRange and produce RandomAccessRange


3. Functions that return a range:

  pathSplitter

Enhance to accept RandomAccessRange


4. Functions that take an array and compute a value:

  isRooted, isAbsolute, filenameCmp, globMatch, isValidPath

These are reducers, and should be enhanced to accept input ranges.

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 to what's lazy and what's not.
>
> One possibility is to informally (i.e. in the documentation rather than
> the core language spec) call something an 'algorithm' if it is lazy and
> 'function' if it is eager.

Don't know if it helps, but we could add a UDA indicating which functions are lazy. This wouldn't require any renaming of existing functions.

-- 
/Jacob Carlborg

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 destructing, in D one can save a range.

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);
>    writeln(before, "\n--->\n", after);
> }
>
> *ouch*
>
> Andrei

void fun(int[] a)
{
   auto before = a.map!(a => a + 1);
   foreach (ref e; a) ++e;
   auto after = a.map!(a => a + 1);
   writeln(before, "\n--->\n", after);
}

Laziness and mutable references are not the best of friends.

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 copied the inputs into an output range.
>
> The second instance (right now) creates an input range that lazily creates the result. The element type of that range is the encoding type of the first argument (i.e. char or wchar most of the time). This is different from string/wstring/etc element-wise iteration because it'll be done code unit-wise, not code point-wise.

I'm with H. S. Teoh that we should prefer the input range approach. My limited experience with output ranges suggests to me that they really need to be the end point, where the data is actually leaving the program (writing to disk, over a network). And as Teoh mentions, if you need it in specific memory you can copy an input range into it.

D is already fairly lazy, and .array() is great for doing eager evaluation into the GC. For strings having something similar which allows for the original encoding to remain would be good.