#49 Lispworks #= reader workaround in URL.LISP

closed-wont-fix
Sam Steingold
cllib (10)
5
2008-07-07
2007-06-21
No

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.

Discussion

  • Sam Steingold
    Sam Steingold
    2007-06-21

    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#)

     
    Attachments
  • 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

     
  • Sam Steingold
    Sam Steingold
    2007-06-21

    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.

     
  • Sam Steingold
    Sam Steingold
    2008-06-22

    • status: open --> pending-wont-fix
     
  • Sam Steingold
    Sam Steingold
    2008-06-22

    Logged In: YES
    user_id=5735
    Originator: NO

    any response from comp.lang.lisp?

     
    • status: pending-wont-fix --> closed-wont-fix
     
  • 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).