[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: |
Thu, 10 Jul 2003 19:09:24 -0500 |
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
- [Gcl-devel] Re: possible lisp reader enhancement/modification, (continued)
- [Gcl-devel] Re: possible lisp reader enhancement/modification, Paul F. Dietz, 2003/07/09
- Re: [Gcl-devel] Re: possible lisp reader enhancement/modification, Camm Maguire, 2003/07/09
- [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 <=
- 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/11
- 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