Re: [PATCH] Elpa: Pinpoint semantics of `seq-subseq' for streams

[Clément Pit--Claudel]

Hi Michael,

On 2016-09-13 17:17, Michael Heerdegen wrote:
> Yes, I want to forbid them, unless there are realistic use cases.
> No, we don't have something like `tail' for streams.  If you want
> something like that, you are in general better done with lists (i.e.
> convert the stream into a list), I think.

I don't think converting to list would be a good idea.  When operating on text 
files, for example, it's often convenient to get the last n lines of a file.  
If the file is represented as a stream of lines, then tail makes sense.  
Doesn't it?  Converting the file to a list of lines beforehand sounds like a 
bad idea, memory wise.

> Streams are a mean to program in a certain way (called data flow
> control or something like that).  Negative indexes for `seq-subseq'
> collide with this model.

I don't see why; isn't it common to implement slyding-window-style algorithms 
on data streams? 'tail' is just one such example.  

I do agree, however, that the return value of these silding-window algorithms 
is not commonly a stream (rather a list, or a function of that list).  But I'm 
not sure that this is enough to make subseq with negative arguments irrelevant. 
Otherwise, what's a point of subseq vs. e.g. drop + take?

Let me know what you think of the 'last n lines of a file' example.  Maybe I'm 
missing something :)

Cheers,
Clément.

signature.asc
Description: OpenPGP digital signature