Custom Query (1030 matches)

And (code-char #xFFFF) returns NIL too.

Unicode Corrigendum 9 ​http://www.unicode.org/versions/corrigendum9.html explains that "noncharacters" should not be rejected. They are the codepoints U+FFFE U+FFFF U+1FFFE U+1FFFF ... up to U+10FFFE and U+10FFFF, plus the codepoints U+FDD0..U+FDEF.

It states "the definition of noncharacter in the standard has led some implementers to interpret any presence of a noncharacter code point in a Unicode string as causing that string to be ill-formed, and thereby has led to inappropriate over-rejection"

And later: noncharacters "are not illegal in interchange nor do they cause ill-formed Unicode text".

Being able to represent codepoint U+FFFE is also important, because when found in a file or stream it is a strong diagnostic indication that the Unicode text was parsed incorrectly - typically the wrong UTF-16 endianity has been used. Replacing it with NIL is both non-standard (see Corrigendum 9 above) and makes troubleshooting more difficult.

For these reasons, I am asking to change CODE-CHAR such that (code-char #xFFFE) returns #\U+FFFE and (code-char #\U+FFFF) returns #\U+FFFF

A function defined with MACROLET that is declaimed as INLINE doesn't seem to actually inline at the call site.

If you manually write the definition out without the MACROLET, inlining works as expected.

I have tried locally declaring the function as INLINE at the call site, and I have also tried doing a DECLAIM INLINE outside of the MACROLET, all to no avail.

See the interactions below to reproduce.

File def.lisp

(defpackage :foo
  (:use :cl)
  (:export fun))

(in-package :foo)

(macrolet ((def (name op)
             `(progn
                (declaim (inline ,name))
                (defun ,name (a b)
                  (,op a b)))))
  (def fun +))

File use.lisp

(in-package :cl-user)

(defun bar (a b)
  (declare (optimize speed (safety 0) (debug 0) (space 0)))
  (foo:fun a (* a b)))

REPL interaction (note the line marked with !!!!...!!)

CL-USER> (lisp-implementation-type)
"Clozure Common Lisp"
CL-USER> (lisp-implementation-version)
"Version 1.11-dev-r16361M-trunk  (LinuxARM32)"
CL-USER> (load (compile-file "def.lisp"))
#P"def.lafsl"
CL-USER> (load (compile-file "use.lisp"))
#P"use.lafsl"
CL-USER> (disassemble #'bar)
;; Source: "use.lisp.newest":23-122
  (mov imm0 (:$ 19))
  (stmdb (:! sp) (imm0 vsp fn lr))
  (mov fn temp2)
  (stmdb (:! vsp) (arg_z arg_y))        ;[12]

;;; (* a b)
  (sploadlr .SPbuiltin-times)           ;[16]
  (blx lr)

;;; (foo:fun a (* a b))
  (ldr arg_y (:@ vsp (:$ 4)))           ;[24]
  (mov nargs (:$ 8))
  (ldr temp1 (:@ fn 'FOO:FUN))          ; *** !!!!!!!!!!!!!!
  (ldmia (:! sp) (imm0 vsp fn lr))
  (ldr temp2 (:@ temp1 (:$ 6)))         ;[40]
  (ldr pc (:@ temp2 (:$ -2)))

;;; #<no source text>
NIL

People have reported that it can be prohibitively slow to call SET-MACRO-CHARACTER on all potential Unicode characters.

I'm not surprised by this, but I'm not sure that there's a good reason to make it impractical for someone who wants to do this to do so, either.

changing the data structures that CCL uses to associate characters with functions can affect things like SET-SYNTAX-FROM-CHAR and COPY-READTABLE as well as SET-MACRO-CHARACTER and (poossibly) SET-DISPATCH-MACRO-CHARACTER.