Legal ANSI comment form?
Larry Kramer
(as opposed to #| ... |#). Is this legal ANSI Common Lisp?
I'm running Allegro 6.0 which is happy with the #- form
with no explicit feature mentioned. MCL complains when
loading the same file.
Thanks,
Larry
Erik Naggum
| I sometimes just use #- to comment out a function or method
| (as opposed to #| ... |#). Is this legal ANSI Common Lisp?
How and why did you even start doing this?
#- and #+ are supposed to be followed by a feature (expression) and then the
form that is conditionalized on that feature. When you think you omit the
feature, what you do is make the following expression the feature expression
and an implementation should look closely at it and barf if it is not valid.
Should an implementation fail to barf, perhaps all that says is that they
could not imagine that anyone would even /try/ something like that.
See Section 24.1.2 (Features).
--
Erik Naggum, Oslo, Norway
Act from reason, and failure makes you rethink and study harder.
Act from faith, and failure makes you blame someone and push harder.
Frode Vatvedt Fjeld
> I sometimes just use #- to comment out a function or method (as
> opposed to #| ... |#). Is this legal ANSI Common Lisp? [..]
Someone, I think here on c.l.l, provided the trick of using #+ignore
in order to achieve this. Now just dont push :ignore onto *features*..
--
Frode Vatvedt Fjeld
Duane Rettig
> I sometimes just use #- to comment out a function or method
> (as opposed to #| ... |#). Is this legal ANSI Common Lisp?
> I'm running Allegro 6.0 which is happy with the #- form
> with no explicit feature mentioned.
Whatever feature you use to describe the ignoring, be sure that that
feature is truly not on the *features* list. I don't think it can
truly be portable, because there is no way to guarantee that no lisps
have that feature defined. In our own source, we sometimes use
#+ignore, or
#+never or #-never (for switching back and forth between two
different implementations)
but it is always with the knowledge of the havoc that would be wreaked
if any developer ever did a
(push :ignore *features*) or
(push :never *features*)
> MCL complains when
> loading the same file.
How does it complain? Are there package qualifiers in the commented
code?
--
Duane Rettig du...@franz.com Franz Inc. http://www.franz.com/
555 12th St., Suite 1450 http://www.555citycenter.com/
Oakland, Ca. 94607 Phone: (510) 452-2000; Fax: (510) 452-0182
Frank A. Adrian
As far as I read the Hyperspec, this seems to be non-conforming code.
Here's my reasoning:
Section 2.4.8.18 says:
"#- is like #+ except that it skips the expression if the test succeeds..."
Section 2.4.8.17 says:
"For a detailed description of success and failure in feature expressions,
see Section 24.1.2.1 (Feature Expressions)."
Section 24.1.2.1 allows four forms for a feature expression, a feature
symbol, (not feature-expression), (and feature-expression*), and (or
feature-expression*).
Now clearly, a null expression is clearly not allowed here, so the syntax is
non-conforming.
Now the specification also says, in section 2.4.8.18, that "#-test
expression == #+(not test) expression".
If there is no test specified, this would equivalence to #+(not) which,
according to Section 24.1.2.1 is also not conformant (note the absence of a
* following the feature expression for the "not" case).
It also can be seen as an "extension" of the language by Allegro because
according to Section 1.6, "An implementation can have extensions, provided
they do not alter the behavior of conforming code and provided they are not
explicitly prohibited by this standard."
Since this non-conformant feature of Allegro seems to work otherwise
according to the standard, it is an extension.
So, the bottom line is:
Fix your code, if you want it to be portable...
faa
Kalle Olavi Niemitalo
> Now clearly, a null expression is clearly not allowed here, so the syntax is
> non-conforming.
What is a null expression? I can't find that in the glossary of
CLHS. The closest thing that comes to my mind is the null list:
#+() (progn)
I suppose that should first read "()" as CL:NIL, which is a
symbol, and then check (member nil *featurep*). Is that right?
Kent M Pitman
It would be weird for () not to mean CL:NIL, but it's worth observing
that #+NIL means :NIL, not CL:NIL, and has in fact been used as a
machine type for NIL (New [sic] Implementation of Lisp), a Lisp that
ran on the Vax after Maclisp and before Common Lisp. Note also that T
is a dialect of Scheme, so relying on degenerate or special names not
to be implementation names is bad, since it's it's tempting fate. One
of these days someone will make a Lisp and call it IGNORE (perhaps
"IGNORE Generates Node Organization from Regular Expressions"), not
realizing there might be a conflict until too late; or perhaps
willfully denying their code will ever be used where it matters ("I
Gather No Opposition Really Exists") or just not caring ("I Gleefully
Notate Obscurely Risking Exception")...
Someone once observed that we'd have a lot fewer awful news stories
about buildings falling into the ocean during hurricanes if people
would stop building buildings there. But people LIKE building buildings
in places that are dramatic, and dramatic places are often on safe.
So too with cute names. Yes, anything CAN be a name, but the really
tempting names are often the ones that cry out "don't use me".
Never say never.
Duane Rettig
> Larry Kramer wrote:
>
> > I sometimes just use #- to comment out a function or method
> > (as opposed to #| ... |#). Is this legal ANSI Common Lisp?
> > I'm running Allegro 6.0 which is happy with the #- form
> > with no explicit feature mentioned. MCL complains when
> > loading the same file.
>
> As far as I read the Hyperspec, this seems to be non-conforming code.
[ ... ]
> Now clearly, a null expression is clearly not allowed here, so the syntax is
> non-conforming.
Either you or I misunderstand what Larry Kramer is asking (or else
he is misunderstanding what he thinks he is doing/seeing and will
have to elaborate anyway).
There is no such thing as just #- by itself; it will always read the next
expression for the test (unless perhaps EOF is encountered). Thus,
#-ignore is the same as #- ignore (note the space in the second
example). Both have a "test" of :ignore. There is _no_ such thing as
a null-expression for the test (whatever expression comes next is
interpreted as the test).
Example:
CL-USER(1): #+ignore 1 #-ignore 2
2
CL-USER(2): #+ ignore 1 #- ignore 2
2
CL-USER(3):
If you look at the description of #+ (which serves as the description
mutatis mutandis for #- ), it says "#+ operates by first reading the
feature expression and then skipping over the form if ..." If you
follow the Reader Algorithm, you find that it skips the first whitespace
it sees, so any spaces encountered are ignored.
> Now the specification also says, in section 2.4.8.18, that "#-test
> expression == #+(not test) expression".
>
> If there is no test specified, this would equivalence to #+(not) which,
> according to Section 24.1.2.1 is also not conformant (note the absence of a
> * following the feature expression for the "not" case).
>
> It also can be seen as an "extension" of the language by Allegro because
> according to Section 1.6, "An implementation can have extensions, provided
> they do not alter the behavior of conforming code and provided they are not
> explicitly prohibited by this standard."
>
> Since this non-conformant feature of Allegro seems to work otherwise
> according to the standard, it is an extension.
I don't see what you are calling an "extension", since the standard reader
algorithm is followed. I think that your #+(not) argument is not applicable
and thus becomes a red herring.
> So, the bottom line is:
>
> Fix your code, if you want it to be portable...
This may indeed be the bottom line, but unless/until we get clarification
from Larry Kramer as to what he was trying to do and assuming, we will not
know if it is programmer error or a bug in MCL.
Paul F. Dietz
and this one always succeed: (and)?
Paul
Hannah Schroeter
Paul F. Dietz <di...@dls.net> wrote:
>Doesn't this feature expression always fail: (or)
>and this one always succeed: (and)?
At least three implementations concur with that.
(list #+(or)1 #+(and) 2) yields (2) in clisp, cmucl and sbcl.
Kind regards,
Hannah.
Takehiko Abe
> This may indeed be the bottom line, but unless/until we get clarification
> from Larry Kramer as to what he was trying to do and assuming, we will not
> know if it is programmer error or a bug in MCL.
um.. What bug? He said he "use #- to comment out a function or method"
"with no explicit feature mentioned." So something like:
#-
(defun foo () nil)
which result in READER-ERROR with MCL4.3.1. I think this is a correct
behavior.
--
This message was not sent to you unsolicited.
Frode Vatvedt Fjeld
> Doesn't this feature expression always fail: (or) and this one
> always succeed: (and)?
Maybe so, but in terms of the choice of feature expression to use for
commenting out forms, I think #+ignore is preferable because it's
vastly more readable, even if it's not 100% theoretically safe.
--
Frode Vatvedt Fjeld
Dorai Sitaram
Duane Rettig <du...@franz.com> wrote:
>Larry Kramer <lkra...@cs.cmu.edu> writes:
>
>> I sometimes just use #- to comment out a function or method
>> (as opposed to #| ... |#). Is this legal ANSI Common Lisp?
>> I'm running Allegro 6.0 which is happy with the #- form
>> with no explicit feature mentioned.
>
>Whatever feature you use to describe the ignoring, be sure that that
>feature is truly not on the *features* list. I don't think it can
>truly be portable, because there is no way to guarantee that no lisps
>have that feature defined. In our own source, we sometimes use
>
> #+ignore, or
>
> #+never or #-never (for switching back and forth between two
>different implementations)
>
>but it is always with the knowledge of the havoc that would be wreaked
>if any developer ever did a
>
> (push :ignore *features*) or
> (push :never *features*)
Arguably the best symbols to use would be things like
`scheme' or `r5rs'. These will never be part of
*features* except in Scheme implementations atop Common
Lisp. The person using #+scheme as a commenting
mechanism in regular Common Lisp situations almost
certainly won't mind that his commenting won't work in
such Scheme implementations.
Fred Gilham
CMU Lisp does this:
* #-
(defun foo () nil)
Error in function EXTENSIONS:FEATUREP:
Unknown operator in feature expression: (:DEFUN :FOO COMMON-LISP:NIL :NIL).
So, as people suspect, it's interpreting the following form as a
features expression. Since it's a list, it winds up trying to treat
`defun' as an operator, like `and', `or' or `not'. The hyperspec
specifies the valid operators for feature expressions (section
24.1.2.1). Apparently CMUCL (and MCL) checks that feature expressions
are valid.
BTW I note that the hyperspec says the following:
(not feature-conditional)
A not feature expression succeeds if its argument feature-conditional fails; otherwise,
it succeeds.
(and feature-conditional*)
An and feature expression succeeds if all of its argument feature-conditionals succeed;
otherwise, it fails.
(or feature-conditional*)
An or feature expression succeeds if any of its argument feature-conditionals succeed;
otherwise, it fails.
It introduces the term `feature-conditional'. What exactly is a
feature-conditional? Is it a feature expression?
--
Fred Gilham gil...@csl.sri.com
In 1981, an OSHA epidemiological study of 2,500 workers, half of whom
had been exposed to PCBs for over 17 years, found that the number of
deaths from cancer was 10 percent lower than what would be expected
for a group with the same profile in the general population.
Ola Rinta-Koski
> Arguably the best symbols to use would be things like `scheme' or
> `r5rs'. These will never be part of *features* except in Scheme
> implementations atop Common Lisp.
Since it's not enforced by anything, I can't see how this would be
any different from 'ignore' or 'never'. Neither string has any
magical meaning within the scope of Common Lisp. In fact, there
would be substantial danger for someone reading the code to get
confused, looking for a meaning where there is none.
--
You were s'posed to laugh! I HIJACKED a 747 to get here!! I hope
those fabulous CONEHEADS are at HOME!! Put FIVE DOZEN red GIRDLES in
each CIRCULAR OPENING!! I can't think about that. It doesn't go with
HEDGES in the shape of LITTLE LULU -- or ROBOTS making BRICKS...
Erik Naggum
| Doesn't this feature expression always fail: (or)
| and this one always succeed: (and)?
Good catch! This is a much better way than to use random names.
Norwegian offers a useful word to remember this. "Avisand" is used for an
untrue news item (avis = newspaper, and = duck), often abbreviated to just
"and". #-(and) could be read as "ignore this mistake". Maybe.
Larry Kramer
>
> "Frank A. Adrian" <fad...@ancar.org> writes:
>
> > Larry Kramer wrote:
> >
> > > I sometimes just use #- to comment out a function or method
> > > (as opposed to #| ... |#). Is this legal ANSI Common Lisp?
> > > I'm running Allegro 6.0 which is happy with the #- form
> > > with no explicit feature mentioned. MCL complains when
> > > loading the same file.
> >
>
> > So, the bottom line is:
> >
> > Fix your code, if you want it to be portable...
>
> This may indeed be the bottom line, but unless/until we get clarification
> from Larry Kramer as to what he was trying to do and assuming, we will not
> know if it is programmer error or a bug in MCL.
Erik in the first reply to my posting identified exactly what
I was trying to do and why it was incorrect. Basically, I
was being lazy and misunderstood the spec in terms of
feature expressions. I was trying to comment out a function using
#-, assuming that since it was followed by whitespace, it would
be taken as some sort of universal "ignore what follows." (Don't
know how I came upon this idea...)
The form following a #- (irrespective of whitespace as Duane points out)
is read as the feature expression. As 24.1.2.1 in the spec reads,
feature expressions should be a boolean combination of features.
Here's an example of what I (incorrectly) was doing,
in order to textually retain the first definition of
func, while using the second definition:
#-
(defun func () <some-code-here>)
(defun func () <new-definition-of-code-here>)
Bottom line, here's what I'll do in the future:
#|
(defun func () <some-code-here>)
|#
(defun func () <new-definition-of-code-here>)
I'll leave it up to others to decide whether Allegro or
MCL should've barfed in the first place. (Sorry, my colleague
is not in yet today, so I don't have access to the exact error
that MCL gave, although I do remember that it reported it as
a "syntax error.")
Thanks,
Larry
Erik Naggum
| Maybe so, but in terms of the choice of feature expression to use for
| commenting out forms, I think #+ignore is preferable because it's
| vastly more readable, even if it's not 100% theoretically safe.
I disagree profoundly. I think Paul's observation is insightful and clever.
Although a naive reader may be stumped upon seeing (or) used for `nil´,
(and) used for `t´, (+) for 0, and (*) for 1, I imagine it would yield a very
pleasant, mathematical realization of the trivial case for these operators.
I certainly smiled in appreciation upon reading Paul's article.
Once internalized, this becomes an idiom that is not at all obscure.
Erik Naggum
| It introduces the term `feature-conditional'. What exactly is a
| feature-conditional? Is it a feature expression?
It is a parameter and as a parameter, I considered it to be only a name.
The parameter's value is a feature expression.
Frode Vatvedt Fjeld
| Maybe so, but in terms of the choice of feature expression to use
| for commenting out forms, I think #+ignore is preferable because
| it's vastly more readable, even if it's not 100% theoretically safe.
Erik Naggum <er...@naggum.no> writes:
> I disagree profoundly. I think Paul's observation is insightful and
> clever.
>
> Although a naive reader may be stumped upon seeing (or) used for
> `nil´, (and) used for `t´, (+) for 0, and (*) for 1, I imagine it
> would yield a very pleasant, mathematical realization of the trivial
> case for these operators. I certainly smiled in appreciation upon
> reading Paul's article.
No disagreement so far.
> Once internalized, this becomes an idiom that is not at all obscure.
Isn't this statement is true by definition? Anything one takes the
trouble to internalize becomes obvious. But in this case and context I
don't see any reason to take that trouble. And also, I believe that
even if (and) and (or) are internalized as general concepts, #+ignore
would still be more readable as a commenting mechanism.
--
Frode Vatvedt Fjeld
Takehiko Abe
> CMU Lisp does this:
>
> * #-
> (defun foo () nil)
>
>
> Error in function EXTENSIONS:FEATUREP:
> Unknown operator in feature expression: (:DEFUN :FOO COMMON-LISP:NIL :NIL).
With MCL4.3.1 I got:
> Error: Reading stream #<LISTENER "Listener" #x83C473E>:
> Illegal #+/- expression (:DEFUN :FOO NIL :NIL).
> While executing: CCL::EVAL-FEATURE
I wonder why the third NIL is in CL package.
> BTW I note that the hyperspec says the following:
>
>
> (not feature-conditional)
> A not feature expression succeeds if its argument
> feature-conditional fails; otherwise, it succeeds.
> [...]
>
> It introduces the term `feature-conditional'. What exactly is a
> feature-conditional? Is it a feature expression?
Wow, its a new term and a glossary section does not list it!
May I say 'I found a limitation'? Nah.
I think feature-conditional is a symbol that may or may not be
present in *FEATURES* list.
Aleksandr Skobelev
[...]
> In our own source, we sometimes use
>
> #+ignore, or
>
> #+never or #-never (for switching back and forth between two
> different implementations)
>
> but it is always with the knowledge of the havoc that would be wreaked
> if any developer ever did a
>
> (push :ignore *features*) or
> (push :never *features*)
It might be better use #+nil or #-nil for this?
Frode Vatvedt Fjeld
> > Error: Reading stream #<LISTENER "Listener" #x83C473E>:
> > Illegal #+/- expression (:DEFUN :FOO NIL :NIL).
> > While executing: CCL::EVAL-FEATURE
>
> I wonder why the third NIL is in CL package.
This is similar to what happens:
(let ((*package* (find-package :keyword)))
(values (read-from-string "nil")
(read-from-string "()")))
=> :nil, nil
I.e binding *package* affects the reading of "nil", but not "()".
--
Frode Vatvedt Fjeld
Duane Rettig
Yes, of course, as is any other behavior, since the behavior for the
above is not specified and is thus programmer error (i.e. not portable),
if that is what Larry Kramer meant in his original post.
Obviously, you also have read Larry Kramer's original post to mean that
he was using #- by itself (and that may in fact what he is saying).
But again, unless he explains what he originally meant, or gives us
examples, we will not know. It is just as easy to interpret his
original message as talking about the #- sharpsign macro _in_ _general_,
which is the normal way to talk about these (whenever I talk about these
sharpsign macros, I always use "#+" or "#-" to describe them, and never
"#+test expression" ...), and that is how I had interpreted Larry's
original message. Indeed, the Ansi Spec deals with them interchangeably;
the "Sharpsign Plus" text mentions #+ twice and "#+test expression"
twice, and the "Sharpsign Minus" description makes it pretty clear that
"#-" and "#+" are names, but "#-test expression" is definitional (and
is defined as "#+(not test) expression").
Duane Rettig
I'm not sure whether a smiley was implied here, but I'll assume it
wasn't (and that this was a serious idea).
As much as I emotionally agree with your clever insurance that a
feature will "never" be defined in a CL program, I must recommend
against it. Just because a user has a Scheme-in-CL implementation
loaded into his CL, doesn't necessarity mean that he is actually
using that Scheme implementation. Most CLs have multiprocessing,
and it would be possible to have one Scheme listener and one or
more (native) CL listeners. Perhaps the Scheme emulation was
loaded in order to run a module that was written for it. CL
)being the open language and the language-writing-language that
it is) must never shut out even competing languages from being
implemented in it.
Another way to look at it: If I had a CL program and it suddenly
broke because I loaded in a module that pushed :scheme onto the
*features* list, then I would have much less justification for
being upset than if I had been using #+ignore or #+never and
someone just stupidly pushed one of these onto *features*.
Duane Rettig
> Doesn't this feature expression always fail: (or)
> and this one always succeed: (and)?
Yes, but would you really want to use these? :-)
Duane Rettig
> Duane Rettig wrote:
> >
> > "Frank A. Adrian" <fad...@ancar.org> writes:
> >
> > > Larry Kramer wrote:
> > >
> > > > I sometimes just use #- to comment out a function or method
> > > > (as opposed to #| ... |#). Is this legal ANSI Common Lisp?
> > > > I'm running Allegro 6.0 which is happy with the #- form
> > > > with no explicit feature mentioned. MCL complains when
> > > > loading the same file.
> > >
> [snip ...]
> >
> > > So, the bottom line is:
> > >
> > > Fix your code, if you want it to be portable...
> >
> > This may indeed be the bottom line, but unless/until we get clarification
> > from Larry Kramer as to what he was trying to do and assuming, we will not
> > know if it is programmer error or a bug in MCL.
>
> Erik in the first reply to my posting identified exactly what
> I was trying to do and why it was incorrect. Basically, I
> was being lazy and misunderstood the spec in terms of
> feature expressions. I was trying to comment out a function using
> #-, assuming that since it was followed by whitespace, it would
> be taken as some sort of universal "ignore what follows." (Don't
> know how I came upon this idea...)
OK, thanks for the clarification. I was wrong in my guess as to what
you were trying to do. The most commonly used (though not foolproof)
method of such commenting is to use a feature that you don't expect to
be defined in your lisp.
> The form following a #- (irrespective of whitespace as Duane points out)
> is read as the feature expression. As 24.1.2.1 in the spec reads,
> feature expressions should be a boolean combination of features.
>
> Here's an example of what I (incorrectly) was doing,
> in order to textually retain the first definition of
> func, while using the second definition:
>
> #-
> (defun func () <some-code-here>)
>
> (defun func () <new-definition-of-code-here>)
>
> Bottom line, here's what I'll do in the future:
>
> #|
> (defun func () <some-code-here>)
> |#
>
> (defun func () <new-definition-of-code-here>)
In cases where you are defining a new version of the same
function, but want to keep the old one around in case the
new one breaks your testing badly, you might want to consider
the #-never / #+never trick that we use; it allows rapid switching
back and forth. So, for example,
#+never
(defun func () <this is the old code>)
#-never
(defun func () <this is the newer, experimental code>)
> I'll leave it up to others to decide whether Allegro or
> MCL should've barfed in the first place. (Sorry, my colleague
> is not in yet today, so I don't have access to the exact error
> that MCL gave, although I do remember that it reported it as
> a "syntax error.")
The answer is, it is undefined - you _cannot_ count on either
behavior.
As for why Allegro CL doesn't barf on #-(some-random-symbol), I'll
take you through it:
1. Allegro CL defines a number of functional extensions to Feature
Extensions. The most notable example is :version>= - it allows
conditional reading of a form based on the version nuumber of
Allegro CL. So, for example,
#+(and allegro-version>= (version>= 6 2)) (defun foo () 'foo)
will only define the function foo if in an Allegro CL of version
6.2 or greater.
2. Note the preliminary test for :allegro-version>= - this test is
recommended for portable code, because the AND expression should
kick out of any lisp that doesn't have :allegro-version>= on the
*features* list, so the version>= expression should never be
evaluated. This allows these extensions to be used in source code
that is ported between Allegro CL and other CLs.
3. Next, because Feature Expressions are recursively defined,
the expression (version>= 6 2) is itself a Feature Expression.
You wouldn't want to say #(version>= 6 2) (defun foo () 'foo)
in portable code, but it is legal with our extension.
4. Finally, the decision not to call out an error when a Feature
Expression is not recognized was made based on a Good Neighbor
policy: if our reader reads a Feature Expression it doesn't
recognize, chances are that it is some other implementation's
own extension, and chances are again that the actual feature was
meant for that implementation only, so we interpret it that way
and count the Feature Expression as having failed.
Duane Rettig
Kent Pitman already pointed out elsewhere in this thread that there is
a Lisp called NIL, and :nil is a perfectly valid feature, and thus is
not a good feature to use as a never-defined feature.
Christopher Browne
> * Paul F. Dietz
> | Doesn't this feature expression always fail: (or)
> | and this one always succeed: (and)?
>
> Good catch! This is a much better way than to use random names.
>
> Norwegian offers a useful word to remember this. "Avisand" is
> used for an untrue news item (avis = newspaper, and = duck), often
> abbreviated to just "and". #-(and) could be read as "ignore this
> mistake". Maybe.
OK, so this means it's necessary to be literate in Norwegian to
understand _wrong_ Lisp code?
I think that makes a whole lot of flame wars make totally a lot more
sense...
--
(reverse (concatenate 'string "gro.gultn@" "enworbbc"))
http://cbbrowne.com/info/oses.html
They are called computers simply because computation is the only
significant job that has so far been given to them. -- Louis Ridenour
Michael Sullivan
> I disagree profoundly. I think Paul's observation is insightful and clever.
> Although a naive reader may be stumped upon seeing (or) used for `nil´,
> (and) used for `t´, (+) for 0, and (*) for 1, I imagine it would yield a
> very pleasant, mathematical realization of the trivial case for these
> operators. I certainly smiled in appreciation upon reading Paul's
> article.
> Once internalized, this becomes an idiom that is not at all obscure.
It is clever, but strange. Until you posted this, my intuition thought
that (or), if it yielded anything, should yield true, and (and) false.
Now, I see that it's getting the identity of the operator, which makes a
kind of sense, but I'm not sure I'd ever guess it. I don't see any
reason why using an operator with no arguments should necessarily return
anything. Is this is the spec, or is there some mathematical basis/use
that I'm missing?
Michael
--
Michael Sullivan
Business Card Express of CT Thermographers to the Trade
Cheshire, CT mic...@bcect.com
Nils Goesche
> Erik Naggum <er...@naggum.no> wrote:
>
> > I disagree profoundly. I think Paul's observation is insightful and clever.
>
> > Although a naive reader may be stumped upon seeing (or) used for `nil´,
> > (and) used for `t´, (+) for 0, and (*) for 1, I imagine it would yield a
> > very pleasant, mathematical realization of the trivial case for these
> > operators. I certainly smiled in appreciation upon reading Paul's
> > article.
>
> > Once internalized, this becomes an idiom that is not at all obscure.
>
> It is clever, but strange. Until you posted this, my intuition thought
> that (or), if it yielded anything, should yield true, and (and) false.
>
> Now, I see that it's getting the identity of the operator, which makes a
> kind of sense, but I'm not sure I'd ever guess it. I don't see any
> reason why using an operator with no arguments should necessarily return
> anything. Is this is the spec, or is there some mathematical basis/use
> that I'm missing?
You can define operators any way you want, of course. But as it turns
out, it is often useful to define operators in a way that they return
a neutral element when applied to zero arguments. For instance,
\sum_{i=1}^n i = n(n+1) / 2
is true even for 0, if you define an empty sum to be zero,
\prod_{i=1}^n i = n!
is true even for 0 if you define an empty product to be one. There
are many more examples. 0 is the neutral element for addition, 1 for
multiplication. Now,
(and x y) is always the same as (and t x y)
and
(or x y) is always the same as (or nil x y).
That's why I'd expect (or) to be nil, and (and) to be t.
Also, you might argue: ``If (and) was false, then there should be one
argument of AND which is false (but there isn't)''. And
``If (or) was true, there should be one argument of OR that is true
(but there isn't).''
Something like that.
Regards,
--
Nils Goesche
"Don't ask for whom the <CTRL-G> tolls."
PGP key ID 0x0655CFA0
Christopher C. Stacy
(Occasionally I have used things like LOSER, LOSSAGE, UNIMPLEMENTED,
NEVER, and ALWAYS, but only temporarily -- not in real code.)
How about just testing *FEATURES* in the SYSDCL (whatever your
implementation does for that) to make sure that :IGNORE isn't there?
You won't compile or load on platforms that have defined that feature,
but at least there will be no mystery.
Here's a can of worms for ya: Maybe a good practice would be to say
that feature names should always be qualified names (like Java packages).
That's not a complete suggestion, of course; let's play with this idea.
Dorai Sitaram
Instead of putting restrictions on the names of legit
features, I would use something like
<programmer-name>-sez-ignore-this
(where <programmer-name> is a metavariable of course)
for the bogus feature name that marks the #+
comment.
It is instantly recognizable as a comment to the
code-browsing eye, and it lets one track down who's
responsible for the comment. It is also highly
unlikely, even unlikelier than are `ignore' and
`debug', to be in *features*. I doubt that even Kent
Pitman at his most counterexample-happy can find a
scenario where symbols like this have good reason
to be in *features*.
Thomas A. Russ
Hmmm. What about empty forms in OR or AND?
#+(or)1 2 => 2 only
#-(and)1 2 => 2 only
#-(or)1 2 => 1 2
#+(and)1 2 => 1 2
Tested in ACL 5.0.1, MCL 4.3.1, CMUCL 18c.
--
Thomas A. Russ, USC/Information Sciences Institute t...@isi.edu
Duane Rettig
> I have always used #+IGNORE and #+DEBUG.
>
> (Occasionally I have used things like LOSER, LOSSAGE, UNIMPLEMENTED,
> NEVER, and ALWAYS, but only temporarily -- not in real code.)
Another one we use temporarily is :notyet or :not-yet, for Work in
Progress.
Iain Little
> Erik Naggum <er...@naggum.no> wrote:
>
>
>> I disagree profoundly. I think Paul's observation is insightful and clever.
>
>
>> Although a naive reader may be stumped upon seeing (or) used for `nil´,
>> (and) used for `t´, (+) for 0, and (*) for 1, I imagine it would yield a
>> very pleasant, mathematical realization of the trivial case for these
>> operators. I certainly smiled in appreciation upon reading Paul's
>> article.
>
>
>> Once internalized, this becomes an idiom that is not at all obscure.
>
>
> It is clever, but strange. Until you posted this, my intuition thought
> that (or), if it yielded anything, should yield true, and (and) false.
>
> Now, I see that it's getting the identity of the operator, which makes a
> kind of sense, but I'm not sure I'd ever guess it. I don't see any
> reason why using an operator with no arguments should necessarily return
> anything. Is this is the spec, or is there some mathematical basis/use
> that I'm missing?
>
>
> Michael
>
One thing that I noticed while reading this is that if you consider the
above functions to be the binary operators of a group, then the result
of not giving the function any arguments is the identity element. But
you don't need to know anything about groups to see the pattern:
(or nil n) => n
(and t n) => n
(+ 0 n) => n
(* 1 n) => n
(I only picked this up because one of the things that I am studying at
the moment is group theory...)
Erik Naggum
| Once internalized, this becomes an idiom that is not at all obscure.
* Frode Vatvedt Fjeld
| Isn't this statement is true by definition?
No. You can internalize something that still remains obscure, not only to
others, but to yourself. That is, some things never progress beyond passive
vocabulary. Some image that you understand when you meet it, but it takes
effort to /remember/ how works, is not used. #-(and) immediately makes so
much sense that it becomes part of your active vocabulary. I think of this
the same way I think of string theory (not the character strings :). It is
very hard for me to read and follow, and my brain just drops it after a few
months so I no longer even remember that I grasped something when I pick up
a new paper. There is no lack of understanding on my part when I immerse
myself in it for the umpteenth time, but it runs counter to my intuition in
a weird way that makes me always stand outside and look in. I have not yet
been able to /enter/ the world of string theory in a way that stays with me
when I put down another excellent article or book on it.
| Anything one takes the trouble to internalize becomes obvious.
If you can say this, you have only tried with easy things. The curse of
high intelligence is that you think /all/ things are easy and are unprepared
for the really hard things. People of lesser intelligence have been used to
dealing with things they do not understand all their lives, and they have
learned to deal with this in ways that very smart people can never dream of
grasping. The kinds of things that you /cannot/ wrap your head around are
the real defining attributes of your intelligence.
| But in this case and context I don't see any reason to take that trouble.
I think you are still looking at it from outside. That (+) => 0, etc, are
such marvelously elegant things that I embrace them immediately.
| And also, I believe that even if (and) and (or) are internalized as general
| concepts, #+ignore would still be more readable as a commenting mechanism.
Not if you think about it, which you should. "Conditionalize this
expression on the presence of the feature called IGNORE" is /actually/
obscure -- but you have internalized it in /spite/ of its meaning. I think
it is much better to have a real feature and conditionalize on its absence.
E.g., in Allegro CL source, I would much rather see #-allegro than #+ignore.
In comforming code, you could write #-common-lisp and know that it would
never be read because if you write Common Lisp at all, it /will/ be present.
I used to not care about #+ignore, but now I do not care /for/ it. It is a
misguided abuse of the feature mechanism that overloads natural language
semantics on the name of a feature and that conflates several concept spaces
in /unnatural/ ways. If you think /in/ Common Lisp, you would not invent
this thing. You would invent #+(or) or #-common-lisp, instead.
Erik Naggum
| How about just testing *FEATURES* in the SYSDCL (whatever your
| implementation does for that) to make sure that :IGNORE isn't there?
| You won't compile or load on platforms that have defined that feature,
| but at least there will be no mystery.
How about testing for something you know is there, instead?
That way, you are actually always safe.
Erik Naggum
| Another way to look at it: If I had a CL program and it suddenly broke because
| I loaded in a module that pushed :scheme onto the *features* list, then I would
| have much less justification for being upset than if I had been using #+ignore
| or #+never and someone just stupidly pushed one of these onto *features*.
FWIW, I think it is stupid to rely on names out of your control. Since you
control a whole bunch of features yourself, there are many ways to ensure
that you test for something that you know is there instead of believe will
not be there. For the "future" case, you could also use a future version of
Allegro CL. Suppose you will never have code for Allegro CL 10.0 while you
are working on Allegro CL 6.3 and 7.0 and perhaps 8.0. You could write
#+(version>= 10 0) for-further-study
to signal to your developers that this is way into the future. You could
also use this mechanism to ensure that features were included in a future
version despite the cvs branch it was inserted on. Going through the code
to find places where a future version were specified would be a good way of
ensuring that those future things were indeed brought into the present.
Using a feature like debug-<package> would be OK, however, since it would
presumably be code that would actually be processed if you requested
debugging of that package.
This discussion has changed my view on #+ignore and the like. From not
having an opinion on it to having an actual opinion on it, I have come to
think it is wrong to use /any/ non-existing feature as a marker that some
code should not be processed, and in particular that overloading natural
language semantics on formal constructs is a form of intellectual sloppiness
that should be avoided.
Erik Naggum
| The most commonly used (though not foolproof) method of such commenting is
| to use a feature that you don't expect to be defined in your lisp.
Argh! This is so dumb. Think about it. You remove a truly large fraction
of your vocabulary from possible feature names. Think of all the synonyms
that various programmers will use for this out of the misguided notion that
feature names "mean" something. They should have the meaning that the thing
they /name/ have. If you want to exclude something, you should do so based
on something you /can/ know, not something you /hope/ you may know, but are
only guessing about. In this age of multiculturalism and such, consider the
mess if you run the whole gamut of Roget's-equivalents in all languages
where people use Common Lisp, and you find that there is a significant risk
of naming your feature something that "means" something in some other
language, and obvious words can no longer be used for features because some
idiot may have used it for a conditional. That is just /wrong/. Let me put
this intensely: Never say #+never!
I think Franz Inc code should use #-franz or something, and portable code
should use #-common-lisp to exclude code that is never going to be parsed.
This if fool-proof. If someone steals your code and they do not define the
franz feature in time, you also get the extra benefit of taking revenge.
If your application includes a feature symbol on `*features*´, then you can
use that symbol to exclude code, too. E.g., if you write an application
that pushes the (legal) feature lex-nemini-facit-injuriam on `*features*´,
you actually /know/ that this feature will be there in your application, and
since you control this yourself, you can use #-lex-nemini-facit-injuriam to
argue that some code violates this feature, i.e., it would do injury if that
feature was absent.
Erik Naggum
| Is this is the spec, or is there some mathematical basis/use that I'm
| missing?
I guess the latter. I have talked about this with a few people (irc) and
unmathematical people do not even understand that (+) => 0 and (*) => 1.
The spec is quite clear that `and´, `or´ and a few other obvious identity
candicates return their identity value. That is, (operator argument) is
identical to (operator (operator) argument), which has as a corrollary
precisely that (operator argument) is identical to argument. This is very
sound mathematically. That there are such hidden gems in Common Lisp
delight me just as much as grokking some mathematical concept.
Christopher C. Stacy
Erik> * Christopher C. Stacy
Erik> | How about just testing *FEATURES* in the SYSDCL (whatever your
Erik> | implementation does for that) to make sure that :IGNORE isn't there?
Erik> | You won't compile or load on platforms that have defined that feature,
Erik> | but at least there will be no mystery.
Erik> How about testing for something you know is there, instead?
Erik> That way, you are actually always safe.
It's just because I want the good names IGNORE and DEBUG to be mine.
Kalle Olavi Niemitalo
> It would be weird for () not to mean CL:NIL, but [...about :NIL]
Sure. I was just wondering if the feature expression evaluator
(EXT:FEATUREP in CMUCL) is required to treat CL:NIL as a symbol
and not as an empty list, which would be invalid.
(CMUCL draws the line between conses and atoms, allowing even
non-symbols as features.)
Michael Sullivan
> * Michael Sullivan
> | Is this is the spec, or is there some mathematical basis/use that I'm
> | missing?
>
> I guess the latter. I have talked about this with a few people (irc) and
> unmathematical people do not even understand that (+) => 0 and (*) => 1.
> The spec is quite clear that `and´, `or´ and a few other obvious identity
> candicates return their identity value. That is, (operator argument) is
> identical to (operator (operator) argument), which has as a corrollary
> precisely that (operator argument) is identical to argument. This is very
> sound mathematically. That there are such hidden gems in Common Lisp
> delight me just as much as grokking some mathematical concept.
Yes, after seeing Nils's post and thinking about it some more, I
realized this make writing certain kinds of operators/functions much
more elegant than having blank operators return nil, or error in some
way. Maybe one of these days I should actually read the spec.
Erik Naggum
| Maybe one of these days I should actually read the spec.
That is really so highly recommended that not doing it is on par with
failing to realize that you need a driver's license if you want a fancy car.
Duane Rettig
> * Duane Rettig
> | Another way to look at it: If I had a CL program and it suddenly broke because
> | I loaded in a module that pushed :scheme onto the *features* list, then I would
> | have much less justification for being upset than if I had been using #+ignore
> | or #+never and someone just stupidly pushed one of these onto *features*.
>
> FWIW, I think it is stupid to rely on names out of your control.
The very fact that we use the *features* list automatically puts it into
that category, although it is not _completely_ out of our control.
The basic problem with *features* is that it has no official registry of
names. And I don't think anyone ever intended such a thing, and if I'm
correct then *features* was never intended to be a perfectly controllable
thing.
Within a specific set of sources, features aid in the ability for the
programmer not to have to change his source code as much. As the source
code expands its scope in many directions, the conditionalizations allow
for such expansions in an orderly manner.
- One direction that source can take (for example, in code we use internally)
is that new architectures are added to the list for which the source is
applicable. Whether or not the source must be changed to add these new
architectures is dependent on how clever we were in specifying the feature;
specific enough to clarify the feature, and general enough to include all
architectures. So, for example, some code that says
#+big-endian (foo)
#+little-endian (bar)
#-(or big-endian little-endian) (error ...)
is much more likely to left alone when adding a new architecture than
#+(or sparc hp ibm sgi) (foo)
#+(or x86 alpha) (bar)
#-(or sparc hp ibm sgi x86 alpha) (error)
even though the same thing is intended in both versions.
- Another more public way that source code is conditionalized is
with the use of brand identifiers. This is where *features* could
use a registery, but probably never will. Publically available
(or private, but shared) source has been around for a long time in
the Lisp world, and various vendors have had to work out how to
identify each lisp:
Two examples of ambiguous names I can recal are #+gcl and #+ccl.
The former might be either "Golden Common Lisp" or "GNU Common Lisp".
And I may be misremembering, but I think I've seen at least one piece
of source conditionalized for Corman Lisp whose #+ccl clashed with the
older "Corral Common Lisp" (which I believe eventually became MCL).
These ambiguities usually don't last long, but it either takes vendors
changing their standard branding *features*, or users changing their
source code. The latter is much harder to do when the source is widely
shared.
By the way, in another article elsewhere on this thred you mentioned that
we should use #-franz for conditionalization. We can't do that, because
that would break conditionaliztions for another, older lisp called
"Franz Lisp"...
> Since you
> control a whole bunch of features yourself, there are many ways to ensure
> that you test for something that you know is there instead of believe will
> not be there.
Yes, you mentioned this also in that other article and I had though of it
at about the same time - How about:
(push :comment *features*)
...
#-comment (foo)
as a way to always guarantee success in ignoring the code?
> For the "future" case, you could also use a future version of
> Allegro CL. Suppose you will never have code for Allegro CL 10.0 while you
> are working on Allegro CL 6.3 and 7.0 and perhaps 8.0. You could write
>
> #+(version>= 10 0) for-further-study
>
> to signal to your developers that this is way into the future. You could
> also use this mechanism to ensure that features were included in a future
> version despite the cvs branch it was inserted on. Going through the code
> to find places where a future version were specified would be a good way of
> ensuring that those future things were indeed brought into the present.
If we were going to do that, I would not want to use 10, since that could be
only 5 or 10 years down the road, which is short enough that it is not a
guarantee, but long enough that I would not want to have to remember back that
far to the time when we generated that code, and _why_ we conditionalized it
that way. If we are going to really remove probabilities, let's go with
most-positive-fixnum instead of 10. :-)
> Using a feature like debug-<package> would be OK, however, since it would
> presumably be code that would actually be processed if you requested
> debugging of that package.
But packages, like features, are not registered, and thus are not guaranteed
to be unique. The problem thus remains that someone else could push the
same feature for a different purpose in their source code. If there is a
requirement that that source work in the same lisp, then source code changes
are already required, anyway. To tie the feature to the package name
centralizes the problem (a Good Thing) but the same amount of source code
may have to be changed if, for example, the package names clash.
> This discussion has changed my view on #+ignore and the like. From not
> having an opinion on it to having an actual opinion on it, I have come to
> think it is wrong to use /any/ non-existing feature as a marker that some
> code should not be processed, and in particular that overloading natural
> language semantics on formal constructs is a form of intellectual sloppiness
> that should be avoided.
I share your concern, but not your opinion, because of my own experience in
what works and what doesn't work in the conditonalization world of lisp code,
and although there are pitfalls to features lists, some are more likely to
occur than others, and #+ignore is not one of them that is as likely to
be a problem.
Paul F. Dietz
Somehow one should be able to use this idiom:
#+#.(predicate-evaluating-to-a-feature-expression) ...
instead of having to preload attributes of the system as
symbols pushed onto the *feature* list.
Paul
Erik Naggum
| Somehow one should be able to use this idiom:
|
| #+#.(predicate-evaluating-to-a-feature-expression) ...
|
| instead of having to preload attributes of the system as symbols pushed onto
| the *feature* list.
A useful extension to the feature scheme would be to treat any form whose
car was not the defined `and´, `or´ and `not´ as a macro to be expanded.
That way, a feature expression could evaluate to (or) or (and) transparently
if the macro returned just `nil´ or `t´, too, hiding what appears to trigger
some irrational aesthetics factor that considers #+ignore OK even though it
totally confuses the semantic spaces of feature names and natural languages.
Tim Bradshaw
> The basic problem with *features* is that it has no official
> registry of names. And I don't think anyone ever intended such a
> thing, and if I'm correct then *features* was never intended to be a
> perfectly controllable thing.
But it's very easy to invent names which essentially are known to be
controlled. We use a domain prefix for almost everything - an idea
borrowed from Java via, I think, Franz's hierarchical package name
documentation. So all our features start COM.CLEY (or ORG.TFEB
depending on which hat I have on). I actually use a mixed convention
of <system-name>/qualifier, so I'd probably use, say:
:COM.CLEY.WELD/NEVER as a `never' feature (I have :COM.CLEY.WELD/DEBUG
for stuff that should be processed only if I want verbose debugging,
say). Similarly we use prefixed package names (but not the /
convention, not sure why).
I figure if someone else starts pushing features with names beginning
COM.CLEY, then they deserve what they get - and similarly if we
started using COM.FRANZ, say.
If you use names prefixed by a DNS domain that you own, it seems to me
that you don't need a global registry, because DNS provides it.
--tim
Thomas F. Burdick
This is essentially the solution I've been using. At one point I was
naming my packages/features things like TFB.GARNET-EXTENSIONS. I
stopped when you yourself posted a reply to one of my c.l.l articles
that began the quoted text from me with "I wrote..." (because your
newsreader recognized my/your initials). Unfortunately, for
completely general-purpose things (ie, not tied to a product
associated with a shorter domain name), I end out with some
attrociously long names: eg, EDU.BERKELEY.OCF.TFB.GARNET-EXTENSIONS.
For packages, I can use nicknames, but for features, it gets ugly.
It's not just the length (I always edit code in 100-column windows),
really it's the ability to scan code and see the names. When I scan
names prefixed like this, I see the domain name part. Maybe I'll try
using / after the domain part -- it seems to emphasize the important
part better.
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
Tim Bradshaw
> This is essentially the solution I've been using. At one point I was
> naming my packages/features things like TFB.GARNET-EXTENSIONS. I
> stopped when you yourself posted a reply to one of my c.l.l articles
> that began the quoted text from me with "I wrote..." (because your
> newsreader recognized my/your initials). Unfortunately, for
> completely general-purpose things (ie, not tied to a product
> associated with a shorter domain name), I end out with some
> attrociously long names: eg, EDU.BERKELEY.OCF.TFB.GARNET-EXTENSIONS.
> For packages, I can use nicknames, but for features, it gets ugly.
> It's not just the length (I always edit code in 100-column windows),
> really it's the ability to scan code and see the names. When I scan
> names prefixed like this, I see the domain name part. Maybe I'll try
> using / after the domain part -- it seems to emphasize the important
> part better.
Well, one question is how often do you end up typing these things? I
changed to long names, and I stressed about this to the extent that I
looked at Franz's relative package names trick, but in practice I've
never used it, because I just don't type package names very much, and
the same goes for features. I think that for packages, the relative
name trick might be quite useful, because I'm aware that some people
prefer to type package names rather than use a whole load of random
packages. And I think Franz-compatible relative names are available
for at least CMUCL, ACL and LW now. For features I find it hard to
imagine a case where I'd be typing them so often that I'd care, unless
I was maintaining something which was densely conditionalised and thus
already in hell. When code gets like that the right solution is to
become a gardener...
Using package nicknames is not a solution because the nicknames can
collide just as easily as the full names.
I guess for features the solution *might* be to have a notion of
`current feature context' and then have #+/#- parse names beginning
with `.' relative to that. But it's really a non-problem for me, so
I've never worried about it.
--tim
Frode Vatvedt Fjeld
> This discussion has changed my view on #+ignore and the like. From
> not having an opinion on it to having an actual opinion on it, I
> have come to think it is wrong to use /any/ non-existing feature as
> a marker that some code should not be processed, and in particular
> that overloading natural language semantics on formal constructs is
> a form of intellectual sloppiness that should be avoided.
I think you are over-rationalizing a rather mundane concept. I can see
there is an overloading of concepts going on, and to some degree this
also runs counter to my aesthetic sense. But I have a bigger problem
with #+(or) or similar variants like #+(and x (not x)), which--while
neat in a slightly geeky way--I'd sooner associate with socially
excluding, "wizard"-friendly languages, rather than the lucidness I've
come to expect with Common Lisp.
Let me propose #+false as a mechanism that to a lesser extent confuses
separate concepts, even if it still only works by accident. For the
next Common Lisp, I'd like to see the feature language extended with a
proper false (and true) expression. This as a perferrable alternative
to using up another macro character to achieve form-scope comments. I
actually think I'd lean towards having "ignore" be this false
expression, acknowledging that feature expressions is a tool to aid
programmers in system construction, not a mirror of formal
mathematical logic.
--
Frode Vatvedt Fjeld
Erik Naggum
| I think you are over-rationalizing a rather mundane concept.
Huh?
| But I have a bigger problem with #+(or) or similar variants like #+(and x
| (not x)), which--while neat in a slightly geeky way--I'd sooner associate
| with socially excluding, "wizard"-friendly languages, rather than the
| lucidness I've come to expect with Common Lisp.
I really wonder what you are afraid of and how you come up with this highly
emotional position.
| Let me propose #+false as a mechanism that to a lesser extent confuses
| separate concepts, even if it still only works by accident.
This "proposal" and the existing abuse of #+ and #- mean that we should no
longer read #+feature as "process the following expression if the feature is
present in the system" and #-feature as "process the following expression if
feature is not present in the system", but as something entirely different.
It was only when I started to /read/ the #+ and #- out loud that I found
#+ignore and the like to be astonishingly counter-productive and abusive of
the concepts involved.
How do you /read/ #+feature? What does it /mean/ to you?
From what you write above, I believe you do not think about what you read,
but sort of go by a feeling that #+feature means "process the following when
some fuzzy interpretation of feature makes intuitive sense apart from what
it actually means". This is only tolerable when people are ignorant of the
language or when they do not understand what they are doing. Such lack of
appreciation and understanding will necessarily lead to such fantastically
counter-productive attitudes as branding /actual/ understanding of the
language as "geeky" and "wizard-friendly". Learn the language instead of
trying to adopt some fuzzy pre-understanding intuition to what you read.
Your strong resistance to learning the nature of feature expressions is
disheartening. And setting yourself up so you cannot embrace a slightly
geeky, socially excluding, "wizard"-friendly language is not conducive to
getting the point. You have to back down from this silly pontificated
opinion because it is false, and you have just made that very much harder
for yourself. Instead of moving towards a solution, you have solidified an
abuse of the feature expression. If you wish to make sense and convince
people that such abuse should be tolerated, you have to remove some of the
emotional ties you have presented and back it up with reasoning. OK?
Frode Vatvedt Fjeld
> I really wonder what you are afraid of and how you come up with this
> highly emotional position.
My concern is not to push CL towards being less readable than need be.
> [...] How do you /read/ #+feature? What does it /mean/ to you?
Well, how do you read out #+(or), exactly? Feature expressions is
already a language, complete with its own interpreter. My position is
to mold that language into being as useful and readable as possible,
rather than holding it to some measure of conceptual purity.
> From what you write above, I believe you do not think about what you
> read, but sort of go by a feeling that #+feature means "process the
> following when some fuzzy interpretation of feature makes intuitive
> sense apart from what it actually means".
No, #+false or even #+ignore would mean "process the following when
the feature that is guaranteed not to be present in any system is
present". Which in the current language can be spelled out as #+(and x
(not x)), which can be reduced to #+(or). By endorsing #+(or) you have
clearly already made that leap from "does this feature exist?" to
"evaluate this expression", so I really can't understand your
complaining over this.
> This is only tolerable when people are ignorant of the language or
> when they do not understand what they are doing. Such lack of
> appreciation and understanding will necessarily lead to such
> fantastically counter-productive attitudes as branding /actual/
> understanding of the language as "geeky" and "wizard-friendly".
> Learn the language instead of trying to adopt some fuzzy
> pre-understanding intuition to what you read.
I never branded anyone's understanding of this, I was describing the
language/notation that would result from adopting #+(or) etc.
What do you expect the average new CL student's reaction to seeing
#+(or) will be?
Fuzzy pre-understanding is a good thing, it's how everyone gets by in
a complex world. Also in a learning situation it is almost essential,
so long as the implied understanding follows the pre-understanding.
But I believe in this case the issue is rather about something quite
different, which might be called fuzzy post-understanding. After you
have understood something, you keep it in your active vocabulary by
means of any number of fuzzy mechanisms. I believe that's how the
brain works. In my view, #+(or) provides very little for that part of
the brain to work with (in other words, it's unreadable), and for no
particularly good reason other than some sense of purity that, in this
smallest and simplest of languages, is worthless. (Again, that's not
worthless in the sense that it's a concept that is worthless to
understand and appreciate, but worthless as a consideration in which
notation to use.)
> If you wish to make sense and convince people that such abuse should
> be tolerated, you have to remove some of the emotional ties you have
> presented and back it up with reasoning. OK?
I tried to, actually. The short form is this: 1. We need a form-scope
comment syntax. 2. Since we already have #+ and #-, using up another
macro character might not be worth it (but if the distaste for
"intellectual sloppiness" is very strong, it might be worth it after
all, #; could be a strong candidate). 3. #+(or) etc. is too
cryptic. 4. So define a less cryptic false feature expression.
--
Frode Vatvedt Fjeld
Daniel Barlow
> No, #+false or even #+ignore would mean "process the following when
> the feature that is guaranteed not to be present in any system is
> present".
That'd be #+cltl2, then :-)
Actually, I wonder why we don't just use #-common-lisp for ignoring
forms. Not only should that feature be present in every "Common Lisp
family" language, but it's also more obvious on casual inspection than
#+(or)
Comments? (ahaha)
-dan, still writing code that won't run in the New Implementation of Lisp
--
http://ww.telent.net/cliki/ - Link farm for free CL-on-Unix resources
Thien-Thi Nguyen
> 3. #+(or) etc. is too cryptic.
a few lines later, someone might see `(or E1 E2)' instead of `unless', or
`(and E1 E2)' instead of `when'. probably it won't be cryptic if these
constructs are seen to be used in different contexts.
one could argue that the whole practice of programming is cryptic (by
definition!), so when congruent usage-meaning mapping shows up like this, it
is actually a way to allow the mental model to settle to a more consistent,
lower-energy-requiring form. the student that sees this moves ahead quicker.
thi
Kent M Pitman
> Actually, I wonder why we don't just use #-common-lisp for ignoring
> forms. Not only should that feature be present in every "Common Lisp
> family" language,
Because people share code between CL and non-CL lisps.
> but it's also more obvious on casual inspection than
> #+(or)
Apparently not since you either overlooked or failed to acknowledge
the complete meaning of #-Common-Lisp. I'd say that included in the
meaning of obvious is not only "quick" but "correct". Of the two
notations #-common-lisp and #-(or) that you cited, you got only
one correct, and of those the fastest was #-(or). So it WAS
actually most obvious, too ... at laest of these.
But that's just my opinion. ;)
Besides, obviousness if a function of time. If people used #+(or) it
would become more obvious. (Sort of like the US courts once ruled that
you had an expectation of privacy in certain situations that the
government has, I'm told more recently argued that since people are so
doubtful that the rights are protected, that there is no expectation
of privacy left to violate...)
Thomas F. Burdick
Hmm, yes, looking at the relative-package support has been on my to-do
list for a while now, maybe I should check it out. At the moment I'm
using MCL, CLISP, CMUCL and SBCL all pretty regularly, so I'm not sure
I want to get too dependant on it, though...
> For features I find it hard to imagine a case where I'd be typing
> them so often that I'd care, unless I was maintaining something
> which was densely conditionalised and thus already in hell. When
> code gets like that the right solution is to become a gardener...
It's not typing them that I mind, it's visually scanning through code
that's the problem. I don't make heavy use of contitionalization, but
often I'll write code so that if, say, garnet, or my package of
garnet-related utilities, isn't loaded, significant chunks of
functionality will disappear, but the rest of the code will load just
fine. So depending on the program, I might have several
conditionalizations in there. Using them *this* way, it doesn't make
me want to go back to serving coffee.
> Using package nicknames is not a solution because the nicknames can
> collide just as easily as the full names.
Well, yes, except I have a utility that manages the naming and
renaming of packages for me O:-)
Thomas F. Burdick
> Let me propose #+false as a mechanism that to a lesser extent confuses
> separate concepts, even if it still only works by accident.
Someone who pushes :nil or :ignore or :debug onto *features* is going
to know there could be trouble. On the other hand, I wouldn't think
twice before using :false. This is IMO a *very* bad plan.
> For the next Common Lisp, I'd like to see the feature language
> extended with a proper false (and true) expression.
Yuck. Remember, this is just a hack to allow you to comment out an
s-expression. Once you're getting into always-true or always-false
feature "tests", you're not really using the feature system anymore.
If we're going to extend the language to support commenting out
s-expressions, why not extend it to do just that. Make #; mean
"discard the next s-expression". Don't standardize ugly hacks.
> This as a perferrable alternative to using up another macro
> character to achieve form-scope comments.
How on earth do you figure?
Erik Naggum
| My concern is not to push CL towards being less readable than need be.
Curiously, we have exactly the same concern. How about that?
| > [...] How do you /read/ #+feature? What does it /mean/ to you?
|
| Well, how do you read out #+(or), exactly?
I would appreciate an answer to my questions before you fire off
counter-questions as if this was some soft of political campaign.
Since I understand how (or) works in general in Common Lisp, I find no
problems reading it exactly as it stands: First, use the following expression
when the feature expression holds. And second, which is never. Likewise,
(and) always holds. I also think of (or x y z) as the first true value of
x, y, and z and (and x y z) as the first false value of x, y, and z.
Contrary to how many people read (< a b c), I read it as testing whether a,
b, and c, in that order are monotonically increasing values. This is
probably because I read < as "less than", I think of the symbol as
indicating growth and increasing values. Color me different, but long ago,
I discovered that so much of mathematics became unduly hard to grasp if I
thought in terms of operations because the operations quickly became so
involved that I could not efficiently abstract them away. It is crucial that
one understands the relationships involved rather than the operations to
compute the values if you want to think mathematically. I see that people
who think in terms of operations never get very far in mathematics, too, so
I think that I got this part right.
That is, when I see (+) I read "the identity under addition" not "add no
numbers together". The identity under veljunction
| My position is to mold that language into being as useful and readable as
| possible, rather than holding it to some measure of conceptual purity.
If there is a conflict here, you have the conceptual purity wrong. I think
you are massively overreacting to something quite different from what is at
hand, and I cannot determine what it is.
| No, #+false or even #+ignore would mean "process the following when the
| feature that is guaranteed not to be present in any system is present".
What a silly way to think about this. My god. There is no such guarantee
for any individual /feature/ -- you had to create it ex nihilo. (or) and
(and), however, embody that guarantee for /feature expressions/.
| Which in the current language can be spelled out as #+(and x (not x)), which
| can be reduced to #+(or).
It is nothing if not silly first to invent a convoluted form that does not
follow from the premisese and then to reduce it (I am not aware of any rules
that make such a reduction possible, though), but I guess this is how you
think about this and why you cannot come to grips with the simplicity and
elegance of (or) and (and). I see this as evidence of a lack of appreciation
of the identity values of operators, which seems incongrous and unexpected.
I hope you will find the time to stop warring so stupidly and tell me /why/
you invented this convoluted form and how you reduced it, in that order.
| By endorsing #+(or) you have clearly already made that leap from "does this
| feature exist?" to "evaluate this expression", so I really can't understand
| your complaining over this.
I have seldom seen less honest argumentation and equivocation in this
newsgroup. I have not made any leap like you say I have. Damn you for
imputing such stupidity to me! Just because you see things differently does
not give you any right you make any claims about what other people think.
Do you understand this much? What /is/ it you fight against? What possible
motivation could you have to engage in such dirty politics just because you
do not "like" an existing facility and have to invent your own bogosity?
The language of feature expressions does not involve evaluation. Why do you
fail to understand this? Read the goddamn specification and understand what
it says! I believe, however, that the reason you are so confused is that you
think a stupid stunt like #+ignore is a good idea and want to abuse the
feature expression for some pseudo-natural language processing without
actually understanding the mechanism. You have argued for a position that
is inconsistent with the actual mechanism and argue against positions that
are consistent with the existing facility. Since you /invent/ "guarantees"
that some some features will never be in a system without any support for
such a claim from the specification, you are clearly not talking about the
existing feature framework, but one where feature names "mean" something to
the reader when interpreted in the reader's natural language, and you ignore
the counter-argument that the vocabulary that programmers would draw from to
invent "meaningful" symbols is unbounded, whereas the vocabulary of the
feature expression language is well-defined. Then you have the gall to
claim that others /also/ "evaluate" the feature expression and the dishonesty
to put words in other people's mouth. This is clearly not a "fight" you
think you can win with argumentation alone, but have to fight it out with
idiotic politics and blame-throwing and imputing positions to your
opposition that are far easier to refute than their real positions. I really
had thought higher of you than to expect this kind of shit from you.
| I never branded anyone's understanding of this, I was describing the
| language/notation that would result from adopting #+(or) etc.
It seems that you make up your mind about consequences without thinking very
carefully about any arguments. I think you just "feel" that #+(or) is ugly
and react emotionally and unintelligently to it without examining your own
reaction. Then you blame other people for your emotional reaction and
impute all sorts of evil intentions to them when nonesuch exist. Right?
That you think something bad will result from A does not mean that A is bad
/until/ it is taken to the extreme, which normal people would not do. To
argue that nothing but the extreme position exists is unbelievably stupid
and counterproductive. The fact that /you/ think "false" will never be on
the feature list and others "ignore" and "never" and perhaps "nil" or whatnot,
however, is cause for concern. There is no natural restriction on the words
that some people will think are never going to be used. People use symbols
in their natural language, for crying out loud.
| What do you expect the average new CL student's reaction to seeing #+(or)
| will be?
I expect the average new Common Lisp programmer to want to know what it
means before they react emotionally like some retarded and judgmental idiot
who cannot deal with the unexpected and goes screaming to mom when he has to
learn to deal with it. I expect the Common Lisp programmer to be smarter
than your average person who judges based on his first impression and never
thinks about it again.
| Fuzzy pre-understanding is a good thing, it's how everyone gets by in a
| complex world.
Sure. But programming is about real and fundamental understanding of the
world you want to control and not just to "get by in a complex world". That
is, unless you want to communicate lack of precision and fuzzy thinking. in
which case a lot of stupid things that people do should be tolerated by their
programming languages. I do not want to go down that road. I see that you
have taken that road and are quite happy with it. Then you have the gall to
argue that you fight against useless conceptual purity. How fucking annoying!
| Also in a learning situation it is almost essential, so long as the implied
| understanding follows the pre-understanding.
It is crucial that when it does not, the student /thinks/ and does not leap to
judgment based on his pre-understanding emotional responses. More often
than not, the pre-understanding is faulty and needs to be updated or even
entirely replaced. If you are the kind of person who judges first and never
thinks, I should think programming computers would be so frustrating that at
the very least you never learn Lisp.
| But I believe in this case the issue is rather about something quite
| different, which might be called fuzzy post-understanding. After you have
| understood something, you keep it in your active vocabulary by means of any
| number of fuzzy mechanisms. I believe that's how the brain works.
I do not disagree with this in general terms, but I find it stunning that you
use this theory to reject something you have clearly not thought much about.
The use of a feature with a name that one hopes should communicate to other
programmers a desire not use it is remarkably naïve. This would be a good
argument in favor of obscenities instead of normal words.
It is only when you do not understand how feature expressions work that you
can dream up something like #+ignore. If you understood how they work, you
would not even /want/ to invent this, but would already understand that you
could achieve it with #+(or) and #-(and). But if you first see #+ignore, it
takes really good understanding to realize that what people mean is #+(or).
(Thanks again, Paul.) #+ignore spreads because it looks OK to the untrained
eye, not because it is linguistically sound. The idea that one should test
for named features are not even going to be present is severely misguided.
| In my view, #+(or) provides very little for that part of the brain to work
| with (in other words, it's unreadable), and for no particularly good reason
| other than some sense of purity that, in this smallest and simplest of
| languages, is worthless.
So much hostile judgment and so little desire to understand. I could cry.
You have not even tried to understand it, but have made up your mind long
before understanding set in that this was unreadable. Such judgmentality is
really harmful to achieving useful results. Mind you, I paid no attention
to #+ignore /until/ I thought about it and saw how awfully stupid it is. It
was "acceptable" because I ignored the actual meaning of #+ and looked only
at the word "ignore". This also caused me to misread feature expressions
that were more complex. From what you say, you do exactly the same thing:
You do not find #+(or) readable /because/ you think #+ignore should make
sense when it clearly does not.
| > If you wish to make sense and convince people that such abuse should be
| > tolerated, you have to remove some of the emotional ties you have
| > presented and back it up with reasoning. OK?
|
| I tried to, actually.
You failed. You keep imputing positions to me that I do not hold. I hate
it when people lack the willingness or perhaps ability to distinguish between
what they think somebody must have meant and what they have heard them say.
Like, today, I learned that Fraunhofer and Thomson want a small license fee
(USD 0.75) for every MP3 decoder (not just the encoders), and a rather naïve
friend of mine was outraged -- not because of the facts he had just learned
himself, but because he had to invent some motives for this when he could
not accept the position emotionally, and then got all worked about these
motives that he had imputed to the license holders.
| The short form is this: 1. We need a form-scope comment syntax.
"Form-scope"?
| 2. Since we already have #+ and #-, using up another macro character might
| not be worth it (but if the distaste for "intellectual sloppiness" is very
| strong, it might be worth it after all, #; could be a strong candidate).
I think #; is a really good idea. I have embellished it with a count, using
the usual infix numeric argument to skip that many expressions. This may
not be a great idea, but it is conveniently available.
(defun sharp-semi (stream char count)
(declare (ignore char))
(let ((*read-suppress* t))
(dotimes (exprs (or count 1))
(read stream nil nil t)))
(values))
(set-dispatch-macro-character #\# #\; 'sharp-semi)
This means we can write (foo bar #;zot quux) and (foo bar #2;zot quux)
instead of (foo bar #|zot|# quux) and (foo bar #|zot quux|#), respectively.
| 3. #+(or) etc. is too cryptic.
This is an emotional argument from ignorance, and consequently has no weight
at all.
| 4. So define a less cryptic false feature expression.
So learn the language and use it to its fullest extent. Shying away from
certain forms of expression because some people might not get it, is wrong.
That is how bad programming languages develop for bad programmers.
Thien-Thi Nguyen
> * Frode Vatvedt Fjeld
>
> | Also in a learning situation it is almost essential, so long as the
> | implied understanding follows the pre-understanding.
>
> It is crucial that when it does not, the student /thinks/ and does
> not leap to judgment based on his pre-understanding [...]
this is to say "pre-" simply means "before", not necessarily "underlying".
evolution of understanding does not preclude extinction of misunderstanding.
you have to be ruthless w/ these supposedly ephemeral thoughts, sometimes.
thi
Lars Brinkhoff
> Contrary to how many people read (< a b c), I read it as testing
> whether a, b, and c, in that order are monotonically increasing
> values.
How do many people read it?
--
Lars Brinkhoff http://lars.nocrew.org/ Linux, GCC, PDP-10,
Brinkhoff Consulting http://www.brinkhoff.se/ HTTP programming
Frode Vatvedt Fjeld
> [..] It seems that you make up your mind about consequences without
> thinking very carefully about any arguments. I think you just
> "feel" that #+(or) is ugly and react emotionally and unintelligently
> to it without examining your own reaction.
You are obviously correct that I feel #+(or) to be ugly. I have felt
that way about many things and since changed my mind. My examining
this particular reaction should be almost literally in your face when
you wrote this, however.
> Then you blame other people for your emotional reaction and impute
> all sorts of evil intentions to them when nonesuch exist. Right?
These and similar accuasations must stem from grave misconseptions
about the most basic premises of why I write what I do, and why I
chose to participate in this discussion. I simply don't understand it.
> [..] The fact that /you/ think "false" will never be on the feature
> list and others "ignore" and "never" and perhaps "nil" or whatnot,
> however, is cause for concern. There is no natural restriction on
> the words that some people will think are never going to be used.
> People use symbols in their natural language, for crying out loud.
Any such proposals I made was--at least intended to be--in the context
of a (hypothetical) revised standard for feature expressions (and as
such CL itself). The idea was to pick one symbol that conforming CL
implementations would have to ensure that #+ and #- saw like a
nonexisting feature. This might not have been very clear, I admit.
--
Frode Vatvedt Fjeld
Erik Naggum
| How do many people read it?
Many people read (< a b c) as "a less than b less than c". I think this
defeats the purpose of a function-application prefix syntax. I even find
the function name "less" to be slightly misleading since the values have to
/increase/ from left to right for "less" to return true. Well, anyway.
Kimmo T Takkunen
> I think #; is a really good idea.
Mee too.
> (defun sharp-semi (stream char count)
> (declare (ignore char))
> (let ((*read-suppress* t))
> (dotimes (exprs (or count 1))
> (read stream nil nil t)))
> (values))
>
> (set-dispatch-macro-character #\# #\; 'sharp-semi)
>
> This means we can write (foo bar #;zot quux) and (foo bar #2;zot quux)
> instead of (foo bar #|zot|# quux) and (foo bar #|zot quux|#), respectively.
Cool.
Running lisp with emacs causes troubles. How I can get emacs to understand?
-- Kimmo, http://www.iki.fi/kt/
((lambda (integer)
(coerce (loop for i upfrom 0 by 8 below (integer-length integer)
collect (code-char (ldb (byte 8 i) integer))) 'string))
100291759904362517251920937783274743691485481194069255743433035)
Erik Naggum
| Running lisp with emacs causes troubles. How I can get emacs to understand?
Yeah, I noticed... I have delved into the problem yesterday and today and
have found no quick and easy fix.
Marco Antoniotti
ktak...@cc.helsinki.fi (Kimmo T Takkunen) writes:
> In article <32394860...@naggum.no>, Erik Naggum wrote:
> Mee too.
>
> > (defun sharp-semi (stream char count)
> > (declare (ignore char))
> > (let ((*read-suppress* t))
> > (dotimes (exprs (or count 1))
> > (read stream nil nil t)))
> > (values))
> >
> > (set-dispatch-macro-character #\# #\; 'sharp-semi)
> >
> > This means we can write (foo bar #;zot quux) and (foo bar #2;zot quux)
> > instead of (foo bar #|zot|# quux) and (foo bar #|zot quux|#), respectively.
>
> Cool
Yep
>
> Running lisp with emacs causes troubles. How I can get emacs to
> understand?
Well, I'd be happy if anybody had a fix for font-lock and #| |#
comments.
Cheers
--
Marco Antoniotti ========================================================
NYU Courant Bioinformatics Group tel. +1 - 212 - 998 3488
715 Broadway 10th Floor fax +1 - 212 - 995 4122
New York, NY 10003, USA http://bioinformatics.cat.nyu.edu
"Hello New York! We'll do what we can!"
Bill Murray in `Ghostbusters'.
Raymond Wiker
> Well, I'd be happy if anybody had a fix for font-lock and #| |#
> comments.
In XEmacs, this works as expected. I haven't tested this in Emacs,
but in XEmacs this is done via the syntax table entries for # and |:
# ' 58 meaning: expression-prefix,
first character of comment-start sequence B,
second character of comment-end sequence B
| . 67 meaning: punctuation,
second character of comment-start sequence B,
first character of comment-end sequence B
--
Raymond Wiker Mail: Raymon...@fast.no
Senior Software Engineer Web: http://www.fast.no/
Fast Search & Transfer ASA Phone: +47 23 01 11 60
P.O. Box 1677 Vika Fax: +47 35 54 87 99
NO-0120 Oslo, NORWAY Mob: +47 48 01 11 60
Try FAST Search: http://alltheweb.com/
Christophe Rhodes
> Marco Antoniotti <mar...@cs.nyu.edu> writes:
>
> > Well, I'd be happy if anybody had a fix for font-lock and #| |#
> > comments.
>
> In XEmacs, this works as expected. I haven't tested this in Emacs,
> but in XEmacs this is done via the syntax table entries for # and |:
>
> # ' 58 meaning: expression-prefix,
> first character of comment-start sequence B,
> second character of comment-end sequence B
> | . 67 meaning: punctuation,
> second character of comment-start sequence B,
> first character of comment-end sequence B
That's the easy bit.
If I remember correctly, Emacs' view of comments was that they
shouldn't nest properly; this was wired quite heavily into the C
engine last time I looked. Unless this has changed, I think that
comments of the form
#| foo #| bar |# baz |#
won't be properly font-locked, and it didn't look trivial to fix.
If it is working in any emacs running on Unix, let me know, please :-)
Cheers,
Christophe
--
Jesus College, Cambridge, CB5 8BL +44 1223 510 299
http://www-jcsu.jesus.cam.ac.uk/~csr21/ (defun pling-dollar
(str schar arg) (first (last +))) (make-dispatch-macro-character #\! t)
(set-dispatch-macro-character #\! #\$ #'pling-dollar)
Marco Antoniotti
Christophe Rhodes <cs...@cam.ac.uk> writes:
> Raymond Wiker <Raymon...@fast.no> writes:
>
> > Marco Antoniotti <mar...@cs.nyu.edu> writes:
> >
> > > Well, I'd be happy if anybody had a fix for font-lock and #| |#
> > > comments.
> >
> > In XEmacs, this works as expected. I haven't tested this in Emacs,
> > but in XEmacs this is done via the syntax table entries for # and |:
> >
> > # ' 58 meaning: expression-prefix,
> > first character of comment-start sequence B,
> > second character of comment-end sequence B
> > | . 67 meaning: punctuation,
> > second character of comment-start sequence B,
> > first character of comment-end sequence B
>
> That's the easy bit.
>
> If I remember correctly, Emacs' view of comments was that they
> shouldn't nest properly; this was wired quite heavily into the C
> engine last time I looked. Unless this has changed, I think that
> comments of the form
> #| foo #| bar |# baz |#
> won't be properly font-locked, and it didn't look trivial to fix.
I do not think this is the problem. The problem is that font-lock
messes up the colors on the definition *following* the #| ... |#
commented region.
Any ideas why?
Hannu Koivisto
> #| foo #| bar |# baz |#
> won't be properly font-locked, and it didn't look trivial to fix.
>
> If it is working in any emacs running on Unix, let me know, please :-)
That comment is fontified just fine by Emacs 21.1.1 running on
Debian GNU/Linux.
--
Hannu
Christophe Rhodes
My goodness. So it is.
Many apologies for any misinformation that people have gathered from
my previous post.
I might just start turning font-lock back on now, then :)
Raymond Wiker
> Hannu Koivisto <az...@iki.fi> writes:
>
> > Christophe Rhodes <cs...@cam.ac.uk> writes:
> >
> > > #| foo #| bar |# baz |#
> > > won't be properly font-locked, and it didn't look trivial to fix.
> > >
> > > If it is working in any emacs running on Unix, let me know, please :-)
> >
> > That comment is fontified just fine by Emacs 21.1.1 running on
> > Debian GNU/Linux.
>
> My goodness. So it is.
>
> Many apologies for any misinformation that people have gathered from
> my previous post.
>
> I might just start turning font-lock back on now, then :)
On the other hand, it *doesn't* work in XEmacs. Ho hum.