newbie in deep over his head
Glenn Burnside
doing a lot of reading in Graham's two books and online. But with the
general mood here, I've approached the act of posting with no small amount
of trepidation. So, finally, here goes.
I was reading recently about read macros - another extensibility feature
I've never seen anywhere else. And I noticed that the CL standard reserves
special delimiters like #n() for things like vectors, etc. But I didn't see
anything for defining a lambda expression. I realize I'm probably treading
on holy ground, but I can't help feeling that something like
#[(x y z) (some-op-over x y z)]
or even
#l((x y z) (some-op-over x y z))
would be easier to deal with than
#'(lambda (x y z) (some-op-over x-y-z))
Is there already a read macro shortcut for lambda expressions that I'm not
aware of? Are there any common implementations that do that? Am I walking a
road that every CL newbie walks, only to get spanked by the gurus in the
end?
Any comments are greatly appreciated.
Glenn B.
Rolf Mach
Glenn Burnside wrote:
> But with the
> general mood here, I've approached the act of posting with no small amount
> of trepidation.
Glenn got my fullest sympathy on that and we all got to "thank" some of the
"big" bullys here for such an outstanding archivement to dominate this mood in
their particular way. ;-(
If they succeeded with one thing than it is to intimidate "ordinary" people who
have no interest in flames and personal ego wars.
If you don愒 think you can dare to post a question before working through Paul
Graham愀 books and still "tremble" to receive a beating there is something
seriously wrong here IMHO.
Cheers
Rolf
--
__________________________________________________________________________________________
XANALYS - www.xanalys.com
Data Analysis and Lisp Development Tools
Software zur Datenanalyse und Lisp Entwicklungsumgebungen
__________________________________________________________________________________________
Rolf Mach
Business Development & Sales Manager, Europe
An der Schaafhansenwiese 6
D-65428 Ruesselsheim, Germany
Phone ++49 +6142 938197
Fax ++49 +6142 938199
rm...@xanalys.com
__________________________________________________________________________________________
NEW: LispWorks 4.2 at LinuxWorld Expo, Frankfurt, 30-Oct/1-Nov 2001, Hall 6.0
Booth E24
__________________________________________________________________________________________
Watson - PowerCase - Quenza - LispWorks
Frode Vatvedt Fjeld
> #[(x y z) (some-op-over x y z)]
> or even
> #l((x y z) (some-op-over x y z))
slightly more readable than
(lambda (x y z) (some-op-over x y z)),
I don't think it can be reasonably argued that either reader macro
version is so valuable as to outveigh their costs, which are firstly
to take up one macro character, and secondly to be non-standard.
> be easier to deal with than
> #'(lambda (x y z) (some-op-over x-y-z))
The #' is usually superfluous. I don't see how the regular lambda
syntax is difficult to deal with, and I certainly don't see how a
character macro would make it easier. Which exact problems are you
trying to solve with your proposed syntax? Would you want a character
macro for defun as well? And let? And so on?
> [..] Am I walking a road that every CL newbie walks, only to get
> spanked by the gurus in the end?
>
> Any comments are greatly appreciated.
Are we to understand that you greatly appreciate a spanking once in a
while? :) Seriously, it's not my impression that newbies are treated
badly in this newsgroup.
--
Frode Vatvedt Fjeld
Erik Naggum
| I've been lurking on this newsgroup for like 6 months now, and I've been
| doing a lot of reading in Graham's two books and online. But with the
| general mood here, I've approached the act of posting with no small
| amount of trepidation. So, finally, here goes.
Boo!
| I was reading recently about read macros - another extensibility feature
| I've never seen anywhere else. And I noticed that the CL standard
| reserves special delimiters like #n() for things like vectors, etc. But
| I didn't see anything for defining a lambda expression.
The reason is that they are not sufficiently widely used. Even Scheme
has not done a lot of work to make writing lambda forms easier, even
though they are far more frequently used there.
| I realize I'm probably treading on holy ground, but I can't help feeling
| that something like
|
| #[(x y z) (some-op-over x y z)]
| or even
| #l((x y z) (some-op-over x y z))
| would be easier to deal with than
| #'(lambda (x y z) (some-op-over x-y-z))
The reason could simply be that people want to see the "lambda" because
it is so special.
| Is there already a read macro shortcut for lambda expressions that I'm
| not aware of?
No.
| Are there any common implementations that do that?
Not that I am aware of.
| Am I walking a road that every CL newbie walks, only to get spanked by
| the gurus in the end?
Gurus do not spank newbies. Gurus bank stupid newbies. Only a few
newbies are stupid. Those newbies are so stupid they do not even
understand why they get spanked, and they remain stupid newbies for very
long, some forever. Smart newbies transition out of newbiehood quickly.
| Any comments are greatly appreciated.
Would it make your life easier? If so, define one yourself. Do you
think the language would be different had it supported a reader macro for
lambda like it does for quote and function? Do you find it easier or
harder to use quote and function because they have reader support?
///
--
In a fight against something, the fight has value, victory has none.
In a fight for something, the fight is a loss, victory merely relief.
Erik Naggum
| Glenn got my fullest sympathy on that and we all got to "thank" some of
| the "big" bullys here for such an outstanding archivement to dominate
| this mood in their particular way. ;-(
You just made it worse and more important. Why?
| If they succeeded with one thing than it is to intimidate "ordinary"
| people who have no interest in flames and personal ego wars.
You just made it more "interesting" to everybody. Why?
| If you don愒 think you can dare to post a question before working through
| Paul Graham愀 books and still "tremble" to receive a beating there is
| something seriously wrong here IMHO.
Yes, people like you who cannot let things go and actually answer the
guy's _questions_, but get up on your high horse to denounce yourself and
your own actions, except that you do not understand this because there is
only ever somebody _else_ who do something wrong in your demented mind.
Understand your own role, apologize to the newsgroup for what you have
just done, and never, ever repeat such a foul stunt again, will you?
What _actually_ prompted you _not_ to answer his technical questions?
Xanalys just lost a potential customer. We are using CMUCL, instead.
Nils Goesche
> I've been lurking on this newsgroup for like 6 months now, and I've been
> doing a lot of reading in Graham's two books and online. But with the
> general mood here, I've approached the act of posting with no small amount
> of trepidation. So, finally, here goes.
One of the facts of life is that on Usenet you need a thick skin.
However, I don't think newbies are particularly badly treated here;
look how they are treated in comp.lang.c and cll will look like the
friendliest place in the world. Here, the gurus flame each other,
in comp.lang.c they flame the newbies :-)
And trolls don't count.
> I realize I'm probably treading on holy ground, but I can't help
> feeling that something like
>
> #[(x y z) (some-op-over x y z)]
> or even
> #l((x y z) (some-op-over x y z))
> would be easier to deal with than
> #'(lambda (x y z) (some-op-over x-y-z))
If you dislike lambda so much, you can replace it by a macro (note
that lambda is itself a macro):
(defmacro limbda (args &body body)
`(lambda ,args ,@body))
Or call it `l' if `limbda' is too long for you. But use it only
if you don't care that people who read your code will hate your
guts :-)
Regards,
--
Nils Goesche
"Don't ask for whom the <CTRL-G> tolls."
PGP key ID 0x42B32FC9
Dorai Sitaram
The #n() notation for vectors represents the full
information, to within structural equality, about the
object that it notates. Such a notation for
lambda-closures would be misleading because it suggests
that all the info relevant to the closure has been
represented, which isn't true unless the lambda-body
contains no free variables. Even for vectors, CL
requires you to use (vector a b ...) rather than #(a b
...) when a, b, ... are non-self-evaluating
expressions, possibly containing variables.
--d
JP Massar
<glenn.b...@ni.com> wrote:
>
>Is there already a read macro shortcut for lambda expressions that I'm not
>aware of?
No.
>Are there any common implementations that do that?
None that I know of.
>Am I walking a
>road that every CL newbie walks, only to get spanked by the gurus in the
>end?
>
>Any comments are greatly appreciated.
>
It's a fine idea. I wouldn't mind at all typing #l instead of
#'(lambda.
OTOH, one doesn't type #'(lambda that often that it would be a major
concern.
Arthur Lemmens
> on holy ground, but I can't help feeling that something like
>
> #[(x y z) (some-op-over x y z)]
> or even
> #l((x y z) (some-op-over x y z))
> would be easier to deal with than
> #'(lambda (x y z) (some-op-over x-y-z))
Normally, you can already leave out the #' if you want to.
So your hypothetical read macro would only allow you to write
#l(...) instead of (lambda ...). That doesn't look like a big
advantage to me. It only makes your code more cryptical to
people who're not used to your read macro.
But I once saw #L used as a read macro which did a bit more.
It allowed you to write
#L(foo !2 (bar !1) !3)
as shorthand for
(lambda (a b c) (foo b (bar a) c))
Something like that may be handy when you're heavy into a
functional programming style. I never felt the need for it.
Arthur Lemmens
Glenn Burnside
notation too early. Several folk now have mentioned that lambda doesn't
come up that often - that surprised the heck out of me. Given that I
(hourly) wish I had full-blown closures in my C++ work, the existence of
lambdas was one of the reasons I started dinking with Lisp to begin with.
If good Lisp code doesn't use lambda's that much, there's certainly no point
in trying to over-simplify their notation.
Incidently, someone pointed out that the #' in front of a lambda is
superfluous? My understanding was that it was necessary to refer to the
function of a symbol instead of its value? Under what circumstances can you
elide the #' in front of a lambda expression?
GB
"JP Massar" <mas...@alum.mit.edu> wrote in message
news:3c7e7bb7....@netnews.attbi.com...
Barry Margolin
Glenn Burnside <glenn.b...@ni.com> wrote:
>..and this is the problem with goofballs like me trying to optimize their
>notation too early. Several folk now have mentioned that lambda doesn't
>come up that often - that surprised the heck out of me. Given that I
>(hourly) wish I had full-blown closures in my C++ work, the existence of
>lambdas was one of the reasons I started dinking with Lisp to begin with.
>If good Lisp code doesn't use lambda's that much, there's certainly no point
>in trying to over-simplify their notation.
They're used occasionally, but not so much that we've felt the need to
abbreviate it.
>
>Incidently, someone pointed out that the #' in front of a lambda is
>superfluous? My understanding was that it was necessary to refer to the
>function of a symbol instead of its value? Under what circumstances can you
>elide the #' in front of a lambda expression?
If you're using a CL implementation that conforms to ANSI CL or CLTL2.
Between CLTL1 and CLTL2, LAMBDA was defined as a macro that expands into
#'(LAMBDA ...).
What you *can't* do is '(lambda ...). Use either #'(lambda ...) or (lambda
...).
--
Barry Margolin, bar...@genuity.net
Genuity, Woburn, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.
Thomas F. Burdick
"Glenn Burnside" <glenn.b...@ni.com> writes:
> I've been lurking on this newsgroup for like 6 months now, and I've been
> doing a lot of reading in Graham's two books and online. But with the
> general mood here, I've approached the act of posting with no small amount
> of trepidation. So, finally, here goes.
[ BTW, I could see how one who doesn't know CL could think this group
flames newbies -- however, once you know CL, it's easy to see that
the people being flamed aren't newbies, they're trolls. Newbies to
a language are generally trying to learn it; people who refuse to
learn, refuese to try, but insist on constantly expounding on What
Is To Be Done ... well, they're trolls. People who want to learn
are generally greeted with the most open arms I've ever seen on
Usenet.]
> I was reading recently about read macros - another extensibility feature
> I've never seen anywhere else.
They are cool. Of course, I don't actually use them much. The only
nonstandard reader macro I've been using recently is one to make it
easy to enter rationals:
* ą10.2
51/5
(Yes, I realize that's a stupid character to have the macro on, but I
was trying to think of a good one, that I wouldn't want to use for
other purposes, but was easy to type, and ą was one of them; plus I
enjoy the irony that 10.3 reads a float, but ą10.3 reads a rational)
> And I noticed that the CL standard reserves
> special delimiters like #n() for things like vectors, etc. But I didn't see
> anything for defining a lambda expression. I realize I'm probably treading
> on holy ground, but I can't help feeling that something like
>
> #[(x y z) (some-op-over x y z)]
> or even
> #l((x y z) (some-op-over x y z))
> would be easier to deal with than
> #'(lambda (x y z) (some-op-over x-y-z))
Sure, and I think there's a good reason that Smalltalk has the
[ var1 var2 var3 | body ... ]
syntax for blocks (anonymous functions, sometimes closures, depending
on the dialect). But in ST, you use them *everywhere*. In CL, we've
got macros, which means that, even when we use them, we don't see them
as often. In fact, the #' in #'(lambda ...) is optional. LAMBDA is a
macro that expands to (function (lambda ...)).
So, why on earth does everyone type #'(lambda ...)? Not because we
think it's fun to type more than is needed (at least, I don't -- I
make heavy use of completion, to the point that I don't think I could
code Lisp without it). Speaking for myself, I like the anonymous
functions to jump out at me. Having the big handle of #'(lambda ...)
to hang them on helps. If I used them more, I'd definately define a
syntax like ST's, but I don't use them enough to make it worth it.
> Is there already a read macro shortcut for lambda expressions that I'm not
> aware of? Are there any common implementations that do that? Am I walking a
> road that every CL newbie walks, only to get spanked by the gurus in the
> end?
>
> Any comments are greatly appreciated.
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
Thomas F. Burdick
> ..and this is the problem with goofballs like me trying to optimize their
> notation too early. Several folk now have mentioned that lambda doesn't
> come up that often - that surprised the heck out of me. Given that I
> (hourly) wish I had full-blown closures in my C++ work, the existence of
> lambdas was one of the reasons I started dinking with Lisp to begin with.
Well, in addition to closures, we also have macros. Some people's
style will involve more lambda forms than others. A lot of WITH-...,
DO-..., and DEF-... macros will expand into forms that create
closures. For example, I'll often write a function MAP-FOO to map a
function across some data structure foo, and an accompanying macro
DO-FOO.
(map-foo #'(lambda (x y z)
(format t "node (~S, ~S, ~S)~%" x y z))
some-foo)
;; notice that you can't see the closure being created, even though
;; it's there.
(do-foo ((x y z) some-foo)
(format t "node (~S, ~S, ~S)~%" x y z))
Even people who always use the functional style, though, don't use
closures as much as, say, Smalltalkers, who use them for conditionals :)
Drew McDermott
I was reading recently about read macros - another extensibility feature
I've never seen anywhere else. And I noticed that the CL standard reserves
special delimiters like #n() for things like vectors, etc. But I didn't see
anything for defining a lambda expression. I realize I'm probably treading
on holy ground, but I can't help feeling that something like#[(x y z) (some-op-over x y z)]
or even
#l((x y z) (some-op-over x y z))
would be easier to deal with than
#'(lambda (x y z) (some-op-over x-y-z))Is there already a read macro shortcut for lambda expressions that I'm not
aware of? Are there any common implementations that do that? Am I walking a
road that every CL newbie walks, only to get spanked by the gurus in the
end?
(defmacro \\ (args &body body) #'(lambda ,args ,@body))
No new readmacros required. (BTW, "\" is the character for lambda in Haskell. It is here, too, but you have to backslash it, which actually looks better to me.)
Now you can write (mapcar (\\ (x y z) ...) ...), for instance. One finds oneself using lambda more often when it's easier to type.
-- Drew McDermott
Glenn Burnside
-- Drew McDermott
Drew, this gets my vote - I had thought about doing something like this, using maybe fn, but then I got carried away with read macros and dreams of Smalltalk syntax. Your last sentence seems to echo something that Paul Graham said in his notes for Arc - something to the effect that if Church used the lambda symbol because it was a convenient symbol - he wouldn't have used "lambda" if he had to write it out each time.
Erann Gat
<glenn.b...@ni.com> wrote:
> I've been lurking on this newsgroup for like 6 months now, and I've been
> doing a lot of reading in Graham's two books and online. But with the
> general mood here, I've approached the act of posting with no small amount
> of trepidation. So, finally, here goes.
>
> I was reading recently about read macros - another extensibility feature
> I've never seen anywhere else. And I noticed that the CL standard reserves
> special delimiters like #n() for things like vectors, etc. But I didn't see
> anything for defining a lambda expression. I realize I'm probably treading
> on holy ground, but I can't help feeling that something like
>
> #[(x y z) (some-op-over x y z)]
> or even
> #l((x y z) (some-op-over x y z))
> would be easier to deal with than
> #'(lambda (x y z) (some-op-over x-y-z))
Personally, I like "fn" as a synonym for "lambda".
(defmacro fn (args &body body) `(lambda ,args ,@body))
It's short, and it's mnemonic (fn ~= function).
I remember reading somewhere that "Lambda" is actually a historical
accident caused by typographical constraints of printing presses available
at the time that Alonzo Church was writing his papers.
E.
Erik Naggum
| Incidently, someone pointed out that the #' in front of a lambda is
| superfluous? My understanding was that it was necessary to refer to the
| function of a symbol instead of its value? Under what circumstances can
| you elide the #' in front of a lambda expression?
(lambda ...) is a macro that expands to (function (lambda ...)).
#'(lambda ...) is a reader macro that returns (function (lambda ...)).
I think using #'(lambda ...) is a notational grossity.
Espen Vestre
> The reason is that they are not sufficiently widely used. Even Scheme
> has not done a lot of work to make writing lambda forms easier, even
> though they are far more frequently used there.
I think they are widely enough used - it *is* slightly irritating that
they use so much s-expression real estate. But every time I think about
it, I can't come up with an idea for a substitute that I really like
(the cutest thing would have been to use the lambda letter, of course,
where were all the lispers when 7-bit ascii was designed? ;-)).
--
(espen)
Espen Vestre
> Glenn got my fullest sympathy on that and we all got to "thank" some of the
> "big" bullys here for such an outstanding archivement to dominate this mood in
> their particular way. ;-(
I agree. The recent noise in this newsgroup must be evem more disgusting
to people who don't know the newsgroup than to those of us who've been
here for a while.
I'm probably wearing nostalgia glasses, but I remember this newsgroup as far
more friendly 10 years ago.
--
(espen)
David Golden
> (the cutest thing would have been to use the lambda letter, of course,
> where were all the lispers when 7-bit ascii was designed? ;-)).
Could use unicode these days... which common lisp implementations
are unicode-capable ?
Then you just need a few of those keyboards with little lcd screens
on every key so that you can find all the extra characters....
I know Perl now supports unicode identifiers (in an effort to allow for
even more unreadable programs), and Java sorta does (AFAIK you can run
utf8 source thru native2ascii which changes all unicode chars to \uxxxx
sequences before passing it to javac...which noone ever does...)
--
Don't eat yellow snow.
Tim Moore
would troll periodically and get roundly flamed for his efforts...
Tim
Kenny Tilton
Glenn Burnside wrote:
>
> Several folk now have mentioned that lambda doesn't
> come up that often - that surprised the heck out of me.
Me, too. The surprise, I mean. The string "lambda" occurs 700 times in
our source tree, and some of those would be in macros, so who knows? I
do know the SM? macro includes a lambda form and SM? occurs 1500 times
in our app.
But i am a devout metaprogrammer, maybe I do not count. Someone working
for me for a summer once said he could not believe how many lambdas I
used. Reminded me of the scene in Amadeus where the king said some
musical piece had too many notes.
> Given that I
> (hourly) wish I had full-blown closures in my C++ work, the existence of
> lambdas was one of the reasons I started dinking with Lisp to begin with.
Me, too. You did right. Ignore these guys. :)
> If good Lisp code doesn't use lambda's that much, there's certainly no point
> in trying to over-simplify their notation.
I am embarrassed to say how long it took me to discover the #' thingy
was unnecessary because there is a macro of the same name. but that sure
helps. otherwise, the big answer is:
uh, yeah, we do do a little extra typing with Lisp when banging out
fresh code.
but I spend most of my time cutting and pasting, so I don't mind. and
then the s-exp thing makes Lisp editing an utter joy compared to other
languages, so I am in pig heaven.
--
kenny tilton
clinisys, inc
---------------------------------------------------------------
"Be the ball...be the ball...you're not being the ball, Danny."
- Ty, Caddy Shack
Christopher C. Stacy
Espen> Erik Naggum <er...@naggum.net> writes:
>> The reason is that they are not sufficiently widely used. Even Scheme
>> has not done a lot of work to make writing lambda forms easier, even
>> though they are far more frequently used there.
Espen> I think they are widely enough used - it *is* slightly irritating that
Espen> they use so much s-expression real estate. But every time I think about
Espen> it, I can't come up with an idea for a substitute that I really like
Espen> (the cutest thing would have been to use the lambda letter, of course,
Espen> where were all the lispers when 7-bit ascii was designed? ;-)).
By the 1970s they had already moved on from ASCII to other extended
character sets. On PDP-10 timesharing (and later, Lisp Machines) at MIT,
the keyboards and operating systems supported character glyphs like Lambda.
The idea to support this in hardware and software was based on what
was available on Stanford's PDP-10 (eg. the "SAIL character set").
Some people wrote their Lisp code using the Lambda glyph instead of
spelling out LAMBDA, but this was not widely accepted in the lab.
I think the main reason most people like #'(LAMBDA..) is that it's an
obvious visual marker that takes about as much space as a DEFUN would.
That's why they don't want to make it smaller. (To the extent that
they think about it at all -- is this really a problem, anyway?!?)
One reason for not defining a new syntax, such as "\\" for LAMBDA,
today, is that it would not be Common Lisp. Anytime you introduce
new reader macros or your own (arguably redundant) control constructs
into your code, you are making it harder for someone else to read.
This is so important that you should only do it iff after thorough
consideration it really is justified by necessity. Your personal
taste and idiosynchrocy are not good reasons to change around the
language, and most people who have been programming in Lisp for
decades choose to hardly ever do that.
Macros, especially reader macros, are like when desktop publishing
with fonts was first invented. It was something new and powerful
and exciting and everyone wanted to _UsE THeM!!_. It takes a
fair amount of self-control and experience to use them reasonably.
Nowadays, I suppose you could program EMACS to display the LAMBDA as a
special character. You're going to have to worry about how it looks
in all the different character sets that you might choose to display
your code in. Past that technical issue, what happens when you hand
the program to someone who does not have that display hack? Your code
might look awful on their screen. This is similar to the existing
formatting issue of how wide you should assume someone's screen is
when writing the code (without any display magic).
Before I learned Lisp, APL was my favorite language, so I'm not
personally adverse to using funny characters for programming.
But I can assure you that it is not a big selling point when trying
to get mainstream programmers to take a look at your language.
People already complain about parenthesis because it makes things look
different from most programming languages. Now you're going to tell
them (or let them mistakenly assume) that they need special characters
in order to use Lisp?
Thomas F. Burdick
to make a ST-like syntax for closures. Except that so as not to wreak
havoc with ILISP, and to allow arbitrary symbol names as usual, it
uses ! instead of |.
(defun pseudo-smalltalk-block-reader (stream char)
(declare (ignore char))
(let ((vars (read-from-string
(with-output-to-string (s)
(princ #\( s)
(loop for char = (read-char stream nil stream t)
until (or (eql char stream) (eql char #\!))
do (princ char s))
(princ #\) s))))
(body (read-from-string
(with-output-to-string (s)
(princ #\( s)
(loop for char = (read-char stream nil stream t)
until (or (eql char stream) (eql char #\]))
do (princ char s))
(princ #\) s)))))
`(lambda ,vars ,@body)))
(set-macro-character #\[ #'pseudo-smalltalk-block-reader t)
Thomas A. Russ
Espen Vestre <espen@*do-not-spam-me*.vestre.net> writes:
> (the cutest thing would have been to use the lambda letter, of course,
Couldn't the lambda letter be used on the Lisp Machine?
--
Thomas A. Russ, USC/Information Sciences Institute t...@isi.edu
Alain Picard
> I think using #'(lambda ...) is a notational grossity.
Why do you say that? Is that because you think (function (lambda ..))
looks worse, or because that's what the (lambda ..) macro is there for?
I'm curious, because I never thought of #'(lambda ..) as ugly. I just
get used to seeing that #' everywhere I expect a function argument.
--
It would be difficult to construe Larry Wall, in article
this as a feature. <1995May29....@netlabs.com>
Nils Goesche
> Erik Naggum <er...@naggum.net> writes:
>
>> I think using #'(lambda ...) is a notational grossity.
>
> Why do you say that? Is that because you think (function (lambda ..))
> looks worse, or because that's what the (lambda ..) macro is there for?
>
> I'm curious, because I never thought of #'(lambda ..) as ugly. I just
> get used to seeing that #' everywhere I expect a function argument.
I remember that I disliked #'(lambda ...) from the very first time I
saw it. To me, (lambda ...) looks like something that evaluates
to a /function/, not to a symbol whose value slot would be taken
if I left out the #'. I took me a long time, too, to find out that
it can actually be omitted (I think it was Erik who told me) because
lambda is also a macro. I was very happy about that. I had written
a curry macro, and didn't understand why #'(curry ...) wouldn't work
but (curry ...) would :-)
Erik Naggum
> I think using #'(lambda ...) is a notational grossity.
* Alain Picard
| Why do you say that? Is that because you think (function (lambda ..))
| looks worse, or because that's what the (lambda ..) macro is there for?
It is because I consider #' a notational grossity in general, but it is a
_functional_ notational grossity. (Is "grossity" even a word? Hm, no,
but it should have been, because of "curiosity".) (Also pardon the pun.)
I think (function car) is notationally better than #'car, but I think
'car is notationally better than (quote car). Why? I have no idea.
Some twisted sense of aesthetics or something, I guess, or maybe I am
just used to ', maybe it is so small it is innocuous, whereas #' looks
like Laurel and Hardy or something. Therefore, (function (lambda ...))
is better than #'(lambda ...), but since that is such a redundancy, I
much prefer (lambda ...) by itself.
| I'm curious, because I never thought of #'(lambda ..) as ugly. I just
| get used to seeing that #' everywhere I expect a function argument.
But that would obviously make it problematic to use a function that
returns a function. I think of lambda as a function-constructor, whereas
function is a function-getter. (function (lambda ...)) would therefore
get at the function that lambda constructs. (Yes, I do know that it is
function that makes the lambda form into a function.) Another function
or look-alike that returns a function would be similarly unquoted.
Kent M Pitman
> In article <868z9c5...@gondolin.local.net>, Alain Picard wrote:
> > Erik Naggum <er...@naggum.net> writes:
> >
> >> I think using #'(lambda ...) is a notational grossity.
> >
> > Why do you say that? Is that because you think (function (lambda ..))
> > looks worse, or because that's what the (lambda ..) macro is there for?
> >
> > I'm curious, because I never thought of #'(lambda ..) as ugly. I just
> > get used to seeing that #' everywhere I expect a function argument.
>
> I remember that I disliked #'(lambda ...) from the very first time I
> saw it. To me, (lambda ...) looks like something that evaluates
> to a /function/, not to a symbol whose value slot would be taken
> if I left out the #'.
It's probably a matter of historical effect, but I find #'foo and
#'(lambda ...) to be more aesthetic, not less.
First, it makes it easier to find the head of the function.
Second, it is more consistent to me because it means functions as data
are all case-marked by #'. I was taught that #' was followed by a function
name, and that (lambda ...) was the name of a function.
Third, I was raised to not think of LAMBDA as a primitive special form,
so I look at LAMBDA as something that will not evaluate at all, and #'
as something that rescues it. ;) It used to be that you could use either
(quote (lambda ...)) or (function (lambda ...)), with the main difference
being that the former didn't get the lexical environment (but then, mostly
we had only specials back then, so that wasn't very different). #' was
a modified form of quote in its early casting, and # was like a modifier on
quote that said "functionally quote" rather than "evaluationally quote",
if you like.
[Then again, when I first tried to standardize the term "special form"
(I'm doubt I invented it, but I think I first published about it), it
meant what we now mean by "special form or macro" (that is, anything
that wasn't a normal functional form). Under that old terminology,
you could say that LAMBDA now _is_ a special form; but under the
modern terminology, not by my choice, there is no abstract term for
that union set, and consequently you have to identify LAMBDA as a
macro, not a special form, and thus still neither really "primitive"
nor even ambiguously "maybe primitive maybe not". Pity. The community
might wish to employ such ambiguity now in order to transition LAMBDA to
a higher status, but there's really no good lingo for doing that.
Maybe that's my fault for not adding yet another glossary word for people
to cling to, though, while I had the chance.]
And, fourth, my preference for #' is partly due to the fact that while I do
quite a lot of #'(lambda...), I still don't think of myself as doing
functional programming. I consider the use of functions as data an
unusual enough event that I don't mind case-marking it.
I don't really mind the modern day (LAMBDA...) and I understand why people
want it, but I think it primarily a "comfort" matter for people who come
from a different culture. I don't think it's a cut and dried matter for
which a coherent objective case can be made, even though I often observe
people trying.
What I find funny in all of this is that this is all about "highlighting"
and one of the problems I have with highlighting is that it does not vary
during the editing process. That is, one puts #'(lambda...) and it is
highlit there WHETHER OR NOT the function it is highlighting is in my
"activity focus". In a sense, it's always blinking in my peripheral
vision. "Right!" I can hear you haters of "#'" saying, "that's why I
don't like it." But those very same people will tell me they love
syntax highlighting. I find it quite a lot more offensive to see every
keyword in purple (or whatever) and every string in brown and so on just
because I may not be caring about comments or keywords. I definitely am
annoyed to see editors highlight the definition name in a function even
when I'm not debugging anything that requires use of the name.
I don't know a good solution to this, and maybe I'm not explaining it
well, but imagine an interface where both my eye and perhaps even my
train of thought was tracked. So that when I was debugging args to
OPEN, suddenly the keyword args to _that_ function (and only that
function) would turn purple. In such a situation, then I wouldn't
have peripheral vision effects, and I'd like coloring better.
I have grudgingly tried to train myself to live with colors because I think
most people like them, and because there are occasionally times that the
color tells me something important. But I almost wish I could have an editor
that hid color and that had a command that would instantaneously enable
color when I was searching for something in particular...
(I have similar problems with Unix ANSI-colored directory list, which
is always highlighting too many things, making it hard to find the one
kind of thing I want highlit.)
Anyway, the reason I mentioned all of this is that I find #'(lambda
...) to be about an order of magnitude, maybe two, less obtrusive
than colorizing my entire screen, and yet people who are hugely
offended by the "#'" notation (to call attention to the promotion of a
"function name" from the function namespace to the variable namespace)
are usually quite happy and unoffended at the use of color to
simultaneously call attention to everything on the screen. And my
real point is that I honestly believe this matter to be considerably
more subjective than people are acknowledging.
Incidentally, I can't entirely clear my buffer on this topic without also
mentioning the bug in Dylan that was replicated from Common Lisp design over
my objections. (Pretty much none of my suggestions were taken in Dylan,
so that's not big surprise.) In particular, Common Lisp should have used
:optional, :rest, :key, etc. and _not_ &optional, &rest, &key, etc. The
fact that & was chosen is unfortunate for a variety of reasons, not the
least of which is that these symbols have to be individually exported, plus
it makes the use of & in other contexts questionable. A number of times,
good suggestions were made to extend Common Lisp that were rejected because
of the need to add "yet another &xxx keyword" but that I'm confident
would have been accepted trivially if it had been "adding yet another :xxx
keyword" because we're already used to having myriad :keywords. Dylan
made #keywords to mirror CL's :keywords, but there was really no syntactic
need. The argument was that people need to have their eye drawn to these
things. My argument, by contrast is, "they need to find it when they need
to find it and not otherwise". The issue of drawing one's eye could have
been handled in color if that really mattered, IMO, but I'd rather have
seen (... foo :optional (x 4) (y 7) :key ((:ex x) 3) ...)in CL or
... foo opt: x=4, y=7, key: ex:x=3 ... in Dylan. We _did_ "fix" this in
ISLISP, where either &optional (as a transitional/compatibility notation)
or :optional can be used, etc.
Bottom line? Programming language notations are statically required all
the time. Focus issues are dynamically needed or not needed, so are not
always well addressed by static notation. It's often a judgment call what
to emphasize and what not to in the static notation, and people often think
they're being a lot more principled than they are. Mostly I don't see a lot
of science applied here at all.
Daniel Barlow
> Could use unicode these days... which common lisp implementations
> are unicode-capable ?
There is a page on CLiki based on a post here by Bruno Haible, which
summarises Unicode support in clisp, eclipse, acl and lispworks.
It's out of date (of course) but it might give you a place to start
http://ww.telent.net/cliki/Unicode%20Support
> I know Perl now supports unicode identifiers
Ran out of single characters for variable names, did they?
-dan
--
http://ww.telent.net/cliki/ - Link farm for free CL-on-Unix resources
Erik Naggum
| People already complain about parenthesis because it makes things look
| different from most programming languages. Now you're going to tell them
| (or let them mistakenly assume) that they need special characters in
| order to use Lisp?
Well, it might get their attention off the parentheses. :)
Besides, one of the perceived problems with the parentheses, is that they
are basically the only syntax you have, and some people seem to get lost
in the homogeneous syntax. So it _might_ actually help...
Nils Goesche
> Nils Goesche <car...@cartan.de> writes:
>
>> I remember that I disliked #'(lambda ...) from the very first time I
>> saw it. To me, (lambda ...) looks like something that evaluates
>> to a /function/, not to a symbol whose value slot would be taken
>> if I left out the #'.
>
> It's probably a matter of historical effect, but I find #'foo and
> #'(lambda ...) to be more aesthetic, not less.
>
> First, it makes it easier to find the head of the function.
>
> Second, it is more consistent to me because it means functions as data
> are all case-marked by #'. I was taught that #' was followed by a function
> name, and that (lambda ...) was the name of a function.
I am not sure if that was clear: I have nothing against #'car,
only against #'(lambda ...), because if #'blark is a function
that returns another function I do (funcall (blark ...) ...); then,
(funcall (lambda ...) ...) looks more visually consistent, doesn't it?
It doesn't, of course, if you think of (lambda ...) as the ``name''
of a function, as you say, but that sounds really foreign to me :-)
Indeed a cultural matter, it seems.
> I find it quite a lot more offensive to see every keyword in purple
> (or whatever) and every string in brown and so on just because I may
> not be caring about comments or keywords. I definitely am annoyed
> to see editors highlight the definition name in a function even when
> I'm not debugging anything that requires use of the name.
>
> I have grudgingly tried to train myself to live with colors because
> I think most people like them, and because there are occasionally
> times that the color tells me something important. But I almost
> wish I could have an editor that hid color and that had a command
> that would instantaneously enable color when I was searching for
> something in particular...
>
> (I have similar problems with Unix ANSI-colored directory list,
> which is always highlighting too many things, making it hard to find
> the one kind of thing I want highlit.)
Interesting. I love syntax coloring just as much as I violently
hate ``ls --color''...
How about ``ls -F''? Does that look fine to you?
> Bottom line? Programming language notations are statically required
> all the time. Focus issues are dynamically needed or not needed,
> so are not always well addressed by static notation. It's often
> a judgment call what to emphasize and what not to in the static
> notation, and people often think they're being a lot more principled
> than they are. Mostly I don't see a lot of science applied here
> at all.
Sure, it is pretty clear that this is all about aesthetics. Trying
to have a rigorous discussion about this seems as futile to me as,
say, wondering about what kind of being the ``it'' in ``it is
rainy'' is :-)
Kent M Pitman
> * Christopher C. Stacy
> | People already complain about parenthesis because it makes things look
> | different from most programming languages. Now you're going to tell them
> | (or let them mistakenly assume) that they need special characters in
> | order to use Lisp?
>
> Well, it might get their attention off the parentheses. :)
>
> Besides, one of the perceived problems with the parentheses, is that they
> are basically the only syntax you have, and some people seem to get lost
> in the homogeneous syntax. So it _might_ actually help...
Allowing people to use {}'s and []'s interchangeably with ()'s might help more.
Or allowing {...} to mean (PROGN ...) so that you had
(if x
{ (print x) (print y) }
{ (print z) })
But then, people can already do this so trivially, and it's so controversial
to do it globally (meaning, for all people), that it will never be adopted
as a standard. But I don't know why people can't just insert the two
lines of code it takes to reorganize the lisp reader this way.
With a couple more lines of work, the pretty printer can be made to display
things back this way, too.
Would that other languages had such flexible syntax redefinition...
But then, the real problem with using notations like this is that they
are opaque as to structure. It's not that you can't write a macro
that destructures a PROGN, but if it looks like {...}, you might not
realize it's a PROGN, and that becomes a barrier to your writing
macros. Lisp, by constantly exposing you to the parsed notation,
prepares you to write macros because the stuff of macro arguments is
so easily predictable from having seen it everywhere right in front of
you forever.
Tim Bradshaw
> Ran out of single characters for variable names, did they?
That can't be it. The Perl Way would be to have only a small finite
number of identifiers but to have an elaborate, ill-explained and
buggy notion of `context' which causes them to mean subtly, or
occasionally completely, different things. A large space of
single-character identifiers would be seen as a positive disadvantage.
Now the MS C++ people are going to love unicode variable names,
because they will be able to pack the whole naming convention
(hungarian naming?) into *single characters*. Studies have shown[1]
that there is no significant loss of readability with this technique.
--tim
Footnotes:
[1] I asked my cat