From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Michael Heerdegen Newsgroups: gmane.emacs.devel Subject: Re: [PATCH] Elpa: Pinpoint semantics of `seq-subseq' for streams Date: Wed, 14 Sep 2016 17:15:22 +0200 Message-ID: <87r38mwm0l.fsf@web.de> References: <87bmzrahvg.fsf@web.de> <79c6ccd6-9808-f4fd-071a-58559f72ecdc@gmail.com> <8737l3a4ab.fsf@web.de> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1473866210 31912 195.159.176.226 (14 Sep 2016 15:16:50 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 14 Sep 2016 15:16:50 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1 (gnu/linux) Cc: =?utf-8?Q?Cl=C3=A9ment?= Pit--Claudel , emacs-devel@gnu.org To: jwiegley@gmail.com Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Sep 14 17:16:46 2016 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bkBvG-0005o2-7D for ged-emacs-devel@m.gmane.org; Wed, 14 Sep 2016 17:16:26 +0200 Original-Received: from localhost ([::1]:56731 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bkBvE-0006YK-CC for ged-emacs-devel@m.gmane.org; Wed, 14 Sep 2016 11:16:24 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:49010) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bkBuN-0006We-6h for emacs-devel@gnu.org; Wed, 14 Sep 2016 11:15:32 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bkBuJ-0004xM-5t for emacs-devel@gnu.org; Wed, 14 Sep 2016 11:15:30 -0400 Original-Received: from mout.web.de ([212.227.17.11]:56698) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bkBuI-0004ww-S5 for emacs-devel@gnu.org; Wed, 14 Sep 2016 11:15:27 -0400 Original-Received: from drachen.dragon ([90.186.1.88]) by smtp.web.de (mrweb102) with ESMTPSA (Nemesis) id 0MD8BU-1bnTAf02HM-00GV9y; Wed, 14 Sep 2016 17:15:25 +0200 In-Reply-To: (John Wiegley's message of "Tue, 13 Sep 2016 18:28:22 -0700") X-Provags-ID: V03:K0:IKP10pn9t/UqI0ubiQJQiEvZrqcd0B4kSTSssYcMJZszC6W4cx+ wKMcqIEU131pKE5sTbNKHbdPwicp+OM3qQ1jShRyhn57SKCjkx2oj/1/NRq/7XCZewrGkiH P0Xeh5/ye3Ebhz8tMFMJMSIiISjKTRbDRdGZN4OenVK8e+4bNEUqdr51Z4/EnRg9ThAiozP zDDp6DPb7/CR6plAv2WCg== X-UI-Out-Filterresults: notjunk:1;V01:K0:uyD1wTIV4xE=:uMghnr6jL54Msov9YyEm8C rjmKKNtP5NYa6SL6i2yoeTTLk4upgk7F+fLqGgmT3nNgIJ0+TCFIB0wRtXkFzSJyvu45xhLc8 hpJk0MsoLx732cDXQ99jIPEl8t0cFc8xsZEsW02HIaBNf8mu1wbhROY5qBA8QXcJlvEfurwdt ftTCLwSwJccuDEXi80/n7yLbJB9DOBV+deBs9idHpZcBthwDwWtaLT2yLfoXF1nhPxzbF9UlC utcRvmWv9VPSrBdi5bh8c5y1n0NU6cCR8/Vcoyi54vD7KpTNI8YcAuL96ZdjYLgUrrPxHqv0a 2C6LbsWwQuak+85Fkx4hEuIZ1apZtCJ8rA1Pq78K4aNN5FN0SLhgZovC04/K7WJJr+RSlVTQx khAsH2jN8k5Ln+c1vDD4V3tsPJmAw7Kzkzl98/I+jJ0c7uVrk2maZYP1DJB+SVxfzEsBIqYh/ SxV0OyWXre9T4wCTCELYGZr62YOcWMNu10PWR6yYR4Lfh2vgqC/ccjDsM5j0CaHNQH5Gq2sDS /PpmqQF11pKgRpU2paFomxADtX63c7RqptXP+2Sp7p4D6cMhObE6vS2HaettJKy3HwXLT7nYB U2GZx54YWcRNQ2wiy/Shk6nx/znr7OF++c8kpPglGzAq/MyJo95UgIkg3a0YczJiL26jkyI8m VBF6L/uwlLBd7WmGjmpSxt52xcIaJLduzvYkDPAXze+sU/n7nPJIL6bSAxTsNxKmj+X8qEYOM 7EthKtw4uXCar53jhDmoQUytoOptGtZdYW/H2h1lRrd1W8YM3OdSrMJo/5oSEWBviFbCrqco X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 212.227.17.11 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:207433 Archived-At: John Wiegley writes: > You could implement tail as a stream adapter that basically implements a > sliding window: > > Whenever an element is requested from the tail stream, it keeps > requesting elements from the parent stream, filling up its window > buffer and cycling out old elements, until it reaches the end of the > parent stream. At that point, it knows enough to start draining the > window buffer to the caller. Yeah, implementing it that way would be cool: if we use `stream-pop', we would not even need to create a new stream, we would just return the original stream `stream-pop'ped accordingly until we have found its end - and everything wrapped inside `stream-delay' so that this is done not before elements are requested from the returned stream. Thanks, Michael.