[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Clément Pit--Claudel
Subject: Re: [PATCH] Elpa: Pinpoint semantics of `seq-subseq' for streams
Date: Tue, 13 Sep 2016 21:24:34 -0400
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0

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 :)


Attachment: signature.asc
Description: OpenPGP digital signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]