freenode/#lisp - IRC Chatlog
Search
10:44:55
phoe
https://github.com/jrm-code-project/LISP-Machine seems like a trove of valuable source code
11:48:40
phoe
the non-#' form is preferable to use because some places in Lisp code do not accept the #' form
11:51:19
phoe
daphnis: it is not macroexpanded again because the FUNCTION special operator, here hidden behind the #' reader macro, treats LAMBDA expressions speially
11:51:50
phoe
when you write (function (lambda ...)) then the LAMBDA expression is not evaluated or macroexpanded
11:53:06
phoe
the symbol LAMBDA itself names a macro, but lambda expressions have special meaning in two contexts
11:53:34
phoe
first context, you can evaluate ((lambda (x) (* x x)) 3) where the lambda expression is the first element of that list
11:54:27
jackdaniel
I think that these "cases" fall in the same category when you pass multiple-value-list instead of #'multiple-value-list to some macros
11:54:32
phoe
the second context, it is understood in its own unique way by the special operator FUNCTION and the function COERCE when you try to coerce a lambda expression to a function object
11:55:42
phoe
jackdaniel: my approach is that if you generally write (lambda ...) you get stung 0% of the time, whereas if you generally write #'(lambda ...) then you get stung >0% of the time
11:56:16
jackdaniel
if you treat (lambda …) as any other function, then you don't need to make mental exceptions
11:56:24
phoe
so if I want to focus on more important tasks than remebering which variant to use, then I can safely always write (lambda ...)
11:58:37
jackdaniel
my point is that if you treat (lambda …) as any other function, then you put #' where you put #' before the symbol, and you're not putting it when you are not putting it before a symbol