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
Howard R. Stearns
still READS it. How else is it supposed to know when to start reading
again?
A similar issue comes up with (list 1 2 #+not-present
#+something-else-not-present 3 4 5)
I think the only thing you can do is make sure that #_GetTickCount is
readable -- even if what it reads to isn't particularly important. In
doing this, check out the documentation of *read-suppress*.
Kenny Tilton wrote:
>
> 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.
>
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
Kent M Pitman
http://world.std.com/~pitman/pfaq/cross-posting.html]
wis...@cs.uchicago.edu (John Wiseman) writes:
> 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?
Yes, this argument is what usually comes up. Indeed, an early use of
#+/#- that I used a lot was:
(#+LISPM foo: bar ...)
to call a function that was called foo:bar on the lisp machine but
only bar on other implementations. It was maclisp's inability to
realize that foo: wasn't just a symbol (since maclisp had no package
system, and since the lispm package system allows a space after a
colon--or, more specifically, permits any expression to be read after
the colon) that allowed this trick to work. [maclisp has nothing to do
with the mac or mcl; it's an older dialect that predates cl and the
package system.]
> 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.
Yep, that's one approach. Another that I've also seen used is just to
make #_ a trivial macro in #-mcl situations where it just reads a
token following and discards it.
The problem is worse in situations
where #_ has incompatible meanings in two implementations, btw. At
that point, the programmer may just have to use extreme care to make
sure the other implementation doesn't see the char sequence at all.
e.g.,
#+mcl #.(read-from-string "#_whatever")
or some such thing would probably work better in a #-mcl situation.
Kenny Tilton
>
Are you ready for this? (But first thanks to everyone for pitching in on
#+)
So there I am in happy semi-retirement when a friend calls up and asks me
to take over systems development for his start-up. His current guru had
given notice. They were doing WinNT, VB + SQL Server...hadn't gotten too
far...some nice proof-of-concept with 3rd-party tools, but a somewhat
awkward interface designed by committee (start-ups!).
I take a long hard look at what is going on and decide I can be in and out
in eight months, so what the hell, I dive in all prepared to put up with VB
for eight months.
But pretty quick the only interesting part of their system (the fact that
it requires massive customization for each /project/ for each client) leads
me back to a nifty Garnet-like framework I rolled for myself in MCL.
My friend/boss trusts me implicitly (well, I quit each Thursday the first
two weeks until he decided to trust me <g>), so he has already agreed to
ODBMS (AllegroStore), knows I have blown off VB in favor of some OO
language (Haven't told him yet <g>) so I am sure I can sell him on Lisp
(having no doubt myself), but....
...the Mac? Nahhhhh.....<g>
Guys! Gals! Is this a dream, or have I died and gone to heaven. Better yet,
my friend knows I have this hot framework and he himself brought up the
idea of spinning it off...move over, CLIM, here I come. <g>
BTW, I have been meaning to ask over here, seriously i am still evaluating
ACL and will be stress-testing AllegroStore before fully committing my
friend's dream project to these tools...anyone here using them for
mission-critical "enterprise" stuff? Happy? Sad?
So far ACL looks good--still waiting on the AllegroStore evaluation. I /do/
miss MCL, but it might just be that I am still coming up to speed, so no
judgment yet on that.
Wish me luck.
Ken
Erik Naggum
| BTW, I have been meaning to ask over here, seriously i am still
| evaluating ACL and will be stress-testing AllegroStore before fully
| committing my friend's dream project to these tools...anyone here using
| them for mission-critical "enterprise" stuff? Happy? Sad?
I'm happy to relate that after two months of grueling development work,
almost 95% of which has gone into surviving the idiotic behavior of
various Microsoft products and Delphi in relation to sockets and the
inability of Microsoft-inflicted programmers to implement protocols, plus
the senile firewalls that randomly forget Network Address Translations,
and a whole truckload of other network-related problems that we must
survive and sail through, my client launched a new service today that
increases the load on my application tenfold (it's been running since
mid-August), now requires a master with slaves (currently one) to handle
the real communications load and network hostilities, and has a hard
real-time requirement of 4 seconds from submission to final destination,
and this requires the cooperation of no less than 25 computers and
thousands of miles of telecommunications cable, with all their failing
routers and all kinds of human errors. we average out at 2 seconds, and
guesstimates indicate 1.3 to 1.5 seconds in network latency.
the master and the slave both run Allegro CL 5.0 on cheap, used 133 PPro
computers with 64M RAM and Linux. the application goes out of its way to
exercise the multiprocessing capabilities and the socket abstraction
layer (somewhat modified to handle socket conditions more flexibly) in
Allegro CL. the existence of the entire new technologies department of
the publishing company involved now rests with Allegro CL. (they also
run my private version of Emacs, since it would be disastrous if Emacs
were to die -- the differences are, again, in handling socket errors, but
also in removing unstable features.)
having worked with Internet protocols at most layers since 1987, I can
safely say that it would have taken me at least two years to get the same
robustness out of a C application, now that I know just how much work was
needed. (I did not _expect_ to have to do traceroutes on live sockets,
or survive and read data _past_ a connection reset error, and other such
unreasonable low-level stuff, but now that I do, I'm really happy that I
could do it in Common Lisp, and Allegro CL in particular.)
but as for AllegroStore, the data my application works with is not
persistent in my part of the big picture. my application only handles
the time-critical parts.
not _all_ has been bliss, however. I have rewritten the semi-lowlevel
file system read/write routines so they wouldn't signal errors on their
own, but call a generic function that may be specialized on the stream
and the error symbol so they can ignore or return EOF on whole classes of
errors, or signal an error if no other handlers exist. in effect, I
wanted to add programatically what I would do with the debugger to return
a value or restart the operation, but even the debugger couldn't just
ignore an error and continue. I have disabled the incredibly annoying
Unix signal SIGPIPE, which took a lot of work to get right, since Allegro
CL uses it internally to shut down properly when the parent Emacs dies,
and it had obviously been a lot work to live _with_ it, too. I have
rewritten the character handling functions so they are table-driven and
can now handle any 7- or 8-bit character set you want. since I use
logical pathnames a lot, a few disagreements over the specification has
required a number of _really_ low-level fixes. Franz Inc has been ever
helpful in fulfilling my needs and requirements even when disagreeing
that something is a problem, however, and I can safely say that this
project would not have been possible without their excellent support. of
course, one might argue that needing support is a sign of weakness on
_both_ ends, but I have come to think that a division of labor as great
as Common Lisp necessarily requires some sharing of insight both ways in
order to make that division work profitably for both parties, and Franz
Inc strongly agrees with that sentiment, at least as far as I'm concerned.