4 ms·

> ‘foo isn’t a function in CL. But in emacs lisp, it might be. In Common Lisp it might be. CL-USER 72 > (funcall (first '(sin cos)) pi) 1.224606353822377

by lispm 7y ago

> ‘foo isn’t a function in CL. But in emacs lisp, it might be. In Common Lisp it might be. CL-USER 72 > (funcall (first '(sin cos)) pi) 1.2246063538223773D-16 In Common Lisp all symbols denoting functions can be called via FUNCALL and APPLY. Thus one can also pass symbols for functions to higher order functions like MAPCAR: CL-USER 73 > (mapcar 'sin '(12 34 56)) (-0.53657294 0.5290827 -0.521551) CL-USER 75 > (mapcar (lambda (f arg) (funcall f arg)) '(sin cos tan) '(1.3d0 1.4d0 1.5d0)) (0.963558185417193D0 0.16996714290024104D0 14.101419947171719D0) CL-USER 76 > (mapcar 'funcall '(sin cos tan) '(1.3d0 1.4d0 1.5d0)) (0.963558185417193D0 0.16996714290024104D0 14.101419947171719D0) A restriction of Common Lisp is that local lexical functions can't be called via symbols. But anything defined by DEFUN, DEFMETHOD, DEFGENERIC uses symbols as names and those can be used by FUNCALL and APPLY. > basics like (require ‘foo) leaves much to be desired. REQUIRE isn't much used in Common Lisp in the last decades. Individual implementations may still support it as a calling interface to some more complex machinery to locate code. Much of the current code uses ASDF to describe and load code files.

sillysaurusx 7y ago
Heh. You’re right of course. Thank you for correcting me. I was going to retract most of my criticism due to being blatantly mistaken. But, the namespace thing is actually the part that seems like it would cause the most friction for CL as a configuration language. Specifically: in emacs lisp, if you write ‘foo-frobber, you know it’s probably from the package ‘foo, and that it’s a frobber. Whether it’s a function or a variable can often be inferred correctly from context. Whereas in CL, isn’t the norm to use the package system everywhere? (Perhaps I am mistaken about this as well.) So you can’t just pass ‘foo-frobber to arbitrary packages and expect it to work. For example, (intern “foo-frobber”) returns a symbol. (Or does it? Now I’m second guessing everything I thought I remembered about CL.) But can you just pass that plain old symbol between packages without having to explicitly indicate its origin? Hmmm... now that I’ve talked through the problem, perhaps the namespace issue isn’t such a big deal. Maybe the friction was moreso ASDF’s peculiarities rather than the fundamental behaviors of CL.
- lispm 7y ago
  > in emacs lisp, if you write ‘foo-frobber, you know it’s probably from the package ‘foo, and that it’s a frobber. It's a convention, not an actual mechanism. But it's open to interpretations. What does ANIMATED-WINDOW-DRAW mean? Is it supposed to be WINDOW-DRAW in the ANIMATED 'package' or is it DRAW from the ANIMATED-WINDOW package? Probably there is another convention for that. Note then that in Emacs Lisp the concept package means a software library, where in Common Lisp the concept package means a symbol namespace. > Whereas in CL, isn’t the norm to use the package system everywhere? It's widely used, but in slightly different ways. Some use it as a poor module system replacement. Often it is used a way to structure code into larger symbol namespaces. Sometimes you'll find code bases which do everything in one package. > So you can’t just pass ‘foo-frobber to arbitrary packages and expect it to work. 'Passing to packages' is not a concept in Common Lisp. But you can use symbols from all packages everywhere. There is no enforced hiding mechanism or module system which hides things. The only thing packages actually do is being a namespace for symbols. Thus it is possible to have many symbols with the same name, but they need to be in different packages or need to belong to no package. > For example, (intern “foo-frobber”) returns a symbol. It does. It uses at runtime the package bound to the current package to intern the symbol. The current package is the value of the symbol *package* > But can you just pass that plain old symbol between packages without having to explicitly indicate its origin? You can pass the symbol around. Its package can be queried. If you want to refer to the symbol in written code while being in another package (another symbol namespace) one has four options: 1) use the symbol fully qualified FOO::BAR. Note the two colons. 2) use exported symbols as FOO:BAR. Note the one colon. 3) use the symbol after importing it into the current package as BAR. 4) programmatically lookup the symbol: (find-symbol "BAR" "FOO")
  - TeMPOraL 7y ago
    There's only one problem[0] that could bite someone used to the way elisp code is written: when the reader sees e.g. FOO:BAR, or FOO::BAZQUUX, the package FOO must already exist (and AFAIK have BAR exported), otherwise you'll get a reader error. You can't work around it with regular macros, because the error is at read-time, way before macroexpansion-time or compile-time. This shows up whenever you need to set up some functions using a package before the code defining that package is loaded. This might be a rare use case in general, but it's something that shows up frequently enough when configuring Emacs. The only workaround for CL that I know is programmatic lookup of the symbol via FIND-SYMBOL, or just keeping the problematic code as string and running it through (EVAL (READ-FROM-STRING ...)) when it's safe for reader to parse it. Since Elisp doesn't have a package system, the problem doesn't exist there; at worst you'll get a warning from the byte compiler/interpreter that it doesn't (yet) know what variable or function a symbol represents. -- [0] - Or at least what I believe to be a problem; I'm half-hoping there's a trivial solution that I'm missing.

by lispm 7y ago

sillysaurusx 7y ago

Heh. You’re right of course. Thank you for correcting me. I was going to retract most of my criticism due to being blatantly mistaken. But, the namespace thing is actually the part that seems like it would cause the most friction for CL as a configuration language. Specifically: in emacs lisp, if you write ‘foo-frobber, you know it’s probably from the package ‘foo, and that it’s a frobber. Whether it’s a function or a variable can often be inferred correctly from context. Whereas in CL, isn’t the norm to use the package system everywhere? (Perhaps I am mistaken about this as well.) So you can’t just pass ‘foo-frobber to arbitrary packages and expect it to work. For example, (intern “foo-frobber”) returns a symbol. (Or does it? Now I’m second guessing everything I thought I remembered about CL.) But can you just pass that plain old symbol between packages without having to explicitly indicate its origin? Hmmm... now that I’ve talked through the problem, perhaps the namespace issue isn’t such a big deal. Maybe the friction was moreso ASDF’s peculiarities rather than the fundamental behaviors of CL.

lispm 7y ago
> in emacs lisp, if you write ‘foo-frobber, you know it’s probably from the package ‘foo, and that it’s a frobber. It's a convention, not an actual mechanism. But it's open to interpretations. What does ANIMATED-WINDOW-DRAW mean? Is it supposed to be WINDOW-DRAW in the ANIMATED 'package' or is it DRAW from the ANIMATED-WINDOW package? Probably there is another convention for that. Note then that in Emacs Lisp the concept package means a software library, where in Common Lisp the concept package means a symbol namespace. > Whereas in CL, isn’t the norm to use the package system everywhere? It's widely used, but in slightly different ways. Some use it as a poor module system replacement. Often it is used a way to structure code into larger symbol namespaces. Sometimes you'll find code bases which do everything in one package. > So you can’t just pass ‘foo-frobber to arbitrary packages and expect it to work. 'Passing to packages' is not a concept in Common Lisp. But you can use symbols from all packages everywhere. There is no enforced hiding mechanism or module system which hides things. The only thing packages actually do is being a namespace for symbols. Thus it is possible to have many symbols with the same name, but they need to be in different packages or need to belong to no package. > For example, (intern “foo-frobber”) returns a symbol. It does. It uses at runtime the package bound to the current package to intern the symbol. The current package is the value of the symbol *package* > But can you just pass that plain old symbol between packages without having to explicitly indicate its origin? You can pass the symbol around. Its package can be queried. If you want to refer to the symbol in written code while being in another package (another symbol namespace) one has four options: 1) use the symbol fully qualified FOO::BAR. Note the two colons. 2) use exported symbols as FOO:BAR. Note the one colon. 3) use the symbol after importing it into the current package as BAR. 4) programmatically lookup the symbol: (find-symbol "BAR" "FOO")
- TeMPOraL 7y ago
  There's only one problem[0] that could bite someone used to the way elisp code is written: when the reader sees e.g. FOO:BAR, or FOO::BAZQUUX, the package FOO must already exist (and AFAIK have BAR exported), otherwise you'll get a reader error. You can't work around it with regular macros, because the error is at read-time, way before macroexpansion-time or compile-time. This shows up whenever you need to set up some functions using a package before the code defining that package is loaded. This might be a rare use case in general, but it's something that shows up frequently enough when configuring Emacs. The only workaround for CL that I know is programmatic lookup of the symbol via FIND-SYMBOL, or just keeping the problematic code as string and running it through (EVAL (READ-FROM-STRING ...)) when it's safe for reader to parse it. Since Elisp doesn't have a package system, the problem doesn't exist there; at worst you'll get a warning from the byte compiler/interpreter that it doesn't (yet) know what variable or function a symbol represents. -- [0] - Or at least what I believe to be a problem; I'm half-hoping there's a trivial solution that I'm missing.