Hello everyone,
I found a JavaScript 2.0 engine writen in Lisp in Mozilla's CVS. There
is a piece of code:
(define-character-set '*white-space-or-line-terminator-char* '((#?0009
#?000D) #\space #?00A0 #?0085 (#?2000 #?200B) #?2028 #?2029 #?3000))
When I compile it, error happened, because #? isn't a defined
readmacro. I have tried cmucl, sbcl and clisp, all failed.
I think the #?0009 means the 9th char in ASCII, #\Tab, and #?000D means
\Return, but I can't use this method to Rewrite other #?s.
What should I do for this? Is Common Lisp have another macros to
reference those charsets?
Thanks.
In article <························@g49g2000cwa.googlegroups.com>,
"Binghe" <··············@gmail.com> wrote:
> Hello everyone,
>
> I found a JavaScript 2.0 engine writen in Lisp in Mozilla's CVS. There
> is a piece of code:
>
> (define-character-set '*white-space-or-line-terminator-char* '((#?0009
> #?000D) #\space #?00A0 #?0085 (#?2000 #?200B) #?2028 #?2029 #?3000))
>
> When I compile it, error happened, because #? isn't a defined
> readmacro. I have tried cmucl, sbcl and clisp, all failed.
>
> I think the #?0009 means the 9th char in ASCII, #\Tab, and #?000D means
> \Return, but I can't use this method to Rewrite other #?s.
>
> What should I do for this? Is Common Lisp have another macros to
> reference those charsets?
(defun sharp-question-reader (stream subchar arg)
(declare (ignore subchar arg))
(code-char (let ((*read-base* 16))
(read stream t nil t))))
(set-dispatch-macro-character #\# #\? #'sharp-question-reader)
--
Barry Margolin, ······@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
Thank you very much, but I still have problem:
CL-USER> #?2000
Type-error in KERNEL::OBJECT-NOT-TYPE-ERROR-HANDLER:
8192 is not of type (UNSIGNED-BYTE 8)
[Condition of type TYPE-ERROR]
Restarts:
0: [ABORT] Return to Top-Level.
Debug (type H for help)
(CODE-CHAR 1 8192)[:EXTERNAL]
Source:
; File: target:code/char.lisp
(DEFUN CODE-CHAR (CODE)
"Returns the character with the code CODE."
(DECLARE (TYPE CHAR-CODE CODE))
...)
0] 0
I think the core problem is that "Standard CL" doesn't support 16bit
characters, only 8bit char is supported.
If you look into these code, you'll find sth about 'char16'... maybe
allegro CL can compile it correctly but I can't test this. I just want
to find a solution to compile it with CMUCL.
From: Christophe Rhodes
Subject: Re: How to port this code into Standard Common Lisp?
Date:
Message-ID: <sq3bpcaae2.fsf@cam.ac.uk>
"Binghe" <··············@gmail.com> writes:
> Thank you very much, but I still have problem:
> CL-USER> #?2000
>
> Type-error in KERNEL::OBJECT-NOT-TYPE-ERROR-HANDLER:
> 8192 is not of type (UNSIGNED-BYTE 8)
> [Condition of type TYPE-ERROR]
>
> If you look into these code, you'll find sth about 'char16'... maybe
> allegro CL can compile it correctly but I can't test this. I just want
> to find a solution to compile it with CMUCL.
You can't have one. CMUCL does not support characters with codes
greater than 255. From where does the requirement to use CMUCL come?
Christophe
> You can't have one. CMUCL does not support characters with codes
> greater than 255. From where does the requirement to use CMUCL come?
I just like CMUCL:) Because It's faster and I't sources are
beautiful...
But I found CLISP can support 16bit char, so I'll try to use it,
thanks!
On Sun, 14 Aug 2005 07:15:31 -0700, Binghe wrote:
>> You can't have one. CMUCL does not support characters with codes
>> greater than 255. From where does the requirement to use CMUCL come?
>
> I just like CMUCL:) Because It's faster and I't sources are
> beautiful...
I think Christoph was trying to mildly push you towards SBCL
which also supports unicode [and might have source as pretty
as CMUCL :)
Cheers Ralf Mattes
> But I found CLISP can support 16bit char, so I'll try to use it,
> thanks!
Thanks, I really doesn't know sbcl can support this before your post:)
But I still have a question, if sbcl can support this, why not apply
sbcl's patch on cmucl?
Is it very diffault to make cmucl support this?
or maybe I should ask "Can cmucl support this by apply some pure lisp
patch on it's code?" (I thought that It should be easy for those CL
implemention which [partially] base on C code)
In article <························@g44g2000cwa.googlegroups.com>,
"Binghe" <··············@gmail.com> wrote:
> Thank you very much, but I still have problem:
> CL-USER> #?2000
>
> Type-error in KERNEL::OBJECT-NOT-TYPE-ERROR-HANDLER:
> 8192 is not of type (UNSIGNED-BYTE 8)
> [Condition of type TYPE-ERROR]
>
> Restarts:
> 0: [ABORT] Return to Top-Level.
>
> Debug (type H for help)
>
> (CODE-CHAR 1 8192)[:EXTERNAL]
> Source:
> ; File: target:code/char.lisp
> (DEFUN CODE-CHAR (CODE)
> "Returns the character with the code CODE."
> (DECLARE (TYPE CHAR-CODE CODE))
> ...)
> 0] 0
>
> I think the core problem is that "Standard CL" doesn't support 16bit
> characters, only 8bit char is supported.
The standard doesn't specify how characters are encoded. It doesn't
even require ASCII. It specifies a minimum set of characters that must
be supported, additional characters and their encodings are all
implementation-dependent. So if an implementation supports fewer than
256 characters, it certainly can limit the acceptable codes to 8 bits.
--
Barry Margolin, ······@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
From: Peter Seibel
Subject: Re: How to port this code into Standard Common Lisp?
Date:
Message-ID: <m2ek8xkry6.fsf@gigamonkeys.com>
"Binghe" <··············@gmail.com> writes:
> Hello everyone,
>
> I found a JavaScript 2.0 engine writen in Lisp in Mozilla's CVS. There
> is a piece of code:
Wow. Can you give a more precise pointer to this code? I'm sure some
folks here (such as me) would be curious to see it. Especially the
folks at Franz who are supposed to be mentoring a Summer of Lisp
volunteer who's going to put a Lisp into Mozilla. Or some such.
-Peter
--
Peter Seibel * ·····@gigamonkeys.com
Gigamonkeys Consulting * http://www.gigamonkeys.com/
Practical Common Lisp * http://www.gigamonkeys.com/book/
From: Edi Weitz
Subject: Re: How to port this code into Standard Common Lisp?
Date:
Message-ID: <uwtmorggh.fsf@agharta.de>
On Sun, 14 Aug 2005 05:28:35 GMT, Peter Seibel <·····@gigamonkeys.com> wrote:
> Wow. Can you give a more precise pointer to this code?
<http://lxr.mozilla.org/mozilla/source/js2/semantics/>
"js/semantics contains experimental code used to generate LR(1) and
LALR(1) grammars for JavaScript as well as compile and check formal
semantics for JavaScript. The semantics can be executed directly
or printed into either HTML or Microsoft Word RTF formats.
This code is written in standard Common Lisp. It's been used under
Macintosh Common Lisp 4.0, and Allegro Common Lisp 5.0.1 for
Windows, but should also work under other Common Lisp
implementations."
> I'm sure some folks here (such as me) would be curious to see
> it. Especially the folks at Franz who are supposed to be mentoring a
> Summer of Lisp volunteer who's going to put a Lisp into Mozilla. Or
> some such.
I don't think this'll help them very much, but who knows? Anyway,
it's interesting from a historical perspective.
Cheers,
Edi.
--
Lisp is not dead, it just smells funny.
Real email: (replace (subseq ·········@agharta.de" 5) "edi")
"Binghe" <··············@gmail.com> writes:
> Hello everyone,
>
> I found a JavaScript 2.0 engine writen in Lisp in Mozilla's CVS. There
> is a piece of code:
>
> (define-character-set '*white-space-or-line-terminator-char* '((#?0009
> #?000D) #\space #?00A0 #?0085 (#?2000 #?200B) #?2028 #?2029 #?3000))
>
> When I compile it, error happened, because #? isn't a defined
> readmacro. I have tried cmucl, sbcl and clisp, all failed.
>
> I think the #?0009 means the 9th char in ASCII, #\Tab, and #?000D means
> \Return, but I can't use this method to Rewrite other #?s.
>
> What should I do for this? Is Common Lisp have another macros to
> reference those charsets?
Locate in the source the reader macro
(grep for: set-dispatch-macro-character)
and extract it along.
--
__Pascal Bourguignon__ http://www.informatimago.com/
Our enemies are innovative and resourceful, and so are we. They never
stop thinking about new ways to harm our country and our people, and
neither do we. -- Georges W. Bush
OK, This problem has been solved by sbcl and clisp, since there's a
piece of code in another source file Utilities.lisp:
;;; READER SYNTAX
; Define #?num to produce a character with code given by the
hexadecimal number num.
; (This is a portable extension; the #\u syntax installed above does
the same thing
; but is not portable.)
(set-dispatch-macro-character
#\# #\?
#'(lambda (stream subchar arg)
(declare (ignore subchar arg))
(let ((*read-base* 16))
(code-char (read stream t nil t)))))
So the problem is myself, if I compile and load this file first, and do
not use cmucl, those problem will not happen.
And, there's another problem comes with sbcl, this code can be compiled
by both cmucl and clisp, but not sbcl:
(defstruct (type (:constructor allocate-type (serial-number kind tag
parameters =-name /=-name)) (:predicate type?))
(name nil :type symbol) ;This type's name;
nil if this type is anonymous
(serial-number nil :type integer) ;This type's unique
serial number
(kind nil :type typekind :read-only t) ;This type's kind
(tag nil :read-only t) ;This type's tag;
ordered list of tags for bit-set;
; ; set of included
subsets represented as a sorted list of integers for restricted-set
(parameters nil :type list :read-only t) ;List of parameter
types (either types or symbols if forward-referenced) describing a
compound type
(=-name nil :type symbol) ;Lazily computed
name of a function that compares two values of this type for equality;
nil if not known yet
(/=-name nil :type symbol) ;Name of a function
that complements = or nil if none
(order-alist nil) ;Either nil or an
association list ((< . t<) (> . t>) (<= . t<=) (>= . t>=)) where the
t's are order functions for this type
(range-set-encode nil :type symbol) ;Either nil or the
name of a function that converts an instance of this type to an integer
for storage in a range-set
(range-set-decode nil :type symbol)) ;Either nil or the
name of a function that reverses the range-set-encode conversion
I know that I must unlock the common-lisp package, but it still fail in
sbcl!
Can any one tell me that It's a problem of the code or sbcl?
Thanks again.
<··············@gmail.com> wrote:
> (defstruct (type (:constructor allocate-type (serial-number kind tag
[...]
> I know that I must unlock the common-lisp package, but it still fail in
> sbcl!
No, you shouldn't be unlocking the package. The package locks are
there to protect you from just this sort of situation.
> Can any one tell me that It's a problem of the code or sbcl?
It's a problem in the code. Using a symbol from the COMMON-LISP
package as the name of a structure is undefined behaviour. You should
either shadow the symbol TYPE in your package or rename the struct:
(defstruct (mytype (:conc-name "type-")
(:constructor allocate-type (serial-number kind tag
In both cases you might need to make other changes to the code too.
--
Juho Snellman
"Premature profiling is the root of all evil."
Juho Snellman wrote:
> <··············@gmail.com> wrote:
>
>>(defstruct (type (:constructor allocate-type (serial-number kind tag
>
> [...]
>
>>I know that I must unlock the common-lisp package, but it still fail in
>>sbcl!
>
>
> No, you shouldn't be unlocking the package. The package locks are
> there to protect you from just this sort of situation.
>
>
>>Can any one tell me that It's a problem of the code or sbcl?
>
>
> It's a problem in the code. Using a symbol from the COMMON-LISP
> package as the name of a structure is undefined behaviour.
Well, TYPE does not have any "definitions" associated to it. Does (or
should) the restriction apply nevertheless?
--
Marco
<·······@cs.nyu.edu> wrote:
>> It's a problem in the code. Using a symbol from the COMMON-LISP
>> package as the name of a structure is undefined behaviour.
>
> Well, TYPE does not have any "definitions" associated to it. Does (or
> should) the restriction apply nevertheless?
Yes, to both "does" and "should". For "does", see
<http://www.lisp.org/HyperSpec/Body/sec_11-1-2-1-2.html>. For
"should"... Trying to define a structure named TYPE with the
COMMON-LISP package unlocked allegedly broke the compiler. Seems like
a pretty good argument for package locks.
[ By the way, TYPE certainly has a "definition" associated with it; it's
a declaration identifier. According to the standard, defining a type
that has the same name as a declaration (or vice versa) must signal
an error. ]
--
Juho Snellman
"Premature profiling is the root of all evil."
Juho Snellman wrote:
> <·······@cs.nyu.edu> wrote:
>
>>>It's a problem in the code. Using a symbol from the COMMON-LISP
>>>package as the name of a structure is undefined behaviour.
>>
>>Well, TYPE does not have any "definitions" associated to it. Does (or
>>should) the restriction apply nevertheless?
>
>
> Yes, to both "does" and "should". For "does", see
> <http://www.lisp.org/HyperSpec/Body/sec_11-1-2-1-2.html>. For
> "should"... Trying to define a structure named TYPE with the
> COMMON-LISP package unlocked allegedly broke the compiler. Seems like
> a pretty good argument for package locks.
Yep. I went to the CLHS and there it was.
Looks like a good argument for package lock indeed.
Cheers
--
Marco
From: Christophe Rhodes
Subject: Re: How to port this code into Standard Common Lisp?
Date:
Message-ID: <sqhddrgptz.fsf@cam.ac.uk>
Marco Antoniotti <·······@cs.nyu.edu> writes:
> Well, TYPE does not have any "definitions" associated to it. Does (or
> should) the restriction apply nevertheless?
Yes.
Christophe
Christophe Rhodes wrote:
> Marco Antoniotti <·······@cs.nyu.edu> writes:
>
>
>>Well, TYPE does not have any "definitions" associated to it. Does (or
>>should) the restriction apply nevertheless?
>
>
> Yes.
Would that be because of CLHS 11.1.2.1.1?
Cheers
--
Marco
From: Christophe Rhodes
Subject: Re: How to port this code into Standard Common Lisp?
Date:
Message-ID: <sqd5ofgp9d.fsf@cam.ac.uk>
Marco Antoniotti <·······@cs.nyu.edu> writes:
> Christophe Rhodes wrote:
>> Marco Antoniotti <·······@cs.nyu.edu> writes:
>>
>>> Well, TYPE does not have any "definitions" associated to it. Does
>>> (or should) the restriction apply nevertheless?
>> Yes.
>
> Would that be because of CLHS 11.1.2.1.1?
No.
(Those are restrictions on implementations.)
Christophe
Christophe Rhodes wrote:
> Marco Antoniotti <·······@cs.nyu.edu> writes:
>
>
>>Christophe Rhodes wrote:
>>
>>>Marco Antoniotti <·······@cs.nyu.edu> writes:
>>>
>>>
>>>>Well, TYPE does not have any "definitions" associated to it. Does
>>>>(or should) the restriction apply nevertheless?
>>>
>>>Yes.
>>
>>Would that be because of CLHS 11.1.2.1.1?
>
>
> No.
>
> (Those are restrictions on implementations.)
Then it should be because of the next section, shouldn't it?
Cheers
--
Marco