#; - lisp

This is a discussion on #; - lisp ; "Alex Mizrahi" <udodenko@users.sourceforge.net> writes: > KMP> Btw, NIL was the New Implementation of Lisp (a lisp implementation for > KMP> the VAX some years ago), and #+NIL actually did have an implementation > KMP> it was defined in. I don't ...

+ Reply to Thread
Page 3 of 6 FirstFirst 1 2 3 4 5 ... LastLast
Results 21 to 30 of 53

#;

  1. Default Re: #;

    "Alex Mizrahi" <udodenko@users.sourceforge.net> writes:

    > KMP> Btw, NIL was the New Implementation of Lisp (a lisp implementation for
    > KMP> the VAX some years ago), and #+NIL actually did have an implementation
    > KMP> it was defined in. I don't recommend it for conditionals. #+(or) is
    > KMP> safer, though not terribly intelligible to everyone. #+ignore is
    > KMP> something I've seen enough people use that it's unlikely anyone would
    > KMP> make :ignore feature and expect it to work.
    >
    > #+nil is widely used in SBCL implementation source code, so it's unlikely
    > SBCL can be compiled with NIL


    Well, first, all Lisp program texts are conforming, and certainly I
    would not expect all texts of implementations themselves to be conforming.

    On the other hand, it's certainly a reasonable claim that no one is
    likely to compile much of anything in NIL. Finding a VAX would be
    hard, and I'm not sure if there are emulators. And even if you had
    one, I don't know if the NIL sources are available. I offered the
    remark about the NIL language per se mostly as color.

    Part of my intent, of course, was just inject a bit of history, for fun.

    But part of the intent, too, with some marginal practical currency is
    that the practice of picking an obscure name and using a #+/#-
    conditional with it is error-prone because of the semantics of that.
    Over the years, I've seen people more than once end up surprised that
    their carefully crafted plan to pick a name no one was using didn't
    work. Sometimes it's trivial to dig one's way out of it with some
    global editing, sometimes not ... it can depend a lot on how gradually
    it happens and how many people are involved in the code. Any shared
    namespace has the possibility of name collision.

    Note, too, that the failure mode may not simply be "does it not read"
    but "why was it put there". For example, some people put these things
    on old dead code they don't want to use any more but are afraid to
    delete, some people temporarily comment out something that's
    troublesome, some people on things that is new code not yet installed.
    And sometimes they use different conventions for each of those. And
    if others are doing the same thing with different intent, it may
    clash. That's why, IF you want to go the route of guessing a name no
    one is probably going to use you're going to do this at all, #+BROKEN,
    #+OBSOLETE, and #+NOT-YET-TESTED might be more clear than #+NIL.

    > grepping for #+nil through my libraries collection shows that many popular
    > libs use it, including SLIME, S-XML, parenscript, Iterate, arnesi.. so one
    > who pushes NIL into features will break quite a lot of software


    Just as an aside...

    (progn (push nil *features*) :done)
    => ONE

    #+NIL :not :missing
    => :MISSING

    [It would have to be :NIL you'd push onto *FEATURES* for that to happen.]

    At minimum I wanted to say that #+NIL is not the lispy form of
    #ifdef 0
    since that NIL is more certainly not the NIL boolean, but rather is a
    feature name. That was my point about #+(OR), which really is reliable
    because it's primitively defined and cannot be overridden... without
    redefining the "#" readmacro of course.

  2. Default Re: #;

    On Dec 30, 7:46 pm, Kent M Pitman <pit...@nhplace.com> wrote:
    > verec <ve...@mac.com> writes:
    > > I have seen many examples using #+nil for this
    > > purpose, but this precisely doesn't work for
    > > incomplete expressions whereas:

    >
    > Btw, NIL was the New Implementation of Lisp (a lisp implementation for
    > the VAX some years ago), and #+NIL actually did have an implementation
    > it was defined in.  I don't recommend it for conditionals.  #+(or) is
    > safer, though not terribly intelligible to everyone.  #+ignore is something
    > I've seen enough people use that it's unlikely anyone would make :ignore
    > feature and expect it to work.


    You know, none of this actually matters, because unconditionally
    commented-out code should never be released (or even checked into the
    code repository).

    So all that matters is whether the trick works in your sandbox.

    If #+NIL does the job for you from the time you add it, to the time
    you remove it before passing the code onto anyone else, then that's
    fine.

    And we don't need a comment-out shorthand in Lisp, because we don't
    need features which specifically don't belong in production code.

    Therefore, of course, Scheme needs such a feature.

  3. Default Re: #;

    Pć Mon, 31 Dec 2007 22:58:00 +0100, skrev Kaz Kylheku <kkylheku@gmail.com>:

    >
    > You know, none of this actually matters, because unconditionally
    > commented-out code should never be released (or even checked into the
    > code repository).
    >
    > So all that matters is whether the trick works in your sandbox.
    >
    > If #+NIL does the job for you from the time you add it, to the time
    > you remove it before passing the code onto anyone else, then that's
    > fine.
    >
    > And we don't need a comment-out shorthand in Lisp, because we don't
    > need features which specifically don't belong in production code.
    >
    > Therefore, of course, Scheme needs such a feature.


    If you have ever worked with CVS in a large group you would know this is
    nonsense.
    The most common cause of CVS update discrepancies is deleted code. Merging
    code usually is uneventful, but if someone adds code to a module while
    another deletes from it havoc is made. It is much preferable to comment
    out code rather than delete it as this only adds two lines of code
    (assuming #| and |# on separate lines)
    Later before a release is made the CVS repository is locked and a script
    (Perl?) is used to remove the code that is commented out. Then all members
    delete their local repositories and check out a fresh copy.

    --------------
    John Thingstad

  4. Default Re: #;

    On Dec 31, 5:10 pm, "John Thingstad" <jpth...@online.no> wrote:
    > Pć Mon, 31 Dec 2007 22:58:00 +0100, skrev Kaz Kylheku <kkylh...@gmail.com>:
    >
    >
    >
    > > You know, none of this actually matters, because unconditionally
    > > commented-out code should never be released (or even checked into the
    > > code repository).

    >
    > > So all that matters is whether the trick works in your sandbox.

    >
    > > If #+NIL does the job for you from the time you add it, to the time
    > > you remove it before passing the code onto anyone else, then that's
    > > fine.

    >
    > > And we don't need a comment-out shorthand in Lisp, because we don't
    > > need features which specifically don't belong in production code.

    >
    > > Therefore, of course, Scheme needs such a feature.

    >
    > If you have ever worked with CVS in a large group you would know this is  
    > nonsense.


    Busted! Yeah, I'm really a janitor pretending to be a software
    developer on Usenet.

    > The most common cause of CVS update discrepancies is deleted code.


    No, that honor probably belongs to the idiotic $ keyword $ expansions,
    like $Log$.

    > Merging  
    > code usually is uneventful, but if someone adds code to a module while  
    > another deletes from it havoc is made.


    Not havoc, just a conflict. This is correct; there ought to be a
    conflict:

    <<<<<<<
    old version
    with
    your edits
    =======
    [ empty: gone in the new copy ]
    >>>>>>>


    You can't keep around obsolete code just so that the merge algorithm
    has a place to patch irrelevant changes.

    If I'm modifying code which no longer exists, I want this to be
    flagged, ASAP.

    It is much preferable to comment  
    > out code rather than delete it as this only adds two lines of code  
    > (assuming #| and |# on separate lines)


    So now instead of conflict markers, you have a potential bad merge
    situation. You're fixing something in some code, do an update, and now
    your change is silently commented out.

    This is a potential semantic conflict which is not reflected in a text
    conflict. It might be a semantic conflict, because the programmer who
    commented out the block of code didn't intend to comment out /your/
    change, which didn't exist in his copy. If you had won the race and
    committed your change first, that programmer might have thought, oops,
    I don't want to comment out this new part!

    In general, it's when merges /don't/ produce conflicts that you have
    to worry. A detected conflict is better than an undetected one.

  5. Default Re: #;

    KK> You know, none of this actually matters, because unconditionally
    KK> commented-out code should never be released

    so, you say that something like 100% of open source Common Lisp libraries
    and implementations should never be released?
    bold statement.

    to start with:

    alex@debetch:~/sbcl-1.0.9$ find . -name "*.lisp" | xargs grep "#+nil" |
    wc -l
    211

    or you think commercial software is somehow better? grepping for source code
    found in ACL (of cource not ACL's code itself, but examples etc) shows some
    76 occurences of #+ignore.

    KK> (or even checked into the
    KK> code repository).

    yes, in theory it works, as well as for hello-world project, maybe.



  6. Default Re: #;

    Kent M Pitman <pitman@nhplace.com> wrote:
    +---------------
    | At minimum I wanted to say that #+NIL is not the lispy form of
    | #ifdef 0
    | since that NIL is more certainly not the NIL boolean, but rather is a
    | feature name. That was my point about #+(OR), which really is reliable
    | because it's primitively defined and cannot be overridden...
    +---------------

    And I just want to repeat that I still prefer the equally-safe
    #-(AND) & #+(AND) rather than #+(OR) & #-(OR), respectively,
    since the cognitive dissonance of the former pair is less.
    With AND, minus is "off" and plus is "on". Easy to remember.


    -Rob

    -----
    Rob Warnock <rpw3@rpw3.org>
    627 26th Avenue <URL:http://rpw3.org/>
    San Mateo, CA 94403 (650)572-2607


  7. Default Re: #;

    On Tue, 1 Jan 2008 05:35:10 +0200, "Alex Mizrahi" <udodenko@users.sourceforge.net> wrote:

    > KK> You know, none of this actually matters, because
    > KK> unconditionally commented-out code should never be released
    >
    > so, you say that something like 100% of open source Common Lisp
    > libraries and implementations should never be released?
    >
    > bold statement.


    So, you're saying that 100% of all open source Common Lisp libraries
    contain unconditionally commented-out code?

    Bold statement...

    Edi.

    --

    European Common Lisp Meeting, Amsterdam, April 19/20, 2008

    http://weitz.de/eclm2008/

    Real email: (replace (subseq "spamtrap@agharta.de" 5) "edi")

  8. Default Re: #;

    Rob Warnock wrote:
    > Kent M Pitman <pitman@nhplace.com> wrote:
    > +---------------
    > | At minimum I wanted to say that #+NIL is not the lispy form of
    > | #ifdef 0
    > | since that NIL is more certainly not the NIL boolean, but rather is a
    > | feature name. That was my point about #+(OR), which really is reliable
    > | because it's primitively defined and cannot be overridden...
    > +---------------
    >
    > And I just want to repeat that I still prefer the equally-safe
    > #-(AND) & #+(AND) rather than #+(OR) & #-(OR), respectively,
    > since the cognitive dissonance of the former pair is less.
    > With AND, minus is "off" and plus is "on". Easy to remember.


    As far as I can tell, #-(AND) is underspecified in ANSI CL.

    Section 24.1.2.1 in the HyperSpec is actually not very precise about
    'and and 'or feature expressions - it doesn't say that they are related
    to the 'and and 'or macros, and it doesn't clearly say what happens when
    there are no arguments.

    In the case of 'and feature expressions, it says: "An and feature
    expression succeeds if all of its argument feature-conditionals succeed;
    otherwise, it fails." So does (AND) succeed or fail? How many of its
    arguments succeed? All or none?

    Same problem for 'or feature expressions, as far as I can tell.

    I'd strongly prefer #; because I wouldn't have to spend any time at all
    thinking about what it actually means. (In my own code, I actually use
    #| |# pairs for the same reason.)


    Pascal

    --
    My website: http://p-cos.net
    Common Lisp Document Repository: http://cdr.eurolisp.org
    Closer to MOP & ContextL: http://common-lisp.net/project/closer/

  9. Default Re: #;



    Edi Weitz wrote:
    > On Tue, 1 Jan 2008 05:35:10 +0200, "Alex Mizrahi" <udodenko@users.sourceforge.net> wrote:
    >
    >
    >> KK> You know, none of this actually matters, because
    >> KK> unconditionally commented-out code should never be released
    >>
    >>so, you say that something like 100% of open source Common Lisp
    >>libraries and implementations should never be released?
    >>
    >>bold statement.

    >
    >
    > So, you're saying that 100% of all open source Common Lisp libraries
    > contain unconditionally commented-out code?
    >
    > Bold statement...


    So you're saying "something like 100%" is 100%?

    Bold statement...

    kenny


    --
    http://www.theoryyalgebra.com/

    "In the morning, hear the Way;
    in the evening, die content!"
    -- Confucius

  10. Default Re: #;

    On Tue, 01 Jan 2008 09:32:28 -0500, Ken Tilton <kennytilton@optonline.net> wrote:

    > So you're saying "something like 100%" is 100%?
    >
    > Bold statement...


    Hey, you always need to have the final say, or what?

    Tststs...

    Edi.

    --

    European Common Lisp Meeting, Amsterdam, April 19/20, 2008

    http://weitz.de/eclm2008/

    Real email: (replace (subseq "spamtrap@agharta.de" 5) "edi")

+ Reply to Thread
Page 3 of 6 FirstFirst 1 2 3 4 5 ... LastLast