From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Yuri Khan Newsgroups: gmane.emacs.devel Subject: Re: [PATCH] Gnu Elpa: stream.el: Add some more basic stream operations Date: Mon, 26 Sep 2016 00:41:02 +0600 Message-ID: References: <87twhbmwbx.fsf@web.de> <878tynl720.fsf@petton.fr> <8737onlapw.fsf@web.de> <87ziqu7ew9.fsf@petton.fr> <87mvmuxuyo.fsf@web.de> <8760tixi99.fsf@web.de> <87twh1kpem.fsf@web.de> <87y42r4d3a.fsf@web.de> <878tug9eh3.fsf@web.de> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 X-Trace: blaine.gmane.org 1474828975 13923 195.159.176.226 (25 Sep 2016 18:42:55 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 25 Sep 2016 18:42:55 +0000 (UTC) Cc: Nicolas Petton , Emacs developers To: Michael Heerdegen Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Sep 25 20:42:52 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 1boENx-0002SF-Ia for ged-emacs-devel@m.gmane.org; Sun, 25 Sep 2016 20:42:45 +0200 Original-Received: from localhost ([::1]:39992 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1boENv-0004LU-Pp for ged-emacs-devel@m.gmane.org; Sun, 25 Sep 2016 14:42:43 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:45822) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1boENk-0004IW-D7 for emacs-devel@gnu.org; Sun, 25 Sep 2016 14:42:33 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1boENe-0008JD-FX for emacs-devel@gnu.org; Sun, 25 Sep 2016 14:42:31 -0400 Original-Received: from mail-lf0-f41.google.com ([209.85.215.41]:32798) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1boENe-0008H6-7Z for emacs-devel@gnu.org; Sun, 25 Sep 2016 14:42:26 -0400 Original-Received: by mail-lf0-f41.google.com with SMTP id b71so98324024lfg.0 for ; Sun, 25 Sep 2016 11:42:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=tycujArh4E8XfhdVhEnJm6/K4LU4DhtCNZS9M1vVVRw=; b=b23fmZKtnXsC0lMHReKFzm7121I390/EYeLgG6fkgZRw+yXcSpGwM5H+/43eBqrcCK j2jthJQ/7ImTB7ATDYTFdOAAYObDaTACf4FJSPZiAuvJkwqB/Sk1ZmMKo4qr6Rjxf5m9 y3gsSyYbnSpUkqcWbvJJFxO3UZ96saQKEAuw3Rat8PBfRGedIN7cegvIBbrl6bvFP1As VTC9OGdmMXrW0YadI38o9OHlyOw0U5cbEPdLPi/EwLDoWEc1qEQYfN3aMTFGxGyaBKF5 ZJz08WRilAYa7nAhXLhCeGmbp7pT4y1T2a08e+RvEyR0PN6dvH1EailHAGDgaqdQ/B0z aLDQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=tycujArh4E8XfhdVhEnJm6/K4LU4DhtCNZS9M1vVVRw=; b=R31b1VyfyvS9tGBKwAFB3ofic3t4oNkF3moOPcJF0NeXrv9KsxeDf/lASV/uC89ZQY VdjXsD5ZvcooBZp5Uuq1Cv3sbyd4xnEvZProNvc1GOhvZ86wRKn4RL8ksex2NoZO28r/ jPHSFplxC7bRwcPo1WcmxU4ggTx4PUuBIUXCpSGObwXcmg+boRJb1ZnUyyGhihmbuB7g T2rlLNAQAYDDq7IUIQ0I+CtyFqlSJFIwbJJ8o5mEnEOihymQMVB02yt6eKSOU7bV38Er 1VvIOU2ZiOHnQjl+QinWL/OxiJigc14BMq19tC+sUBYbX2wUy0WVSOphceK4LfFJ8AlH FhKw== X-Gm-Message-State: AE9vXwMeJchc1ckqruUBUPny8DzZtvRqHkaeL05oRcOEJT4lZ7Up4PAIyL1vIHWlzy5ZMGdEbfauDxEShZCAqQ== X-Received: by 10.46.1.231 with SMTP id f100mr6011077lji.21.1474828883831; Sun, 25 Sep 2016 11:41:23 -0700 (PDT) Original-Received: by 10.114.80.163 with HTTP; Sun, 25 Sep 2016 11:41:02 -0700 (PDT) In-Reply-To: <878tug9eh3.fsf@web.de> X-Google-Sender-Auth: QghvygwYeSlPeoDfRpy3DgUcDOM X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 209.85.215.41 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:207790 Archived-At: On Sun, Sep 25, 2016 at 10:38 PM, Michael Heerdegen wrote: > If you asking the question implies that you find the semantics not > trivially clear Yes. Naming things is listed as the second hardest problem in computer science, and having a concise explanation of the semantics helps with that greatly. > maybe the following simpler (even superior) approach > would be much better: Add an optional integer type argument to > `seq-drop-while' and `seq-take-while' that allows to shift the index by > the specified amount (as far as possible): > > #+begin_src emacs-lisp > (cl-defgeneric seq-drop-while (pred sequence &optional less) > (seq-drop sequence (- (seq--count-successive pred sequence) (or less 0)))) > > (cl-defgeneric seq-take-while (pred sequence &optional more) > (seq-take sequence (+ (seq--count-successive pred sequence) (or more 0)))) > #+end_src Let me see if I can formulate the semantics here. I will work from cases first and then try to describe the intended behavior in a single sentence. seq-drop-while * Easiest happy case: A finite number, no fewer than LESS, of initial elements satisfy PRED. They are counted, then LESS subtracted, yielding a non-negative count of elements to drop. * Fewer than LESS (possibly zero) initial elements satisfy PRED. They are counted, then LESS subtracted, yielding a negative drop count. Presumably then seq-drop returns the original sequence. * The sequence is infinite and its every successive element satisfies PRED. Then the above implementation diverges, trying to count to infinity. My guess at intended semantics: Return the subsequence of SEQUENCE obtained by dropping all but the last LESS initial elements that satisfy PRED. (This does not explain the negative drop count case.) seq-take-while * A finite number (possibly zero) of initial elements satisfy PRED, and after that follow at least MORE elements. * A finite number (possibly zero) of initial elements satisfy PRED, and after that follow fewer than MORE (possibly zero) elements. Presumably, seq-take will return the original sequence. * The sequence is infinite and its every successive element satisfies PRED. The counting implementation will again diverge. My guess: Return the initial subsequence of SEQUENCE whose elements satisfy PRED, followed by at most MORE more successive elements. (Another implementation can be devised that handles the infinite case.) Looking back at the thread, I recall that this exploration started from my conjecture that detecting the presence of an absorbing element could make reduction lazy wrt all following elements. The possibility is fun to explore, but I am now thinking that was not such a useful idea.