So this works on Allegro 6.2
'user: bar
bar
It fails using Lispworks and Corman Lisp.
A priori I would have expected it to fail in every CL.
But I can't find any clause in the Hyperspec specifically
relating to this.
Comments?
James P. Massar <······@alum.mit.edu> writes:
> So this works on Allegro 6.2
>
> 'user: bar
>
> bar
>
>
> It fails using Lispworks and Corman Lisp.
> A priori I would have expected it to fail in every CL.
>
> But I can't find any clause in the Hyperspec specifically
> relating to this.
Look in the syntax chapter. Look at the description for the main reader
loop and the description of how the tokens are then processed.
The reader finds the token "user:" when the quote-reader-macro calls a
recursive READ. It is whitespace terminated. A token may not end in a
colon. Parse error. I have no idea what ACL is up to.
--
Rahul Jain
·····@nyct.net
Professional Software Developer, Amateur Quantum Mechanicist
Rahul Jain wrote:
> James P. Massar <······@alum.mit.edu> writes:
>
>
>>So this works on Allegro 6.2
>>
>>'user: bar
>>
>>bar
>>
>>
>>It fails using Lispworks and Corman Lisp.
>>A priori I would have expected it to fail in every CL.
>>
>>But I can't find any clause in the Hyperspec specifically
>>relating to this.
>
>
> Look in the syntax chapter. Look at the description for the main reader
> loop and the description of how the tokens are then processed.
>
> The reader finds the token "user:" when the quote-reader-macro calls a
> recursive READ. It is whitespace terminated. A token may not end in a
> colon. Parse error. I have no idea what ACL is up to.
I am sure it is a plot to end civilization as we know it. They also let
slide a ::thingy (typo for :thingy) that Lispworks parsed as :\:thingy,
I wager correctly?
kenny
--
http://tilton-technology.com
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Your Project Here! http://alu.cliki.net/Industry%20Application
Kenny Tilton wrote:
> I am sure it is a plot to end civilization as we know it. They also let
> slide a ::thingy (typo for :thingy) that Lispworks parsed as :\:thingy,
> I wager correctly?
See Duane's and my comments about a colon terminating a token. The case
of two colons at the beginning of a token is _also_ explicitly not defined
by the ANS and explicitly available for implementation-defined behavior.
Both Lispworks and Allegro are behaving legally here, whether or not the
interpretation is intentional or useful.
On 2004-03-03 04:27:56, Rahul Jain wrote:
> The reader finds the token "user:" when the quote-reader-macro calls a
> recursive READ. It is whitespace terminated. A token may not end in a
> colon. Parse error. I have no idea what ACL is up to.
No colon allowed at the end? Damn! I want to call my function -:
Stefan Scholl <······@no-spoon.de> wrote in message news:<················@parsec.no-spoon.de>...
> No colon allowed at the end? Damn! I want to call my function -:
Bah. Use pipes and type whatever you want. Don't call it good style, though...
(defun |-:| (|Cheers,|
-- Nikodemus Siivola) |:-|)
Rahul Jain <·····@nyct.net> wrote in message news:<··············@nyct.net>...
> The reader finds the token "user:" when the quote-reader-macro calls a
> recursive READ. It is whitespace terminated. A token may not end in a
> colon. Parse error. I have no idea what ACL is up to.
Does it have to signal an error? According to 2.3.5 Valid Patterns for
Tokens, it's simply an undefined pattern.
···@ashi.footprints.net (Kaz Kylheku) writes:
> Rahul Jain <·····@nyct.net> wrote in message news:<··············@nyct.net>...
> > The reader finds the token "user:" when the quote-reader-macro calls a
> > recursive READ. It is whitespace terminated. A token may not end in a
> > colon. Parse error. I have no idea what ACL is up to.
>
> Does it have to signal an error? According to 2.3.5 Valid Patterns for
> Tokens, it's simply an undefined pattern.
This is exactly true. Section 2.3.5 even shows examples of such
non-defined behaviors, inclusding the pattern aaaaa: which it
labels as undefined. Also, the fifth bullet in the description
says that any other pattern of pattern marker usage (such as
when the colon is at the end of the token) is undefined.
How can what Allegro CL does be regarded as useful? Well,
in Allegro CL (and, I'm told, as legacy behavior in Lisp
Machines), one can read a whole expression in a package that
is not the current package, without resorting to an in-package
form, or other trickery. For example:
CL-USER(1): (read-from-string "sys::(foo bar bas)")
(SYSTEM::FOO SYSTEM::BAR SYSTEM::BAS)
18
CL-USER(2):
One can also use this in source code when the majority of symbols is
in one package not the current package, as in
comp::
(defun foo (x y z)
(excl:bar x (sys:bas y z)))
which will read foo, x, y, and z as if they had all had comp::
prepended.
--
Duane Rettig ·····@franz.com Franz Inc. http://www.franz.com/
555 12th St., Suite 1450 http://www.555citycenter.com/
Oakland, Ca. 94607 Phone: (510) 452-2000; Fax: (510) 452-0182
Duane Rettig wrote:
> This is exactly true. Section 2.3.5 even shows examples of such
> non-defined behaviors, inclusding the pattern aaaaa: which it
> labels as undefined. Also, the fifth bullet in the description
> says that any other pattern of pattern marker usage (such as
> when the colon is at the end of the token) is undefined.
"Undefined" is correct but states the case rather weakly.
The ANS is rather clearer about its intention:
All other uses of package markers within names of symbols are
not defined by this standard but are reserved for
implementation-dependent use.
>How can what Allegro CL does be regarded as useful? Well,
>in Allegro CL (and, I'm told, as legacy behavior in Lisp
>Machines), one can read a whole expression in a package that
>is not the current package, without resorting to an in-package
>form, or other trickery. For example:
>
>CL-USER(1): (read-from-string "sys::(foo bar bas)")
>(SYSTEM::FOO SYSTEM::BAR SYSTEM::BAS)
>18
>CL-USER(2):
>
>One can also use this in source code when the majority of symbols is
>in one package not the current package, as in
>
>comp::
>(defun foo (x y z)
> (excl:bar x (sys:bas y z)))
>
>which will read foo, x, y, and z as if they had all had comp::
>prepended.,
I always thought that that syntax should be part of Common Lisp.
But as it's not and no other Common Lisp seems to do it, seems to me
like it would be best to have this 'feature' turned off by default and
enabled by a switch/flag.
It was rather puzzling why my portable code was compiling using
Allegro and failing with a package error, of all things, in Lispworks.
In article <··································@4ax.com>,
James P. Massar <······@alum.mit.edu> wrote:
> >One can also use this in source code when the majority of symbols is
> >in one package not the current package, as in
> >
> >comp::
> >(defun foo (x y z)
> > (excl:bar x (sys:bas y z)))
> >
> >which will read foo, x, y, and z as if they had all had comp::
> >prepended.,
>
>
> I always thought that that syntax should be part of Common Lisp.
>
> But as it's not and no other Common Lisp seems to do it, seems to me
> like it would be best to have this 'feature' turned off by default and
> enabled by a switch/flag.
IIRC, Lisp Machines also support that syntax.
--
Barry Margolin, ······@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
Barry Margolin <······@alum.mit.edu> writes:
> In article <··································@4ax.com>,
> James P. Massar <······@alum.mit.edu> wrote:
>
> > >One can also use this in source code when the majority of symbols is
> > >in one package not the current package, as in
> > >
> > >comp::
> > >(defun foo (x y z)
> > > (excl:bar x (sys:bas y z)))
> > >
> > >which will read foo, x, y, and z as if they had all had comp::
> > >prepended.,
> >
> >
> > I always thought that that syntax should be part of Common Lisp.
> >
> > But as it's not and no other Common Lisp seems to do it, seems to me
> > like it would be best to have this 'feature' turned off by default and
> > enabled by a switch/flag.
>
> IIRC, Lisp Machines also support that syntax.
You do remember correctly. Steve Haflich implemented this in Allegro
because he missed it.
Kevin
James P. Massar wrote:
>
>
>>How can what Allegro CL does be regarded as useful? Well,
>>in Allegro CL (and, I'm told, as legacy behavior in Lisp
>>Machines), one can read a whole expression in a package that
>>is not the current package, without resorting to an in-package
>>form, or other trickery. For example:
>>
>>CL-USER(1): (read-from-string "sys::(foo bar bas)")
>>(SYSTEM::FOO SYSTEM::BAR SYSTEM::BAS)
>>18
>>CL-USER(2):
>>
>>One can also use this in source code when the majority of symbols is
>>in one package not the current package, as in
>>
>>comp::
>>(defun foo (x y z)
>> (excl:bar x (sys:bas y z)))
>>
>>which will read foo, x, y, and z as if they had all had comp::
>>prepended.,
>
>
>
> I always thought that that syntax should be part of Common Lisp.
>
> But as it's not and no other Common Lisp seems to do it, seems to me
> like it would be best to have this 'feature' turned off by default and
> enabled by a switch/flag.
>
> It was rather puzzling why my portable code was compiling using
> Allegro and failing with a package error, of all things, in Lispworks.
Get used to it. :) Lispworks finds so many things I do wrong (away with
which Allegro lets me get) that just a few days ago when I was
righteously stumped on a problem (working with ACL) that I loaded it up
in LW in hopes of finding the problem. I do not think it worked, but the
moral is that I find a lot of things porting from ACL to LW, and they
are usually of the type "oops, that's wrong".
Unresolved is whether this good for ACL, good for LW, or neutral.
kenneth
--
http://tilton-technology.com
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Your Project Here! http://alu.cliki.net/Industry%20Application
Duane Rettig <·····@franz.com> writes:
> How can what Allegro CL does be regarded as useful? Well,
> in Allegro CL (and, I'm told, as legacy behavior in Lisp
> Machines), one can read a whole expression in a package that
> is not the current package, without resorting to an in-package
> form, or other trickery.
Aha. Yes, I saw this in the Zeta-C sources and was a bit surprised. But
it was rather clear what it meant after a moment of thought.
--
Rahul Jain
·····@nyct.net
Professional Software Developer, Amateur Quantum Mechanicist