Read macro blues: #+
Kenny Tilton
something that has me stumped...
take the expression:
#+mcl (#_GetTickCount)
(I am trying to keep my source the same on both platforms.)
When Allegro trys to compile this, it squawks that it does not know
about #_. But my understanding is that the whole point of #+ being a
read macro is that it can keep the reader ever from encountering alien
other read macros.
In support of my understanding, I tried giving MCL an unknown read macro
after #+allegro and it did not blink.
And in further support, as well as constituting a separate ACL
confusuion, incremental /evaluation/ under ACL does not in fact complain
about the #_ read macro!
I'm thinking....ACL bug?
Ken
PS I am spamming both c.l.l and c.l.l.f to discover the best place for
such newbie ACL stuf.
John Wiseman
> OK, just to get the ball rolling on my MCL->ACL transition Q's, here's
> something that has me stumped...
>
> take the expression:
>
> #+mcl (#_GetTickCount)
>
> (I am trying to keep my source the same on both platforms.)
>
> When Allegro trys to compile this, it squawks that it does not know
> about #_. But my understanding is that the whole point of #+ being a
> read macro is that it can keep the reader ever from encountering
> alien other read macros.
According to the spec, in the case where #+ wants to skip over the
following expression it calls READ with *READ-SUPPRESS* bound to T.
The section on *READ-SUPPRESS* says that parsing continues in "the
normal way", with specific types of errors (invalid potential numbers,
invalid patterns of package markers, invalid uses of the dot
character) being suppressed. It specifically says that dispatching
macro characters will invoke the dispatch function, and does not say
anything about suppressing an error cause by not having a dispatch
function.
It's conceivable that it could act the way you think it should act in
the case where the expression it's trying to skip is a list, since you
can easily figure out where the end of the expression is, but imagine
if MCL had a read macro #{ and you tried to read the following
expression in ACL:
#+mcl #{ Pure Funk }
The fact that #\} terminates the expression is determined entirely by
the implementation of the #{ macro. How would any other Lisp's reader
be able to figure out when to stop skipping?
A workaround specific to MCL's #_ and #$ read macros is to use the
require-trap and (um, I forgot the other one; require-trap-constant
maybe?) macros instead.
John Wiseman
Paul Meurer
wrote:
>OK, just to get the ball rolling on my MCL->ACL transition Q's, here's
>something that has me stumped...
>
Why going form MCL to ACL in the first place? ;-)
>take the expression:
>
> #+mcl (#_GetTickCount)
>
>(I am trying to keep my source the same on both platforms.)
>
>When Allegro trys to compile this, it squawks that it does not know
>about #_. But my understanding is that the whole point of #+ being a
>read macro is that it can keep the reader ever from encountering alien
>other read macros.
> ...
>
>I'm thinking....ACL bug?
>
I have exactly the same problem with #_ (from MCL) in LispWorks. The
reason is probably that the reader goes through the commented-out text
to find the end of the comment, where it encounters #_ and barks.
The Ansi Standard suggests (as I interprete the following passage)
that this is a bug, but this is not entirely clear to me.
[about *read-suppress*, which is t under the discussed conditions:]
>>>>>>>>
This variable is intended primarily to support the operation of the
read-time conditional notations #+ and #-. It is important for the
reader macros which implement these notations to be able to skip over
the printed representation of an expression despite the possibility
that the syntax of the skipped expression may not be entirely valid
for the current implementation, since #+ and #- exist in order to
allow the same program to be shared among several Lisp implementations
(including dialects other than Common Lisp) despite small
incompatibilities of syntax.
<<<<<<<<
Paul
Paul Meurer at HIT UiB no
Humanities Information Technologies,
University of Bergen
Allegt. 27
5007 Bergen, Norway
Erik Naggum
| I have exactly the same problem with #_ (from MCL) in LispWorks. The
| reason is probably that the reader goes through the commented-out text to
| find the end of the comment, where it encounters #_ and barks.
#+ is not a comment. #|...|# is a comment.
there reason it does not work is there is no telling what a reader macro
will do in the normal case that is supposed to be skipped if there is no
code to dispatch to.
#:Erik
--
SIGTHTBABW: a signal sent from Unix to its programmers at random
intervals to make them remember that There Has To Be A Better Way.
Erik Naggum
| And in further support, as well as constituting a separate ACL
| confusuion, incremental /evaluation/ under ACL does not in fact complain
| about the #_ read macro!
it doesn't? it does for me.
| I'm thinking....ACL bug?
no.
try (#+allegro #L"sys:foobar.cl") in MCL. if it doesn't fail, it's
because #L means something else in MCL than in ACL, and once you go down
that _road_, you realize that yours is a really dangerous assumption.
the solution is to make a reader for #_ with #-mcl in front of it.
Paul Meurer
wrote:
>>
>>I'm thinking....ACL bug?
>>
>
>I have exactly the same problem with #_ (from MCL) in LispWorks. The
>reason is probably that the reader goes through the commented-out text
>to find the end of the comment, where it encounters #_ and barks.
>
Oops, of couse I did not mean comment here.
Paul