[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[VM] [XEMACS COMMIT] Be lazy converting markers to integers, bytecode_{a
From: |
Stephen J. Turnbull |
Subject: |
[VM] [XEMACS COMMIT] Be lazy converting markers to integers, bytecode_{arithcompare, arithop}(). |
Date: |
Mon, 16 Dec 2013 02:04:34 +0900 |
Aidan Kehoe writes:
> I would like to move to returning markers in #'max, #'min when all
> arguments are markers that point to the same buffer,
Are there efficiency implications to this?
What is the logic for returning markers (other than efficiency)?
Specifically, I would expect that most usages would be of the form
(goto-char (max m1 m2 m3))
or other inline calls, and I would consider
(setq last-marker (max m1 m2 m3))
to be a code smell whether you have an integer or marker result, and
would be rather suspicious of
(let ((last-marker (max m1 m2 m3))) ...)
> Note that a with number types build, before 3bfcdeb65578 , interpreted #'max
> and #'min already returned markers, and we haven’t had any problems with
> that.
I wouldn't expect to have a problem because I'd expect that any code
that actually behaves differently with markers and integers is buggy
anyway. ;-)
> See also the comments in the tests. It surprised me strongly that the
> markers weren’t preserved with changes that should have kept the same
> relative character count, but it’s a separate issue that needs separate
> investigation.
Yeah, that sucks. I would go farther than "surprising" and just say
that's a bug. But fixing that efficiently is probably not easy.