[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gcl-devel] Re: possible lisp reader enhancement/modification
From: |
Matt Kaufmann |
Subject: |
Re: [Gcl-devel] Re: possible lisp reader enhancement/modification |
Date: |
Fri, 11 Jul 2003 22:02:20 -0500 |
Hi, Camm --
OK, it worked! Thanks so much for doing this. I was surprised actually to
find that Allegro CL outperformed GCL in my test application, given that I've
done lots of other tests where they seem to perform comparably (in fact GCL has
had the edge).
Allegro dynamic runtime:
4794.130u 26.690s 1:20:49.38 99.4% 0+0k 0+0io 78483pf+0w
Allegro developer image
5349.650u 34.900s 1:30:36.18 99.0% 0+0k 0+0io 96292pf+0w
GCL
12412.970u 42.110s 3:27:52.93 99.8% 0+0k 0+0io 89326pf+0w
I wonder if there's a way to speed things up. We already do quite a bit of
proclaiming so maybe the next thing to try would be to increase default
allocations. In case it's relevant, this was an unusually large application --
we had to increase MAX_PAGES by a factor of two -- I think it was by running
configure with '--enable-maxpage=64*1024' -- in order to avoid running out of
space. I think that's the first time I've had to do that, at least in recent
years.
If you have any ideas for speeding up GCL, I'd be interested. But please don't
go through any trouble unless you're interested in exploring this further.
I'll be away until Thursday night, anyhow.
>> In general, it would help me if you had a small
>> testfile indicating the expected behavior, as there are a number of
>> precedence assumptions in putting this together with which I am a bit
>> unfamiliar.
The following file tests some or all of the functionality that was an issue for
me, but I don't claim that it's complete. (In particular, I haven't much used
":" instead of "::" except for the keyword package, so I haven't addressed it.)
============================================================
(in-package "USER")
(setq xxx 17)
(make-package "FOO" :use nil)
(or (and (eql xxx 17)
(equal (find-package "USER") (symbol-package 'ab)))
(error "Error #1"))
FOO::(user::setq yyy 3)
(or (and (eql xxx 17)
(equal (find-package "USER") (symbol-package 'ab)))
(error "Error #2"))
(or (and (eql foo::yyy 3)
(equal (find-package "FOO") (symbol-package 'foo::yyy)))
(error "Error #3"))
(or (equal FOO:: (user::quote (a :b user:: c d user::
e))
'(foo::a :b
c ; need user::c if not in "USER" package
foo::d user::e))
(error "Error #4"))
============================================================
Thanks!
-- Matt
cc: address@hidden, address@hidden, address@hidden,
address@hidden
From: "Camm Maguire" <address@hidden>
Date: 10 Jul 2003 21:24:12 -0400
User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2
X-WSS-ID: 1310CE473643692-01-01
Content-Type: text/plain;
charset=us-ascii
Hi Matt! Take six. In general, it would help me if you had a small
testfile indicating the expected behavior, as there are a number of
precedence assumptions in putting this together with which I am a bit
unfamiliar. Apparently you want the keyword package implied in ':p to
override the outside package as 'user::p would inside a list. This
should accomplish that.
Please let me know,
Take care,
=============================================================================
diff -u -r1.14 read.d
--- read.d 26 Feb 2003 22:21:37 -0000 1.14
+++ read.d 11 Jul 2003 01:19:14 -0000
@@ -392,6 +392,11 @@
Read_object(in) reads an object from stream in.
This routine corresponds to COMMON Lisp function READ.
*/
+
+/* FIXME What should this be? Apparently no reliable way to use value stack
*/
+#define MAX_PACKAGE_STACK 1024
+static object P0[MAX_PACKAGE_STACK],*PP0=P0,LP;
+
object
read_object(in)
object in;
@@ -428,6 +433,19 @@
});
a = cat(c);
} while (a == cat_whitespace);
+ if (c->ch.ch_code == '(') { /* Loose package extension */
+ LP=LP || PP0==P0 ? LP : PP0[-1]; /* push loose packages into nested
lists */
+ if (LP) {
+ if (PP0-P0>=MAX_PACKAGE_STACK)
+ FEerror("Too many nested package specifiers",0);
+ *PP0++=LP;
+ LP=NULL;
+ }
+ } else if (LP)
+ FEerror("Loose package prefix must be followed by a list",0);
+ if (c->ch.ch_code==')' && PP0>P0) PP0--; /* regardless of error
behavior,
+ will pop stack to beginning
as parens
+ must match before the
reader starts */
delimiting_char = vs_head;
if (delimiting_char != OBJNULL && c == delimiting_char) {
delimiting_char = OBJNULL;
@@ -499,8 +517,15 @@
token_buffer[(tok_leng++,length++)] =
char_code(c);
}
goto K;
- } else if (a == cat_whitespace || a == cat_terminating)
+ } else if (a == cat_terminating) {
break;
+ } else if (a == cat_whitespace) {
+ /* skip all whitespace after trailing colon */
+ if (colon+colon_type==length)
+ goto K;
+ else
+ break;
+ }
else if ('a' <= char_code(c) && char_code(c) <= 'z')
c = code_char(char_code(c) - ('a' - 'A'));
else if (char_code(c) == ':') {
@@ -587,6 +612,15 @@
token->st.st_fillp = length - (colon + 2);
} else
p = current_package();
+ /* loose package is an empty token following a non-beginning
+ colon with no escape, to allow for ||*/
+ if (!token->st.st_fillp && colon && !escape_flag) {
+ LP=p;
+ goto BEGIN;
+ }
+ /* unless package specified for this symbol, use loose package if
present */
+ if (PP0>P0 && !colon_type)
+ p=PP0[-1];
vs_push(p);
x = intern(token, p);
vs_push(x);
=============================================================================
"Matt Kaufmann" <address@hidden> writes:
> Thanks, Camm. Sorry about our mistake before. I ran my test again and
this
> time I got the following problem (probably because I got past the previous
> failure point):
>
> >'user::(a :b)
>
> (A B)
>
> >
>
> I believe that we should have gotten (A :B).
>
> Thanks --
> -- Matt
> cc: address@hidden, address@hidden, address@hidden
> From: "Camm Maguire" <address@hidden>
> Date: 10 Jul 2003 18:31:27 -0400
> User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2
> X-WSS-ID: 131336C53611643-01-01
> Content-Type: text/plain;
> charset=us-ascii
>
> Greetings! Here is the 'take five' I wrote about a while ago. Only
> difference here is that whitespace between trailing colons and symbols
> are also skipped over.
>
> Please test and report.
>
> Take care,
>
=============================================================================
> diff -u -r1.14 read.d
> --- read.d 26 Feb 2003 22:21:37 -0000 1.14
> +++ read.d 10 Jul 2003 22:28:16 -0000
> @@ -392,6 +392,11 @@
> Read_object(in) reads an object from stream in.
> This routine corresponds to COMMON Lisp function READ.
> */
> +
> +/* FIXME What should this be? Apparently no reliable way to use value
stack */
> +#define MAX_PACKAGE_STACK 1024
> +static object P0[MAX_PACKAGE_STACK],*PP0=P0,LP;
> +
> object
> read_object(in)
> object in;
> @@ -428,6 +433,19 @@
> });
> a = cat(c);
> } while (a == cat_whitespace);
> + if (c->ch.ch_code == '(') { /* Loose package extension */
> + LP=LP || PP0==P0 ? LP : PP0[-1]; /* push loose packages into
nested lists */
> + if (LP) {
> + if (PP0-P0>=MAX_PACKAGE_STACK)
> + FEerror("Too many nested package specifiers",0);
> + *PP0++=LP;
> + LP=NULL;
> + }
> + } else if (LP)
> + FEerror("Loose package prefix must be followed by a
list",0);
> + if (c->ch.ch_code==')' && PP0>P0) PP0--; /* regardless of error
behavior,
> + will pop stack to
beginning as parens
> + must match before
the reader starts */
> delimiting_char = vs_head;
> if (delimiting_char != OBJNULL && c == delimiting_char) {
> delimiting_char = OBJNULL;
> @@ -499,8 +517,15 @@
> token_buffer[(tok_leng++,length++)] =
char_code(c);
> }
> goto K;
> - } else if (a == cat_whitespace || a == cat_terminating)
> + } else if (a == cat_terminating) {
> break;
> + } else if (a == cat_whitespace) {
> + /* skip all whitespace after trailing colon */
> + if (colon+colon_type==length)
> + goto K;
> + else
> + break;
> + }
> else if ('a' <= char_code(c) && char_code(c) <= 'z')
> c = code_char(char_code(c) - ('a' - 'A'));
> else if (char_code(c) == ':') {
> @@ -587,6 +612,15 @@
> token->st.st_fillp = length - (colon + 2);
> } else
> p = current_package();
> + /* loose package is an empty token following a non-beginning
> + colon with no escape, to allow for ||*/
> + if (!token->st.st_fillp && colon && !escape_flag) {
> + LP=p;
> + goto BEGIN;
> + }
> + /* unless package specified for this symbol, use loose package
if present */
> + if (PP0>P0 && !colon)
> + p=PP0[-1];
> vs_push(p);
> x = intern(token, p);
> vs_push(x);
>
=============================================================================
> >(setq xxx 17)
>
>
> 17
>
> >(make-package "FOO" :use nil)
>
>
> #<"FOO" package>
>
> >xxx
>
>
> 17
>
> >FOO::(user::setq yyy 3)
>
>
> 3
>
> >xxx
>
>
> 17
>
> >'xxx
>
>
> XXX
>
> >'lisp:: a
>
>
> LISP::A
>
> >q
>
>
> Error: The variable Q is unbound.
> Fast links are on: do (si::use-fast-links nil) for debugging
> Error signalled by EVAL.
> Broken at EVAL. Type :H for Help.
> >>'lisp::a
>
>
> LISP::A
> >>a
>
>
> Error: The variable A is unbound.
> Fast links are on: do (si::use-fast-links nil) for debugging
> Error signalled by EVALHOOK.
> Backtrace: system:universal-error-handler > EVALHOOK
>
> Broken at EVAL.
> >>`a
>
>
> A
> >>'lisp::(a b user::c)
>
>
> (LISP::A LISP::B C)
> >>'lisp:: (a b user::c)
>
>
> (LISP::A LISP::B C)
> >>'lisp::
>
> (a b user::c)
>
>
> (LISP::A LISP::B C)
> >>(quote lisp::(a b user::c))
>
>
> (LISP::A LISP::B C)
> >>(quote lisp::
>
> (a b user::c))
>
>
> (LISP::A LISP::B C)
> >>(quote (q lisp::(a b si::c d) e))
>
>
> (Q (LISP::A LISP::B SYSTEM::C LISP::D) E)
> >>(quote (q lisp::(a b si::c . . d) e))
>
>
> Error: Two dots appeared consecutively.
> Fast links are on: do (si::use-fast-links nil) for debugging
> Error signalled by SYSTEM:UNIVERSAL-ERROR-HANDLER.
> Backtrace: system:universal-error-handler
>
> Broken at EVAL.
> >>
> Error: The variable LISP::D is unbound.
> Fast links are on: do (si::use-fast-links nil) for debugging
> Error signalled by EVALHOOK.
> Backtrace: system:universal-error-handler > EVALHOOK
>
> Broken at EVAL.
> >>
> Error: The variable E is unbound.
> Fast links are on: do (si::use-fast-links nil) for debugging
> Error signalled by EVALHOOK.
> Backtrace: system:universal-error-handler > EVALHOOK
>
> Broken at EVAL.
> >>(quote (q lisp::(a b si::c . . d) e))
>
>
> Error: Two dots appeared consecutively.
> Fast links are on: do (si::use-fast-links nil) for debugging
> Error signalled by SYSTEM:UNIVERSAL-ERROR-HANDLER.
> Backtrace: system:universal-error-handler
>
> Broken at EVAL.
> >>
> Error: The variable LISP::D is unbound.
> Fast links are on: do (si::use-fast-links nil) for debugging
> Error signalled by EVALHOOK.
> Backtrace: system:universal-error-handler > EVALHOOK
>
> Broken at EVAL.
> >>
> Error: The variable E is unbound.
> Fast links are on: do (si::use-fast-links nil) for debugging
> Error signalled by EVALHOOK.
> Backtrace: system:universal-error-handler > EVALHOOK
>
> Broken at EVAL.
> >>:q
>
>
> Top level.
> >(quote (q lisp::(a b si::c d) e))
>
>
> (Q (LISP::A LISP::B SYSTEM::C LISP::D) E)
>
> >(quote (q lisp::(a b si::c . . d) e))
>
>
> Error: Two dots appeared consecutively.
> Fast links are on: do (si::use-fast-links nil) for debugging
> Error signalled by READ.
> Broken at READ. Type :H for Help.
> >>
> Error: The variable LISP::D is unbound.
> Fast links are on: do (si::use-fast-links nil) for debugging
> Error signalled by EVALHOOK.
> Backtrace: system:universal-error-handler > EVALHOOK
>
> Broken at READ.
> >>
> Error: The variable E is unbound.
> Fast links are on: do (si::use-fast-links nil) for debugging
> Error signalled by EVALHOOK.
> Backtrace: system:universal-error-handler > EVALHOOK
>
> Broken at READ.
> >>:q
>
>
> Top level.
> >'(q lisp::(a b (c d) e) f)
>
>
> (Q (LISP::A LISP::B (LISP::C LISP::D) LISP::E) F)
>
> >'(q lisp::(a b si::(c d) e) f)
>
>
> (Q (LISP::A LISP::B (SYSTEM::C SYSTEM::D) LISP::E) F)
>
> >'(q lisp::(a b si::(c user::d) e) f)
>
>
> (Q (LISP::A LISP::B (SYSTEM::C D) LISP::E) F)
>
> >'(q lisp::(a b si::(c foo::d) e) f)
>
>
> (Q (LISP::A LISP::B (SYSTEM::C FOO::D) LISP::E) F)
>
> >(by)
>
=============================================================================
>
>
> "Matt Kaufmann" <address@hidden> writes:
>
> > Hi, Camm --
> >
> > Thanks for your "Take four". That helped, but there still appears to
be a
> > problem: after a package prefix is read, we continue to read into
that package
> > outside the scope of that prefix. Here is an example.
> >
> > GCL (GNU Common Lisp) (2.5.3) Thu Jul 10 09:07:22 CDT 2003
> > Licensed under GNU Library General Public License
> > Dedicated to the memory of W. Schelter
> >
> > Use (help) to get some basic information on how to use GCL.
> >
> > >(setq xxx 17)
> >
> > 17
> >
> > >(make-package "FOO" :use nil)
> >
> > #<"FOO" package>
> >
> > >xxx
> >
> > 17
> >
> > >FOO::(user::setq yyy 3)
> >
> > 3
> >
> > >xxx
> >
> > Error: The variable FOO::XXX is unbound.
> > Fast links are on: do (si::use-fast-links nil) for debugging
> > Error signalled by EVAL.
> > Broken at EVAL. Type :H for Help.
> > >>:q
> >
> > Top level.
> > >'xxx
> >
> > FOO::XXX
> >
> > >
> >
> > -- Matt
> > cc: address@hidden, address@hidden, address@hidden,
> > "Paul F. Dietz" <address@hidden>
> > From: "Camm Maguire" <address@hidden>
> > Date: 09 Jul 2003 18:24:21 -0400
> > User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2
> > X-WSS-ID: 131249A67698307-01-01
> > Content-Type: text/plain;
> > charset=us-ascii
> >
> > Hi Matt! OK, Take four. I can't imagine it would be a problem to
> > skip over whitespace in the case of our extension (package
designator
> > before a left paren), so that's what I've included below. As for
> > skipping in the case of whitespace between a package designator
and a
> > symbol, I'll refer this to Paul for comment.
> >
> >
=============================================================================
> > --- read.d 26 Feb 2003 22:21:37 -0000 1.14
> > +++ read.d 9 Jul 2003 22:19:55 -0000
> > @@ -392,6 +392,11 @@
> > Read_object(in) reads an object from stream in.
> > This routine corresponds to COMMON Lisp function READ.
> > */
> > +
> > +/* FIXME What should this be? Apparently no reliable way to use
value stack */
> > +#define MAX_PACKAGE_STACK 100
> > +static object P0[MAX_PACKAGE_STACK],*PP0=P0;
> > +
> > object
> > read_object(in)
> > object in;
> > @@ -428,6 +433,7 @@
> > });
> > a = cat(c);
> > } while (a == cat_whitespace);
> > + if (c->ch.ch_code==')' && PP0>P0) PP0--;
> > delimiting_char = vs_head;
> > if (delimiting_char != OBJNULL && c == delimiting_char) {
> > delimiting_char = OBJNULL;
> > @@ -587,6 +593,35 @@
> > token->st.st_fillp = length - (colon + 2);
> > } else
> > p = current_package();
> > + /* FIXME Perhaps one of these is redundant */
> > + if (!token->st.st_fillp && colon_type) {
> > + int i=0;
> > +
> > + while (a == cat_whitespace) {
> > + i=1;
> > + read_char_to(c,in, {
> > + if (df) {
> > + vs_reset;
> > + return(OBJNULL);
> > + } else
> > + end_of_stream(in);
> > + });
> > + a=cat(c);
> > + }
> > + if (i)
> > + unread_char(c, in);
> > +
> > + if (c->ch.ch_code == '(') {
> > + if (PP0-P0>=MAX_PACKAGE_STACK)
> > + FEerror("Too many nested package specifiers",0);
> > + *PP0++=p;
> > + x=read_object(in);
> > + vs_reset;
> > + return (x);
> > + }
> > + }
> > + if (PP0>P0 && !colon_type)
> > + p=PP0[-1];
> > vs_push(p);
> > x = intern(token, p);
> > vs_push(x);
> >
=============================================================================
> >
> >
> > Matt Kaufmann <address@hidden> writes:
> >
> > > Hi, Camm --
> > >
> > > Thank you very much. Sorry I didn't think to mention this
before, but for the
> > > purpose I have in mind I'd like whitespace after the :: to be
ignored by the
> > > reader, so for example the following would work.
> > >
> > > >'lisp:: a
> > >
> > > LISP::||
> > >
> > > >
> > > Error: The variable LISP::A is unbound.
> > > Fast links are on: do (si::use-fast-links nil) for debugging
> > > Error signalled by EVAL.
> > > Broken at EVAL. Type :H for Help.
> > > >>:q
> > >
> > > Top level.
> > > >
> > >
> > > Here are some more examples (probably you can just ignore them).
I don't so
> > > much need whitespace ignored before :: and a symbol, but rather,
between :: and
> > > an open paren.
> > >
> > > >'lisp::(a b user::c)
> > >
> > > (LISP::A LISP::B C)
> > >
> > > >'lisp:: (a b user::c)
> > >
> > > LISP::||
> > >
> > > >
> > > Error: The function LISP::A is undefined.
> > > Fast links are on: do (si::use-fast-links nil) for debugging
> > > Error signalled by EVAL.
> > > Broken at EVAL. Type :H for Help.
> > > >>:q
> > >
> > > Top level.
> > > >'lisp::
> > > (a b user::c)
> > >
> > > LISP::||
> > >
> > > >
> > > Error: The function LISP::A is undefined.
> > > Fast links are on: do (si::use-fast-links nil) for debugging
> > > Error signalled by EVAL.
> > > Broken at EVAL. Type :H for Help.
> > > >>:q
> > >
> > > Top level.
> > > >(quote lisp::(a b user::c))
> > >
> > > (LISP::A LISP::B C)
> > >
> > > >(quote lisp::
> > > (a b user::c))
> > >
> > > Error: Too many arguments.
> > > Fast links are on: do (si::use-fast-links nil) for debugging
> > > Error signalled by QUOTE.
> > > Broken at QUOTE. Type :H for Help.
> > > >>
> > >
> > > Is this an easy fix for you that you're willing to make?
> > >
> > > Thanks --
> > > -- Matt
> > > Cc: address@hidden, address@hidden
> > > From: Camm Maguire <address@hidden>
> > > Date: 09 Jul 2003 11:49:11 -0400
> > > User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2
> > > Content-Type: text/plain; charset=us-ascii
> > >
> > > Greetings! OK, here is take three -- this should ensure that
the
> > > stack is popped on input error somewhere in the list:
> > >
> > >
=============================================================================
> > > diff -u -r1.14 read.d
> > > --- read.d 26 Feb 2003 22:21:37 -0000 1.14
> > > +++ read.d 9 Jul 2003 15:45:45 -0000
> > > @@ -392,6 +392,11 @@
> > > Read_object(in) reads an object from stream in.
> > > This routine corresponds to COMMON Lisp function READ.
> > > */
> > > +
> > > +/* FIXME What should this be? Apparently no reliable way to
use value stack */
> > > +#define MAX_PACKAGE_STACK 100
> > > +static object P0[MAX_PACKAGE_STACK],*PP0=P0;
> > > +
> > > object
> > > read_object(in)
> > > object in;
> > > @@ -428,6 +433,7 @@
> > > });
> > > a = cat(c);
> > > } while (a == cat_whitespace);
> > > + if (c->ch.ch_code==')' && PP0>P0) PP0--;
> > > delimiting_char = vs_head;
> > > if (delimiting_char != OBJNULL && c == delimiting_char) {
> > > delimiting_char = OBJNULL;
> > > @@ -587,6 +593,17 @@
> > > token->st.st_fillp = length - (colon + 2);
> > > } else
> > > p = current_package();
> > > + /* FIXME Perhaps one of these is redundant */
> > > + if (c->ch.ch_code=='(' && !token->st.st_fillp &&
colon_type) {
> > > + if (PP0-P0>=MAX_PACKAGE_STACK)
> > > + FEerror("Too many nested package specifiers",0);
> > > + *PP0++=p;
> > > + x=read_object(in);
> > > + vs_reset;
> > > + return (x);
> > > + }
> > > + if (PP0>P0 && !colon_type)
> > > + p=PP0[-1];
> > > vs_push(p);
> > > x = intern(token, p);
> > > vs_push(x);
> > >
=============================================================================
> > > (sid)address@hidden:/fix/t1/camm/gcl/unixport$ ./saved_gcl
> > > GCL (GNU Common Lisp) (2.5.3) Tue Jul 8 17:07:32 UTC 2003
> > > Licensed under GNU Library General Public License
> > > Dedicated to the memory of W. Schelter
> > >
> > > Use (help) to get some basic information on how to use GCL.
> > >
> > > >(read)
> > > (quote (q lisp::(a b si::c d) e))
> > >
> > > '(Q (LISP::A LISP::B SYSTEM::C LISP::D) E)
> > >
> > > >(read)
> > > (quote (q lisp::(a b si::c . . d) e))
> > >
> > > Error: Two dots appeared consecutively.
> > > Fast links are on: do (si::use-fast-links nil) for debugging
> > > Error signalled by READ.
> > > Broken at READ. Type :H for Help.
> > > >>
> > > Error: The variable LISP::D is unbound.
> > > Fast links are on: do (si::use-fast-links nil) for debugging
> > > Error signalled by EVALHOOK.
> > > Backtrace: system:universal-error-handler > EVALHOOK
> > >
> > > Broken at READ.
> > > >>
> > > Error: The variable E is unbound.
> > > Fast links are on: do (si::use-fast-links nil) for debugging
> > > Error signalled by EVALHOOK.
> > > Backtrace: system:universal-error-handler > EVALHOOK
> > >
> > > Broken at READ.
> > > >>(quote (q lisp::(a b si::c d) e))
> > >
> > > (Q (LISP::A LISP::B SYSTEM::C LISP::D) E)
> > > >>:q
> > >
> > > Top level.
> > > >(quote (q lisp::(a b si::c d) e))
> > >
> > > (Q (LISP::A LISP::B SYSTEM::C LISP::D) E)
> > >
> > > >(by)
> > >
=============================================================================
> > >
> > > Take care,
> > >
> > > Matt Kaufmann <address@hidden> writes:
> > >
> > > > Thanks, Camm! Rob Sumners put your mods in and built GCL
with them. He looked
> > > > at your code and described your approach, so I tried an
example with nested
> > > > package prefixes. Unfortunately, it didn't do what I
expected, which is to use
> > > > the closest package prefix:
> > > >
> > > > GCL:
> > > >
> > > > >'lisp::(a b user::c)
> > > >
> > > > (LISP::A LISP::B LISP::C)
> > > >
> > > > >
> > > >
> > > > Allegro CL:
> > > >
> > > > CL-USER(1): 'lisp::(a b user::c)
> > > > (COMMON-LISP::A COMMON-LISP::B C)
> > > > CL-USER(2):
> > > >
> > > > Maybe an easy fix for you?
> > > >
> > > > Thanks --
> > > > -- Matt
> > > > cc: address@hidden
> > > > From: Camm Maguire <address@hidden>
> > > > Date: 08 Jul 2003 12:52:30 -0400
> > > > User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2
> > > > Content-Type: text/plain; charset=us-ascii
> > > >
> > > > Greetings! Given Paul's analysis, let's put in this
feature. You
> > > > might want to try this patch:
> > > >
> > > > diff -u -r1.14 read.d
> > > > --- read.d 26 Feb 2003 22:21:37 -0000 1.14
> > > > +++ read.d 8 Jul 2003 16:47:32 -0000
> > > > @@ -392,6 +392,9 @@
> > > > Read_object(in) reads an object from stream in.
> > > > This routine corresponds to COMMON Lisp function
READ.
> > > > */
> > > > +
> > > > +static object p0=Cnil;
> > > > +
> > > > object
> > > > read_object(in)
> > > > object in;
> > > > @@ -587,6 +590,15 @@
> > > > token->st.st_fillp = length - (colon + 2);
> > > > } else
> > > > p = current_package();
> > > > + if (c->ch.ch_code=='(' && !token->st.st_fillp
&& colon_type) {
> > > > + p0=p;
> > > > + x=read_object(in);
> > > > + p0=Cnil;
> > > > + vs_reset;
> > > > + return (x);
> > > > + }
> > > > + if (p0!=Cnil)
> > > > + p=p0;
> > > > vs_push(p);
> > > > x = intern(token, p);
> > > > vs_push(x);
> > > >
> > > >
> > > >
=============================================================================
> > > > (sid)address@hidden:/fix/t1/camm/gcl/unixport$
./saved_gcl
> > > > GCL (GNU Common Lisp) (2.5.3) Tue Jul 8 15:22:09 UTC
2003
> > > > Licensed under GNU Library General Public License
> > > > Dedicated to the memory of W. Schelter
> > > >
> > > > Use (help) to get some basic information on how to use
GCL.
> > > >
> > > > >(quote lisp::(a b c))
> > > >
> > > > (LISP::A LISP::B LISP::C)
> > > >
> > > > >(quote (a b c))
> > > >
> > > > (A B C)
> > > >
> > > > >(by)
> > > >
=============================================================================
> > > >
> > > > I'll test this and commit to the unstable branch if all
is well.
> > > > Comments welcome, as always.
> > > >
> > > > Take care,
> > > >
> > > > Matt Kaufmann <address@hidden> writes:
> > > >
> > > > > Thanks for the quick reply!
> > > > >
> > > > > -- Matt
> > > > > cc: address@hidden, "Paul F. Dietz" <address@hidden>
> > > > > From: Camm Maguire <address@hidden>
> > > > > Date: 02 Jul 2003 15:42:16 -0400
> > > > > User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2
> > > > > Content-Type: text/plain; charset=us-ascii
> > > > >
> > > > > Greetings, and thanks for your suggestion!
> > > > >
> > > > > I'm forwarding this to the list to solicit opinions
from our ANSI
> > > > > standard experts on whether such a change would be
permissible in ANSI
> > > > > common lisp. Comments?
> > > > >
> > > > > Take care,
> > > > >
> > > > > Matt Kaufmann <address@hidden> writes:
> > > > >
> > > > > > Hi --
> > > > > >
> > > > > > I wonder if it would be possible to modify the
GCL reader so that package
> > > > > > prefixes can apply to lists, not just symbols.
Here's an example of what I
> > > > > > mean.
> > > > > >
> > > > > > >'lisp::(a b)
> > > > > >
> > > > > > LISP::||
> > > > > >
> > > > > > >
> > > > > > Error: The function A is undefined.
> > > > > > Fast links are on: do (si::use-fast-links nil)
for debugging
> > > > > > Error signalled by EVAL.
> > > > > > Broken at EVAL. Type :H for Help.
> > > > > > >>
> > > > > >
> > > > > > Here is the corresponding log for Allegro Common
Lisp.
> > > > > >
> > > > > > CL-USER(2): 'lisp::(a b)
> > > > > > (COMMON-LISP::A COMMON-LISP::B)
> > > > > > CL-USER(3):
> > > > > >
> > > > > > I'm pretty sure that there's no CLtL requirement
to make such a change. It's
> > > > > > even possible that GCL does this right and
Allegro CL does it wrong. But
> > > > > > anyhow, I thought I'd ask, because it would be
very handy to have such a
> > > > > > capability in GCL (it could affect which Lisp is
used under ACL2 at AMD).
> > > > > >
> > > > > > Thanks --
> > > > > > -- Matt
> > > > > >
> > > > > >
> > > > > >
> > > > >
> > > > > --
> > > > > Camm Maguire
address@hidden
> > > > >
==========================================================================
> > > > > "The earth is but one country, and mankind its
citizens." -- Baha'u'llah
> > > > >
> > > > >
> > > > >
> > > >
> > > > --
> > > > Camm Maguire
address@hidden
> > > >
==========================================================================
> > > > "The earth is but one country, and mankind its
citizens." -- Baha'u'llah
> > > >
> > > >
> > > > _______________________________________________
> > > > Gcl-devel mailing list
> > > > address@hidden
> > > > http://mail.gnu.org/mailman/listinfo/gcl-devel
> > > >
> > > >
> > > >
> > >
> > > --
> > > Camm Maguire
address@hidden
> > >
==========================================================================
> > > "The earth is but one country, and mankind its citizens." --
Baha'u'llah
> > >
> > >
> > >
> >
> > --
> > Camm Maguire
address@hidden
> >
==========================================================================
> > "The earth is but one country, and mankind its citizens." --
Baha'u'llah
> >
> >
> >
>
> --
> Camm Maguire address@hidden
>
==========================================================================
> "The earth is but one country, and mankind its citizens." --
Baha'u'llah
>
>
>
>
--
Camm Maguire address@hidden
==========================================================================
"The earth is but one country, and mankind its citizens." -- Baha'u'llah
- [Gcl-devel] defgeneric method fix, (continued)
- [Gcl-devel] defgeneric method fix, Camm Maguire, 2003/07/11
- Segfault in change-class (was Re: [Gcl-devel] defgeneric method fix), Paul F. Dietz, 2003/07/12
- Re: Segfault in change-class (was Re: [Gcl-devel] defgeneric method fix), Paul F. Dietz, 2003/07/12
- [Gcl-devel] [ Task #1924] IN-PACKAGE form put out of order in compiled file, Camm Maguire, 2003/07/14
- Re: Segfault in change-class (was Re: [Gcl-devel] defgeneric method fix), Camm Maguire, 2003/07/15
- Re: [Gcl-devel] Re: possible lisp reader enhancement/modification, Matt Kaufmann, 2003/07/10
- Re: [Gcl-devel] Re: possible lisp reader enhancement/modification, Camm Maguire, 2003/07/10
- Re: [Gcl-devel] Re: possible lisp reader enhancement/modification, Camm Maguire, 2003/07/10
- Re: [Gcl-devel] Re: possible lisp reader enhancement/modification, Matt Kaufmann, 2003/07/10
- Re: [Gcl-devel] Re: possible lisp reader enhancement/modification, Camm Maguire, 2003/07/10
- Re: [Gcl-devel] Re: possible lisp reader enhancement/modification,
Matt Kaufmann <=
- Re: [Gcl-devel] Re: possible lisp reader enhancement/modification, Camm Maguire, 2003/07/14
- Re: [Gcl-devel] Re: possible lisp reader enhancement/modification, Matt Kaufmann, 2003/07/18
- Re: [Gcl-devel] Re: possible lisp reader enhancement/modification, Vadim V. Zhytnikov, 2003/07/19
- Re: [Gcl-devel] Re: possible lisp reader enhancement/modification, Matt Kaufmann, 2003/07/19
- Re: [Gcl-devel] Re: possible lisp reader enhancement/modification, Vadim V. Zhytnikov, 2003/07/20
- Re: [Gcl-devel] Re: possible lisp reader enhancement/modification, Camm Maguire, 2003/07/20
- Re: [Gcl-devel] Re: possible lisp reader enhancement/modification, Matt Kaufmann, 2003/07/21
- Re: [Gcl-devel] Re: possible lisp reader enhancement/modification, Camm Maguire, 2003/07/28
- Re: [Gcl-devel] Re: possible lisp reader enhancement/modification ?JUNK MAIL? 4, Matt Kaufmann, 2003/07/28
- Re: [Gcl-devel] Re: possible lisp reader enhancement/modification ?JUNK MAIL? 4, Camm Maguire, 2003/07/28