gcl-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gcl-devel] Re: possible lisp reader enhancement/modification


From: Camm Maguire
Subject: Re: [Gcl-devel] Re: possible lisp reader enhancement/modification
Date: 09 Jul 2003 18:24:21 -0400
User-agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]