I just started using lisp today (coming from C-esque languages), so
please be gentle ;)
This is from the CLISP 2.33.1 in iteractive mode:
[3]> (setq inputTemp 5)
5
- [4]> (setq input '(1 2 3))
(1 2 3)
- [5]> (append '(inputTemp) input)
(INPUTTEMP 1 2 3)
From documents I know append joins two lists. Append also works fine
if I use a constant list in place of the inputTemp atom (that's a
single value in lisp terms I think, right?). The INPUTTEMP in caps
also shows up if I call the print function. I'm sure I'm doing
something obviously wrong, but I can't seem to spot it. If I combine
push and reverse I can do the task just fine, but append appears to be
the correct function for the job.
From: Peter Seibel
Subject: Re: Novice: problem with atoms showing up in caps with append
Date:
Message-ID: <m3vfbhxoft.fsf@javamonkey.com>
············@gmail.com (Brian Peyton) writes:
> I just started using lisp today (coming from C-esque languages), so
> please be gentle ;)
>
>
> This is from the CLISP 2.33.1 in iteractive mode:
> [3]> (setq inputTemp 5)
> 5
> - [4]> (setq input '(1 2 3))
> (1 2 3)
> - [5]> (append '(inputTemp) input)
> (INPUTTEMP 1 2 3)
>
> From documents I know append joins two lists. Append also works fine
> if I use a constant list in place of the inputTemp atom (that's a
> single value in lisp terms I think, right?). The INPUTTEMP in caps
> also shows up if I call the print function. I'm sure I'm doing
> something obviously wrong, but I can't seem to spot it. If I combine
> push and reverse I can do the task just fine, but append appears to
> be the correct function for the job.
Try this
(append (list inputTemp) input)
Then look up QUOTE, which is what the ' is a shortand for. If that
doesn't clear it up, consider these experiments at the REPL and do
your own.
CL-USER> (defparameter *a* 10)
*A*
CL-USER> *a*
10
CL-USER> '*a*
*A*
CL-USER> '(*a*)
(*A*)
CL-USER> '((*a*))
((*A*))
CL-USER> (list *a*)
(10)
CL-USER> (list '*a*)
(*A*)
CL-USER> (list '(*a*))
((*A*))
CL-USER> ''*a*
'*A*
The short version is QUOTE is not a way to build lists, its a way to
prevent something from being evaluated. Also, you should probably not
just SETQ random variables at the REPL as its strictly speaking
undefined what happens if you do. Better to use DEFPARAMETER. (And
watch out for DEFVAR, DEFPARAMETER's sibling since it only assigns the
value you give it to the variable if the variable does not already
have a value.)
And finally, don't use interCap names. Hyphen is a legal character in
Lisp names so input-temp is the Lispy name you should use instead of
inputTemp.
-Peter
P.S. Blatant self promotion: If you're looking for a book to guide you
into the wonderful world of Common Lisp programming, check out:
<http:www.gigamonkeys.com/book/> and let me know what you think.
--
Peter Seibel ·····@javamonkey.com
Lisp is the red pill. -- John Fraser, comp.lang.lisp
Peter Seibel wrote:
> And finally, don't use interCap names. Hyphen is a legal character in
> Lisp names so input-temp is the Lispy name you should use instead of
> inputTemp.
To be clear, inputTemp is just as Lisp-y as input-temp. the problem is
that lispniks are as cultish as any other devout group and basically
fall down frothing at the mouth if they see camelCase.
but Peter's advice is sound: lose the studlyCaps if you are not keen on
black helicopters hovering about. Also: closing parens on their own
line, variables named "lst" instead of "list", recursion where iteration
would do... ok, Lispniks are /more/ cultish.
:)
kenny
--
Cells? Cello? Celtik?: http://www.common-lisp.net/project/cells/
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
From: Alex Mizrahi
Subject: Re: Novice: problem with atoms showing up in caps with append
Date:
Message-ID: <31ggjuF3bgrlgU1@individual.net>
(message (Hello 'Kenny)
(you :wrote :on '(Sun, 05 Dec 2004 08:28:10 GMT))
(
KT> To be clear, inputTemp is just as Lisp-y as input-temp. the problem
KT> is that lispniks are as cultish as any other devout group and
KT> basically fall down frothing at the mouth if they see camelCase.
if you're using SLIME abc-def-ght style names are better because you can
type a-d-g and completion function will look for a*-d*-g*
)
(With-best-regards '(Alex Mizrahi) :aka 'killer_storm)
(prin1 "Jane dates only Lisp programmers"))
From: Svein Ove Aas
Subject: Re: Novice: problem with atoms showing up in caps with append
Date:
Message-ID: <cov70j$jk5$1@services.kq.no>
Alex Mizrahi wrote:
> (message (Hello 'Kenny)
> (you :wrote :on '(Sun, 05 Dec 2004 08:28:10 GMT))
> (
>
> KT> To be clear, inputTemp is just as Lisp-y as input-temp. the problem
> KT> is that lispniks are as cultish as any other devout group and
> KT> basically fall down frothing at the mouth if they see camelCase.
>
> if you're using SLIME abc-def-ght style names are better because you can
> type a-d-g and completion function will look for a*-d*-g*
(Actually, it looks for .*a.*-.*d.*-.*g.*
HTH, etc.)
From: Alex Mizrahi
Subject: Re: Novice: problem with atoms showing up in caps with append
Date:
Message-ID: <31hm1oF3a071jU1@individual.net>
(message (Hello 'Svein)
(you :wrote :on '(Sun, 05 Dec 2004 15:47:00 +0100))
(
>> if you're using SLIME abc-def-ght style names are better because you
>> can type a-d-g and completion function will look for a*-d*-g*
SOA> (Actually, it looks for .*a.*-.*d.*-.*g.*
SOA> HTH, etc.)
--
The default @code{slime-complete-symbol*}
performs completion ``in parallel'' over the hyphen-delimited
sub-words of a symbol name.
@footnote{This style of completion is modelled on @file{completer.el}
by Chris McConnell. That package is bundled with @acronym{ILISP}.}
Formally this means that ··@code{a-b-c}'' can complete to any symbol
matching the regular expression ··@code{^a.*-b.*-c.*}'' (where ``dot''
matches anything but a hyphen).
--
(there's also slime-fuzzy-complete-symbol that ignores hyphens, but it works
in other way..
default one is working incrementally, while fuzzy shows list of all matching
symbols)
)
(With-best-regards '(Alex Mizrahi) :aka 'killer_storm)
(prin1 "Jane dates only Lisp programmers"))
From: Brian Downing
Subject: Re: Novice: problem with atoms showing up in caps with append
Date:
Message-ID: <bLptd.726911$8_6.287763@attbi_s04>
In article <···············@individual.net>,
Alex Mizrahi <········@hotmail.com> wrote:
> (there's also slime-fuzzy-complete-symbol that ignores hyphens, but it
> works in other way.. default one is working incrementally, while
> fuzzy shows list of all matching symbols)
It doesn't actually ignore hyphens, it just doesn't require them to find
matches. The fuzzy completer finds all cases where the letters of the
abbreviation are present in the order given. It scores a result higher
if it has matching letters in "significant" places, such as at the
beginning of a symbol or after a hyphen.
For example, for "mvb" the match "Multiple-Value-Bind" is considered
better than "Most-positiVe-douBle-float", which is itself better than
"reMoVe-ooB-handler".
Specifically:
(defparameter *fuzzy-completion-symbol-prefixes* "*+-%&?<"
"Letters that are likely to be at the beginning of a symbol.
Letters found after one of these prefixes will be scored as if
they were at the beginning of ths symbol.")
(defparameter *fuzzy-completion-symbol-suffixes* "*+->"
"Letters that are likely to be at the end of a symbol.
Letters found before one of these suffixes will be scored as if
they were at the end of the symbol.")
(defparameter *fuzzy-completion-word-separators* "-/."
"Letters that separate different words in symbols. Letters
after one of these symbols will be scores more highly than other
letters.")
-bcd
--
*** Brian Downing <bdowning at lavos dot net>
From: Coby Beck
Subject: Re: Novice: problem with atoms showing up in caps with append
Date:
Message-ID: <FFGsd.236031$df2.222878@edtnps89>
"Kenny Tilton" <·······@nyc.rr.com> wrote in message
··························@twister.nyc.rr.com...
> Peter Seibel wrote:
>> And finally, don't use interCap names. Hyphen is a legal character in
>> Lisp names so input-temp is the Lispy name you should use instead of
>> inputTemp.
>
> To be clear, inputTemp is just as Lisp-y as input-temp. the problem is
No it's not. It is very uncommon in lisp code, therefore not Lisp-y, and
there are good reasons for this, easily googled.
> that lispniks are as cultish as any other devout group and basically fall
> down frothing at the mouth if they see camelCase.
[gets up, wipes froth from mouth]
--
Coby Beck
(remove #\Space "coby 101 @ big pond . com")
Coby Beck wrote:
> "Kenny Tilton" <·······@nyc.rr.com> wrote in message
> ··························@twister.nyc.rr.com...
>
>>Peter Seibel wrote:
>>
>>>And finally, don't use interCap names. Hyphen is a legal character in
>>>Lisp names so input-temp is the Lispy name you should use instead of
>>>inputTemp.
>>
>>To be clear, inputTemp is just as Lisp-y as input-temp. the problem is
>
>
> No it's not.
Is, too!
> It is very uncommon in lisp code,...
All my code is uncommon.
> therefore not Lisp-y,
Hand-waving.
> and
> there are good reasons for this, easily googled.
No room in the margin, eh?
>
>>that lispniks are as cultish as any other devout group and basically fall
>>down frothing at the mouth if they see camelCase.
>
>
> [gets up, wipes froth from mouth]
>
:)
kenny
--
Cells? Cello? Celtik?: http://www.common-lisp.net/project/cells/
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
In article <·····················@twister.nyc.rr.com>,
Kenny Tilton <·······@nyc.rr.com> wrote:
> Coby Beck wrote:
> > "Kenny Tilton" <·······@nyc.rr.com> wrote in message
> > ··························@twister.nyc.rr.com...
> >
> >>Peter Seibel wrote:
> >>
> >>>And finally, don't use interCap names. Hyphen is a legal character in
> >>>Lisp names so input-temp is the Lispy name you should use instead of
> >>>inputTemp.
> >>
> >>To be clear, inputTemp is just as Lisp-y as input-temp. the problem is
> >
> > No it's not.
> > It is very uncommon in lisp code,...
>
> All my code is uncommon.
Kenny, what percentage of the Common Lisp code that you have seen or
used but not written yourself used camel-case/camelCase/CamelCase?
Sashank Varma <····@vanderbilt.edu> writes:
> In article <·····················@twister.nyc.rr.com>,
> Kenny Tilton <·······@nyc.rr.com> wrote:
>
> > Coby Beck wrote:
> > > "Kenny Tilton" <·······@nyc.rr.com> wrote in message
> > > ··························@twister.nyc.rr.com...
> > >
> > >>Peter Seibel wrote:
> > >>
> > >>>And finally, don't use interCap names. Hyphen is a legal character in
> > >>>Lisp names so input-temp is the Lispy name you should use instead of
> > >>>inputTemp.
> > >>
> > >>To be clear, inputTemp is just as Lisp-y as input-temp. the problem is
> > >
> > > No it's not.
>
> > > It is very uncommon in lisp code,...
> >
> > All my code is uncommon.
>
> Kenny, what percentage of the Common Lisp code that you have seen or
> used but not written yourself used camel-case/camelCase/CamelCase?
I'm not Kenny, but ...
I haven't seen any non-Kenny code that uses CamelCase, but I have seen
quite a bit that uses Camel-Case. It looks like it was a common style
at CMU back when they produced a lot of Lisp.
Kenny wrote:
> To be clear, inputTemp is just as Lisp-y as input-temp. the problem
> is that lispniks are as cultish as any other devout group and
> basically fall down frothing at the mouth if they see camelCase.
Many other languages, saddled with what Drew McDermott refers to as an
encryption mechanism called "grammar", will misinterpret the symbol
foo-bar as "foo minus bar". Thus in these languages you cannot use
foo-bar as a symbol, and some people decided the solution was to write
something like FooBar. This is both harder to read and harder to
type. Since Lisp programmers aren't saddled with the need to satisfy
grammar decrypters (aka parsers), they can write in an easy to read
and type style using dashes instead. After all, why use a coding
style designed to solve a problem you don't have?
Here's Drew McDermott's quotation, just so people know what I'm
talking about:
All languages have Lisp syntax, of course, except that so many of
them insist on encrypting it using a mechanism called "grammar."
Excuse me while I pick myself up and wipe the froth from my mouth.
--
Fred Gilham ······@csl.sri.com
I know the strange tale of the Slug; / the Early Sin -- the Fall --
the Sleep -- the Vision -- and the Vow -- / the Quest -- the Crown --
the Call. --- G. K. Chesterton
From: Marcin 'Qrczak' Kowalczyk
Subject: Re: Novice: problem with atoms showing up in caps with append
Date:
Message-ID: <87zn0rrsk4.fsf@qrnik.zagroda>
Fred Gilham <······@snapdragon.csl.sri.com> writes:
> Thus in these languages you cannot use foo-bar as a symbol, and some
> people decided the solution was to write something like FooBar. This
> is both harder to read and harder to type.
It is debatable whether it's harder to read.
The point is that it's more important to see a name as a whole than to
decode words which are its components. Especially in a syntax which
uses just spaces between function arguments, and between a function
name and its arguments.
--
__("< Marcin Kowalczyk
\__/ ······@knm.org.pl
^^ http://qrnik.knm.org.pl/~qrczak/
In article <··············@snapdragon.csl.sri.com>,
Fred Gilham <······@snapdragon.csl.sri.com> wrote:
> Kenny wrote:
> > To be clear, inputTemp is just as Lisp-y as input-temp. the problem
> > is that lispniks are as cultish as any other devout group and
> > basically fall down frothing at the mouth if they see camelCase.
>
> Many other languages, saddled with what Drew McDermott refers to as an
> encryption mechanism called "grammar", will misinterpret the symbol
> foo-bar as "foo minus bar". Thus in these languages you cannot use
> foo-bar as a symbol, and some people decided the solution was to write
> something like FooBar. This is both harder to read and harder to
> type.
My mileage differs. Actually, i hyphenated function names and camelcased
slot names and class names. I know it is supposed to be an abstraction,
but I always liked knowing when something was just a slot and not a
function whose processing I would have to check. Class names, i do not
know, I guess I knew I wanted to start with an uppercase, and TreeView
looks a helluva lot better than Tree-view or tree-view.
> Since Lisp programmers aren't saddled with the need to satisfy
> grammar decrypters (aka parsers), they can write in an easy to read
> and type style using dashes instead. After all, why use a coding
> style designed to solve a problem you don't have?
I simply did not like all the extra hyphen characters. It was my
personal preference, and offered me the small advantage noted above. I
programmed that way in Lisp for six or seven years before being dragged
down by the savages of c.l.l., so clearly there is no technical or
practical disadvantage to camelcase in Lisp.
There is only rank, irrational, hyphaphobia. However calmly presented. :)
kenny
ps. Someone presented the solitary argument that all Lisp code eschews
camelCase. Sounds as if we agree: there is nothing technical or
pragamatic one can point to in defense of hyphens, only conformity.
k
From: David Steuber
Subject: Re: Novice: problem with atoms showing up in caps with append
Date:
Message-ID: <87vfbe2bxq.fsf@david-steuber.com>
Kenneth Tilton <·······@nyc.rr.com> writes:
> ps. Someone presented the solitary argument that all Lisp code eschews
> camelCase. Sounds as if we agree: there is nothing technical or
> pragamatic one can point to in defense of hyphens, only conformity.
You don't need to hold down the shift key to type the hyphen.
--
An ideal world is left as an excercise to the reader.
--- Paul Graham, On Lisp 8.1
David Steuber wrote:
> Kenneth Tilton <·······@nyc.rr.com> writes:
>
>
>>ps. Someone presented the solitary argument that all Lisp code eschews
>>camelCase. Sounds as if we agree: there is nothing technical or
>>pragamatic one can point to in defense of hyphens, only conformity.
>
>
> You don't need to hold down the shift key to type the hyphen.
>
For a bunch of people key-chording more than Segovia, I gotta say that
is a bit of a reach. :)
But you know, I am not a touch-typist, I hate shifting, and I still have
not remapped [] to be () and used to use camelCase instead of
camel-case. Go figger. I guess this stuff is not worth bothering about.
<hint>
:)
kenny
--
Cells? Cello? Celtik?: http://www.common-lisp.net/project/cells/
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Kenny wrote:
> But you know, I am not a touch-typist, I hate shifting, and I still have
> not remapped [] to be () and used to use camelCase instead of
> camel-case.
Lazy. :-)
Hey, Kenny, I agree with you about most everything you post here, but
I've got to find some nit to pick.
--
Fred Gilham ······@csl.sri.com
I mean what's Stanford doing teaching Java? That's not education,
it's vocational training. -- Bruce Stephens
Kenneth Tilton <·······@nyc.rr.com> writes:
> I simply did not like all the extra hyphen characters. It was my
> personal preference, and offered me the small advantage noted above. I
> programmed that way in Lisp for six or seven years before being dragged
> down by the savages of c.l.l., so clearly there is no technical or
> practical disadvantage to camelcase in Lisp.
>
> There is only rank, irrational, hyphaphobia. However calmly presented. :)
There is the slight risk of collision because even when you write
CamelCase, it's actally CAMELCASE and the same as CaMelcase.
--
__Pascal Bourguignon__ http://www.informatimago.com/
The world will now reboot; don't bother saving your artefacts.
"Pascal Bourguignon" <····@mouse-potato.com> wrote in message
···················@thalassa.informatimago.com...
> Kenneth Tilton <·······@nyc.rr.com> writes:
> > I simply did not like all the extra hyphen characters. It was my
> > personal preference, and offered me the small advantage noted above. I
> > programmed that way in Lisp for six or seven years before being dragged
> > down by the savages of c.l.l., so clearly there is no technical or
> > practical disadvantage to camelcase in Lisp.
> >
> > There is only rank, irrational, hyphaphobia. However calmly presented.
:)
>
> There is the slight risk of collision because even when you write
> CamelCase, it's actally CAMELCASE and the same as CaMelcase.
Not if you change your readtable case to :preserve (or :downcase if you want
to be perverse, though that would still give you collisions).
Gorbag wrote:
>
> "Pascal Bourguignon" <····@mouse-potato.com> wrote in message
> ···················@thalassa.informatimago.com...
>> Kenneth Tilton <·······@nyc.rr.com> writes:
>> > I simply did not like all the extra hyphen characters. It was my
>> > personal preference, and offered me the small advantage noted above. I
>> > programmed that way in Lisp for six or seven years before being dragged
>> > down by the savages of c.l.l., so clearly there is no technical or
>> > practical disadvantage to camelcase in Lisp.
>> >
>> > There is only rank, irrational, hyphaphobia. However calmly presented.
> :)
>>
>> There is the slight risk of collision because even when you write
>> CamelCase, it's actally CAMELCASE and the same as CaMelcase.
>
> Not if you change your readtable case to :preserve (or :downcase if you
> want to be perverse, though that would still give you collisions).
If you actually, say, /did/ make this change, and used a :preserve-ing
readtable, wouldn't you have to type CL symbols in CAPS or make a package
that re-exported all the CL symbols with lower-case names? (I hear Allegro
has already done this work for you.) That's a lot of effort to make
programming in a case-sensitive style worth it.
Chris Capel
From: Nikodemus Siivola
Subject: Re: Novice: problem with atoms showing up in caps with append
Date:
Message-ID: <cp713c$ilu68$1@midnight.cs.hut.fi>
Chris Capel <······@iba.nktech.net> wrote:
> If you actually, say, /did/ make this change, and used a :preserve-ing
> readtable, wouldn't you have to type CL symbols in CAPS or make a package
> that re-exported all the CL symbols with lower-case names? (I hear Allegro
This is what readtable :invert is for.
Cheers,
-- Nikodemus
Pascal Bourguignon wrote:
> Kenneth Tilton <·······@nyc.rr.com> writes:
>
>>I simply did not like all the extra hyphen characters. It was my
>>personal preference, and offered me the small advantage noted above. I
>>programmed that way in Lisp for six or seven years before being dragged
>>down by the savages of c.l.l., so clearly there is no technical or
>>practical disadvantage to camelcase in Lisp.
>>
>>There is only rank, irrational, hyphaphobia. However calmly presented. :)
>
>
> There is the slight risk of collision because even when you write
> CamelCase, it's actally CAMELCASE and the same as CaMelcase.
Sure, and if someone varies hyphenation to distinguish names and misses
a hyphen...
:)
kenny
--
Cells? Cello? Celtik?: http://www.common-lisp.net/project/cells/
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Hi Kenneth Tilton,
> I simply did not like all the extra hyphen characters. It was my
> personal preference, and offered me the small advantage noted above. I
> programmed that way in Lisp for six or seven years before being dragged
> down by the savages of c.l.l., so clearly there is no technical or
> practical disadvantage to camelcase in Lisp.
And the hyphens take up horizontal real estate.
In fact there is a technical/practical advantage to camelCase for those
who like counting every CPU cycle. camelCase symbols can be interned
faster in the case preserving :INVERT mode. Once a change in character
case is detected the whole symbol name can be stored as read.
This is ABCL:
(setf (readtable-case *readtable*) :invert)
(time (dotimes (i 1000000) (read-from-string "with-output-to-string")))
=> average 11.88 seconds
(time (dotimes (i 1000000) (read-from-string "with-Output-To-String")))
=> average 9.14 seconds
The above shows us camelCase is faster in ABCL even when the symbol name
is the same length. But the symbol name is actually shorter:
(time (dotimes (i 1000000) (read-from-string "withOutputToString")))
=> average 8.61 seconds
Regards,
Adam
From: Brian Downing
Subject: Re: Novice: problem with atoms showing up in caps with append
Date:
Message-ID: <jPytd.626944$mD.483535@attbi_s02>
In article <······························@consulting.net.nz>,
Adam Warner <······@consulting.net.nz> wrote:
> And the hyphens take up horizontal real estate.
>
> In fact there is a technical/practical advantage to camelCase for those
> who like counting every CPU cycle. camelCase symbols can be interned
> faster in the case preserving :INVERT mode. Once a change in character
> case is detected the whole symbol name can be stored as read.
...but the cycles you save get reclaimed by M-x glasses-mode. :-)
-bcd
--
*** Brian Downing <bdowning at lavos dot net>
Hi Brian Downing,
> In article <······························@consulting.net.nz>,
> Adam Warner <······@consulting.net.nz> wrote:
>> And the hyphens take up horizontal real estate.
>>
>> In fact there is a technical/practical advantage to camelCase for those
>> who like counting every CPU cycle. camelCase symbols can be interned
>> faster in the case preserving :INVERT mode. Once a change in character
>> case is detected the whole symbol name can be stored as read.
>
> ...but the cycles you save get reclaimed by M-x glasses-mode. :-)
I thought I'd better check that this functionality exists in Emacs.
And it does!
Very useful. It displays names such as withOutputToString as
with_Output_To_String (even though the underlying name remains the same
and selections copy without underscores).
Now all we need is to adopt case distinction between variable and function
names and we can unify Common Lisp and Scheme within a single namespace ;-)
Have fun,
Adam
"Kenny Tilton" <·······@nyc.rr.com> wrote in message
··························@twister.nyc.rr.com...
>
> Peter Seibel wrote:
> > And finally, don't use interCap names. Hyphen is a legal character in
> > Lisp names so input-temp is the Lispy name you should use instead of
> > inputTemp.
>
> To be clear, inputTemp is just as Lisp-y as input-temp.
It is if you interpret "Lisp-y" as "legal according to the language
grammar", but not if you consider idioms and community shared culture.
Since code usually gets read several times by several people, it is
very important that it respects shared culture (as well as being legal
of course).
> the problem is
> that lispniks are as cultish as any other devout group and basically
> fall down frothing at the mouth if they see camelCase.
I'd rather say that lispniks' shared culture is more "developed" than
that of many other language communities, with more precise (thus
restrictive) idioms.
--
Matthieu Villeneuve
Matthieu Villeneuve wrote:
> "Kenny Tilton" <·······@nyc.rr.com> wrote in message
> ··························@twister.nyc.rr.com...
>
>>Peter Seibel wrote:
>>
>>>And finally, don't use interCap names. Hyphen is a legal character in
>>>Lisp names so input-temp is the Lispy name you should use instead of
>>>inputTemp.
>>
>>To be clear, inputTemp is just as Lisp-y as input-temp.
>
>
> It is if you interpret "Lisp-y" as "legal according to the language
> grammar", but not if you consider idioms and community shared culture.
> Since code usually gets read several times by several people, it is
> very important that it respects shared culture (as well as being legal
> of course).
>
>
>>the problem is
>>that lispniks are as cultish as any other devout group and basically
>>fall down frothing at the mouth if they see camelCase.
>
>
> I'd rather say that lispniks' shared culture is more "developed" than
> that of many other language communities, with more precise (thus
> restrictive) idioms.
Oh, please, lipstick on a pig. the problem with this pose of
sophistication is that the mob does not look very "developed" when it is
shouting down a camelcaser.
kenny
--
Cells? Cello? Celtik?: http://www.common-lisp.net/project/cells/
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
"Kenny Tilton" <·······@nyc.rr.com> wrote in message
··························@twister.nyc.rr.com...
> >>the problem is
> >>that lispniks are as cultish as any other devout group and basically
> >>fall down frothing at the mouth if they see camelCase.
> >
> > I'd rather say that lispniks' shared culture is more "developed" than
> > that of many other language communities, with more precise (thus
> > restrictive) idioms.
>
> Oh, please, lipstick on a pig. the problem with this pose of
> sophistication is that the mob does not look very "developed" when it
> is shouting down a camelcaser.
Absolutely, but I believe that a Lisp newbie can be nicely told
about the community idioms and programming style, and doesn't need
to get shouted at and scared.
(I'd also recommend that we replace scary black helicopters with
friendlier innocent-looking pizza vans parked down the street...)
--
Matthieu Villeneuve
From: Tim Bradshaw
Subject: Re: Novice: problem with atoms showing up in caps with append
Date:
Message-ID: <ey3k6rsya8s.fsf@cley.com>
* Matthieu Villeneuve wrote:
> (I'd also recommend that we replace scary black helicopters with
> friendlier innocent-looking pizza vans parked down the street...)
Black helicopters are compulsory, actually.
Kenny Tilton <·······@nyc.rr.com> writes:
> Matthieu Villeneuve wrote:
>
> > "Kenny Tilton" <·······@nyc.rr.com> wrote in message
> > ··························@twister.nyc.rr.com...
> >
> >>Peter Seibel wrote:
> >>
> >>>And finally, don't use interCap names. Hyphen is a legal character in
> >>>Lisp names so input-temp is the Lispy name you should use instead of
> >>>inputTemp.
> >>
> >>To be clear, inputTemp is just as Lisp-y as input-temp.
> > It is if you interpret "Lisp-y" as "legal according to the language
> > grammar", but not if you consider idioms and community shared culture.
> > Since code usually gets read several times by several people, it is
> > very important that it respects shared culture (as well as being legal
> > of course).
> >
> >>the problem is
> >>that lispniks are as cultish as any other devout group and basically
> >>fall down frothing at the mouth if they see camelCase.
> > I'd rather say that lispniks' shared culture is more "developed" than
> > that of many other language communities, with more precise (thus
> > restrictive) idioms.
>
> Oh, please, lipstick on a pig. the problem with this pose of
> sophistication is that the mob does not look very "developed" when it
> is shouting down a camelcaser.
Indeed. It is worth to repeat pedagogically the good conventions of
the lisp community, but give the newbies time to lose their old
habits and convince themselves of the goodness of the lisp way.
My first CLOS programs were CamelCase (for they were written with
eieio in case sensitive emacs), I hyphenated them some years later.
I'm still losing some old imported conventions of mine...
--
__Pascal Bourguignon__ http://www.informatimago.com/
The world will now reboot; don't bother saving your artefacts.
From: Duane Rettig
Subject: Re: Novice: problem with atoms showing up in caps with append
Date:
Message-ID: <48y88pvr1.fsf@franz.com>
Pascal Bourguignon <····@mouse-potato.com> writes:
> Kenny Tilton <·······@nyc.rr.com> writes:
>
> > Matthieu Villeneuve wrote:
> >
> > > "Kenny Tilton" <·······@nyc.rr.com> wrote in message
> > > ··························@twister.nyc.rr.com...
> > >
> > >>Peter Seibel wrote:
> > >>
> > >>>And finally, don't use interCap names. Hyphen is a legal character in
> > >>>Lisp names so input-temp is the Lispy name you should use instead of
> > >>>inputTemp.
> > >>
> > >>To be clear, inputTemp is just as Lisp-y as input-temp.
> > > It is if you interpret "Lisp-y" as "legal according to the language
> > > grammar", but not if you consider idioms and community shared culture.
> > > Since code usually gets read several times by several people, it is
> > > very important that it respects shared culture (as well as being legal
> > > of course).
> > >
> > >>the problem is
> > >>that lispniks are as cultish as any other devout group and basically
> > >>fall down frothing at the mouth if they see camelCase.
> > > I'd rather say that lispniks' shared culture is more "developed" than
> > > that of many other language communities, with more precise (thus
> > > restrictive) idioms.
> >
> > Oh, please, lipstick on a pig. the problem with this pose of
> > sophistication is that the mob does not look very "developed" when it
> > is shouting down a camelcaser.
>
> Indeed. It is worth to repeat pedagogically the good conventions of
> the lisp community, but give the newbies time to lose their old
> habits and convince themselves of the goodness of the lisp way.
Perhaps, but we Lispers aren't that good at organizing such teaching.
For example, perhaps I missed it, but I don't remember seeing on this
thread one of the strongest arguments for hyphenation over CamelCase:
if in some emacs/lisp work environments you type w-o-f and then perform
completion, it will either expand on the spot to with-open-file, or
it will offer you a choice of completions. I don't know if any
such expansions are available for that kind of WOF -> WithOpenFile
expansions.
If in our pedagogy we can organize lists of reasons for doing things
a certain way, then the reasons for certain "Lispy" choices become
much clearer, and aren't so mysterious. Of course, mystery might
be some peoples' goal ... :-)
> My first CLOS programs were CamelCase (for they were written with
> eieio in case sensitive emacs), I hyphenated them some years later.
> I'm still losing some old imported conventions of mine...
Can you list the reasons why? I think that if you put your
mind to it, you might come up with a couple of reasons, and
then later on more reasons will just suddenly hit you. We tend
to internalize and forget our reasons for doing things a certain
way, and that is what comes across to newbies as cultish.
--
Duane Rettig ·····@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
From: Brian Downing
Subject: Re: Novice: problem with atoms showing up in caps with append
Date:
Message-ID: <HJHtd.730994$8_6.426565@attbi_s04>
In article <·············@franz.com>, Duane Rettig <·····@franz.com> wrote:
> Perhaps, but we Lispers aren't that good at organizing such teaching.
> For example, perhaps I missed it, but I don't remember seeing on this
> thread one of the strongest arguments for hyphenation over CamelCase:
> if in some emacs/lisp work environments you type w-o-f and then perform
> completion, it will either expand on the spot to with-open-file, or
> it will offer you a choice of completions. I don't know if any
> such expansions are available for that kind of WOF -> WithOpenFile
> expansions.
(shameless-plug (:not-to-be-construed-as "support of camel-case")
"Check out fuzzy-complete-symbol in Slime (C-c M-i by default). With
READTABLE-CASE set to :PRESERVE or :INVERT, it will do exactly that.")
It isn't actually designed to work that way, as I don't use camel case,
but it sort of falls out of the design naturally.
-bcd
--
*** Brian Downing <bdowning at lavos dot net>
From: Duane Rettig
Subject: Re: Novice: problem with atoms showing up in caps with append
Date:
Message-ID: <4vfbco9rq.fsf@franz.com>
Brian Downing <·············@lavos.net> writes:
> In article <·············@franz.com>, Duane Rettig <·····@franz.com> wrote:
> > Perhaps, but we Lispers aren't that good at organizing such teaching.
> > For example, perhaps I missed it, but I don't remember seeing on this
> > thread one of the strongest arguments for hyphenation over CamelCase:
> > if in some emacs/lisp work environments you type w-o-f and then perform
> > completion, it will either expand on the spot to with-open-file, or
> > it will offer you a choice of completions. I don't know if any
> > such expansions are available for that kind of WOF -> WithOpenFile
> > expansions.
>
> (shameless-plug (:not-to-be-construed-as "support of camel-case")
> "Check out fuzzy-complete-symbol in Slime (C-c M-i by default). With
> READTABLE-CASE set to :PRESERVE or :INVERT, it will do exactly that.")
>
> It isn't actually designed to work that way, as I don't use camel case,
> but it sort of falls out of the design naturally.
OK, good to know. Thanks.
--
Duane Rettig ·····@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
Duane Rettig <·····@franz.com> writes:
> > Indeed. It is worth to repeat pedagogically the good conventions of
> > the lisp community, but give the newbies time to lose their old
> > habits and convince themselves of the goodness of the lisp way.
>
> Perhaps, but we Lispers aren't that good at organizing such teaching.
> For example, perhaps I missed it, but I don't remember seeing on this
> thread one of the strongest arguments for hyphenation over CamelCase:
> if in some emacs/lisp work environments you type w-o-f and then perform
> completion, it will either expand on the spot to with-open-file, or
> it will offer you a choice of completions. I don't know if any
> such expansions are available for that kind of WOF -> WithOpenFile
> expansions.
>
> If in our pedagogy we can organize lists of reasons for doing things
> a certain way, then the reasons for certain "Lispy" choices become
> much clearer, and aren't so mysterious. Of course, mystery might
> be some peoples' goal ... :-)
>
> > My first CLOS programs were CamelCase (for they were written with
> > eieio in case sensitive emacs), I hyphenated them some years later.
> > I'm still losing some old imported conventions of mine...
>
> Can you list the reasons why? I think that if you put your
> mind to it, you might come up with a couple of reasons, and
> then later on more reasons will just suddenly hit you. We tend
> to internalize and forget our reasons for doing things a certain
> way, and that is what comes across to newbies as cultish.
Well, the main reason I had to convert old CamelCased code to lisp
style was the fact that I ported it from case-sensitive-and-preserving
emacs lisp to Common Lisp (or it was a couple of classes written at a
time when my main programming language was Objective-C where CamelCase
is the way). It's easier to use and maintain code that has only one
convention.
One thing I'm loosing up recently is my comment (automatically) added
at the end of the functions.
(defun do-some-thing (...)
...
...);;do-some-thing
I have this convention since a long time with all programming
languages, starting from pascal and Modula-2 and it's was quite useful
to identify the tail of big functions (when the head scrolled off
screen). Now, I changed the parameter that put this comment only on
really big functions (more than 20 lines currently), because indeed
the placement of closing parenthesis preconized in lisp is nicer and
after all, lisp functions are usually smaller than in other languages
so the problem this convention solves does not occurs so often in lisp.
--
__Pascal Bourguignon__ http://www.informatimago.com/
The world will now reboot; don't bother saving your artefacts.
On 08 Dec 2004 09:04:02 -0800, <·····@franz.com> wrote:
> Pascal Bourguignon <····@mouse-potato.com> writes:
>
>> Kenny Tilton <·······@nyc.rr.com> writes:
>>
>> > Matthieu Villeneuve wrote:
>> >
>> > > "Kenny Tilton" <·······@nyc.rr.com> wrote in message
>> > > ··························@twister.nyc.rr.com...
>> > >
>> > >>Peter Seibel wrote:
>> > >>
>> > >>>And finally, don't use interCap names. Hyphen is a legal character in
>> > >>>Lisp names
>
> Perhaps, but we Lispers aren't that good at organizing such teaching.
> For example, perhaps I missed it, but I don't remember seeing on this
> thread one of the strongest arguments for hyphenation over CamelCase:
> if in some emacs/lisp work environments you type w-o-f and then perform
> completion, it will either expand on the spot to with-open-file, or
> it will offer you a choice of completions. I don't know if any
Ah, now that's a reason to make me abandon my perl past in a moment!
Less typing, more time for XYZ.
--
Everyman has three hearts;
one to show the world, one to show friends, and one only he knows.
Brian Peyton wrote:
> I just started using lisp today (coming from C-esque languages), so
> please be gentle ;)
>
>
> This is from the CLISP 2.33.1 in iteractive mode:
> [3]> (setq inputTemp 5)
> 5
> - [4]> (setq input '(1 2 3))
> (1 2 3)
> - [5]> (append '(inputTemp) input)
> (INPUTTEMP 1 2 3)
>
> From documents I know append joins two lists. Append also works fine
> if I use a constant list in place of the inputTemp atom (that's a
> single value in lisp terms I think, right?). The INPUTTEMP in caps
> also shows up if I call the print function. I'm sure I'm doing
> something obviously wrong, but I can't seem to spot it. If I combine
> push and reverse I can do the task just fine, but append appears to be
> the correct function for the job.
It looks like you need to hook up with a good Lisp book in order to
become familiar with the fundamental ideas in Lisp. Try this for starters:
http://www.gigamonkeys.com/book/
A few quick points--every object in Lisp is either an atom (numbers,
strings, functions, packages, arrays, etc...) or a pair known as a CONS.
(CONS is the basic constructor function used to create lists, trees.)
Symbols are a special type of atom known formally as symbolic atoms. We
often speak loosely of 'the symbol foo' when strictly what we mean is
'the symbol whose name is "FOO"'. As you have seen, the default behavior
of the Lisp system is to associate symbols which you input with the
symbol whose name is the uppercase version of your input:
(print 'foo) => FOO
(print 'FOO) => FOO
(symbol-name 'foo) => "FOO"
(symbol-name 'FOO) => "FOO"
(symbol-name 'fOo) => "FOO"
Here the single quote tells Lisp that we are interested in the symbol
itself, not the value of the variable it names.
This probably seems odd to you, especially when using symbols to name
functions and variables:
(list 'a 'b) => (A B)
(LIST 'a 'B) => (A B)
When you type in 'list' or 'LiSt' or any other variant, Lisp associates
your input with the symbol named "LIST" which is the name of a function
that makes lists.
Here is the most important online reference:
http://www.lispworks.com/reference/HyperSpec/Front/index.htm
You can use it to look up specific Lisp functions via the 'Master Index'
link.
Good luck, but take time to learn the basics.
David Sletten
From: Jeff
Subject: Re: Novice: problem with atoms showing up in caps with append
Date:
Message-ID: <ndysd.443316$wV.37195@attbi_s54>
Brian Peyton wrote:
> I just started using lisp today (coming from C-esque languages), so
> please be gentle ;)
What Peter said. And do check out his great book. Likewise, if you
*really* wnat case-sensitive symbol names (which is *not* recommended),
you can use || around your symbol names to preserve case:
(setf |foo| 10) ==> 10
(setf |FOO| 20) ==> 20
(eq '|foo| '|FOO|) ==> NIL
(+ |foo| |FOO|) ==> 30
Jeff M.
--
http://www.retrobyte.org
··············@gmail.com
"Jeff" <·······@gmail.com> writes:
> Brian Peyton wrote:
>
> > I just started using lisp today (coming from C-esque languages), so
> > please be gentle ;)
>
> What Peter said. And do check out his great book. Likewise, if you
> *really* wnat case-sensitive symbol names (which is *not* recommended),
> you can use || around your symbol names to preserve case:
>
>
> (setf |foo| 10) ==> 10
> (setf |FOO| 20) ==> 20
> (eq '|foo| '|FOO|) ==> NIL
> (+ |foo| |FOO|) ==> 30
>
> Jeff M.
If you want case-sensitivity, always quoting your symbols is probably
the worst way to get it. If you're using a library which uses
mixed-case symbols, but in your own code you're inconsistent wrt case,
then you'll have to quote those symbols. And that's why it's
generally not recommended.
That said, I personally work with a case-sensitive Lisp reader. It's
all nice and standard, too:
CL-USER> (setf (readtable-case *readtable*) :invert)
:invert
CL-USER> (symbol-name 'normal-lisp-symbol)
"NORMAL-LISP-SYMBOL"
CL-USER> (symbol-name 'camel-Case)
"camel-Case"
CL-USER> (symbol-name 'SHOUTING)
"shouting"
CL-USER> (eq 'foo 'Foo)
nil
It also has the advantage that your Lisp system doesn't shout at you
all the time :-)
Brian Peyton wrote:
> I just started using lisp today (coming from C-esque languages), so
> please be gentle ;)
>
>
> This is from the CLISP 2.33.1 in iteractive mode:
> [3]> (setq inputTemp 5)
> 5
> - [4]> (setq input '(1 2 3))
> (1 2 3)
> - [5]> (append '(inputTemp) input)
> (INPUTTEMP 1 2 3)
' is short for QUOTE, not LIST. It just happens to work on lists, which
is why '(1 2 3) is a legal way to make a list. But it will be a literal,
and your next FAQ will be about some astonishing behavior arising from
your unwittingly modifying said literal list. (Not the case here, but I
see it coming <g>).
This works:
(push inputTemp input)
ie, no, APPEND is not what you want, tho it is not bad. I think this
would be simpler:
(cons inputTemp input)
But that does not re-bind the variable input to the new list. It is not
clear if that is what you wanted in this little experiment. But the real
problem is understanding QUOTE alias ', the understanding of which
introductory texts all screw up by using it to make simple lists for
simple exercises, unawares they are grievously miseducating newbies on
its meaning.
kenny
--
Cells? Cello? Celtik?: http://www.common-lisp.net/project/cells/
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
From: Coby Beck
Subject: Re: Novice: problem with atoms showing up in caps with append
Date:
Message-ID: <OJHsd.236358$df2.235065@edtnps89>
"Brian Peyton" <············@gmail.com> wrote in message
································@posting.google.com...
>I just started using lisp today (coming from C-esque languages), so
> please be gentle ;)
>
>
> This is from the CLISP 2.33.1 in iteractive mode:
> [3]> (setq inputTemp 5)
> 5
> - [4]> (setq input '(1 2 3))
> (1 2 3)
> - [5]> (append '(inputTemp) input)
> (INPUTTEMP 1 2 3)
Others have provided good details so I thought I would provide a
"translation" of what you did into what you probably meant in idiomatic
lisp-speak:
CL-USER 14 > (defvar *input-temp*)
*INPUT-TEMP*
CL-USER 15 > (defvar *input*)
*INPUT*
CL-USER 16 > (setf *input-temp* 5)
5
CL-USER 17 > (setf *input* (list 1 2 3))
(1 2 3)
CL-USER 18 > (append (list *input-temp*) *input*)
(5 1 2 3)
CL-USER 19 > *input*
(1 2 3)
;; note this destructive version of the above append
CL-USER 20 > (push *input-temp* *input*)
(5 1 2 3)
CL-USER 21 > *input*
(5 1 2 3)
That said, I frequently just (setf foo <blah>) at top level to try something
out, without the proper defvar...but "don't try this at home!"
--
Coby Beck
(remove #\Space "coby 101 @ big pond . com")