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
Kenny Tilton
latter leaves the #' behind.
Erik Winkels
> 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.
Isn't that mostly because they are newbies and are not aware of it
being possible? (For which I'm glad.)
Most other people stop worrying about importing the syntactic sugar
from their previous, and more familiar, languages once they are used
to Lisp.
Lieven Marchand
> 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.
Actually, I find that these two arguments apply so often, that I've
never felt a shortage of available macro characters. About the only
one I use regularly is, in code that does a lot of lexer like actions,
a #L"string" that expands to (#\s #\t #\r #\i #\n #\g) for use in
calls to member, as character-bag etc. But then to use it in case
constructs, I need to write #.#L"foo" which I find is a bit too
obscure.
So, what are people using reader macro's for?
--
Lieven Marchand <m...@wyrd.be>
She says, "Honey, you're a Bastard of great proportion."
He says, "Darling, I plead guilty to that sin."
Cowboy Junkies -- A few simple words
Glenn Burnside
just looking for some sugar. But obviously a little sugar is good - else
why '#... for function, or ' for list? Do you tink you could get by without
that? I don't think the motivation here is to import syntax from another
language, just to find some simpler ways of expressing things. If I wrote a
lot of progn's, {} might be a nice, simple alternative for me. But I
wouldn't want other people viewing my code to see that - I'd want them to
see the progn. Likewise for my suggested lambda hack. This is going into
stream of consciousness mode, so bear with me. What if you had a Lisp
environment that let you elevate the read macro kind of thing into the
editor - where the editor let you specify how you want to view and type
certain things, but the source file stored the actual forms? Would that be
worth anything?
GB
"Erik Winkels" <aer...@xs4all.nl> wrote in message
news:87zo1s1...@xs4all.nl...
Dorai Sitaram
Kent M Pitman <pit...@world.std.com> wrote:
>
>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.
Syntax-highlighting is always optional. #' is forever.
--d
Coby Beck
"Glenn Burnside" <glenn.b...@ni.com> wrote in message
news:u7vf5tp...@corp.supernews.com...
> For the immediate case at hand (lambda seems bulky), you're right - I am
> just looking for some sugar. But obviously a little sugar is good - else
> why '#... for function, or ' for list?
this may have just been a mental typo, but <'> is <QUOTE>, not <LIST> - very
different.
--
Coby Beck
(remove #\Space "coby 101 @ bigpond . com")
Rahul Jain
> What if you had a Lisp environment that let you elevate the read
> macro kind of thing into the editor - where the editor let you
> specify how you want to view and type certain things, but the source
> file stored the actual forms? Would that be worth anything?
This is a long-term goal of my DefDoc (f.k.a. LambdaTeX) project. A
structured source editor that would automagically reindent all code to
your constraints about line-breaking, line-size, visual markup,
etc. The reason I think it's a good sub-project of a document layout
application is that the layout of the code is similar to layout of
text on paper, just with different ideas of what can be changed to
satisfy the layout constraints.
--
-> -/- - Rahul Jain - -\- <-
-> -\- http://linux.rice.edu/~rahul -=- mailto:rj...@techie.com -/- <-
-> -/- "I never could get the hang of Thursdays." - HHGTTG by DNA -\- <-
|--|--------|--------------|----|-------------|------|---------|-----|-|
Version 11.423.999.221020101.23.50110101.042
(c)1996-2002, All rights reserved. Disclaimer available upon request.
Erik Naggum
| But obviously a little sugar is good - else why '#... for function, or '
| for list?
One of the things I hope you will appreciate here is that people take
some pains to be as precise as they can when they post, and that means
that '# instead of #' is an annoyance. ' does not mean list, it means
quote. 'x does _not_ do the same as (list x), but (quote x).
| Do you think you could get by without that?
You mean would I abstain from defining them if I wanted them? No. :)
| What if you had a Lisp environment that let you elevate the read macro
| kind of thing into the editor - where the editor let you specify how you
| want to view and type certain things, but the source file stored the
| actual forms? Would that be worth anything?
If you are not familiar with Emacs, yet, now is a good time to start.
Martin Simmons
> 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.
Slightly OT, but I sometimes prefer to use FLET instead of LAMBDA, because it
can help make the code self-documenting by giving the function a sensible name.
--
Martin Simmons, Xanalys Software Tools
zne...@xanalys.com
rot13 to reply
Martin Simmons
> For the immediate case at hand (lambda seems bulky), you're right - I am
> just looking for some sugar. But obviously a little sugar is good - else
> why '#... for function, or ' for list? Do you tink you could get by without
> that? I don't think the motivation here is to import syntax from another
> language, just to find some simpler ways of expressing things. If I wrote a
> lot of progn's, {} might be a nice, simple alternative for me. But I
> wouldn't want other people viewing my code to see that - I'd want them to
> see the progn. Likewise for my suggested lambda hack. This is going into
> stream of consciousness mode, so bear with me. What if you had a Lisp
> environment that let you elevate the read macro kind of thing into the
> editor - where the editor let you specify how you want to view and type
> certain things, but the source file stored the actual forms? Would that be
> worth anything?
For some reason, this reminded me of the first Lisp I ever played with, where
the editor was a function that required you to walk over the conses in your
function definition using operations that were thin layers over CAR and
RPLACA...
Brian P Templeton
Heh. Someone just asked how to display LAMBDA as λ (the lambda
character) on comp.emacs, and I posted a short hack to do this. It
doesn't work particularly well, but it would be easy to extend to work
normally.
> 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?
Regards,
--
BPT <b...@tunes.org> /"\ ASCII Ribbon Campaign
backronym for Linux: \ / No HTML or RTF in mail
Linux Is Not Unix X No MS-Word in mail
Meme plague ;) ---------> / \ Respect Open Standards
Brian P Templeton
> Espen Vestre wrote:
>
>> (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 ?
>
SBCL has Unicode support, I think, but not in the latest released
version.
> 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.
Alain Picard
>
> I think of lambda as a function-constructor, whereas
> function is a function-getter.
I think that's probably the crux. One of the lisp books (Winston?)
says lambda, in modern lisp, really should have been renamed
to MAKE-FUNCTION (or some such).
Then your point would be well taken:
renaming lambda to make-function, and the current function
to function-slot, we'd get:
(defun make-adder (n)
(make-function (x)
(+ x n)))
(mapcar (make-adder 3) my-list)
(mapcar (function-slot some-symbol) my-list)
(mapcar (make-function (x) (+ 3 x)) my-list)
...
all of which looks fairly clean and symmetric. Thanks.
Kent M Pitman
> Erik Naggum <er...@naggum.net> writes:
>
> >
> > I think of lambda as a function-constructor, whereas
> > function is a function-getter.
>
> I think that's probably the crux. One of the lisp books (Winston?)
> says lambda, in modern lisp, really should have been renamed
> to MAKE-FUNCTION (or some such).
>
> Then your point would be well taken:
> renaming lambda to make-function, and the current function
> to function-slot, we'd get:
>
> (defun make-adder (n)
> (make-function (x)
> (+ x n)))
>
> (mapcar (make-adder 3) my-list)
> (mapcar (function-slot some-symbol) my-list)
> (mapcar (make-function (x) (+ 3 x)) my-list)
>
> ...
>
> all of which looks fairly clean and symmetric. Thanks.
One of the reasons it's not done this way is that often functions don't have
to cons. In this sense, they are a little like symbols. You name them and
you mean "map the function that adds 3 to its arg over my-list" not
"make a function that adds 3 to its arg and then map it over my-list", just
as when you do (list 'a 3) you do not mean "make a symbol A and then make
a list containing that symbol and 3".
A very astute observation by Paul Robertson (who authored Robertson
Common Lisp, a CLTL that Symbolics licensed and adapted to become the
lesser-known Symbolics CLOE 386-based native Lisp product) made
privately to me one day in the hall, but something I periodically
repeat to this day because it struck me as so obvious and important
that he should have written it down, was that it was a shame, probably
in general but particularly for those with C mindset who obsess about
consing, that LAMBDA blurred two very different operations:
(lambda (x) (+ x 3)) refers to a function that can be statically
compiled and has no overhead to execute beyond that of a literal.
That is, given (defun f () (lambda (x) (+ x 3))), you'll note that (f)
is a non-consing function.
(lambda (x) (+ x y)) refers to a closure that has a more complex operation,
more like LIST. When you do
(defun f (y) (lambda (x) (+ x y)))
you're doing something more like
(defun f-helper (closure-storage x) (+ x (storage-ref closure-storage 0)))
which can be statically compiled and then
(defun f (y)
(let ((storage (make-storage 1)))
(setf (storage-ref storage 0) y)
(make-closure #'f-helper storage)))
Paul suggested that if these two operations were different, such that
[I don't remember the names he used, if any, so I'll make some up]
(PROCEDURE (X) (+ X 3)) meant the first kind [non-consing] and
(CLOSURE (X) (+ X 3)) meant hte second kind [closing/consing], then compilers
could be an error rather than do unwanted capture; that is, it's easy to
write (LAMBDA (X) (+ X Y)) not realizing you're doing capture, but if you
did (PROCEDURE (X) (+ X Y)) the compiler could stop you dead in your tracks,
while if you did (CLOSURE (X) (+ X Y)) the compiler would assume you knew
what you were up to.
Note there's still some opportunity to lose a little in
(CLOSURE (X) (+ X Y Z))
because in hairy code, you might have thought Z wasn't a
capture even though you expected Y to be, and maybe
(CLOSURE-OVER (Y) (X) (+ X Y Z))
would catch that. But that's a detail, by comparison.
It is an issue of the difference between Common Lisp and C that what
we say is "this is what I want" not "this is how to implement what I
want", but Paul's formulation was nice because one could just always
use CLOSURE and sometimes be pleasantly surprised that it didn't cons.
(Maybe one could make it "complain" if nothing got captured, but
probably that would turn out to be annoying in the case of degenerate
macros.) So there's some question as to whether it's dictating
implementation or just saying "this establishes a conceptual space".
The functional programming community, in general, prefers to blur these two
notations because both describe functions. But compiler writers are VERY
familiar with the difference, and no one who becomes a writer of good code
in CL fails to understand the distinction between these two things. So it's
quite bizarre, in a way, that we map them to one function.
It reminds me a little of the absolute nightmare I had when translating
Symbolics Macsyma from MACLISP to Common Lisp back in 1986 and trying to
accomodate QUOTIENT. MACLISP's QUOTIENT had the awful property that if you
gave it only integers, it did truncating divide. But if you gave it any
arg that was a flonum (the MACLISP name for float), it did floating point
division instead. So (QUOTIENT 3 2) => 1, but (QUOTIENT 3.0 2) => 1.5.
Obviously, some of these had to be translated to / in CL and others to
TRUNCATE. Figuring which was which, since they were all called QUOTIENT.
If you step back from Lisp, and functional languages in general, you can see
how LAMBDA would have this same kind of nightmarish ambiguity to some who
really cared about what it was "doing" ...
Timothy M. Schaeffer
> 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?
>
The following is extracted from the iterate package. It creates a #L syntax
for creating functions, and automatically creates variables !1 !2 by finding
them in the definition and creating the lambda list automatically e.g.
(defun create-let (&rest vals)
`(let ,(mapcar #L(list !1 !2)
(make-gensym-list (length vals)) vals)))
The function created by #L automatically takes two arguments which replace
!1 and !2. A numeric argument indicates exactly how many arguments there
should be, in case it is different from that indicated by the 'bang'
variables.
I thought it was kinda neat.
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;;;
;;; SharpL.
(eval-when (compile load eval)
(defvar *old-sharpL-func* (get-dispatch-macro-character #\# #\L))
(set-dispatch-macro-character #\# #\L 'sharpL-reader)
(defun sharpL-reader (stream subchar n-args)
(declare (ignore subchar))
(let* ((form (read stream t nil t))
(bang-vars (sort (bang-vars form) #'< :key #'bang-var-num))
(bang-var-nums (mapcar #'bang-var-num bang-vars))
(max-bv-num (if bang-vars
(reduce #'max bang-var-nums :initial-value 0)
0)))
(cond
((null n-args)
(setq n-args max-bv-num))
((< n-args max-bv-num)
(error "#L: digit-string ~d specifies too few arguments" n-args)))
(let* ((bvars (let ((temp nil))
(dotimes (i n-args (nreverse temp))
(push (make-bang-var (1+ i)) temp))))
(args (mapcar #'(lambda (x) (declare (ignore x)) (gensym))
bvars))
(ignores (set-difference bvars bang-vars))
(decl (if ignores `(declare (ignore ,.ignores)) nil))
(body (if (list-of-forms? form)
(if decl (cons decl form) form)
(if decl (list decl form) (list form))))
(subbed-body (sublis (pairlis bvars args) body)))
`#'(lambda ,args ,.subbed-body))))
(defun make-bang-var (n)
(intern (format nil "!~d" n)))
(defun list-of-forms? (x)
(and (listp x) (listp (car x))
(not (eq (caar x) 'lambda))))
(defun bang-vars (form)
(delete-duplicates (bang-vars-1 form) :test #'eq))
(defun bang-vars-1 (form)
(cond
((symbolp form)
(if (bang-var? form)
(list form)
nil))
((atom form)
nil)
(t
(nconc (bang-vars-1 (car form)) (bang-vars-1 (cdr form))))))
(defun bang-var? (sym)
(char= (char (symbol-name sym) 0) #\!))
(defun bang-var-num (sym)
(let ((num (read-from-string (subseq (symbol-name sym) 1))))
(if (not (and (integerp num) (> num 0)))
(error "#L: ~a is not a valid variable specifier" sym)
num)))
) ;end eval-when
Paolo Amoroso
> (hungarian naming?) into *single characters*. Studies have shown[1]
> that there is no significant loss of readability with this technique.
[...]
> [1] I asked my cat
That's unfair: cats see in the dark much better than humans.
Paolo
--
EncyCMUCLopedia * Extensive collection of CMU Common Lisp documentation
http://www.paoloamoroso.it/ency/README
[http://cvs2.cons.org:8000/cmucl/doc/EncyCMUCLopedia/]
mda...@andrew.cmu.edu
[ interesting discussion omitted ]
> It reminds me a little of the absolute nightmare I had when translating
> Symbolics Macsyma from MACLISP to Common Lisp back in 1986 and trying to
> accomodate QUOTIENT. MACLISP's QUOTIENT had the awful property that if you
> gave it only integers, it did truncating divide. But if you gave it any
> arg that was a flonum (the MACLISP name for float), it did floating point
> division instead. So (QUOTIENT 3 2) => 1, but (QUOTIENT 3.0 2) => 1.5.
> Obviously, some of these had to be translated to / in CL and others to
> TRUNCATE. Figuring which was which, since they were all called QUOTIENT.
> If you step back from Lisp, and functional languages in general, you can see
> how LAMBDA would have this same kind of nightmarish ambiguity to some who
> really cared about what it was "doing" ...
I don't know what the situation was like back in 1986, but today couldn't
something like this be done?:
(defun quotient (a b)
(if (and (typep a 'integer)
(typep b 'integer))
(truncate a b)
(/ a b)))
With an inline declaration and a good compiler even the function-call to
quotient could be elided, I would think. This doesn't help when someone
is reading through the code, though, if that was your main point.
I do understand your point about LAMBDA however, though I imagine that
there is some way of distinguishing between the two usages; compilers
(at least efficient ones) need to do so. Not that I am any expert on
compiler-writing.
--
; Matthew Danish <mda...@andrew.cmu.edu>
; OpenPGP public key: C24B6010 on keyring.debian.org
; Signed or encrypted mail welcome.
; "There is no dark side of the moon really; matter of fact, it's all dark."
Thomas F. Burdick
> The functional programming community, in general, prefers to blur these two
> notations because both describe functions. But compiler writers are VERY
> familiar with the difference, and no one who becomes a writer of good code
> in CL fails to understand the distinction between these two things. So it's
> quite bizarre, in a way, that we map them to one function.
Huh. In the Ciel-80 compiler, everything's a closure. Something like
(lambda (x) (+ x 3)) closes over nothing, but
(defun f () (lambda (x) (+ x 3))) will always cons. I know that I
could special-case things like this, when the compiler, having gone
over the body of the lambda discovers that it doesn't close over
anything, but that seems more like an optimization than any kind of
real difference, to me. You could define a language with both
closures and non-closing procedures, but if you have closures, you
have non-closing procedures too for free; consing is an optimization
problem. I could add the ability to make F non-consing (and will, if
anyone complains and actually needs it), but a closure object in the
Ciel-80 system is exactly the same size as a cons cell. There's about
100 million little optimizations I could do all over the place, so I
just ignore them unless I have a reason to think they're worth it.
[ Related to your comment about (eq #'foo #'foo) from yesterday, I'm
wondering if I shouldn't change how this works. Currently, calling
FUNCTION on a name can cons, too. Eg:
(defun make-f ()
(let ((x 3))
(flet ((f () x))
(function f))))
(eq (make-f) (make-f)) => NIL
It didn't occur to me that someone would *do* this. I'm confident
that the spec backs me up on this one, but users might not be too
happy anyhow. As for implementing MAKE-HASH-TABLE, that's a problem
for implementors, not users. And, as a matter of fact, I don't see
anything in the spec that would allow you as a user to implement a
function with a weird interface like MAKE-HASH-TABLE.
> It reminds me a little of the absolute nightmare I had when translating
> Symbolics Macsyma from MACLISP to Common Lisp back in 1986 and trying to
> accomodate QUOTIENT. MACLISP's QUOTIENT had the awful property that if you
> gave it only integers, it did truncating divide. But if you gave it any
> arg that was a flonum (the MACLISP name for float), it did floating point
> division instead. So (QUOTIENT 3 2) => 1, but (QUOTIENT 3.0 2) => 1.5.
> Obviously, some of these had to be translated to / in CL and others to
> TRUNCATE. Figuring which was which, since they were all called QUOTIENT.
> If you step back from Lisp, and functional languages in general, you can see
> how LAMBDA would have this same kind of nightmarish ambiguity to some who
> really cared about what it was "doing" ...
It seems a bit streached, because you can always see what LAMBDA will
do by looking at its body, whereas QUOTIENT depended on runtime
values, but I can see your point. And it also makes me happy to be
working with a language that works in terms of an imaginary virtual
machine, because as a user, I don't have to worry about details like
that, and as an implementor, I get more room for creativity :)
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
Kent M Pitman
> On Sat, Mar 02, 2002 at 06:58:11AM +0000, Kent M Pitman wrote:
> [ interesting discussion omitted ]
> > It reminds me a little of the absolute nightmare I had when translating
> > Symbolics Macsyma from MACLISP to Common Lisp back in 1986 and trying to
> > accomodate QUOTIENT. MACLISP's QUOTIENT had the awful property that if you
> > gave it only integers, it did truncating divide. But if you gave it any
> > arg that was a flonum (the MACLISP name for float), it did floating point
> > division instead. So (QUOTIENT 3 2) => 1, but (QUOTIENT 3.0 2) => 1.5.
> > Obviously, some of these had to be translated to / in CL and others to
> > TRUNCATE. Figuring which was which, since they were all called QUOTIENT.
> > If you step back from Lisp, and functional languages in general, you can see
> > how LAMBDA would have this same kind of nightmarish ambiguity to some who
> > really cared about what it was "doing" ...
>
> I don't know what the situation was like back in 1986, but today couldn't
> something like this be done?:
Yes and no. It can be done. It is not efficient, which was the whole point.
> (defun quotient (a b)
> (if (and (typep a 'integer)
> (typep b 'integer))
> (truncate a b)
> (/ a b)))
>
> With an inline declaration and a good compiler even the function-call to
> quotient could be elided, I would think.
No, not really. Only where you knew the type of the argument. Often the
type was not declared. And anyway, the whole point was not to leave this
kind of grossness in the code. The only reason that anyone ever wrote
it this way before is that the operator you needed was called QUOTIENT in
both cases. If they'd had any sense, they'd have defined two macros that
each both expanded to QUOTIENT but that had different names so that code
readability was improved.
In practice, though, people type declared some code, but not nearly
enough to cover all the uses of QUOTIENT. If they had, I could have just
looked at surrounding declarations to do the syntactic rewrite I was engaged
in doing. My problem was that there were utterly impenetrable things
that just did (DEFUN FOO (X Y Z) (PLUS (TIMES X) (QUOTIENT Y Z)))
where I had to decide "is this supposed to get only fixnums?" "only flonums?"
"is this supposed to get either?" "is the person who wrote the code
even conscious of the weird thing that happens in the other case they weren't
writing for?"
> This doesn't help when someone
> is reading through the code, though, if that was your main point.
Yes. Precisely. I could also make something that did
(declaim (inline foo))
(defun foo (x)
(if (stringp x) (open x) (cdr x)))
And perhaps if people type-declared their code well, they could never get
hit with a performance penalty, but manipulating code that FOO'd its argument
would still be quite tricky.
> I do understand your point about LAMBDA however, though I imagine that
> there is some way of distinguishing between the two usages; compilers
> (at least efficient ones) need to do so. Not that I am any expert on
> compiler-writing.
The ENTIRE and ONLY point of my remark about LAMBDA was about human
code readability. Compilers already do fine. They know when there is
capture and when there is not because they just cannot compile the
code otherwise. So you are definitely missing the point.
Kent M Pitman
> Kent M Pitman <pit...@world.std.com> writes:
>
> > The functional programming community, in general, prefers to blur these two
> > notations because both describe functions. But compiler writers are VERY
> > familiar with the difference, and no one who becomes a writer of good code
> > in CL fails to understand the distinction between these two things. So it's
> > quite bizarre, in a way, that we map them to one function.
>
> Huh. In the Ciel-80 compiler, everything's a closure. Something like
> (lambda (x) (+ x 3)) closes over nothing, but
> (defun f () (lambda (x) (+ x 3))) will always cons. I know that I
> could special-case things like this, when the compiler, having gone
> over the body of the lambda discovers that it doesn't close over
> anything, but that seems more like an optimization than any kind of
> real difference, to me. You could define a language with both
> closures and non-closing procedures, but if you have closures, you
> have non-closing procedures too for free; consing is an optimization
> problem. I could add the ability to make F non-consing (and will, if
> anyone complains and actually needs it), but a closure object in the
> Ciel-80 system is exactly the same size as a cons cell. There's about
> 100 million little optimizations I could do all over the place, so I
> just ignore them unless I have a reason to think they're worth it.
Well, I think most Lisp implementors don't.
But I just ranted the other day about the nuisance value of tiny
optimizations, so maybe I should just let it go here and agree with you
that it's possible to make an engineering choice. What you're saying
isn't really wrong in any sense, it just doesn't constitute good "Lisp
outreach" ...
The purpose of my remark was to note that there are those who are made
nervous by their sense (sometimes right, sometimes not) of Lisp's
propensity to cons, and I guess what I was saying was that there are
places we could have guaranteed we wouldn't cons, but LAMBDA can't be
such a one unless we split it in two...
> > [...] It reminds me a little of the absolute nightmare I had when
> > translating Symbolics Macsyma from MACLISP to Common Lisp back in
> > 1986 and trying to accomodate QUOTIENT. MACLISP's QUOTIENT had the
> > awful property that [...]
>
> It seems a bit streached, because you can always see what LAMBDA will
> do by looking at its body, whereas QUOTIENT depended on runtime
> values,
Yes, they are of somewhat different quality in that regard.
It might have been a bad analogy to raise.
Gareth McCaughan
> It reminds me a little of the absolute nightmare I had when translating
> Symbolics Macsyma from MACLISP to Common Lisp back in 1986 and trying to
> accomodate QUOTIENT. MACLISP's QUOTIENT had the awful property that if you
> gave it only integers, it did truncating divide. But if you gave it any
> arg that was a flonum (the MACLISP name for float), it did floating point
> division instead.
Ha. "Those who cannot remember the past are condemned to repeat it."
Python's "/" operator does exactly that, and the language is in
the process of changing (very slowly and carefully, to give everyone
a chance to adjust) to more sensible semantics for division.
(They're going with 3/2 -> 1.5 rather than introducing a rational
type, which is a debatable decision...) You can imagine the amount
of angst this has caused. :-)
--
Gareth McCaughan Gareth.M...@pobox.com
.sig under construc
Tim Bradshaw
> That's unfair: cats see in the dark much better than humans.
The study was conducted in carefully controlled light conditions (I
didn't adjust the screen brightness, and the cat was asleep in the
same location (another room) both times. And she can't read.
Thomas F. Burdick
> t...@apocalypse.OCF.Berkeley.EDU (Thomas F. Burdick) writes:
>
> > Kent M Pitman <pit...@world.std.com> writes:
> >
> > > The functional programming community, in general, prefers to blur these two
> > > notations because both describe functions. But compiler writers are VERY
> > > familiar with the difference, and no one who becomes a writer of good code
> > > in CL fails to understand the distinction between these two things. So it's
> > > quite bizarre, in a way, that we map them to one function.
> >
> > Huh. In the Ciel-80 compiler, everything's a closure. Something like
> > (lambda (x) (+ x 3)) closes over nothing, but
> > (defun f () (lambda (x) (+ x 3))) will always cons. I know that I
> > could special-case things like this, when the compiler, having gone
> > over the body of the lambda discovers that it doesn't close over
> > anything, but that seems more like an optimization than any kind of
> > real difference, to me. You could define a language with both
> > closures and non-closing procedures, but if you have closures, you
> > have non-closing procedures too for free; consing is an optimization
> > problem. I could add the ability to make F non-consing (and will, if
> > anyone complains and actually needs it), but a closure object in the
> > Ciel-80 system is exactly the same size as a cons cell. There's about
> > 100 million little optimizations I could do all over the place, so I
> > just ignore them unless I have a reason to think they're worth it.
>
> Well, I think most Lisp implementors don't.
That's probably true. My position on micro-optimizations in Ciel-80
is that they don't get done unless they're generally useful: if I've
had experience with them being generally useful before in another
compiler, they go in; otherwise, they don't go in unless someone
notices they're not there. Hopefully this will be an effective sort
of profiling, but only time will tell. The big hope is that the gains
in maintainability (because the code won't be cluttered with useless
optimizations) will be enough that the overall quality will be better.
> But I just ranted the other day about the nuisance value of tiny
> optimizations, so maybe I should just let it go here and agree with you
> that it's possible to make an engineering choice. What you're saying
> isn't really wrong in any sense, it just doesn't constitute good "Lisp
> outreach" ...
I'm not sure what you mean by "doesn't constitute good `Lisp
outreach'". Do you mean that it promotes misguided views that Lisp
conses all the time, unnecessarily? When/if this system goes into
general consumption, it will hopefully have gone through enough rounds
of optimization that it won't perpetuate that myth; for its initial
users, they're aware of the development process, and it's probably a
win on that front. At least for the population concerned, it's
comforting to tell someone who's usually a non-Lisper to feel free to
look at what the compiler's producing and complain if it's doing
something stupid (like consing unnecessarily), so it can get fixed.
> The purpose of my remark was to note that there are those who are made
> nervous by their sense (sometimes right, sometimes not) of Lisp's
> propensity to cons, and I guess what I was saying was that there are
> places we could have guaranteed we wouldn't cons, but LAMBDA can't be
> such a one unless we split it in two...
Okay, I see.
Kent M Pitman
> I'm not sure what you mean by "doesn't constitute good `Lisp
> outreach'". Do you mean that it promotes misguided views that Lisp
> conses all the time, unnecessarily?
Well, I'd probably say "risks promoting". Who am I to say? But,
yes, that was what I meant. Not sure if there's much to be done by
that...