[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 14:45:11 -0500 |
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
- Re: [Gcl-devel] Re: possible lisp reader enhancement/modification, (continued)
- Re: [Gcl-devel] Re: possible lisp reader enhancement/modification, Camm Maguire, 2003/07/09
- Re: [Gcl-devel] Re: possible lisp reader enhancement/modification, Matt Kaufmann, 2003/07/09
- Re: [Gcl-devel] Re: possible lisp reader enhancement/modification, Camm Maguire, 2003/07/09
- [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 <=
- 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, 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