Shouldn't records be sequences?

Shouldn't records be sequences?

[Štěpán Němec]

Records currently seem a bit weird: `aref', `cl-loop''s "across" clause
(which uses `aref'), `copy-sequence' support them; `substring' (which
does support vectors) and other sequence functions do not.

Shouldn't records become subtype of sequence and get better support from
related functionality?

(bug#40562 got me thinking about this)

-- 
Štěpán

Re: Shouldn't records be sequences?

[Štěpán Němec]

[There's also the thread starting at
<https://lists.gnu.org/archive/html/emacs-devel/2017-04/msg00190.html>
with various opinions on the matter, but as far as I can see it ends
without bringing any change to the half-way status quo]

-- 
Štěpán

Re: Shouldn't records be sequences?

[Stefan Monnier]

> Records currently seem a bit weird: `aref', `cl-loop''s "across" clause
> (which uses `aref'), `copy-sequence' support them; `substring' (which
> does support vectors) and other sequence functions do not.

My opinion is that records are not sequences, just like C's `structs`
and Java's objects are not sequences (e.g. it doesn't make much sense to
concatenate records or to take subsequences of them).  Some of our
builtin functions operating on sequences also work on records, but
that's only motivated by the need for backward compatibility with code
which used to expect `cl-defstruct` to use vectors instead of records.


        Stefan

Re: Shouldn't records be sequences?

[Clément Pit-Claudel]

On 12/04/2020 12.30, Stefan Monnier wrote:
> but that's only motivated by the need for backward compatibility with
> code which used to expect `cl-defstruct` to use vectors instead of
> records.

Isn't performance part of it too?  A recent example: I have a list of records that I display to users, using a custom sort order (a list of record fields).  It's convenient to be able to go from list of fields to list of array offsets once, and then use those offsets in the comparison function (this is similar to what I'd do with C structs).

Re: Shouldn't records be sequences?

[Štěpán Němec]

On Sun, 12 Apr 2020 12:30:26 -0400
Stefan Monnier wrote:

>> Records currently seem a bit weird: `aref', `cl-loop''s "across" clause
>> (which uses `aref'), `copy-sequence' support them; `substring' (which
>> does support vectors) and other sequence functions do not.
>
> My opinion is that records are not sequences, just like C's `structs`
> and Java's objects are not sequences (e.g. it doesn't make much sense to
> concatenate records or to take subsequences of them).  Some of our
> builtin functions operating on sequences also work on records, but
> that's only motivated by the need for backward compatibility with code
> which used to expect `cl-defstruct` to use vectors instead of records.

I think that makes sense, quite possibly more sense than the other way
("records are sequences"), but shouldn't the current state, where some
sequence functions work with records and some do not, and (info "(elisp)
Records") explicitly mentions `aref' and `copy-sequence', be improved in
some way?

IOW, if records really are "much like a vector" (to quote the manual
section), is there any reason not to make the other sequence functions
support them? Alternatively, if their being like a vector is only an
implementation detail, does it make sense to expose that in Lisp at all
and document it?

Thanks,

  Štěpán

Re: Shouldn't records be sequences?

[Stefan Monnier]

>> but that's only motivated by the need for backward compatibility with
>> code which used to expect `cl-defstruct` to use vectors instead of
>> records.
> Isn't performance part of it too?

It could be relevant, tho I can't remember it being a factor in practice.

> A recent example: I have a list of records that I display to users,
> using a custom sort order (a list of record fields).  It's convenient
> to be able to go from list of fields to list of array offsets once,
> and then use those offsets in the comparison function (this is similar
> to what I'd do with C structs).

Not sure how that relates to treating them as sequences.
We do want some way to work at the lower level (i.e. access the N'th
field), which is currently done with `aref` but could be done by
a `record-ref` instead.


        Stefan


PS: The clean equivalent in Elisp would be to use a list of
field-accessors instead of a list of fields.  This also saves you from
converting to a list of array offsets.  But (funcall accessor x) is
probably significantly slower than (aref x offset), indeed.  OTOH I can
imagine an implementation of Elisp where the cost is comparable
(because the `funcall` is cheap enough).

Re: Shouldn't records be sequences?

[Clément Pit-Claudel]

On 12/04/2020 13.23, Stefan Monnier wrote:
>> A recent example: I have a list of records that I display to users,
>> using a custom sort order (a list of record fields).  It's convenient
>> to be able to go from list of fields to list of array offsets once,
>> and then use those offsets in the comparison function (this is similar
>> to what I'd do with C structs).
> 
> Not sure how that relates to treating them as sequences.
> We do want some way to work at the lower level (i.e. access the N'th
> field), which is currently done with `aref` but could be done by
> a `record-ref` instead.

Depends what you mean by sequence, I guess.  I usually think of a sequence as anything having an 'nth', so once you have a record-ref that takes an offset and returns a value, you might as well call that seq-elt.

> PS: The clean equivalent in Elisp would be to use a list of
> field-accessors instead of a list of fields.  This also saves you from
> converting to a list of array offsets.  But (funcall accessor x) is
> probably significantly slower than (aref x offset), indeed.

That's the exact issue I ran into, yes.
(Well, and the fact that the existence of cl-struct-slot-offset makes it easy to get the offset of a field, and I couldn't find a corresponding primitive to get an accessor function).
Python solves this issue by having special "accessor" objects that are faster to call than the corresponding lambdas ("itemgetter")

Re: Shouldn't records be sequences?

[Stefan Monnier]

> IOW, if records really are "much like a vector" (to quote the manual
> section), is there any reason not to make the other sequence functions
> support them?

Mostly, the lack of a reason to add them?

> Alternatively, if their being like a vector is only an implementation
> detail, does it make sense to expose that in Lisp at all and
> document it?

We should probably document it less, indeed, or clarify that it's
a historical accident and code shouldn't rely on it.


        Stefan