I'm curious, because I never thought of #'(lambda ..) as ugly.  I just
get used to seeing that #' everywhere I expect a function argument.

Regards,
--
Nils Goesche
"Don't ask for whom the <CTRL-G> tolls."

  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.

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.

   http://ww.telent.net/cliki/Unicode%20Support

-dan

--

  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...

How about ``ls -F''?  Does that look fine to you?

Regards,
--
Nils Goesche
"Don't ask for whom the <CTRL-G> tolls."

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...

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

--

So, what are people using reader macro's for?

GB

  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.

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.

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.

(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)))