function and lambda, again
Erik Naggum
also be some obcure, but very valuable history lesson hidden underneath
this, so if you permit me the useless, annoying suggestion as a means to
an end...
(lambda (argument-list) body)
(function function-name)
Recall that a function-name is a symbol or a list.
If lambda is an undesirable choice of name, function could assume both
roles, as it is disambiguated by its required one argument and lambda
needs a body.
In the degenerate case of a lambda with no body, its arguments, if any,
are unused and could need a declaration to that effect. The empty
argument-list is disambiguated from the function nil by the inability
(or at least extremely poor taste) to name a function nil.
In other words, here is the proposal: Replace lambda with function, and
arrive at something like this:
(function (x) (mumble-frotz x))
Now, I am not allowed to set up a macro for cl:function, but I can create
my own package and do the following there:
(defmacro function (first &rest rest)
(if rest
`(cl:lambda ,first ,rest)
`(cl:function first)))
This macro could, if necesary, walk through the body and discovery free
variables and make it possible to distinguish function and closure (a
subclass of function), which would then have its own "constructor".
I am actually more curious how "lambda" became the name of this operator
and if something else has been proposed and rejected, and if, why.
///
--
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.
Nils Goesche
> I am actually more curious how "lambda" became the name of this operator
> and if something else has been proposed and rejected, and if, why.
From ``History of Lisp'' (John McCarthy 1979):
# To use functions as arguments, one needs a notation for functions,
# and it seemed natural to use the \lambda-notation of Church (1941).
# I didn't understand the rest of his book, so I wasn't tempted to
# implement his more general mechanism for defining functions.
I like the name lambda for it... it's kindof a historical tribute.
The full text can be downloaded here:
http://www-formal.stanford.edu/jmc/history/lisp.dvi
Regards,
--
Nils Goesche
"Don't ask for whom the <CTRL-G> tolls."
PGP key ID 0x42B32FC9
Erann Gat
Or just use "fn" instead of "function" and save yourself some typing while
you're at it.
E.
Christian Nybų
> Or just use "fn" instead of "function" and save yourself some typing
> while you're at it.
Why do you suggest "fn" rather than "f"? And do the reasons for
choosing "fn" rather than "f" hold for choosing "function" rather than
"fn"?
I think using function (or make-function, as I translate it) rather
than lambda, first and rest rather than car and cdr, perhaps
(make-)pair rather than cons, would be a worthwhile experiment for
teaching languages that have car cons and cdr (whatever that subset of
languages is called). Then students could familiarize themselves with
the usual forms after their introductory courses.
--
chr
Nils Goesche
I doubt it. IIRC learning the meaning of car, cdr and lambda was
*by far* the easiest part when I began learning (Emacs-)Lisp. I
didn't know at the time /why/ it was called ``lambda'', but I
couldn't care less what it's called. I remember that I found
those freaky names somewhat ``funny'', I liked them; I still do.
If I imagine being taught ``make-function'', ``first'' and
``rest'' instead, only to find out later that everybody else
calls those ``lambda'', ``car'' and ``cdr'', I would feel somewhat
insulted, as if my teachers were assuming I was a total moron.
Dorai Sitaram
>g...@jpl.nasa.gov (Erann Gat) writes:
>
>> Or just use "fn" instead of "function" and save yourself some typing
>> while you're at it.
>
>Why do you suggest "fn" rather than "f"? And do the reasons for
>choosing "fn" rather than "f" hold for choosing "function" rather than
>"fn"?
Single-char identifiers should really be left for the
user -- cf the unfortunate use of `t' for boolean true,
thereby rendering it unusable as a user variable.
--d
Kalle Olavi Niemitalo
> If I imagine being taught ``make-function'', ``first'' and
> ``rest'' instead, only to find out later that everybody else
> calls those ``lambda'', ``car'' and ``cdr'', I would feel somewhat
> insulted, as if my teachers were assuming I was a total moron.
This reminds me of the programming course I had as a teenager.
The procedures of Turbo Pascal 4 were hidden under an obligatory
"YTI" unit which provided subroutines like ruutu8 and ruutu11 for
creating windows with predefined sizes and positions -- as if it
had been too difficult for us to pass coordinates as arguments.
Erann Gat
> g...@jpl.nasa.gov (Erann Gat) writes:
>
> > Or just use "fn" instead of "function" and save yourself some typing
> > while you're at it.
>
> Why do you suggest "fn" rather than "f"? And do the reasons for
> choosing "fn" rather than "f" hold for choosing "function" rather than
> "fn"?
Hmmm... I never really thought about it. My knee-jerk reaction was that
"f" is a little too terse, and as a mnemonic it evokes "false" more than
"function". But now that I think about it (f (x) ...) doesn't look half
bad.
For that matter, how about the symbol whose name is ""?
(|| (x) ...)
It's not so different visually from (\\ (x) ...) which has also been
suggested before (since backslashes look like lambdas) and it really
drives home the idea that this is a function without a name.
Actually, in Common Lisp we could even stipulate that any list whose car
is a lambda list describes an anonymous function: ((x) ...) but that can't
be implemented without a major change in the standard.
E.
Erik Winkels
>
> For that matter, how about the symbol whose name is ""?
>
> (|| (x) ...)
Yeah!
Let's put '$' in front of all our variables and get rid of all
datatypes besides arrays and hashes.
Robert Pluim
Yep,
many's the time that I've lamented the fact that I couldn't use yet
another impossibly short, meaningless variable name for my own
nefarious purposes, and cursed silently at the standardizers of Common
Lisp for not rectifying this *glaring* defect in the language when they
had the chance.
(Did I just get trolled? Oh well)
--
Thomas F. Burdick
> Actually, in Common Lisp we could even stipulate that any list whose car
> is a lambda list describes an anonymous function: ((x) ...) but that can't
> be implemented without a major change in the standard.
But that forces you to type an unnecessary character! If we use
Smalltalk's block syntax, we aren't forced to type that extra char:
[x| ...]
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
Dorai Sitaram
Robert Pluim <rpl...@bigfoot.com> wrote:
>ds...@goldshoe.gte.com (Dorai Sitaram) writes:
>>
>> Single-char identifiers should really be left for the
>> user -- cf the unfortunate use of `t' for boolean true,
>> thereby rendering it unusable as a user variable.
>
>Yep,
>
>many's the time that I've lamented the fact that I couldn't use yet
>another impossibly short, meaningless variable name for my own
>nefarious purposes, and cursed silently at the standardizers of Common
>Lisp for not rectifying this *glaring* defect in the language when they
>had the chance.
>
>(Did I just get trolled? Oh well)
I admit I was surprised I had said something
controversial. I actually do find x, y, z, t to be
very convenient proglang identifiers for the
corresponding "independent variables" (cf math,
physics, elec engg scenarios), and would find
substituting them with x-coordinate, y-coordinate,
z-coordinate, time-coordinate to be awkward.
Similarly, I do use indices like i, j, k instead of...
indeed I can't readily imagine the substitutes:
perhaps, first-index, second-index, third-index? I
honestly didn't think I was expressing a peculiar
preference.
Cheers,
--d
Glenn Burnside
[:x|...], so it's the same number of characters. It just incorporates 4
different characters instead of 2. But with more than one variable, the
Lisp syntax wins -((x y z) ...) vs [:x :y :z|...].
Can we micro-optimize on any smaller scale than this?
GB
"Thomas F. Burdick" <t...@conquest.OCF.Berkeley.EDU> wrote in message
news:xcvr8my...@conquest.OCF.Berkeley.EDU...
Tim Bradshaw
> I admit I was surprised I had said something
> controversial. I actually do find x, y, z, t to be
> very convenient proglang identifiers for the
> corresponding "independent variables" (cf math,
> physics, elec engg scenarios), and would find
> substituting them with x-coordinate, y-coordinate,
> z-coordinate, time-coordinate to be awkward.
> Similarly, I do use indices like i, j, k instead of...
> indeed I can't readily imagine the substitutes:
> perhaps, first-index, second-index, third-index? I
> honestly didn't think I was expressing a peculiar
> preference.
binding (or trying to) T is one of the mistakes I make fairly
regularly.
Thomas F. Burdick
> Ah, not entirely correct - the Smalltalk syntax is actually
> [:x|...], so it's the same number of characters. It just incorporates 4
> different characters instead of 2. But with more than one variable, the
> Lisp syntax wins -((x y z) ...) vs [:x :y :z|...].
You're right, I meant to say ST-like. Actually using ST's syntax
wouldn't make any sense in the Lisp world where you can do:
(lambda (foo:x bar:y baz:z) ...)
> Can we micro-optimize on any smaller scale than this?
Is that a challenge? :)
Thomas F. Burdick
> binding (or trying to) T is one of the mistakes I make fairly
> regularly.
Yeah, me too. In one of the most amusing attempts, I wrote a function
that started with t bound to nil (to indicate that it hadn't started
keeping track of the time yet), then depended on t working as the
default in a cond in order to give t a non-null value. Oops.
Kenny Tilton
"Thomas F. Burdick" wrote:
>
> Tim Bradshaw <t...@cley.com> writes:
>
> > binding (or trying to) T is one of the mistakes I make fairly
> > regularly.
>
> Yeah, me too.
Me? Once in six years of full-time Lisp. And ACL spanked me with a
compilation error.
--
kenny tilton
clinisys, inc
---------------------------------------------------------------
"Be the ball...be the ball...you're not being the ball, Danny."
- Ty, Caddy Shack
Kalle Olavi Niemitalo
> Actually, in Common Lisp we could even stipulate that any list whose car
> is a lambda list describes an anonymous function: ((x) ...) but that can't
> be implemented without a major change in the standard.
When I played with AutoLisp in 1990 or so, (lambda (x) x)
returned the list ((x) x). They may have changed it by now.
Christophe Rhodes
> ds...@goldshoe.gte.com (Dorai Sitaram) writes:
>
> > Single-char identifiers should really be left for the
> > user -- cf the unfortunate use of `t' for boolean true,
> > thereby rendering it unusable as a user variable.
>
> Yep,
>
> many's the time that I've lamented the fact that I couldn't use yet
> another impossibly short, meaningless variable name for my own
> nefarious purposes, and cursed silently at the standardizers of Common
> Lisp for not rectifying this *glaring* defect in the language when they
> had the chance.
>
> (Did I just get trolled? Oh well)
I have a feeling I might just have been, actually; certainly, when
doing numerical work, it's quite common to wish to do a direct
translation of mathematical formulae, and not being able to use t for
a time variable is mildly irritating. No more than that, but there is
some irritation there.
Not that it stops me from using Common Lisp, though ;)
Christophe
--
Jesus College, Cambridge, CB5 8BL +44 1223 510 299
http://www-jcsu.jesus.cam.ac.uk/~csr21/ (defun pling-dollar
(str schar arg) (first (last +))) (make-dispatch-macro-character #\! t)
(set-dispatch-macro-character #\! #\$ #'pling-dollar)
Harald Hanche-Olsen
| Single-char identifiers should really be left for the
| user -- cf the unfortunate use of `t' for boolean true,
| thereby rendering it unusable as a user variable.
Since this thread is diverging all over the place, maybe I should take
the opportunity to ask a question that I have long wanted to ask, but
never did because I didn't think it was important enough to bother
anybody with:
In a lisp-mode buffer in emacs with font-locking turned on,
multiletter keywords like :foo are highlighted (highlit?) but
single-letter keywords like :f are not. I actually looked in the
Hyperspec to check if single-letter keywords have a specific
significance, but I did not find anything. But maybe there is a
special convention surrounding them, that is reflected in this choice
of non-highlighting? If so, what is it?
--
* Harald Hanche-Olsen <URL:http://www.math.ntnu.no/~hanche/>
- Yes it works in practice - but does it work in theory?
Julian Stecklina
> "Thomas F. Burdick" wrote:
> >
> > Tim Bradshaw <t...@cley.com> writes:
> >
> > > binding (or trying to) T is one of the mistakes I make fairly
> > > regularly.
> >
> > Yeah, me too.
>
> Me? Once in six years of full-time Lisp. And ACL spanked me with a
> compilation error.
[...]
I did it recently when I was porting some old PASCAL code that used a
variable called t. I do not think, that I would make this mistake in
code which is written in Lisp from scratch.
So I do not believe this to be a problem.
Regards,
Julian
--
Meine Hompage: http://julian.re6.de
Um meinen oeffentlichen Schluessel zu erhalten:
To get my public key:
http://math-www.uni-paderborn.de/pgp/
Kent M Pitman
> In a lisp-mode buffer in emacs with font-locking turned on,
> multiletter keywords like :foo are highlighted (highlit?) but
(Webster.com says "highlighted" is correct, but I use either in casual
conversation and firmly believe in the rule that the more heavily used
a word is, the more it will try to contract. The conjugation rules for
this verb were surely created in a time when highlighting was an obscure
thing that didn't happen multiple times per minute to a large fraction
of the population. So "highlit" will surely get into the dictionary
in short order. Then again, I personally often bypass all this and just say
"light up" and "lit up" as part of my personal quest for something short.)
> single-letter keywords like :f are not. I actually looked in the
> Hyperspec to check if single-letter keywords have a specific
> significance, but I did not find anything. But maybe there is a
> special convention surrounding them, that is reflected in this choice
> of non-highlighting? If so, what is it?
None that I personally know of.
This is a great example for those who implement font locking to
understand the importance of getting things right. People come to
depend on shifts or non-shifts of color to tell them something, and if
the shifting algorithm isn't completely accurate, you get newbies
asking all kinds of confused questions. Or worse, you get people just
assuming they shouldn't do the thing that aggravates the bug and
building up a whole religion around it, either because they are
confused or because they know better but can't bear the colors not
working right.
Raymond Wiker
> In a lisp-mode buffer in emacs with font-locking turned on,
> multiletter keywords like :foo are highlighted (highlit?) but
> single-letter keywords like :f are not. I actually looked in the
> Hyperspec to check if single-letter keywords have a specific
> significance, but I did not find anything. But maybe there is a
> special convention surrounding them, that is reflected in this choice
> of non-highlighting? If so, what is it?
I think this is simply a bug in a particular version of emacs
and/or font-lock-mode. My xemacs installation (21.1p12) does _not_
have this problem.
--
Raymond Wiker Mail: Raymon...@fast.no
Senior Software Engineer Web: http://www.fast.no/
Fast Search & Transfer ASA Phone: +47 23 01 11 60
P.O. Box 1677 Vika Fax: +47 35 54 87 99
NO-0120 Oslo, NORWAY Mob: +47 48 01 11 60
Try FAST Search: http://alltheweb.com/
Jacek Generowicz
> Harald Hanche-Olsen <han...@math.ntnu.no> writes:
>
> > In a lisp-mode buffer in emacs with font-locking turned on,
> > multiletter keywords like :foo are highlighted (highlit?) but
>
> (Webster.com says "highlighted" is correct, but I use either in casual
> conversation and firmly believe in the rule that the more heavily used
> a word is, the more it will try to contract. The conjugation rules for
> this verb were surely created in a time when highlighting was an obscure
> thing that didn't happen multiple times per minute to a large fraction
> of the population. So "highlit" will surely get into the dictionary
> in short order.
The Oxford English Dictionary:
highlight, high-light, v. trans. a. To bring into prominence, to
`feature', to draw attention to.
Then, as it traces the word's use though history, starting with
1934 M. WESEEN Dict. Amer. Slang x. 143 Highlight, to give one a
prominent place on a program or a leading part in a
show. Highlighted, marked by; featured by.
it lists
1957 Economist 19 Oct. 192/1 The genuineness with which each
holds the belief was highlit during last week's..interview.
Strangely enough, the last entry is from 1967, and nowhere is it
acknowledged that highlighting is a thing that happens multiple times
per minute to a large fraction of the population. Maybe it just
doesn't in Oxford.
Erik Naggum
| I did it recently when I was porting some old PASCAL code that used a
| variable called t. I do not think, that I would make this mistake in
| code which is written in Lisp from scratch.
| So I do not believe this to be a problem.
Well, I consider it a problem. I use x, y, z, t, in my equations on
paper all the time, and it annoys me that t is "busy" when I want to do
math with Common Lisp.
Erik Naggum
| This is a great example for those who implement font locking to
| understand the importance of getting things right. People come to depend
| on shifts or non-shifts of color to tell them something, and if the
| shifting algorithm isn't completely accurate, you get newbies asking all
| kinds of confused questions. Or worse, you get people just assuming they
| shouldn't do the thing that aggravates the bug and building up a whole
| religion around it, either because they are confused or because they know
| better but can't bear the colors not working right.
I note in passing that the same applies to editor symbol completion in a
language that has different namespace for symbols depending on whether
they follow a left paren or not. <pause for effect> Experienced Lispers
recognize that this is All Wrong -- this is not a good criterion for
functionhood at all, yet it is precisely what Emacs Lisp does in all Lisp
modes, and a bug that has spread to other Lisp modes, too.
Christopher Browne
> * Julian Stecklina <der_j...@web.de>
> | I did it recently when I was porting some old PASCAL code that used a
> | variable called t. I do not think, that I would make this mistake in
> | code which is written in Lisp from scratch.
> | So I do not believe this to be a problem.
>
> Well, I consider it a problem. I use x, y, z, t, in my equations on
> paper all the time, and it annoys me that t is "busy" when I want to do
> math with Common Lisp.
I don't think Scheme has that particular problem :-).
--
(reverse (concatenate 'string "gro.mca@" "enworbbc"))
http://www3.sympatico.ca/cbbrowne/linuxxian.html
"A good rule of thumb is never to use PROG under any circumstances for
anything." -- Dave Moon
Harald Hanche-Olsen
| None that I personally know of.
Thanks. As I suspected.
| Or worse, you get people just assuming they shouldn't do the thing
| that aggravates the bug and building up a whole religion around it,
| either because they are confused or because they know better but
| can't bear the colors not working right.
Fortunately, I am not the religious type. I am somehow reminded of
the suggestion from Microsoft to avoid using the word "begin", at
least in lower case, particularly if it happens to end up at the
begin^H^H^H^H^Hstart of a line. This in order to avoid having MS
Outlook over-enthusiastically trying to uudecode the rest of your
message! (No, I am not making this up:
<ftp://ftp.sri.com/risks/risks-21.90>.)
Surely, it's no great wonder if religious beliefs do arise in the
computing world.
Harald Hanche-Olsen
| I note in passing that the same applies to editor symbol
| completion in a language that has different namespace for symbols
| depending on whether they follow a left paren or not.
And not only completion, but again syntax highlighting gets it wrong:
Just look at how it highlights
(let ((let let)) ...)
Fortunately, I understood all along that this just had to be a bug.
(But then, the mechanism for this bug is easily understood.)
Bruce Lewis
> Can we micro-optimize on any smaller scale than this?
Yes, with several macros similar to the one below. For tiny little
anonymous procedures, the args frequently aren't descriptive anyway.
(defmacro fn3 body
`(lambda (a b c) ,@body))
--
<brlewis@[(if (brl-related? message) ; Bruce R. Lewis
"users.sourceforge.net" ; http://brl.sourceforge.net/
"alum.mit.edu")]>
Bruce Lewis
> Erik Naggum <er...@naggum.net> wrote:
> >
> > Well, I consider it a problem. I use x, y, z, t, in my equations on
> > paper all the time, and it annoys me that t is "busy" when I want to do
> > math with Common Lisp.
>
> I don't think Scheme has that particular problem :-).
Right. That's because equations on paper rarely include a variable
named "list". :-)
Thomas F. Burdick
> "Thomas F. Burdick" wrote:
> >
> > Tim Bradshaw <t...@cley.com> writes:
> >
> > > binding (or trying to) T is one of the mistakes I make fairly
> > > regularly.
> >
> > Yeah, me too.
>
> Me? Once in six years of full-time Lisp. And ACL spanked me with a
> compilation error.
Wow. You've either got better alarms in your head, or you don't code
up many formulas, or both. I am glad that this is a case where you
have to try to break things[*] before CMUCL will let you compile the
code. Otherwise I'd have had some really annoying bugs.
[*] * (defun foo (t) (bar))
FOO
* (defun bar () (if t (princ 't) (princ '(not t))))
BAR
* (compile 'foo)
In: LAMBDA (T)
#'(LAMBDA (T) (BLOCK FOO (BAR)))
Error: Name of lambda-variable is a constant: T.
;; ...
* (defvar t)
T
* (compile 'foo)
Compiling LAMBDA (T):
Compiling Top-Level Form:
FOO
NIL
NIL
* (foo t)
T
T
* (foo nil)
(NOT T)
(NOT T)
*
Thomas F. Burdick
> Not that it stops me from using Common Lisp, though ;)
Not me, if I can't use t as my time variable, what's the point of
using the language! I'm switching back to Fortran!
... er, maybe not
Thomas F. Burdick
> * Kent M Pitman <pit...@world.std.com>
> | This is a great example for those who implement font locking to
> | understand the importance of getting things right. People come to depend
> | on shifts or non-shifts of color to tell them something, and if the
> | shifting algorithm isn't completely accurate, you get newbies asking all
> | kinds of confused questions. Or worse, you get people just assuming they
> | shouldn't do the thing that aggravates the bug and building up a whole
> | religion around it, either because they are confused or because they know
> | better but can't bear the colors not working right.
>
> I note in passing that the same applies to editor symbol completion in a
> language that has different namespace for symbols depending on whether
> they follow a left paren or not. <pause for effect> Experienced Lispers
> recognize that this is All Wrong -- this is not a good criterion for
> functionhood at all, yet it is precisely what Emacs Lisp does in all Lisp
> modes, and a bug that has spread to other Lisp modes, too.
We should probably have different keys for variable and function
completion, since there's really no way to tell what I want if I type:
(my-macro foo<M-TAB>
Erann Gat
<brl...@users.sourceforge.net> wrote:
> "Glenn Burnside" <glenn.b...@ni.com> writes:
>
> > Can we micro-optimize on any smaller scale than this?
>
> Yes, with several macros similar to the one below. For tiny little
> anonymous procedures, the args frequently aren't descriptive anyway.
>
> (defmacro fn3 body
> `(lambda (a b c) ,@body))
Or...
(defmacro [ body
`(lambda (&rest argv &aux (argc (length argv))) ,@body))
;-) ;-) ;-)
E.
John Paul Wallington
> Harald Hanche-Olsen <han...@math.ntnu.no> writes:
>
>> In a lisp-mode buffer in emacs with font-locking turned on,
>> multiletter keywords like :foo are highlighted (highlit?) but
>> single-letter keywords like :f are not. I actually looked in the
>> Hyperspec to check if single-letter keywords have a specific
>> significance, but I did not find anything. But maybe there is a
>> special convention surrounding them, that is reflected in this choice
>> of non-highlighting? If so, what is it?
>
> I think this is simply a bug in a particular version of emacs
> and/or font-lock-mode. My xemacs installation (21.1p12) does _not_
> have this problem.
I think generally speaking GNU Emacs has this problem and XEmacs
doesn't. XEmacs has its own keyword fontification problem - keywords
are often fontified when in comments!
;; (make-hash-table :size 61)
--
John Paul Wallington
Kent M Pitman
> I think generally speaking GNU Emacs has this problem and XEmacs
> doesn't. XEmacs has its own keyword fontification problem - keywords
> are often fontified when in comments!
Is that necessarily wrong? Does a keyword cease to be a keyword in that
context?
John Paul Wallington
> John Paul Wallington <j...@shootybangbang.com> writes:
>
>> I think generally speaking GNU Emacs has this problem and XEmacs
>> doesn't. XEmacs has its own keyword fontification problem - keywords
>> are often fontified when in comments!
>
> Is that necessarily wrong?
I don't know, but I don't like it.
> Does a keyword cease to be a keyword in that context?
I think so. I guess the only things within a comment that I don't
mind getting fontified are symbols with single quotes around them.
--
John Paul Wallington
Raymond Toy
jpw> Raymond Wiker <Raymon...@fast.no> wrote:
>> Harald Hanche-Olsen <han...@math.ntnu.no> writes:
>>
>>> In a lisp-mode buffer in emacs with font-locking turned on,
>>> multiletter keywords like :foo are highlighted (highlit?) but
>>> single-letter keywords like :f are not. I actually looked in the
>>> Hyperspec to check if single-letter keywords have a specific
>>> significance, but I did not find anything. But maybe there is a
>>> special convention surrounding them, that is reflected in this choice
>>> of non-highlighting? If so, what is it?
>>
>> I think this is simply a bug in a particular version of emacs
>> and/or font-lock-mode. My xemacs installation (21.1p12) does _not_
>> have this problem.
jpw> I think generally speaking GNU Emacs has this problem and XEmacs
jpw> doesn't. XEmacs has its own keyword fontification problem - keywords
jpw> are often fontified when in comments!
Aren't all of these fontification problems because fontification is
primarily driven by regexps, with a little bit of syntax knowledge?
Ray
Erik Naggum
| Aren't all of these fontification problems because fontification is
| primarily driven by regexps, with a little bit of syntax knowledge?
Emacs fontification is a colorful way of telling experienced and
knowledgeable users that regexps are insufficient to solve this kind of
problem. Inexperienced or unknowledgeable users only get the message
that they need more crap in their regexps.
The novice had a problem. "I know", thought the novice, "I'll just use
regexps!" The novice now has two problems.
Drew McDermott
> ...
> In other words, here is the proposal: Replace lambda with function, and
> arrive at something like this:
>
> (function (x) (mumble-frotz x))
...
> I am actually more curious how "lambda" became the name of this operator
> and if something else has been proposed and rejected, and if, why.
As others have pointed out, it was the obvious notation to borrow from
mathematical logic, although I would rather write it as '\\'; 'fn' is good, too
(isn't that how they write it in ML?).
The real puzzler is where 'function' came from. My guess would be the
following: Originally it seemed right to write (quote car) and (quote (lambda
(x) ...)) to refer to functions. (Remember that this is circa 1959, when what
seems clear to us now was totally obscure.) But for various reasons the early
Lisp hackers decided to replace the 'quote's with 'function' to distinguish a
reference to 'car' from a reference to the function named 'car'. It didn't
occur to them that just *discarding* the 'quote' was the right thing to do for
the 'lambda' case. (It should also have occurred to them that the function
named 'car' should be the *value* of 'car', thus eliminating 'function'
entirely, as in Scheme, but that's another argument.)
All other functional languages get this right, including Scheme.
-- Drew McDermott
Wade Humeniuk
"Drew McDermott" <drew.mc...@yale.edu> wrote in message
news:3C8D3D02...@yale.edu...
>
> As others have pointed out, it was the obvious notation to borrow from
> mathematical logic, although I would rather write it as '\\'; 'fn' is
good, too
> (isn't that how they write it in ML?).
>
Stop, please stop,....., don't do that, desist, halt, cease,...
I guess it will not work.
Just to let you know, CL is not Scheme or ML or Haskell or C++. (If that
does any good). :(
> The real puzzler is where 'function' came from. My guess would be the
> following: Originally it seemed right to write (quote car) and (quote
(lambda
> (x) ...)) to refer to functions. (Remember that this is circa 1959, when
what
> seems clear to us now was totally obscure.) But for various reasons the
early
> Lisp hackers decided to replace the 'quote's with 'function' to
distinguish a
> reference to 'car' from a reference to the function named 'car'. It
didn't
> occur to them that just *discarding* the 'quote' was the right thing to do
for
> the 'lambda' case. (It should also have occurred to them that the
function
> named 'car' should be the *value* of 'car', thus eliminating 'function'
> entirely, as in Scheme, but that's another argument.)
>
> All other functional languages get this right, including Scheme.
CL has more that just functional language capabilities. CL is CL or in CL
(CL CL).
Wade
Kent M Pitman
Drew! I'm surprised at you for oversimplifying so!
> The real puzzler is where 'function' came from. My guess would be
> the following: Originally it seemed right to write (quote car) and
> (quote (lambda (x) ...)) to refer to functions. (Remember that this
> is circa 1959, when what seems clear to us now was totally obscure.)
> But for various reasons the early Lisp hackers decided to replace
> the 'quote's with 'function' to distinguish a reference to 'car'
> from a reference to the function named 'car'. It didn't occur to
> them that just *discarding* the 'quote' was the right thing to do
> for the 'lambda' case. (It should also have occurred to them that
> the function named 'car' should be the *value* of 'car', thus
> eliminating 'function' entirely, as in Scheme, but that's another
> argument.)
First, discarding the quote didn't do the right thing because there
was no LAMBDA special form to fall through to. That meant a lot more
implementation work. FUNCTION behaved just like QUOTE in the interpreter
back then because all binding in the interpreter was dynamic. So keeping
the QUOTE was a sane choice in that system because it meant the interpreter
required no upgrade.
At the time FUNCTION crept in, the problem wasn't interpretation but
compilation. One of the "revolutionary" ideas of Common Lisp was that
the language would have the same semantics in the compiler as the
interpreter, as surely you recall Drew, since you used Maclisp and
know how it was prior.
In Maclisp, when you compiled
(defun foo (x) (bar x))
you changed [merely by having compiled it] the binding of X from a
dynamic binding to a lexical binding [though we didn't have a name
like lexical binding ... I think we said that the binding of X was
"compiled away"]. This had very strange effects, and there was tons
of code that worked only compiled but not interpreted (or vice versa).
In some cases this was really useful because one could make clever use
of things the compiler would "compile away" to get strange and marvelous
effects. We weren't much concerned with semantics back then. Just with
getting a job done. Lisp was more like an assembly language toolbox than
something with very definite meaning to it. There were all kinds of ways
to set options that would completely change the type system behavior
dynamically (e.g., the treatment of hunks), etc.
So given that backdrop, you can see that
(defun f (x z) (mapcar '(lambda (y) (+ x y)) z))
worked fine in the interpreter because it pretty much did what CL
would do for:
(defun f (x z)
(declare (special x z))
(mapcar '(lambda (y) (+ x y)) z))
which in turn gave mapcar the list (lambda (y) (+ x z)) and did what
we would in CL describe as:
(dolist (z0 z)
(progv '(y) (list z0)
(eval '(+ x y))))
and succeeded. And the compiler had special knowledge that you might
do (mapcar '(lambda ...) something) so it had no trouble "compiling away"
the quotation. But it had a lot of trouble with:
(defun f (x z)
(let ((f0 '(lambda (y) (+ x y))))
(mapcar f0 z)))
because we didn't do a lot of flow analysis back then and if it "compiled
away" the x binding, X would not be bound in MAPCAR when the implicit
EVAL of the lambda body happened.
The purpose of FUNCTION was to authorize the compiler to compile the thing
as a function even when the quotation occurred "out of context" of its use.
Consider that there was still a troubling situation that was not easy to
compile using either QUOTE or FUNCTION, which was:
(defun f (z)
(let ((x nil))
(let ((f0 '(lambda (y) (list (car x) y))))
(setq x f0) ;<-- this use of F0 will be as a list
(mapcar f0 z)))) ;<-- this use of F0 will be as a function
This was quite simply a problem in that day and age, and one just
learned not to do this, or else one put lots of SPECIAL declarations
around to keep variables they cared about from being "compiled away".
Note further that the problem of upward closures was treated as a separate
problem, hence the presence of *FUNCTION in Maclisp as a separate operator
which tried badly to implement closures.
But I'm surprised since you were there that you don't remember all this
pain and that you were willing to submit so simplistic an explanation as
"it would have worked to simply drop the quote". Nothing worked that
easily back then, but you do the designers of the time a disservice by
even hinting that this would really have been a very visible option at
the time to anyone down and dirty in the trenches.
> All other functional languages get this right, including Scheme.
For various values of right.
Erik Naggum
| (It should also have occurred to them that the function named 'car'
| should be the *value* of 'car', thus eliminating 'function' entirely, as
| in Scheme, but that's another argument.)
Some of us really, really *hate* Lisp1, and loathe every other
programming language that forces us to conflate clearly distinct
namespaces.
| All other functional languages get this right, including Scheme.
Common Lisp and all the natural languages I know get it right.
This kind of stupid troll is why Scheme freaks have their own forum.
Bernice Barnett
In the early 1960's (and maybe before but I wasn't there), forms such as
(x y z) would apply the function x to y z. However, if no functions was
defined, the form acted like (funcall x y z) which was just great if x had
a reasonable value. Also forms like ((f x) y z) where f was a function or
a variable, etc. were possible. Note, the operator and variable namespaces
were one and the same in those days. I think that these possibilities were
part of the motivation for the syntax that was used. The capability was
thought to be a feature, and like so many features, ..... It took a decade to
sort this all out.
-- Jeff Barnett
Rahul Jain
> (It should also have occurred to them that the function
> named 'car' should be the *value* of 'car', thus eliminating 'function'
> entirely, as in Scheme, but that's another argument.)
> All other functional languages get this right, including Scheme.
Hmm, I would have expected to get a more balanced view from such an
experienced and respected figure. Amazingly enough, not all people
think the same way as you might, and we actually _like_ the
function/value/class/etc distinction in the evaluation rules.
In fact, in DefDoc, I plan to add _more_ namespaces (e.g. spring,
spring-function, environment, font, box). This allows one to concisely
express exactly what he or she means. This is much like the way that
natural language words can be overloaded and the exact meaning to use
is obvious from syntactic context (in the case that the overloaded
meanings don't occur in the same syntactic usage, which is, of course,
how we are doing things in lisp).
--
-> -/ - Rahul Jain - \- <-
-> -\ http://linux.rice.edu/~rahul -=- mailto:rj...@techie.com /- <-
-> -/ "Structure is nothing if it is all you got. Skeletons spook \- <-
-> -\ people if [they] try to walk around on their own. I really /- <-
-> -/ wonder why XML does not." -- Erik Naggum, comp.lang.lisp \- <-
|--|--------|--------------|----|-------------|------|---------|-----|-|
(c)1996-2002, All rights reserved. Disclaimer available upon request.
David Combs
Drew McDermott <drew.mc...@yale.edu> wrote:
>Erik Naggum wrote:
>
>> ...
>> In other words, here is the proposal: Replace lambda with function, and
>> arrive at something like this:
>>
>> (function (x) (mumble-frotz x))
>
>...
>
>> I am actually more curious how "lambda" became the name of this operator
>> and if something else has been proposed and rejected, and if, why.
>
>As others have pointed out, it was the obvious notation to borrow from
>mathematical logic, although I would rather write it as '\\'; 'fn' is good, too
NO NO NO NO!
That's not it at all!
Here's what *really* happened: McCarthy (sp?) et al were
playing with the language design via a classroom set of
blackboards -- except sometimes, eg at a chinese restaurant,
where no blackboards available for *them* to use, they
resorted to those long, yellow, legal-sized pads of
paper.
What they'd do, to keep everything strictly separate,
is to write their functions (or whatever they called
those things, subroutines (from Fortran), maybe) only
*one* per sheet of (yellow) paper.
Then they could refer to a function, or even "call"
one, using not an actual name they'd have to invent,
but by simply pointing with their finger or knife
or chopstick at the actual sheet of paper it was
written on -- see, no name needed, that way.
Much less clutter of vocabulary (of names of functions)
to memorize and forget and misspell.
Then they needed a notation for this concept of
the sheet of paper, eg in passing args to it.
What (generic) to call that?
Well, what's common to all of those functions?
NOTHING -- but wait a sec -- yes! -- EACH ONE
is written on a YELLOW piece of paper.
Well, "y" is no good as a symbol for that, since
it interfered with the y in x, y, z as variable
names.
So, they turned it UPSIDE DOWN!
Of course they did that only for the discussion
that evening during one dinner-mit-chopsticks.
However, like so many "just for tonight" conventions,
it persisted, even down to today.
History is strange, when you get down into it, no?
Hope this helps.
David
(And today is only the 31st of March! ;-)
William D Clinger
> At the time FUNCTION crept in, the problem wasn't interpretation but
> compilation. One of the "revolutionary" ideas of Common Lisp was that
> the language would have the same semantics in the compiler as the
> interpreter, as surely you recall Drew, since you used Maclisp and
> know how it was prior.
In 1978, prior to Common Lisp, compiled and interpreted programs had
the same semantics in Scheme. This was one of the few "revolutionary"
ideas that Common Lisp took from Scheme.
Will
Kent M Pitman
That's a fair restatement, though probably the really right way to say it
is "... ideas of Steele ..." since it may have been the EQ idea in both
cases.
The more things change, the more they stay the same...
(let ((x (list 'a 'b 'c)))
(eq x (rplaca x 'd)))
It could have been Sussman's idea, though; in which case it would not be
the EQ idea... might be worth finding out, just for trivia.