Range of n lines from stdin

[Ivan Kazmenko]

On Friday, 27 December 2013 at 20:30:52 UTC, Ivan Kazmenko wrote:
> On Friday, 27 December 2013 at 18:32:29 UTC, Jakob Ovrum wrote:
>>> If repeat could know whether its first argument is pure, it 
>>> could then enable or disable front caching depending on 
>>> purity... no way currently?
>>
>> `readln.repeat(n)` can also be written `repeat(readln(), n)`. 
>> Maybe that makes it more obvious what it does - reads one line 
>> from standard input and passes that to `repeat`, which returns 
>> a range that returns that same line `n` times.
>
> The confusion for me is this: does "repeat" mean "eagerly get a 
> value once and then lazily repeat it n times" or "do what the 
> first argument suggests (emit constant, call function, etc.) n 
> times"?  I guess it depends on the defaults of the language.  
> Currently, I had no strong preference for one definition over 
> the other when I saw the name.  Maybe I would indeed prefer the 
> first definition if I knew D better, I don't know.
>
> In the first definition, the "eagerly vs. lazily" contradiction 
> in my mind is what scares me off from making it the default: if 
> "repeat" is a lazy range by itself, why would it treat its 
> argument eagerly?  What if the argument is a lazy range itself, 
> having a new value each time repeat asks for it?
>
> The first definition makes much more sense for me when I treat 
> it this way: "repeat expects its first argument to be pure (not 
> able to change between calls)".
>
> Perhaps there's a wholly different way of thinking about this 
> in which the first definition makes much more sense than then 
> second one from the start.  If so, please share it.

Maybe the imperative should be "repeat is a function, and 
arguments of functions should be evaluated only once"?  It does 
make sense from a language point of view, but somewhat breaks the 
abstraction for me.