Merging nth, aref, and elt.

Merging nth, aref, and elt.

[Artur Malabarba]

[-- 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 --]

Re: Merging nth, aref, and elt.

[Stefan Monnier]

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

Re: Merging nth, aref, and elt.

[David Kastrup]

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

Re: Merging nth, aref, and elt.

[Artur Malabarba]

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

Re: Merging nth, aref, and elt.

[Stefan Monnier]

> 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

Re: Merging nth, aref, and elt.

[Stefan Monnier]

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

Re: Merging nth, aref, and elt.

[Stephen J. Turnbull]

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.

Re: Merging nth, aref, and elt.

[Stefan Monnier]

> 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

Re: Merging nth, aref, and elt.

[Artur Malabarba]

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);
 }

Re: Merging nth, aref, and elt.

[Stefan Monnier]

> 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

Re: Merging nth, aref, and elt.

[Nicolas Petton]

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

Re: Merging nth, aref, and elt.

[Stefan Monnier]

> 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

Re: Merging nth, aref, and elt.

[Artur Malabarba]

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

Re: Merging nth, aref, and elt.

[Stefan Monnier]

> 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

Re: Merging nth, aref, and elt.

[Ted Zlatanov]

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

Re: Merging nth, aref, and elt.

[Nicolas Petton]

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

Re: Merging nth, aref, and elt.

[Stefan Monnier]

> 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

Re: Merging nth, aref, and elt.

[Nicolas Petton]

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