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

["Clément Pit--Claudel" <clement.pit@gmail.com>]

[-- Attachment #1.1: Type: text/plain, Size: 1377 bytes --]

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.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]