(n)reverse vs. length

(n)reverse vs. length

[Dmitry Antipov]

Should (n)reverse has the same semantics as length, i.e. accept
vectors and strings as well? IMHO this is the convenient and expected
behavior from the point of view of the elisp programmer.

Dmitry

Re: (n)reverse vs. length

[Stefan Monnier]

> Should (n)reverse has the same semantics as length, i.e. accept
> vectors and strings as well?

Good question.

> IMHO this is the convenient and expected behavior from the point of
> view of the elisp programmer.

Elisp is pretty lame and messy in this respect.
E.g. we have elt/aref/nth which operate on various subsets of sequences.
We have mapc/mapcar which apply to lists and arrays (and strings), but
mapcar returns a list in any case.

I think it would be OK to make `reverse' work on arrays and strings.
I definitely don't want `nreverse' working on strings (strings should
be immutable), but I guess making it work on arrays is fine.


        Stefan

Re: (n)reverse vs. length

[David Kastrup]

Stefan Monnier <monnier@IRO.UMontreal.CA> writes:

>> Should (n)reverse has the same semantics as length, i.e. accept
>> vectors and strings as well?
>
> Good question.
>
>> IMHO this is the convenient and expected behavior from the point of
>> view of the elisp programmer.
>
> Elisp is pretty lame and messy in this respect.
> E.g. we have elt/aref/nth which operate on various subsets of sequences.
> We have mapc/mapcar which apply to lists and arrays (and strings), but
> mapcar returns a list in any case.
>
> I think it would be OK to make `reverse' work on arrays and strings.
> I definitely don't want `nreverse' working on strings (strings should
> be immutable),

Doesn't aset work on strings?

-- 
David Kastrup

Re: (n)reverse vs. length

[Stefan Monnier]

>> strings should be immutable
> Doesn't aset work on strings?

Yes, I said "should be" not "are".


        Stefan

Re: (n)reverse vs. length

[Dmitry Antipov]

On 05/15/2014 05:45 AM, Stefan Monnier wrote:

>>> strings should be immutable
>> Doesn't aset work on strings?
>
> Yes, I said "should be" not "are".

Hm, what about an existing code which relies on aset'table strings? Questions
like http://lists.gnu.org/archive/html/emacs-devel/2014-04/msg00378.html shows
that treating string as an array of characters is a common practice (which is
"natural" for the people with C background). And, in case of large strings,
in-place reverse may save a lot of memory.

Dmitry

Re: (n)reverse vs. length

[David Kastrup]

Dmitry Antipov <dmantipov@yandex.ru> writes:

> On 05/15/2014 05:45 AM, Stefan Monnier wrote:
>
>>>> strings should be immutable
>>> Doesn't aset work on strings?
>>
>> Yes, I said "should be" not "are".
>
> Hm, what about an existing code which relies on aset'table strings? Questions
> like http://lists.gnu.org/archive/html/emacs-devel/2014-04/msg00378.html shows
> that treating string as an array of characters is a common practice (which is
> "natural" for the people with C background). And, in case of large strings,
> in-place reverse may save a lot of memory.

I am not sure there is a use case for in-place reverse of strings.  If
there is, the algorithm for multibyte characters would definitely
warrant writing in C as it is quite non-trivial.  Two characters of
buffer should suffice: just copy one character from each end to its
respective buffer, and then repeat copying and refilling the respective
one of the two buffers which has enough space to fit in the original
string.  Doing it in C would be O(n), doing it with aset instead would
be O(n^2).

-- 
David Kastrup

Re: (n)reverse vs. length

[Stefan Monnier]

> Hm, what about an existing code which relies on aset'table strings?

I recommend against it.  And I've been known to install changes in trunk
to make such code use arrays instead (or avoid `aset', depending on the
situation).

> Questions like
> http://lists.gnu.org/archive/html/emacs-devel/2014-04/msg00378.html
> shows that treating string as an array of characters is a common
> practice (which is "natural" for the people with C background).

I know.  And we should discourage that practice.

> And, in case of large strings, in-place reverse may save a lot
> of memory.

I can't think of any case where it can save a significant amount
of memory.


        Stefan