Hi all,
I'm trying to find my way into Lisp and came across this function
definition in "On Lisp" (sect. 4.1, pg 42):
(defun find2 (fn lst)
(if (null lst)
nil
(let ((val (funcall fn (car lst))))
(if val
(values (car lst) val)
(find2 fn (cdr lst))))))
I asked myself, why did Paul Graham use (car lst) twice? Isn't it cheaper
to omit one call and store the value? Is it a matter of style or are
there any differences between that and the function I came up with:
(defun find3 (fn lst)
(if (null lst)
nil
(let* ((x (car lst))
(val (funcall fn x)))
(if val
(values x val)
(find2 fn (cdr lst))))))
Thanks!
robert
Robert Klemme wrote:
> Hi all,
>
> I'm trying to find my way into Lisp and came across this function
> definition in "On Lisp" (sect. 4.1, pg 42):
>
> (defun find2 (fn lst)
> (if (null lst)
> nil
> (let ((val (funcall fn (car lst))))
> (if val
> (values (car lst) val)
> (find2 fn (cdr lst))))))
>
> I asked myself, why did Paul Graham use (car lst) twice? Isn't it cheaper
> to omit one call and store the value? Is it a matter of style or are
> there any differences between that and the function I came up with:
>
> (defun find3 (fn lst)
> (if (null lst)
> nil
> (let* ((x (car lst))
> (val (funcall fn x)))
> (if val
> (values x val)
> (find2 fn (cdr lst))))))
Car is not expensive enough to justify more code clutter, but I have a
macro which will deftly bind one return value in a conditional:
(defun find2 (fn list &aux (head (car list))) ;; if you like
(when list
(bif (val (funcall fn head))
(values head val)
(find2 fn (cdr list)))))
(untested)
kenny
From: Steven E. Harris
Subject: Re: Is it just style or another reason?
Date:
Message-ID: <q677k3vqw30.fsf@raytheon.com>
Kenny Tilton <·······@nyc.rr.com> writes:
> (defun find2 (fn list &aux (head (car list))) ;; if you like
Speaking of style, that &aux expression looks weird. What motivates
one to put such a binding in an &aux expression rather than in the
most local, appropriate point within the function? (Note that here,
you bind "head" whether or not "list" is null, whereas the other
version waits to bind it ("x") until we know it's needed.)
--
Steven E. Harris :: ········@raytheon.com
Raytheon :: http://www.raytheon.com
Steven E. Harris wrote:
> Kenny Tilton <·······@nyc.rr.com> writes:
>
>
>>(defun find2 (fn list &aux (head (car list))) ;; if you like
>
>
> Speaking of style, that &aux expression looks weird.
Fine:
(defun find2 (fn list)
(bwhen (head (car list))
(bif (val (funcall fn head))
(values head val)
(find2 fn (cdr list)))))
> What motivates
> one to put such a binding in an &aux expression rather than in the
> most local, appropriate point within the function?
&aux is a natural, nicely self-documenting way of pulling things out of
parameters, esp if the only thing one would be doing in the let is
pulling things out of arguments and super-especially if there would be
only one. Saves an indentation level as well.
> (Note that here,
> you bind "head" whether or not "list" is null, whereas the other
> version waits to bind it ("x") until we know it's needed.)
Isn't Lisp grand that way? The original was kinda Scheme-y ("if NUll
nil...") as well as using LST as the name of the list parameter.
I take advantage of this kind of imprecision all day long every day, not
just treating NIL and false equally, but also taking the car of
something when I do not even know if I have something.
Isn't Lisp grand? :)
kenny
From: Steven E. Harris
Subject: Re: Is it just style or another reason?
Date:
Message-ID: <q67wubvs4vt.fsf@raytheon.com>
Kenny Tilton <·······@nyc.rr.com> writes:
> Fine:
>
> (defun find2 (fn list)
> (bwhen (head (car list))
> (bif (val (funcall fn head))
> (values head val)
> (find2 fn (cdr list)))))
Cool. Here's my try at bwhen and bif:
(defmacro bwhen ((var test-form) &body body)
`(let ((,var ,test-form))
(when ,var
,@body)))
(defmacro bif ((var test-form) then-form &optional else-form)
`(let ((,var ,test-form))
(if ,var
,then-form
,else-form)))
Are those correct?
I looked at the OnLisp utilities in CLOCC and noticed that they
delegated the similar "pg:awhen" to "pg:aif", which would make my
"bwhen" more like:
(defmacro bwhen ((var test-form) &body body)
`(bif (,var ,test-form)
(progn
,@body)))
> I take advantage of this kind of imprecision all day long every day,
> not just treating NIL and false equally, but also taking the car of
> something when I do not even know if I have something.
I was just doing that yesterday, wondering if it's bad style, but
noting that it works just fine, being that the car of nil is nil.
> Isn't Lisp grand? :)
I'm using it more and more each day, and finding it very hard to
accept working any other way.
--
Steven E. Harris :: ········@raytheon.com
Raytheon :: http://www.raytheon.com
Steven E. Harris wrote:
> Kenny Tilton <·······@nyc.rr.com> writes:
>
>
>>Fine:
>>
>> (defun find2 (fn list)
>> (bwhen (head (car list))
>> (bif (val (funcall fn head))
>> (values head val)
>> (find2 fn (cdr list)))))
>
>
> Cool. Here's my try at bwhen and bif:
>
> (defmacro bwhen ((var test-form) &body body)
> `(let ((,var ,test-form))
> (when ,var
> ,@body)))
>
> (defmacro bif ((var test-form) then-form &optional else-form)
> `(let ((,var ,test-form))
> (if ,var
> ,then-form
> ,else-form)))
>
> Are those correct?
Well, it's what I had anyway. I did not think to use bIf to do bWhen,
which is a good idea.
> I was just doing that yesterday, wondering if it's bad style, but
> noting that it works just fine, being that the car of nil is nil.
This is one place where I get this eerie sense of the Ghost of Lispniks
Past just damning the torpedos (style) and full speed ahead. All these:
(fn1 (fn 2 (fn3 'x)))
...sailing merrily along even when one decides to return what in C would
be a null pointer and the beginning of a segfault.
>
>
>>Isn't Lisp grand? :)
>
>
> I'm using it more and more each day, and finding it very hard to
> accept working any other way.
>
Hang on. Are you a newbie!?:
http://alu.cliki.net/The%20Road%20to%20Lisp%20Survey
<g> I don't see you in the Road to Lisp Survey. Every newbie should
throw their two cents into that so /potential/ newbies will feel better
about taking up a dead language.
The pages got a little beat up in shipping, but they'll have to serve
until after ILC2003, I'm pegged.
kenny
From: Steven E. Harris
Subject: Re: Is it just style or another reason?
Date:
Message-ID: <q677k3rse5o.fsf@raytheon.com>
Kenny Tilton <·······@nyc.rr.com> writes:
> I don't see you in the Road to Lisp Survey.
As mentioned in the ongoing "Road to ALU" thread, I used to be there.�
I was even in your Top 10.
Today I copied my entry to the ALU Wiki.� Now how do I apply for the
Top 10 again, and who's taking bribes?
Footnotes:
� Since 2 July 2003:
http://groups.google.com/groups?threadm=q67znjw6cq4.fsf%40raytheon.com
http://www.cliki.net/Steven%20Harris
� http://alu.cliki.net/Steven%20Harris'%20Road%20to%20Lisp
--
Steven E. Harris :: ········@raytheon.com
Raytheon :: http://www.raytheon.com
Steven E. Harris wrote:
> Kenny Tilton <·······@nyc.rr.com> writes:
>
>
>>I don't see you in the Road to Lisp Survey.
>
>
> As mentioned in the ongoing "Road to ALU" thread, I used to be there.�
> I was even in your Top 10.
Oops. :) Well, the memory went a long time ago, no surprise over here.
>
> Today I copied my entry to the ALU Wiki.� Now how do I apply for the
> Top 10 again, and who's taking bribes?
Do I look like an ice skating judge? <g> I have you planned for another
group, to be created after ILC, one for Roads with lots of details on
Why Lisp?
thx for refreshing your entry.
kenny
"Kenny Tilton" <·······@nyc.rr.com> wrote in message
··························@twister.nyc.rr.com...
> (defun find2 (fn list &aux (head (car list))) ;; if you like
Don't use &aux!
--
Coby Beck
(remove #\Space "coby 101 @ big pond . com")
Coby Beck wrote:
> "Kenny Tilton" <·······@nyc.rr.com> wrote in message
> ··························@twister.nyc.rr.com...
>
>>(defun find2 (fn list &aux (head (car list))) ;; if you like
>
>
> Don't use &aux!
>
heh-heh. You are the second person I have heard rant against &aux. &aux
is the perfect thing when you just need to suck one or two values out of
a parameter.
I'd love to hear the counter-arguments (to &aux). They better be better
than the "we don't like it" camelCase arguments.
:)
kenny
"Kenny Tilton" <·······@nyc.rr.com> wrote in message
··························@twister.nyc.rr.com...
> Coby Beck wrote:
> > "Kenny Tilton" <·······@nyc.rr.com> wrote in message
> > ··························@twister.nyc.rr.com...
> >
> >>(defun find2 (fn list &aux (head (car list))) ;; if you like
> >
> > Don't use &aux!
> >
> I'd love to hear the counter-arguments (to &aux). They better be better
> than the "we don't like it" camelCase arguments.
Sorry, no better argument than it's anti-social.
CamelCase does have a slightly more than "I just don't like it" downside,
namely when you see:
Error in Function ANEXTRAINLAWFUNCTION...was that anExtraInlawFunction or
anexTrainLawFunction? (and however long it took me to come up with that is
irrelevant!!)
--
Coby Beck
(remove #\Space "coby 101 @ big pond . com")
Coby Beck wrote:
> "Kenny Tilton" <·······@nyc.rr.com> wrote in message
> ··························@twister.nyc.rr.com...
>
>>Coby Beck wrote:
>>
>>>"Kenny Tilton" <·······@nyc.rr.com> wrote in message
>>>··························@twister.nyc.rr.com...
>>>
>>>
>>>>(defun find2 (fn list &aux (head (car list))) ;; if you like
>>>
>>>Don't use &aux!
>>>
>
>
>>I'd love to hear the counter-arguments (to &aux). They better be better
>>than the "we don't like it" camelCase arguments.
>
>
> Sorry, no better argument than it's anti-social.
What I meant was, don't just say you hate it or "we all hate it" (in
which case at least define "we"), but wax poetic on the its evil. /Why/
do you hate it? Do you even know, or was this hatred passed down to you
from the village elders?
> CamelCase does have a slightly more than "I just don't like it" downside,
> namely when you see:
>
> Error in Function ANEXTRAINLAWFUNCTION...was that anExtraInlawFunction or
> anexTrainLawFunction?
Sorry to start this one up again, it's a dead horse because for me at
least it is a declining feature, but anyway: in ACL/win32 I just
right-click on the symbol and select 'find definition'.
kenny
From: Joe Marshall
Subject: Re: Is it just style or another reason?
Date:
Message-ID: <7k3rekv9.fsf@ccs.neu.edu>
"Coby Beck" <·····@mercury.bc.ca> writes:
> CamelCase does have a slightly more than "I just don't like it" downside,
> namely when you see:
>
> Error in Function ANEXTRAINLAWFUNCTION...was that anExtraInlawFunction or
> anexTrainLawFunction? (and however long it took me to come up with that is
> irrelevant!!)
EXPERTSEXCHANGE
POWERGENITALIA
etc.
studlycaps aRe bad Because They make It fAr Too temptiNg tO eNcode
semaNtic informaTion Within thE miCrO-Syntax of names. PEoplE staRt
aSsiGninG different meanings tO "foo", "Foo", and "FOO".
As fOr using &auX, wHaT's wrong with LET?
Joe Marshall <···@ccs.neu.edu> writes:
> "Coby Beck" <·····@mercury.bc.ca> writes:
>
> > CamelCase does have a slightly more than "I just don't like it" downside,
> > namely when you see:
> >
> > Error in Function ANEXTRAINLAWFUNCTION...was that anExtraInlawFunction or
> > anexTrainLawFunction? (and however long it took me to come up with that is
> > irrelevant!!)
>
> EXPERTSEXCHANGE
> POWERGENITALIA
> etc.
>
> studlycaps aRe bad Because They make It fAr Too temptiNg tO eNcode
> semaNtic informaTion Within thE miCrO-Syntax of names. PEoplE staRt
> aSsiGninG different meanings tO "foo", "Foo", and "FOO".
>
> As fOr using &auX, wHaT's wrong with LET?
I like using &aux occasionally, but only for relatively short
functions, and only for values that are based on the arguments (eg, a
length or car/cdr of one of arguments).. if the function is only one
or two lines long I hate to add the extra line for LET..
FWIW I am agaist StudlyCaps in LISP; in VB they are OK.. In C or Perl I
use_the_underscore..
Jock Cooper
--
www.fractal-recursions.com
Joe Marshall <···@ccs.neu.edu> writes:
> "Coby Beck" <·····@mercury.bc.ca> writes:
>
>> CamelCase does have a slightly more than "I just don't like it" downside,
>> namely when you see:
>>
>> Error in Function ANEXTRAINLAWFUNCTION...was that anExtraInlawFunction or
>> anexTrainLawFunction? (and however long it took me to come up with that is
>> irrelevant!!)
>
> EXPERTSEXCHANGE
> POWERGENITALIA
www.whorepresents.com
--
Raymond Wiker Mail: ·············@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/
"Raymond Wiker" <·············@fast.no> wrote in message
···················@raw.grenland.fast.no...
> Joe Marshall <···@ccs.neu.edu> writes:
>
> > "Coby Beck" <·····@mercury.bc.ca> writes:
> >
> >> CamelCase does have a slightly more than "I just don't like it"
downside,
> >> namely when you see:
> >>
> >> Error in Function ANEXTRAINLAWFUNCTION...was that anExtraInlawFunction
or
> >> anexTrainLawFunction? (and however long it took me to come up with
that is
> >> irrelevant!!)
> >
> > EXPERTSEXCHANGE
> > POWERGENITALIA
>
> www.whorepresents.com
>
Those are so much better than mine...I'm truly embarassed!
--
Coby Beck
(remove #\Space "coby 101 @ big pond . com")
"Coby Beck" <·····@mercury.bc.ca> writes:
> "Raymond Wiker" <·············@fast.no> wrote in message
> ···················@raw.grenland.fast.no...
>> Joe Marshall <···@ccs.neu.edu> writes:
>>
>> > "Coby Beck" <·····@mercury.bc.ca> writes:
>> >
>> >> CamelCase does have a slightly more than "I just don't like it"
> downside,
>> >> namely when you see:
>> >>
>> >> Error in Function ANEXTRAINLAWFUNCTION...was that anExtraInlawFunction
> or
>> >> anexTrainLawFunction? (and however long it took me to come up with
> that is
>> >> irrelevant!!)
>> >
>> > EXPERTSEXCHANGE
>> > POWERGENITALIA
>>
>> www.whorepresents.com
>>
>
> Those are so much better than mine...I'm truly embarassed!
I think the people behind www.whorepresents.com are, too...
--
Raymond Wiker Mail: ·············@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/
From: ·············@comcast.net
Subject: Re: Is it just style or another reason?
Date:
Message-ID: <1xty42ot.fsf@comcast.net>
"Coby Beck" <·····@mercury.bc.ca> writes:
> "Raymond Wiker" <·············@fast.no> wrote in message
> ···················@raw.grenland.fast.no...
>> Joe Marshall <···@ccs.neu.edu> writes:
>>
>> > "Coby Beck" <·····@mercury.bc.ca> writes:
>> >
>> >> CamelCase does have a slightly more than "I just don't like it"
> downside,
>> >> namely when you see:
>> >>
>> >> Error in Function ANEXTRAINLAWFUNCTION...was that anExtraInlawFunction
> or
>> >> anexTrainLawFunction? (and however long it took me to come up with
> that is
>> >> irrelevant!!)
>> >
>> > EXPERTSEXCHANGE
>> > POWERGENITALIA
>>
>> www.whorepresents.com
>>
>
> Those are so much better than mine...I'm truly embarassed!
You came up with your own. I just stole mine.
Today, Joe Marshall <···@ccs.neu.edu> wrote:
> As fOr using &auX, wHaT's wrong with LET?
Nothing, it just doesn't carry information over to arglist info in Lisp
development environments.
Consider:
(defun opposite-of (var val1 val2 &optional (test #'eql))
(if (funcall test var val1)
val2
val1))
(defun some-function (&optional (par :most-specific-last)
&aux (other-par (opposite-of par
:most-specific-last
:most-specific-first)))
other-par)
With ilisp/(sbcl|cmucl|...), when I type the key that shows me the
function arglist, I get to know that it uses an optional parameter and
computes another parameter that is the opposite. Quite good to have,
IMHO.
--
Andreas Fuchs, <···@acm.org>, ···@jabber.at, antifuchs
"Andreas Fuchs" <···@boinkor.net> wrote in message
···················@boinkine.defun.at...
> Today, Joe Marshall <···@ccs.neu.edu> wrote:
> > As fOr using &auX, wHaT's wrong with LET?
>
> Nothing, it just doesn't carry information over to arglist info in Lisp
> development environments.
Hmm..bug, feature...feature, bug... its a feature. I think this is as it
should be. If you don't get to pass it in, why should you get to how it is
given an initial value? And why is this little piece of what goes on inside
the function so different that it should be exposed but the other internal
logic is not? At best it is irrelevant, at worst a possible enticement to
attempt a manipulation of something you're not supposed to manipulate.
"oh..that &aux expression takes the absolute value of X...I will pass it the
absolute value directly to help otimize."
Yes I know this is getting what you ask for, but what would be a proper use
of knowledge about the internal variables of some function? And if there is
no proper way to use that info, why should it be exposed?
> With ilisp/(sbcl|cmucl|...), when I type the key that shows me the
> function arglist, I get to know that it uses an optional parameter
&optional is within your right to know, for sure.
> and computes another parameter that is the opposite. Quite good to have,
> IMHO.
Why? What good could possibly come of knowing that tiny piece of the whole
equation?
Today, Coby Beck <·····@mercury.bc.ca> wrote:
> Yes I know this is getting what you ask for, but what would be a
> proper use of knowledge about the internal variables of some function?
> And if there is no proper way to use that info, why should it be
> exposed?
My point was that some variables are more external than others
(illustrated with an overly simplistic example; sorry for that), and
that sometimes it is good to let the user of your programs know what
effects passing a value to the function will have.
>> With ilisp/(sbcl|cmucl|...), when I type the key that shows me the
>> function arglist, I get to know that it uses an optional parameter
>
> &optional is within your right to know, for sure.
This is not about rights. The person who wrote the function and designed
the lambda list had the choice between LET and &AUX, and when they used
&AUX, there was a reason for it (which hopefully does not involve
newbiedom); and given that &AUX parameters are parameters, it is my wish
and (if you will) my right to know it when I query my lisp for the
function lambda list.
Personally, I'm glad that lisp functions have auxilliary parameters in
addition to normal parameters. That does not mean that you or I should
(nor would) use them exclusively when just a LET form would be
sufficient. But it "is good to have" when you have parameters that you
want to pass to the user but you don't want the user to pass the
function. (-:
--
Andreas Fuchs, <···@acm.org>, ···@jabber.at, antifuchs
"Andreas Fuchs" <···@boinkor.net> wrote in message
···················@boinkine.defun.at...
> Today, Coby Beck <·····@mercury.bc.ca> wrote:
> > Yes I know this is getting what you ask for, but what would be a
> > proper use of knowledge about the internal variables of some function?
> > And if there is no proper way to use that info, why should it be
> > exposed?
>
> My point was that some variables are more external than others
> (illustrated with an overly simplistic example; sorry for that),
Yes, that's pretty much the point I took. I still don't see why. Perhaps a
more realistic example would help...
> sometimes it is good to let the user of your programs know what
> effects passing a value to the function will have.
But you're not, seeing an &aux parameter initialization is not very much
information (and as a substitute for documentation is completely
inadequate). And in the sense of trying to help a user of your code, a
small peek is worse than nothing.
A function signature is the interface to the user, well choosen parameter
names provide a convenient reminder to a user about what they are expected
to pass in. Internal variables are just that, internal. I don't see an
advantage to that little extra peek seeing &aux gives you and I already said
why I thought it is a possible disadvantage. To me it violates the proper
seperation of interface and internals.
> >> With ilisp/(sbcl|cmucl|...), when I type the key that shows me the
> >> function arglist, I get to know that it uses an optional parameter
> >
> > &optional is within your right to know, for sure.
>
> This is not about rights.
That was mostly for dramatic emphasis :) But it is about The Right Thing...
> The person who wrote the function and designed
> the lambda list had the choice between LET and &AUX, and when they used
> &AUX, there was a reason for it
This is what I am waiting for, a good design reason. So far the only one
I've heard (and I do understand it, no problem) is it reduces indentation.
That is not compelling enough in the light of what I perceive as the
disadvantage I talk about above. It is also not compelling enough to
resurrect something that is an historic relic fading into the past. (I hope
that is not just my own misimpression...)
Generated code may be a different matter, I could imagine &aux being a
simpler solution for programmatically written code, but don't see it as
appropriate for hand wrriten code.
> and given that &AUX parameters are parameters, it is my wish
> and (if you will) my right to know it when I query my lisp for the
> function lambda list.
But they aren't parameters. I know, I know, they are called that and they
are in the parameter list, but I insist that they are not really function
parameters in any meaningful sense.
--
Coby Beck
(remove #\Space "coby 101 @ big pond . com")
From: Joe Marshall
Subject: Re: Is it just style or another reason?
Date:
Message-ID: <fzid12y7.fsf@ccs.neu.edu>
Andreas Fuchs <···@boinkor.net> writes:
> Today, Joe Marshall <···@ccs.neu.edu> wrote:
>> As fOr using &auX, wHaT's wrong with LET?
>
> Nothing, it just doesn't carry information over to arglist info in Lisp
> development environments.
You say that as if that would be a good thing.
The caller shouldn't need to know the implementation of the callee,
and if you wish to document something about the behavior of the
function, there are more appropriate mechanisms than tacking the first
few LET bindings on to the argument list. The docstring comes to mind.
Joe Marshall <···@ccs.neu.edu> writes:
> "Coby Beck" <·····@mercury.bc.ca> writes:
>
> > CamelCase does have a slightly more than "I just don't like it" downside,
> > namely when you see:
> >
> > Error in Function ANEXTRAINLAWFUNCTION...was that anExtraInlawFunction or
> > anexTrainLawFunction? (and however long it took me to come up with that is
> > irrelevant!!)
>
> EXPERTSEXCHANGE
> POWERGENITALIA
> etc.
>
> studlycaps aRe bad Because They make It fAr Too temptiNg tO eNcode
> semaNtic informaTion Within thE miCrO-Syntax of names. PEoplE staRt
> aSsiGninG different meanings tO "foo", "Foo", and "FOO".
Another thing I dislike about studlycaps has to do with word
composition, eg is it called HashTable or Hashtable? For some reason
it is much easier to distinguish between hashtable/hash-table or
hashtable/hash_table than the studlycaps equivalent. Probably because
there is a clear separation between words.
Bj�rn
Bj�rn Lindberg wrote:
> Another thing I dislike about studlycaps has to do with word
> composition, eg is it called HashTable or Hashtable?
You know, every time this comes up, people assume using camelCase
somehow also entails use of case sensitivity. Understandable, I guess,
but one canType likeThis toMake code moreReadable even if the compiler
doesnotsee it likethat atall.
kenny
bTw, aLl yUo CamElcase crItcs who do si-llyt-hing-sliket-hat, can you
say "strawMan"? Sher ya can.
:)
From: Joe Marshall
Subject: Re: Is it just style or another reason?
Date:
Message-ID: <d6dfzkp0.fsf@ccs.neu.edu>
Kenny Tilton <·······@nyc.rr.com> writes:
> Bj�rn Lindberg wrote:
>> Another thing I dislike about studlycaps has to do with word
>> composition, eg is it called HashTable or Hashtable?
>
> You know, every time this comes up, people assume using camelCase
> somehow also entails use of case sensitivity. Understandable, I guess,
> but one canType likeThis toMake code moreReadable even if the compiler
> doesnotsee it likethat atall.
>
> kenny
>
> bTw, aLl yUo CamElcase crItcs who do si-llyt-hing-sliket-hat, can you
> say "strawMan"? Sher ya can.
What dO YoU meaN? yoU seem tO Think i am moDifying thE capitaliZatioN At randOm.
i aSsure YoU thAt i am nOt. ThE stUdlY case EmAcs package is DeTerminisTic.
DO YoU haVe unambiGuOuS ruleS fOr stUdlIfIcAtIon? What aRe thEy?
If YoU dO, then we can both be HaPpy by rEplAcIng [a-z][A-Z] => \1-\2
M4yb3 w3 5h0u1d 4l1 u5e 3l|t3 |d3n+if|er5!
Kenny Tilton <·······@nyc.rr.com> writes:
> Bj�rn Lindberg wrote:
> > Another thing I dislike about studlycaps has to do with word
> > composition, eg is it called HashTable or Hashtable?
>
> You know, every time this comes up, people assume using camelCase
> somehow also entails use of case sensitivity. Understandable, I guess,
> but one canType likeThis toMake code moreReadable even if the compiler
> doesnotsee it likethat atall.
Well, camelCasing doesn't really make any sense without having
caseSensitivity, since one should always strive to have equally
readable printed names as read names (if that makes sense). On reading
an dthen printing a camelCase symbol, it'd be CAMELCASE, whereas a
lisp-case symbol would be LISP-CASE. Other than that, you do what you
want, as long as you are happy the code is readable-enough in a text
backtrace bunged in an email to you.
//Ingvar (opines)
--
(defmacro fakelambda (args &body body) `(labels ((me ,args ,@body)) #'me))
(funcall (fakelambda (a b) (if (zerop (length a)) b (format nil "~a~a"
(aref a 0) (me b (subseq a 1))))) "Js nte iphce" "utaohrls akr")
Ingvar Mattsson <······@cathouse.bofh.se> writes:
> Kenny Tilton <·······@nyc.rr.com> writes:
>
> > Bj�rn Lindberg wrote:
> > > Another thing I dislike about studlycaps has to do with word
> > > composition, eg is it called HashTable or Hashtable?
> >
> > You know, every time this comes up, people assume using camelCase
> > somehow also entails use of case sensitivity. Understandable, I guess,
> > but one canType likeThis toMake code moreReadable even if the compiler
> > doesnotsee it likethat atall.
>
> Well, camelCasing doesn't really make any sense without having
> caseSensitivity, since one should always strive to have equally
> readable printed names as read names (if that makes sense). On reading
> an dthen printing a camelCase symbol, it'd be CAMELCASE, whereas a
> lisp-case symbol would be LISP-CASE. Other than that, you do what you
> want, as long as you are happy the code is readable-enough in a text
> backtrace bunged in an email to you.
Not necessarily. The MacOS and Windows file systems use names that
retain their original case, but are not case sensitive.
One could easily imagine doing something similar with symbol names. The
reader would preserve the case of symbol names, but the lookup and
matching to find the actual symbol would be done in a case insensitive
manner. If no symbol is found, then the first capitalization is the one
that is preserved as the canonical name of the symbol.
In that case, both "HashTable" and "Hashtable" would map to the same
symbol object, which would be printed "HashTable" (because that was the
first spelling seen).
The longer I have thought about this language design issue, the more I
become convinced that preserving capitalization but not having symbols
be case-sensitive is the right way to go. I think that it is just
asking for trouble to have "foo" and "Foo" mean different things. About
the only case distinction that seems to make any sense to me is to
differentiate between all caps and not all caps, as in "Foo" and "FOO",
but that is not a sufficiently compelling distinction to be worth
preserving in a programming language. I would be willing to give up
that minor ability to use synonym names in favor of not having the
baggage of details of capitalization affect the identity of symbols.
--
Thomas A. Russ, USC/Information Sciences Institute
···@sevak.isi.edu (Thomas A. Russ) writes:
> The longer I have thought about this language design issue, the more I
> become convinced that preserving capitalization but not having symbols
> be case-sensitive is the right way to go. I think that it is just
> asking for trouble to have "foo" and "Foo" mean different things. About
> the only case distinction that seems to make any sense to me is to
> differentiate between all caps and not all caps, as in "Foo" and "FOO",
> but that is not a sufficiently compelling distinction to be worth
> preserving in a programming language. I would be willing to give up
> that minor ability to use synonym names in favor of not having the
> baggage of details of capitalization affect the identity of symbols.
However, in natural human languages, the distinction between
capitalized and uncapitalized and even upcased words is routinely and
explicitely done. OpenStep is not the same as OPENSTEP. Pascal is not
the same as a pascal (or Newton is not the same as a newton). And of
course, an Abba is not ABBA.
The reason why lisp is not case sensitive is because it existed at a
time when there was no case (everything was "upper case").
The reason why MacOS and MS-Windows file systems are not case
sensitive is because they're targeted to dumb people who can't be
precise in their spellings (and let me ask you what importance since
they'll designate their files by clicking on their icons anyway?!).
--
__Pascal_Bourguignon__
http://www.informatimago.com/
Do not adjust your mind, there is a fault in reality.
In article <··············@thalassa.informatimago.com>, Pascal Bourguignon
<····@thalassa.informatimago.com> wrote:
> ···@sevak.isi.edu (Thomas A. Russ) writes:
> > The longer I have thought about this language design issue, the more I
> > become convinced that preserving capitalization but not having symbols
> > be case-sensitive is the right way to go. I think that it is just
> > asking for trouble to have "foo" and "Foo" mean different things. About
> > the only case distinction that seems to make any sense to me is to
> > differentiate between all caps and not all caps, as in "Foo" and "FOO",
> > but that is not a sufficiently compelling distinction to be worth
> > preserving in a programming language. I would be willing to give up
> > that minor ability to use synonym names in favor of not having the
> > baggage of details of capitalization affect the identity of symbols.
>
> However, in natural human languages, the distinction between
> capitalized and uncapitalized and even upcased words is routinely and
> explicitely done. OpenStep is not the same as OPENSTEP. Pascal is not
> the same as a pascal (or Newton is not the same as a newton). And of
> course, an Abba is not ABBA.
That doesn't necessarily mean that this is a good idea for software development.
> The reason why lisp is not case sensitive
But Lisp is case-sensitive. FOO and |foo| are distinct symbols.
E.
From: Joe Marshall
Subject: Re: Is it just style or another reason?
Date:
Message-ID: <vfr79zs8.fsf@ccs.neu.edu>
Pascal Bourguignon <····@thalassa.informatimago.com> writes:
> ···@sevak.isi.edu (Thomas A. Russ) writes:
>> The longer I have thought about this language design issue, the more I
>> become convinced that preserving capitalization but not having symbols
>> be case-sensitive is the right way to go. I think that it is just
>> asking for trouble to have "foo" and "Foo" mean different things. About
>> the only case distinction that seems to make any sense to me is to
>> differentiate between all caps and not all caps, as in "Foo" and "FOO",
>> but that is not a sufficiently compelling distinction to be worth
>> preserving in a programming language. I would be willing to give up
>> that minor ability to use synonym names in favor of not having the
>> baggage of details of capitalization affect the identity of symbols.
>
> However, in natural human languages, the distinction between
> capitalized and uncapitalized and even upcased words is routinely and
> explicitely done. OpenStep is not the same as OPENSTEP. Pascal is not
> the same as a pascal (or Newton is not the same as a newton). And of
> course, an Abba is not ABBA.
sO, yOU wOULD bE cOMPLETELY uNABLE tO rEAD tHIS bECAUSE tHE wORDS aRE
nOT tHE sAME aS tHE sTANDARD oNES.
"Joe Marshall" <···@ccs.neu.edu> wrote in message
·················@ccs.neu.edu...
> Pascal Bourguignon <····@thalassa.informatimago.com> writes:
>
> > However, in natural human languages, the distinction between
> > capitalized and uncapitalized and even upcased words is routinely and
> > explicitely done. OpenStep is not the same as OPENSTEP. Pascal is not
> > the same as a pascal (or Newton is not the same as a newton). And of
> > course, an Abba is not ABBA.
>
> sO, yOU wOULD bE cOMPLETELY uNABLE tO rEAD tHIS bECAUSE tHE wORDS aRE
> nOT tHE sAME aS tHE sTANDARD oNES.
Huh? Speak english please! ;)
But seriously, in natural language, case does carry information but it is
absolutely secondary to context and common sense. These things are very
difficult to apply to programming. I think it would be very difficult to
find an example usage (in natural language) where case was essential to
disambiguating the meaning of a word, and I think most often people avoid
such situations. Don't forget, written language followed spoken language,
and Pascal vs pascal is not distinguishable aurally.
As for Kenny and his strawManCounterAttack...it does not escape my notice
that you were silent in the face of POWERGENITALIA and EXPERTSEXCHANGE!
(and something tells me it is not because you find the examples
embarassing... ;)
--
Coby Beck
(remove #\Space "coby 101 @ big pond . com")
"Coby Beck" <·····@mercury.bc.ca> writes:
> "Joe Marshall" <···@ccs.neu.edu> wrote in message
> ·················@ccs.neu.edu...
> > Pascal Bourguignon <····@thalassa.informatimago.com> writes:
> >
> > > However, in natural human languages, the distinction between
> > > capitalized and uncapitalized and even upcased words is routinely and
> > > explicitely done. OpenStep is not the same as OPENSTEP. Pascal is not
> > > the same as a pascal (or Newton is not the same as a newton). And of
> > > course, an Abba is not ABBA.
> >
> > sO, yOU wOULD bE cOMPLETELY uNABLE tO rEAD tHIS bECAUSE tHE wORDS aRE
> > nOT tHE sAME aS tHE sTANDARD oNES.
>
> Huh? Speak english please! ;)
>
> But seriously, in natural language, case does carry information but it is
> absolutely secondary to context and common sense. These things are very
> difficult to apply to programming. I think it would be very difficult to
> find an example usage (in natural language) where case was essential to
> disambiguating the meaning of a word, and I think most often people avoid
> such situations. Don't forget, written language followed spoken language,
> and Pascal vs pascal is not distinguishable aurally.
>
> As for Kenny and his strawManCounterAttack...it does not escape my notice
> that you were silent in the face of POWERGENITALIA and EXPERTSEXCHANGE!
> (and something tells me it is not because you find the examples
> embarassing... ;)
Written natural languages are not the same as spoken natural languages
(even if there are some strong relationships). Written natural
languages may be more formal.
All right, it's not in natural language that case sensitivity is
needed, but in formal language. Maths need a lot of symbols, and
there, case is distinguished (and other typographical variations on
the same letter), not counting alternate alphabets.
Since programming language are formal languages like maths and logics,
_naturally_ they distinguish case. We even have editors that will put
a different typography to different classes of symbols automatically,
when it's not stored in the sources!
[Try to type: (defun defun (name defun) (setq defun name)) in a lisp
buffer in emacs with font-lock-mode: three different typographies]
In the absence of such nice editor, and in languages where such an
overloading of roles is not possible, you may want to be able to write:
(defun DEFUN (Name Defun) #|...|#)
So you have the whole spectrum, from formally formal symbolic
languages to ambiguously informal spoken languages, and somewhere in
the middle the frontier between a need or a usefullness of case
sensitivity and a more convenient or irrelevant case insensitivity.
Lisp seems agnotic in this respect: it lets the user/programmer decide
how to handle case.
Another observation: I've often seen that natural language IA code
translated N.L. sentences to Lisp lists of symbols. Which gives things
like: (|I'VE| OFTEN SEEN THAT NATURAL LANGUAGE IA CODE TRANSLATED
N.L. SENTENCES TO LISP LISTS OF SYMBOLS). It should be useful to be
able to keep case sensitivity in these symbols (more in languages such
as German for example): (|I've| often seen that natural language IA
code translated N.L. sentences to Lisp lists of symbols).
(A feature useful for data items is not necessarily to be commended
for our sources).
--
__Pascal_Bourguignon__
http://www.informatimago.com/
Do not adjust your mind, there is a fault in reality.
Pascal Bourguignon <····@thalassa.informatimago.com> wrote in message news:<··············@thalassa.informatimago.com>...
> The reason why MacOS and MS-Windows file systems are not case
> sensitive is because they're targeted to dumb people who can't be
> precise in their spellings (and let me ask you what importance since
> they'll designate their files by clicking on their icons anyway?!).
Because:
1. Directory listings can be, and often are, sorted by name, even in
the Mac GUI, and it makes no sense from a user standpoint to do unix
style "alphabetization" (in quotes because unix, case sensitive
"alphabetization" is broken from a natural language speaker's
perspective).
2. Automated tools, such as scripts, which will be written by
programmers, but used by users, will do the right thing.
Experience with the majority of users shows that Case Insensitive Case
Preserving is the way to go.
BTW, characterizing Mac OS as "targeted to dumb people" is not going
to make you very popular here - lots of correspondents to this group
use Mac OS X.
·······@mediaone.net (Raffael Cavallaro) writes:
> BTW, characterizing Mac OS as "targeted to dumb people" is not going
> to make you very popular here - lots of correspondents to this group
> use Mac OS X.
Me too. Note the difference between MacOS and MacOSX.
--
__Pascal_Bourguignon__
http://www.informatimago.com/
Do not adjust your mind, there is a fault in reality.
···@sevak.isi.edu (Thomas A. Russ) writes:
> Ingvar Mattsson <······@cathouse.bofh.se> writes:
>
> > Kenny Tilton <·······@nyc.rr.com> writes:
> >
> > > Bj�rn Lindberg wrote:
> > > > Another thing I dislike about studlycaps has to do with word
> > > > composition, eg is it called HashTable or Hashtable?
> > >
> > > You know, every time this comes up, people assume using camelCase
> > > somehow also entails use of case sensitivity. Understandable, I guess,
> > > but one canType likeThis toMake code moreReadable even if the compiler
> > > doesnotsee it likethat atall.
> >
> > Well, camelCasing doesn't really make any sense without having
> > caseSensitivity, since one should always strive to have equally
> > readable printed names as read names (if that makes sense). On reading
> > an dthen printing a camelCase symbol, it'd be CAMELCASE, whereas a
> > lisp-case symbol would be LISP-CASE. Other than that, you do what you
> > want, as long as you are happy the code is readable-enough in a text
> > backtrace bunged in an email to you.
>
> Not necessarily. The MacOS and Windows file systems use names that
> retain their original case, but are not case sensitive.
>
> One could easily imagine doing something similar with symbol names. The
> reader would preserve the case of symbol names, but the lookup and
> matching to find the actual symbol would be done in a case insensitive
> manner. If no symbol is found, then the first capitalization is the one
> that is preserved as the canonical name of the symbol.
>
> In that case, both "HashTable" and "Hashtable" would map to the same
> symbol object, which would be printed "HashTable" (because that was the
> first spelling seen).
Well, as I said, "as long as you're happy you can read it in a
backtrace pasted into an email" (that is, I was not referring to how
case *should* be handled, but how to case *is* handled, in Common
Lisp, specifically).
//Ingvar
--
A routing decision is made at every routing point, making local hacks
hard to permeate the network with.
"Kenny Tilton" <·······@nyc.rr.com> schrieb im Newsbeitrag
··························@twister.nyc.rr.com...
>
>
> Robert Klemme wrote:
>
> > Hi all,
> >
> > I'm trying to find my way into Lisp and came across this function
> > definition in "On Lisp" (sect. 4.1, pg 42):
> >
> > (defun find2 (fn lst)
> > (if (null lst)
> > nil
> > (let ((val (funcall fn (car lst))))
> > (if val
> > (values (car lst) val)
> > (find2 fn (cdr lst))))))
> >
> > I asked myself, why did Paul Graham use (car lst) twice? Isn't it
cheaper
> > to omit one call and store the value? Is it a matter of style or are
> > there any differences between that and the function I came up with:
> >
> > (defun find3 (fn lst)
> > (if (null lst)
> > nil
> > (let* ((x (car lst))
> > (val (funcall fn x)))
> > (if val
> > (values x val)
> > (find2 fn (cdr lst))))))
>
> Car is not expensive enough to justify more code clutter,
Thanks for that explanation.
> but I have a
> macro which will deftly bind one return value in a conditional:
[snip]
You completely lost me on that one. But I hope once I'll be able to read
that. :-)
For now I'll go on reading "On Lisp"...
Regards
robert
"Robert Klemme" <········@gmx.net> wrote in message news:<··············@ID-52924.news.uni-berlin.de>...
> Hi all,
>
> I'm trying to find my way into Lisp and came across this function
> definition in "On Lisp" (sect. 4.1, pg 42):
>
> (defun find2 (fn lst)
> (if (null lst)
> nil
> (let ((val (funcall fn (car lst))))
> (if val
> (values (car lst) val)
> (find2 fn (cdr lst))))))
>
> I asked myself, why did Paul Graham use (car lst) twice? Isn't it cheaper
> to omit one call and store the value?
Why should it be cheaper to access the binding of a lexical variable
versus the CAR slot of a CONS?
A lexical variable is typically stored in a stack frame, or a closure.
You need something like indirect addressing with displacement to
access it relative to a stack or closure pointer, assuming there are
no register-caching optimizations.
To access a CAR field, you need---guess what---indirect addressing
through a pointer to the CONS. Same thing.
An optimizing compiler can may be able to perform CSE---common
subexpression elimination, so that the value of (CAR LST) is cached in
a register the first time and just retrieved thereafter. It's easy to
identify that this optimization is possible because LST is a lexical
variable that is never assigned to in the lexical scope, and CAR is a
standard function whose semantics are free of side effects.
Kaz Kylheku wrote:
> Why should it be cheaper to access the binding of a lexical variable
> versus the CAR slot of a CONS?
The lexical variable can be stored in a register.
> An optimizing compiler can may be able to perform CSE---common
> subexpression elimination, so that the value of (CAR LST) is cached in
> a register the first time and just retrieved thereafter.
However, it cannot in this case, because it cannot know
that the funcall does not (as a side effect) change the
car of lst. It's easier to figure out that a lexical
variable is not modified.
Paul
"Paul Dietz" <············@motorola.com> schrieb im Newsbeitrag
······················@motorola.com...
> Kaz Kylheku wrote:
>
> > Why should it be cheaper to access the binding of a lexical variable
> > versus the CAR slot of a CONS?
>
> The lexical variable can be stored in a register.
>
> > An optimizing compiler can may be able to perform CSE---common
> > subexpression elimination, so that the value of (CAR LST) is cached in
> > a register the first time and just retrieved thereafter.
>
> However, it cannot in this case, because it cannot know
> that the funcall does not (as a side effect) change the
> car of lst. It's easier to figure out that a lexical
> variable is not modified.
The question is how much the compiler can assume (or know) about the side
effects of functions. This would be an easier optimization in a pure
functional language I guess.
Thanks to both of you for this answers! (5 duke dollars for each of you)
Regards
robert
From: Joe Marshall
Subject: Re: Is it just style or another reason?
Date:
Message-ID: <brt112t6.fsf@ccs.neu.edu>
Paul Dietz <············@motorola.com> writes:
> Kaz Kylheku wrote:
>
>> Why should it be cheaper to access the binding of a lexical variable
>> versus the CAR slot of a CONS?
>
> The lexical variable can be stored in a register.
Not on one of these modern register-starved machines it can't.
>> An optimizing compiler can may be able to perform CSE---common
>> subexpression elimination, so that the value of (CAR LST) is cached in
>> a register the first time and just retrieved thereafter.
>
> However, it cannot in this case, because it cannot know
> that the funcall does not (as a side effect) change the
> car of lst. It's easier to figure out that a lexical
> variable is not modified.
On the other hand, the CAR slot can be cached, in which case the
hardware knows if the slot has been modified over the function
call.
In either case, it's premature optimization.