bug#9653: 24.0.50; `ucs-names' - Why all of the ("" . XXX) entries?

[Kenichi Handa <handa@m17n.org>]

In article <jwvd3eep5vo.fsf-monnier+emacs@gnu.org>, Stefan Monnier <monnier@iro.umontreal.ca> writes:
> >     * For miscellaneous properties which take strings as
> >       values, such as the Unicode Name property, the default
> >       value is a null string.
> >                ^^^^^^^^^^^^^

> I'm not opposed to this change, but your answer surprises me:
> - we don't have to follow any standard.

But, it is better to follow a standard, especially an
important one as Unicode.

> - even less so when it talks about internal APIs rather than about
>   externally-visible behavior.

I think that UCD is talking about external visible
behaviour.  Unicode says that all characters have `Name'
property and each value is a string.  So, when you ask a
name of a specific character, you should always get a string
value.

> - "null string" can mean nil just as well as it can mean "".

But, as I wrote, nil usually means
no-value/not-specified/unassigned/unknown, which is
different from the explicit "".

>   They actually behave quite similarly: length/concat/mapcar treat them
>   the same, aref signals an error in both cases, ...

Similar but different.  I think the difference is bigger.
insert/string-match/search-forward/etc. signal an error on
nil argument.

And these two signals the different error; wrong-type-argument
vs. args-out-of-range.
  (aref nil 1)
  (aref "" 1)

> So was there some other motivation (e.g. simpler implementation?

No.

> Simpler code somewhere else?)?

Yes, hypothetically.  You can safely write, for instance,
  (search-forward (get-char-code-property CHAR 'name) ...)
or
  (insert (get-char-code-property CHAR 'name) ...)
without checking the return value.

> If not (i.e. all things being equal) I'd
> prefer to use nil which is ever so slightly closer to usual Elisp
> practice,

Really?  I've thought nil and "" are rather different object
in Elisp.  In a char-table, (aset CHAR-TABLE CHAR nil)
results in that (aref CHAR-TABLE CHAR) returns the default
value which may not be nil.

> and matches the Emacs-23 behavior.

I'm sorry for this incomaptible change.  As I wrote before,
when I first implemented UCD in Emacs, the Unicode was not
clear about the property value of a character not explicitly
listed in the database file.  So, at that time, I simply
selected nil as the default value.  But, recently I found
that the default value is clearly defined in the recent
versions of Unicode.

So, if you the emacs maintainer thinks that the backward
compatibility is more important, I don't oppose to change
the default value back to nil.

---
Kenichi Handa
handa@m17n.org