From: Michael Heerdegen <michael_heerdegen@web.de>
To: Yuri Khan <yuri.v.khan@gmail.com>
Cc: Nicolas Petton <nicolas@petton.fr>,
Emacs developers <emacs-devel@gnu.org>
Subject: Re: [PATCH] Gnu Elpa: stream.el: Add some more basic stream operations
Date: Thu, 02 Mar 2017 03:36:09 +0100 [thread overview]
Message-ID: <87shmw76cm.fsf@drachen> (raw)
In-Reply-To: <CAP_d_8WYgjFhexb23KkaicOOLk3hQ-fma0D_RbXPr-9MB8iPZQ@mail.gmail.com> (Yuri Khan's message of "Thu, 29 Sep 2016 01:19:04 +0600")
[-- Attachment #1: Type: text/plain, Size: 2337 bytes --]
Hi everybody!
I want to revive this discussion. I needed something like this for
el-search, so I gave it a second thought.
> >> As an example, if you want a subsequence starting at the first odd
> >> number or at index 1000, whichever is earlier, (seq-drop (min 1000
> >> (seq-position-if 'odd S)) S) will not do the right thing.
> >
> > Would adding an optional argument that allows to specify an upper limit
> > for the indexes the function looks at cover (all of) your concerns?
>
> That was just an example. Real users will have other needs. If given a
> primitive that returns an index of something, they will try solving
> their problems in terms of that index. It is an interface that is easy
> to use incorrectly.
>
> But please do not let my theoretical concerns stop you from
> implementing useful things. A working implementation is the surest way
> of gaining collective experience about a tool.
I tried to cope with our problems by using abstraction and higher order
functions (so far, only implemented for streams - see below).
We talked about pairs of function (take-until, drop-until), and a
problem was that the semantics were always a bit vague or hard to define
(is a border element in or out?, etc). A difficulty with the discussed
concepts was that it was not easily possible to step back to cut a
stream before a certain element when we already had skipped that element
etc.
That brought me to the following idea:
The underlying basic "operation" is to divide a stream into two parts.
Such a division is non-ambiguously described by specifying the second
part, the rest-stream. Any function dividing a stream into two parts
can be described by another function F stream -> rest, that takes a
stream, and returns a rest. Such functions F are the input of my
low-level functions.
A subsequent application of divide operations leads to a partition of a
stream into a stream of substreams, which I also implemented.
I also implemented two more higher-level functions for stream
dividing/partitioning that hopefully should cover most of the use cases
of seq-drop-while et alter. For the cases that should not be covered,
you can use the lower level functions with an appropriate function F as
described above. Sounds complicated, but it's just a sum of trivial
pieces.
And this is how that looks. WDYT?
[-- Attachment #2: stream-divide.el --]
[-- Type: application/emacs-lisp, Size: 2323 bytes --]
[-- Attachment #3: Type: text/plain, Size: 21 bytes --]
Regards,
Michael.
next prev parent reply other threads:[~2017-03-02 2:36 UTC|newest]
Thread overview: 48+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-06-02 15:42 [PATCH] Gnu Elpa: stream.el: Add some more basic stream operations Michael Heerdegen
2016-06-02 15:50 ` Michael Heerdegen
2016-06-02 19:33 ` Nicolas Petton
2016-06-02 19:44 ` Michael Heerdegen
2016-06-08 19:52 ` Michael Heerdegen
2016-06-09 11:58 ` Nicolas Petton
2016-06-09 15:06 ` Michael Heerdegen
2016-06-09 15:46 ` Nicolas Petton
2016-06-09 16:01 ` Davis Herring
2016-06-09 16:24 ` Michael Heerdegen
2016-06-09 17:11 ` Yuri Khan
2016-06-09 19:41 ` Michael Heerdegen
2016-06-09 21:06 ` Yuri Khan
2016-06-10 15:57 ` Michael Heerdegen
2016-06-10 16:13 ` Yuri Khan
2016-06-10 19:37 ` Michael Heerdegen
2016-09-16 23:52 ` Michael Heerdegen
2016-09-17 6:22 ` Yuri Khan
2016-09-25 15:38 ` Michael Heerdegen
2016-09-25 18:41 ` Yuri Khan
2016-09-28 1:07 ` Michael Heerdegen
2016-09-28 4:13 ` Yuri Khan
2016-09-28 8:50 ` Nicolas Petton
2016-09-28 18:27 ` Michael Heerdegen
2016-09-28 19:19 ` Yuri Khan
2017-03-02 2:36 ` Michael Heerdegen [this message]
2017-03-02 5:00 ` Michael Heerdegen
2017-03-02 12:58 ` Nicolas Petton
2017-03-02 12:55 ` Nicolas Petton
2017-03-02 22:38 ` Michael Heerdegen
2017-03-15 14:42 ` Michael Heerdegen
2017-03-21 11:37 ` Nicolas Petton
2017-03-22 17:09 ` Michael Heerdegen
2017-04-21 2:34 ` Michael Heerdegen
2017-04-22 20:34 ` Nicolas Petton
2017-04-23 5:08 ` Michael Heerdegen
2017-03-20 11:29 ` Nicolas Petton
2016-09-25 20:49 ` John Wiegley
2016-06-12 8:34 ` Markus Triska
2016-06-12 14:07 ` Michael Heerdegen
2016-06-12 14:31 ` Nicolas Petton
2016-06-12 22:28 ` Markus Triska
2016-06-11 1:34 ` Michael Heerdegen
2016-07-06 23:20 ` Michael Heerdegen
2016-08-01 21:13 ` Michael Heerdegen
2016-08-01 22:05 ` Nicolas Petton
2016-08-02 0:39 ` Michael Heerdegen
2016-06-09 15:48 ` Nicolas Petton
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87shmw76cm.fsf@drachen \
--to=michael_heerdegen@web.de \
--cc=emacs-devel@gnu.org \
--cc=nicolas@petton.fr \
--cc=yuri.v.khan@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).