Lispworks has a bug in the #=/#n# reader macro. (I've submitted a bug report).
I've altered the function HTTP-PROXY with conditionals to workaround this.
> I am reluctant to accommodate such a blatant bug.
Understandably. (On the other hand, the workaround (without using conditionals) looks like perfectly fine Lisp code.)
> do they have a response?
I haven't heard back from Lispworks yet.
> what lw version is broken?
This problem appears in at least versions 4.4.6 and 5.0.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Lispworks' response:
"We think this use of #n# inside #. is incorrect, though the Common Lisp
standard doesn't make it clear. The problem is that you cannot generally
carry the context of the current read operation into the form to be evaluated,
e.g. consider these cases
#1=#.(#1#)
`#.(car ',x)
`#.(load-time-value ',x)
To avoid these problems, the LispWorks implementation of #. reads the object
with a non-recursive read so the #n# context from the surrounding forms is not
used.
I suggest just using (length #1#) instead, because the compiler will optimize
this to the length of the constant string anyway.
There are also a couple of issues with the buf string that you might like to
consider:
- It is not thread-safe, because there is only one string.
- The string is a literal object in the code because it is made at read time,
so the code is not compliant with the Common Lisp rules for modifying
literal objects."
File Added: url.lisp
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
This Tracker item was closed automatically by the system. It was
previously set to a Pending status, and the original submitter
did not respond within 14 days (the time period specified by
the administrator of this Tracker).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Logged In: YES
user_id=5735
Originator: NO
I am reluctant to accommodate such a blatant bug.
do they have a response?
what lw version is broken?
please note that you attached a modified OLD file, not a patch against CVS head.
Logged In: YES
user_id=870521
Originator: YES
> I am reluctant to accommodate such a blatant bug.
Understandably. (On the other hand, the workaround (without using conditionals) looks like perfectly fine Lisp code.)
> do they have a response?
I haven't heard back from Lispworks yet.
> what lw version is broken?
This problem appears in at least versions 4.4.6 and 5.0.
HTTP-PROXY modified: #.(length #1#) => (length #1#)
Logged In: YES
user_id=870521
Originator: YES
I've attached a modified head version.
Lispworks' response:
"We think this use of #n# inside #. is incorrect, though the Common Lisp
standard doesn't make it clear. The problem is that you cannot generally
carry the context of the current read operation into the form to be evaluated,
e.g. consider these cases
#1=#.(#1#)
`#.(car ',x)
`#.(load-time-value ',x)
To avoid these problems, the LispWorks implementation of #. reads the object
with a non-recursive read so the #n# context from the surrounding forms is not
used.
I suggest just using (length #1#) instead, because the compiler will optimize
this to the length of the constant string anyway.
There are also a couple of issues with the buf string that you might like to
consider:
- It is not thread-safe, because there is only one string.
- The string is a literal object in the code because it is made at read time,
so the code is not compliant with the Common Lisp rules for modifying
literal objects."
File Added: url.lisp
Logged In: YES
user_id=5735
Originator: NO
[1]> #1=#.(#1#)
*** - EVAL: #<READ-LABEL 1> is not a function name; try using a symbol instead
no problem - just signal an error for a semantically unsound form.
I think LW just threw out the baby with the water.
neither
http://www.lisp.org/HyperSpec/Body/sec_2-4-8-15.html
http://www.lisp.org/HyperSpec/Body/sec_2-4-8-6.html
prohibit this.
I suggest that you raise this question on comp.lang.lisp and see what the community thinks.
Logged In: YES
user_id=5735
Originator: NO
any response from comp.lang.lisp?
Logged In: YES
user_id=1312539
Originator: NO
This Tracker item was closed automatically by the system. It was
previously set to a Pending status, and the original submitter
did not respond within 14 days (the time period specified by
the administrator of this Tracker).