* Merging nth, aref, and elt.
@ 2014-10-29 21:40 Artur Malabarba
2014-10-30 1:52 ` Stefan Monnier
0 siblings, 1 reply; 18+ messages in thread
From: Artur Malabarba @ 2014-10-29 21:40 UTC (permalink / raw)
To: Stefan Monnier; +Cc: emacs-devel
[-- Attachment #1: Type: text/plain, Size: 314 bytes --]
On 29 Oct 2014 16:35, "Stefan Monnier" <monnier@iro.umontreal.ca> wrote:
> But yes, Elisp's "core" functions suffer from lots of irregularities,
> and getting rid of them would be an improvement. E.g.: [...]
> - Merge nth, aref, and elt.
I wouldn't mind giving this a try.
I take it this should be a C function?
[-- Attachment #2: Type: text/html, Size: 462 bytes --]
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Merging nth, aref, and elt. 2014-10-29 21:40 Merging nth, aref, and elt Artur Malabarba @ 2014-10-30 1:52 ` Stefan Monnier 2014-10-30 9:51 ` David Kastrup 0 siblings, 1 reply; 18+ messages in thread From: Stefan Monnier @ 2014-10-30 1:52 UTC (permalink / raw) To: Artur Malabarba; +Cc: emacs-devel >> But yes, Elisp's "core" functions suffer from lots of irregularities, >> and getting rid of them would be an improvement. E.g.: [...] >> - Merge nth, aref, and elt. > I wouldn't mind giving this a try. > I take it this should be a C function? Yes, of course. Arguably `elt' is already the answer. Stefan ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Merging nth, aref, and elt. 2014-10-30 1:52 ` Stefan Monnier @ 2014-10-30 9:51 ` David Kastrup 2014-10-30 13:30 ` Artur Malabarba 0 siblings, 1 reply; 18+ messages in thread From: David Kastrup @ 2014-10-30 9:51 UTC (permalink / raw) To: emacs-devel Stefan Monnier <monnier@iro.umontreal.ca> writes: >>> But yes, Elisp's "core" functions suffer from lots of irregularities, >>> and getting rid of them would be an improvement. E.g.: [...] >>> - Merge nth, aref, and elt. >> I wouldn't mind giving this a try. >> I take it this should be a C function? > > Yes, of course. > Arguably `elt' is already the answer. Reminds me of <URL:https://xkcd.com/927/> -- David Kastrup ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Merging nth, aref, and elt. 2014-10-30 9:51 ` David Kastrup @ 2014-10-30 13:30 ` Artur Malabarba 2014-10-31 19:13 ` Stefan Monnier 0 siblings, 1 reply; 18+ messages in thread From: Artur Malabarba @ 2014-10-30 13:30 UTC (permalink / raw) To: David Kastrup; +Cc: emacs-devel >> Yes, of course. >> Arguably `elt' is already the answer. Yes. I was away from the compuiter when I sent the other email, so I thought maybe `elt' wasn't quite the same as nth+aref. But looking at it now, that's exactly what it is. So it looks like there's nothing to be done. here :-) ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Merging nth, aref, and elt. 2014-10-30 13:30 ` Artur Malabarba @ 2014-10-31 19:13 ` Stefan Monnier 2014-10-31 19:56 ` Stefan Monnier 0 siblings, 1 reply; 18+ messages in thread From: Stefan Monnier @ 2014-10-31 19:13 UTC (permalink / raw) To: Artur Malabarba; +Cc: David Kastrup, emacs-devel > So it looks like there's nothing to be done. here :-) I think there is: - The efficiency of (setf (elt s i) v) needs to be improved. - I'd argue that `elt' should also work on hash tables. Stefan ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Merging nth, aref, and elt. 2014-10-31 19:13 ` Stefan Monnier @ 2014-10-31 19:56 ` Stefan Monnier 2014-11-01 1:08 ` Stephen J. Turnbull 0 siblings, 1 reply; 18+ messages in thread From: Stefan Monnier @ 2014-10-31 19:56 UTC (permalink / raw) To: Artur Malabarba; +Cc: David Kastrup, emacs-devel >> So it looks like there's nothing to be done. here :-) > I think there is: > - The efficiency of (setf (elt s i) v) needs to be improved. > - I'd argue that `elt' should also work on hash tables. A few more steps, and `elt' becomes foo-get. Stefan ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Merging nth, aref, and elt. 2014-10-31 19:56 ` Stefan Monnier @ 2014-11-01 1:08 ` Stephen J. Turnbull 2014-11-01 3:19 ` Stefan Monnier 0 siblings, 1 reply; 18+ messages in thread From: Stephen J. Turnbull @ 2014-11-01 1:08 UTC (permalink / raw) To: Stefan Monnier; +Cc: David Kastrup, Artur Malabarba, emacs-devel Stefan Monnier writes: > >> So it looks like there's nothing to be done. here :-) > > I think there is: > > - The efficiency of (setf (elt s i) v) needs to be improved. > > - I'd argue that `elt' should also work on hash tables. > > A few more steps, and `elt' becomes foo-get. `get' should just work on everything. (It's a shame getf has a conflicting definition.) But note that (get not-necessarily-symbolp-obj 0) has a gotcha: for sequences 0 means the first object when iterating, for hashes and symbols it means the value of the mapping at the object which represents the integer 0 (which happens to be unique in Lisp). So it's potentially ambiguous. ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Merging nth, aref, and elt. 2014-11-01 1:08 ` Stephen J. Turnbull @ 2014-11-01 3:19 ` Stefan Monnier 2014-12-13 4:09 ` Artur Malabarba 0 siblings, 1 reply; 18+ messages in thread From: Stefan Monnier @ 2014-11-01 3:19 UTC (permalink / raw) To: Stephen J. Turnbull; +Cc: David Kastrup, Artur Malabarba, emacs-devel > But note that (get not-necessarily-symbolp-obj 0) has a gotcha: for > sequences 0 means the first object when iterating, for hashes and > symbols it means the value of the mapping at the object which > represents the integer 0 (which happens to be unique in Lisp). So > it's potentially ambiguous. I don't see any ambiguity there: sequences are mappings from integers to objects. There are ambiguities tho if we try to use `get' for everything like hash tables, array, lists, symbol properties, window parameters, buffer-local variables, object fields, ...: - we can't reliably distinguish a list from an alist. - we can't reliably distinguish a defstruct object from an array. Stefan ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Merging nth, aref, and elt. 2014-11-01 3:19 ` Stefan Monnier @ 2014-12-13 4:09 ` Artur Malabarba 2014-12-14 3:57 ` Stefan Monnier 0 siblings, 1 reply; 18+ messages in thread From: Artur Malabarba @ 2014-12-13 4:09 UTC (permalink / raw) To: Stefan Monnier; +Cc: Stephen J. Turnbull, David Kastrup, emacs-devel Here's an initial diff for hash-tables. Should it use `get' instead of `elt'? (fns.c) elt: Also work on hash-tables (lisp/emacs-lisp/gv.el): Fix setf on `elt' (bytecode.c) exec_byte_code: Add nil arg to Felt call. 3 files changed, 26 insertions(+), 14 deletions(-) lisp/emacs-lisp/gv.el | 7 ++++--- src/bytecode.c | 2 +- src/fns.c | 31 +++++++++++++++++++++---------- Modified lisp/emacs-lisp/gv.el diff --git a/lisp/emacs-lisp/gv.el b/lisp/emacs-lisp/gv.el index a0f92a5..11c35a4 100644 --- a/lisp/emacs-lisp/gv.el +++ b/lisp/emacs-lisp/gv.el @@ -302,7 +302,8 @@ The return value is the last VAL in the list. (gv-define-setter cdar (val x) `(setcdr (car ,x) ,val)) (gv-define-setter cddr (val x) `(setcdr (cdr ,x) ,val)) -(gv-define-setter elt (store seq n) - `(if (listp ,seq) (setcar (nthcdr ,n ,seq) ,store) - (aset ,seq ,n ,store))) +(gv-define-setter elt (store set index) + `(if (listp ,set) (setcar (nthcdr ,index ,set) ,store) + (if (arrayp ,set) (aset ,set ,index ,store) + (puthash ,index ,store ,set)))) (gv-define-simple-setter get put) (gv-define-setter gethash (val k h &optional _d) `(puthash ,k ,val ,h)) Modified src/bytecode.c diff --git a/src/bytecode.c b/src/bytecode.c index d3c8b47..456f23d 100644 --- a/src/bytecode.c +++ b/src/bytecode.c @@ -1843,5 +1843,5 @@ exec_byte_code (Lisp_Object bytestr, Lisp_Object vector, Lisp_Object maxdepth, BEFORE_POTENTIAL_GC (); v1 = POP; - TOP = Felt (TOP, v1); + TOP = Felt (TOP, v1, Qnil); AFTER_POTENTIAL_GC (); } Modified src/fns.c diff --git a/src/fns.c b/src/fns.c index e891fdb..aabe757 100644 --- a/src/fns.c +++ b/src/fns.c @@ -1355,15 +1355,26 @@ N counts from zero. If LIST is not that long, nil is returned. */) } -DEFUN ("elt", Felt, Selt, 2, 2, 0, - doc: /* Return element of SEQUENCE at index N. */) - (register Lisp_Object sequence, Lisp_Object n) -{ - CHECK_NUMBER (n); - if (CONSP (sequence) || NILP (sequence)) - return Fcar (Fnthcdr (n, sequence)); +DEFUN ("elt", Felt, Selt, 2, 3, 0, + doc: /* Return element of SET at INDEX. +If SET is a list or an array, INDEX is a number and DFLT is ignored. +If SET is a hash table, INDEX is a key. If INDEX is not found, return +DFLT which defaults to nil. */) + (register Lisp_Object set, Lisp_Object index, Lisp_Object dflt) +{ + if (CONSP (set) || NILP (set)) + { + CHECK_NUMBER (index); + return Fcar (Fnthcdr (index, set)); + } + + if (ARRAYP (set)) + { + CHECK_NUMBER (index); + return Faref (set, index); + } - /* Faref signals a "not array" error, so check here. */ - CHECK_ARRAY (sequence, Qsequencep); - return Faref (sequence, n); + /* Fgethash signals a "not hash-table" error, so check here. */ + CHECK_TYPE (HASH_TABLE_P (set), Qsequencep, set); + return Fgethash (index, set, dflt); } ^ permalink raw reply related [flat|nested] 18+ messages in thread
* Re: Merging nth, aref, and elt. 2014-12-13 4:09 ` Artur Malabarba @ 2014-12-14 3:57 ` Stefan Monnier 2014-12-14 11:23 ` Nicolas Petton 0 siblings, 1 reply; 18+ messages in thread From: Stefan Monnier @ 2014-12-14 3:57 UTC (permalink / raw) To: Artur Malabarba; +Cc: Stephen J. Turnbull, David Kastrup, emacs-devel > Here's an initial diff for hash-tables. Should it use `get' instead of `elt'? Hmm... I think we should distinguish the "get element" of sequences and the "get element" of tables. The upcoming seq.el provides operations on sequences, such as seq-elt and that doesn't apply to hash-tables because I don't think we should treat them as sequences. So, yes, support for hash-tables would fall into the `get' extension, or whatever name we end up choosing. I think we should probably come up with a library akin to seq.el but for mappings (also known as "functions" in set-theory). It could be called map.el, maybe, and the operation could be map-elt? Stefan ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Merging nth, aref, and elt. 2014-12-14 3:57 ` Stefan Monnier @ 2014-12-14 11:23 ` Nicolas Petton 2014-12-14 13:47 ` Stefan Monnier 0 siblings, 1 reply; 18+ messages in thread From: Nicolas Petton @ 2014-12-14 11:23 UTC (permalink / raw) To: Stefan Monnier Cc: Stephen J. Turnbull, David Kastrup, Artur Malabarba, emacs-devel Stefan Monnier writes: >> Here's an initial diff for hash-tables. Should it use `get' instead of `elt'? > > I think we should probably come up with a library akin to seq.el but > for mappings (also known as "functions" in set-theory). It could be > called map.el, maybe, and the operation could be map-elt? That would be really nice. subr-x contains some extra hash-tables functions already and I'm wondering how it should be dealt with without implementing some functions twice if we were implementing a map.el library. Should we keep hash-table functions in subr-x and simply alias them in map.el or remove them from subr-x.el? Nico -- Nicolas Petton http://nicolas-petton.fr ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Merging nth, aref, and elt. 2014-12-14 11:23 ` Nicolas Petton @ 2014-12-14 13:47 ` Stefan Monnier 2014-12-18 16:01 ` Artur Malabarba 0 siblings, 1 reply; 18+ messages in thread From: Stefan Monnier @ 2014-12-14 13:47 UTC (permalink / raw) To: Nicolas Petton Cc: Stephen J. Turnbull, David Kastrup, Artur Malabarba, emacs-devel > That would be really nice. subr-x contains some extra hash-tables > functions already and I'm wondering how it should be dealt with without > implementing some functions twice if we were implementing a map.el > library. Should we keep hash-table functions in subr-x and simply alias > them in map.el or remove them from subr-x.el? That's a very minor issue, I think. Either way would work fine, Stefan ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Merging nth, aref, and elt. 2014-12-14 13:47 ` Stefan Monnier @ 2014-12-18 16:01 ` Artur Malabarba 2014-12-18 19:12 ` Stefan Monnier 0 siblings, 1 reply; 18+ messages in thread From: Artur Malabarba @ 2014-12-18 16:01 UTC (permalink / raw) To: Stefan Monnier Cc: Nicolas Petton, David Kastrup, Stephen J. Turnbull, emacs-devel I like the idea of having a library akin to seq.el, to unite hash-tables, alists, and perhaps even symbol properties. But that would have to be done by someone else, more familiar with these structures. As a starting point, I could patch `get' to work on hash tables and alists (thus ditching this patch on `elt'), if that's desirable. 2014-12-14 11:47 GMT-02:00 Stefan Monnier <monnier@iro.umontreal.ca>: >> That would be really nice. subr-x contains some extra hash-tables >> functions already and I'm wondering how it should be dealt with without >> implementing some functions twice if we were implementing a map.el >> library. Should we keep hash-table functions in subr-x and simply alias >> them in map.el or remove them from subr-x.el? > > That's a very minor issue, I think. Either way would work fine, > > > Stefan ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Merging nth, aref, and elt. 2014-12-18 16:01 ` Artur Malabarba @ 2014-12-18 19:12 ` Stefan Monnier 2014-12-19 1:37 ` Ted Zlatanov 0 siblings, 1 reply; 18+ messages in thread From: Stefan Monnier @ 2014-12-18 19:12 UTC (permalink / raw) To: Artur Malabarba Cc: Nicolas Petton, David Kastrup, Stephen J. Turnbull, emacs-devel > As a starting point, I could patch `get' to work on hash tables and > alists (thus ditching this patch on `elt'), if that's desirable. I think it's better to work directly on a new "seq.el for associative tables" (I suggested to call it "map.el", but if someone has a better idea, I'm not wedded to this name). Stefan ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Merging nth, aref, and elt. 2014-12-18 19:12 ` Stefan Monnier @ 2014-12-19 1:37 ` Ted Zlatanov 2015-01-11 13:58 ` Nicolas Petton 0 siblings, 1 reply; 18+ messages in thread From: Ted Zlatanov @ 2014-12-19 1:37 UTC (permalink / raw) To: emacs-devel On Thu, 18 Dec 2014 14:12:22 -0500 Stefan Monnier <monnier@iro.umontreal.ca> wrote: >> As a starting point, I could patch `get' to work on hash tables and >> alists (thus ditching this patch on `elt'), if that's desirable. SM> I think it's better to work directly on a new "seq.el for associative SM> tables" (I suggested to call it "map.el", but if someone has a better SM> idea, I'm not wedded to this name). I like map.el and it's nicely short. I don't think it's a problem there are many existing map* functions. Ted ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Merging nth, aref, and elt. 2014-12-19 1:37 ` Ted Zlatanov @ 2015-01-11 13:58 ` Nicolas Petton 2015-01-12 5:28 ` Stefan Monnier 0 siblings, 1 reply; 18+ messages in thread From: Nicolas Petton @ 2015-01-11 13:58 UTC (permalink / raw) To: emacs-devel Has someone started to work on a map.el library? If not, I could start something. Cheers, Nico Ted Zlatanov <tzz@lifelogs.com> writes: > On Thu, 18 Dec 2014 14:12:22 -0500 Stefan Monnier <monnier@iro.umontreal.ca> wrote: > >>> As a starting point, I could patch `get' to work on hash tables and >>> alists (thus ditching this patch on `elt'), if that's desirable. > > SM> I think it's better to work directly on a new "seq.el for associative > SM> tables" (I suggested to call it "map.el", but if someone has a better > SM> idea, I'm not wedded to this name). > > I like map.el and it's nicely short. I don't think it's a problem there > are many existing map* functions. > > Ted -- Nicolas Petton http://nicolas-petton.fr ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Merging nth, aref, and elt. 2015-01-11 13:58 ` Nicolas Petton @ 2015-01-12 5:28 ` Stefan Monnier 2015-01-12 9:29 ` Nicolas Petton 0 siblings, 1 reply; 18+ messages in thread From: Stefan Monnier @ 2015-01-12 5:28 UTC (permalink / raw) To: Nicolas Petton; +Cc: emacs-devel > Has someone started to work on a map.el library? I don't think so, or at least haven't heard about anyone doing so. > If not, I could start something. Sounds good, Stefan ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Merging nth, aref, and elt. 2015-01-12 5:28 ` Stefan Monnier @ 2015-01-12 9:29 ` Nicolas Petton 0 siblings, 0 replies; 18+ messages in thread From: Nicolas Petton @ 2015-01-12 9:29 UTC (permalink / raw) To: Stefan Monnier; +Cc: Nicolas Petton, emacs-devel Ok then! Nico Stefan Monnier <monnier@iro.umontreal.ca> writes: >> Has someone started to work on a map.el library? > > I don't think so, or at least haven't heard about anyone doing so. > >> If not, I could start something. > > Sounds good, > > > Stefan -- Nicolas Petton http://nicolas-petton.fr ^ permalink raw reply [flat|nested] 18+ messages in thread
end of thread, other threads:[~2015-01-12 9:29 UTC | newest] Thread overview: 18+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2014-10-29 21:40 Merging nth, aref, and elt Artur Malabarba 2014-10-30 1:52 ` Stefan Monnier 2014-10-30 9:51 ` David Kastrup 2014-10-30 13:30 ` Artur Malabarba 2014-10-31 19:13 ` Stefan Monnier 2014-10-31 19:56 ` Stefan Monnier 2014-11-01 1:08 ` Stephen J. Turnbull 2014-11-01 3:19 ` Stefan Monnier 2014-12-13 4:09 ` Artur Malabarba 2014-12-14 3:57 ` Stefan Monnier 2014-12-14 11:23 ` Nicolas Petton 2014-12-14 13:47 ` Stefan Monnier 2014-12-18 16:01 ` Artur Malabarba 2014-12-18 19:12 ` Stefan Monnier 2014-12-19 1:37 ` Ted Zlatanov 2015-01-11 13:58 ` Nicolas Petton 2015-01-12 5:28 ` Stefan Monnier 2015-01-12 9:29 ` Nicolas Petton
Code repositories for project(s) associated with this external index https://git.savannah.gnu.org/cgit/emacs.git https://git.savannah.gnu.org/cgit/emacs/org-mode.git This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.