Re: Java identifiers (was: languages with full unicode support)



David Hopwood wrote:

[quotes reordered]

Note that I am not defending in any way the complexity of this
definition; there's
clearly no excuse for it (or for the "ignorable" documentation bug). The
language
spec should have been defined directly in terms of the Unicode General
Categories,
and then the API in terms of the language spec. They way it is done now is
completely backwards.

Noted and agreed. The rest of this is just nit-picking.

By the way, I admire your patience and dedication in following through all the
hoops...


And no, I don't think Java's approach -- where there /is no defined set
of
allowed identifier characters/ -- makes any sense at all :-(

# A "Java letter" is a character for which the method
# Character.isJavaIdentifierStart(int) returns true. A "Java
letter-or-digit"
# is a character for which the method Character.isJavaIdentifierPart(int)
# returns true.

Yes, but I don't agree that that amounts to a normative definition. If
Character.isJavaIdentifierPart(int), and more pivotally, Character.getType(),
/has/ a normative specification at all (which I doubt) then it is clearly
intended to vary over time to reflect changes to the Unicode standard. There
would be little sense in the JLS punting to the definition (?!) of that method
if change were not anticipated (and it's not as if the JLS author's are prone
to taking short-cuts ;-)

But Character is only "/based on/ the Unicode Standard, version 4.0" (my
emphasis) -- which hardly (to my mind) constitutes either a specification (how
does one write a conforming recogniser for Java identifiers in another language
?), nor a guarantee of stability in future releases of the platform (even up
to dot-dot releases).

-- chris



.



Relevant Pages

  • Re: CLtL2 copyright question
    ... lot more conservative about what I'm willing to say in a casual forum. ... doesn't match the CL spec in semantics. ... personal description of a language that isn't even the one you could ... Common Lisp needs a publicly-modifiable specification for many reasons, of which here are a few examples. ...
    (comp.lang.lisp)
  • Re: Test first as specification
    ... > I'm not sure I understand the spec. ... Does it specify a language for which ... It is cheating: because one not-tests specification ... Dmitry A. Kazakov ...
    (comp.object)
  • Re: File.lastModified *extremely* slow ?
    ... >> the spec. ... part of the standard platform, and that the JVM could therefore assume anything ... java.lang.Class (if only because it isn't possible to create a conforming JVM ... in their licensing, IIRC, both the language it uses, and the actual ...
    (comp.lang.java.programmer)
  • Re: Test first as specification
    ... I'm not sure I understand the spec. ... Does it specify a language for which ... the only valid input string is an infinite string of a's? ... > (it is a hard mathematical fact) that there is no general ...
    (comp.object)
  • Re: singleton vs static
    ... > to be independent of the language of implementation, ... > spec in English, then derive the tests from the spec. ... > spec and a portable test harness. ... Daniel Parker ...
    (comp.object)