I will get an undefined function warning about f2 in SBCL with following code sample.
Is it possible that I can declare f2 first, like in C, to avoid the warning.
I Googled, without any clue.
(defun f ()
(print (f2)))
(defun f2 ()
(print "f2"))
If you use the function before you define it in a single compilation unit, e.g., the same file, then the compiler will not complain about the undefined function (plain load still may, so compile your code first!)
Otherwise, you can declaim ftype:
(declaim (ftype (function () t) f2)
meaning that f2 accepts no arguments and returns a single value of type t.
However, it makes much more sense to compile the file where you use the function while the definition is already loaded. You can (and should!) use asdf as a Lisp-specific make(1): specifying dependencies so that the compiler has the definitions of all the functions while it compiles their users.
If the functions are in the same file, a compiler won't give a warning.
Example SBCL:
bash-3.2$ sbcl
This is SBCL 1.3.10, an implementation of ANSI Common Lisp.
More information about SBCL is available at <http://www.sbcl.org/>.
SBCL is free software, provided as is, with absolutely no warranty.
It is mostly in the public domain; some portions are provided under
BSD-style licenses. See the CREDITS and COPYING files in the
distribution for more information.
* (compile-file "/tmp/order.lisp")
; compiling file "/private/tmp/order.lisp" (written 28 NOV 2016 12:14:37 PM):
; compiling (DEFUN F ...)
; compiling (DEFUN F2 ...)
; /tmp/order.fasl written
; compilation finished in 0:00:00.178
#P"/private/tmp/order.fasl"
NIL
NIL
* (load *)
T
*
You do not have to put functions into the same file in Common Lisp for them to be in the same compilation unit.
Doing this is an anti-pattern; large programs are, of course, constructed from modules, most of which call functions that are in another module. You cannot roll an entire program into a single physical module to avoid a warning about this.
Lisp has a mechanism by which a cluster of compiles is regarded as a single compilation unit: the with-compilation-unit macro:
(with-compilation-unit
(compile-file "file-f")
(compile-file "file-f2"))
If you use the ASDF build system, I seem to recall it does the with-compilation-unit under the hood for you, around all of the files of a system.
This approach will help eliminate those warnings which are deferred. That is to say, if the implementation warns about undefined identifiers, but defers doing so until the end of the compilation unit, then if you use this macro, the deferral is extended until the end of the total compilation unit spanning multiple files.
When warnings about undefined identifiers are deferred, the purpose is to eliminate those warnings. If the definition of a previously undefined function appears before the end of a translation unit, the warning can be suppressed. This macro allows a definition in one file to suppress a deferred warning in another file.
If an implementation doesn't defer warnings, then the macro will not help.
Just change the order of your defun's. First, define f2 and than f.
Related
defmacro is documented at http://clhs.lisp.se/Body/m_defmac.htm but the documentation is not entirely clear on exactly when things happen. By experiment with Clisp, I have found the following (assuming all macros and functions defined at top level):
Straight top-level code can only call macros and functions that have been defined earlier.
Code within a macro or function, or generated by a macro, can call any function it likes, including one define later (as expected from the need to support mutual recursion).
Code within a macro can only call a macro defined earlier than the calling site of the first macro.
Code generated by a macro can call a macro defined later.
Is it the case that Clisp is just following the specification, or is there any variation between implementations in this regard?
Is the exact intended set of rules, and the rationale behind them, documented anywhere?
You are asking about macro expansion - but I'd like to clarify how functions are handled first.
Pay attention to when the calls and the defines actually happens. In your second point you say code within a function can call a function that is defined later. This isn't strictly true.
In languages like C++ you declare and define functions and then compile your app. Ignoring inlining, templates, lambdas and other magic..., when compiling a function, the declarations of all other functions used by that function need to be present - and at link time, the compiled definitions need to be present - all before the program starts running. Once the program starts running, all functions are already fully prepared and ready to be called.
Now in Lisp, things are different. Ignore compilation for now - let's just think about an interpreted environment. If you run:
;; time 1
(defun a () (b))
;; time 2
(defun b () 123)
;; time 3
(a)
At time 1 your program has no functions.
The first defun then creates a function (lambda () (b)), and associates it with the symbol a. This function contains a reference to the symbol b, but at this point in time it is not calling b. a will only call b when a itself gets called.
So, at time 2 your program has one function, associated with the symbol a, but it has not been executed yet.
Now the second defun creates a function (lambda () 123), and associates it with the symbol b.
At time 3 your program has two functions, associated with the symbols a and b, but neither has been called yet.
Now you call a. During its execution, it looks for the function associated with the symbol b, finds that such a function already exists at this point in time, and calls it. b executes and returns 123.
Let's add more code:
;; time 4
(defun b () 456)
;; time 5
(a)
After time 4, a new defun creates a function returning 456, and associates it with the symbol b. This replaces the reference b was holding to the function returning 123, which will then be garbage collected (or whatever you implementation does to take out the trash).
Calling a (or more correctly, the lambda referenced by the function attribute of the symbol a), will now result in a call to a function that returns 456.
If, instead, we had originally written:
;; time 1
(defun a () (b))
;; time 2
(a)
;; time 3
(defun b () 123)
... this would not have worked, because after time 2 when we call a, it can't find a function associated with the symbol b and so it will fail.
Now - compile, eval-when, optimisation and other magic can do all kinds of funky things different from what I've described above, but make sure you first have a grasp of these basics before worrying about that more advanced stuff.
Functions are only created at the time that defun is called. (The interpreter doesn't "look ahead in the file".)
One of the attributes of a symbol is a reference to a function. (The function itself doesn't actually have a name.)
Multiple symbols can reference the same function. ((setf (symbol-function 'd) (symbol-function 'b)))
Defining a function a that calls function b (speaking colloquially), is OK as long as the symbol b has an associated function by the time a is called. (It is not required at the time of defunning a.)
A symbol can refer to different functions at different times. This affects any functions "calling" that symbol.
The rules for macros are different (their expansions are static after "read" time), but many of the principles remain the same (Lisp doesn't "look ahead in the file" to find them). Understand that Lisp programs are far more dynamic and "run-time" than most (lesser ;-) ) languages you may be used to. Understand what happens when during execution of a Lisp program, and the rules governing macro expansion will start making sense.
In the "Dictio" file, located at the link "Text-only console version" of this site, I've noticed a Lisp command (?) called defs.
I assume that this is something similar to defun, but am unable to find any information on what defs does; is it used to define a function, or maybe a variable? I am looking to reproduce this code using modern techniques and it would help to know the purpose of defs.
The defs calls seem to also include more than a name before the arguments (I would expect it to read (defs name () body).
Looking at the first function in the list, there appears to be more included in this "function definition" [the word 'features' specifically] and in the third function, there is ['semantics'] included after what appears to be the name of the function (before the arguments).
DEFS is defined by the software in the file SYSCOM.
It is a FEXPR, which is a function which gets the arguments unevaluated. Common Lisp has no such feature. It uses macros instead.
Example use:
(DEFS \#COLOR
FEXPR (LAMBDA (A)
(EVAL (SUBST (CAR A)
'COLOR
'(OBJECT
(MARKERS\: (\#PHYSOB COLOR)
PROCEDURE\: ((\#COLOR *** COLOR)))))))
PRIORITY 192.
SYS (\#PROPERTY))
Here you have a symbol #COLOR. It gets a function (actually a FEXPR) defined under this name. Also it puts a PRIORITY and SYS onto the property list of the symbol. Thus DEFS is used to define symbols with functions and properties in one defining form.
I have a code-base for a graphics program in cljx that gets compiled to Clojure and ClojureScript.
I now want to introduce my first macro.
(defmacro optional-styled-primitive [args body]
(let [extra (conj args 'style)]
`(fn (~extra (->SShape ~'style ~body))
(~args (->SShape {} ~body))
)
)
)
The purpose of this macro is to take a list of arguments, and an expression that uses those arguments to generate a geometry. And to return a function with two arities : one of which takes an optional style parameter. This macro is then to be used within the file where it's defined, to make a number of other functions that optionally take styles. For example :
(def square (optional-styled-primitive [n] [[0 0] [0 n] [n n] [n 0]]))
But introducing this macro, obviously, breaks the ClojureScript stage of the compilation.
What I can't figure out is what to do about it. The online discussions talk about ClojureScript needing to use :require-macros but I never actually export or require this macro anywhere. I just want to use it where it's defined. So how can I, in the middle of a file, tell the compiler to use Clojure to expand this macro, before it gets to the ClojureScript compiler?
OK.
I've made some progress with this.
Here's what I did.
1) I refactored my macro definition out into a separate file called macros.cljx
2) In the file where I was using the macros, I did this. (A different require for clj and cljs)
(#+clj :require #+cljs :require-macros
[myapp.macros :refer [optional-styled-primitive]])
3) I updated my leiningen project.clj file :
:cljsbuild {:builds [{
:source-paths ["target/classes" "src-cljs" ] ...
The important thing here I added "target/classes", which is the output-path where cljx puts the clj files it creates, to the cljsbuild source-paths. This is where the cljsbuild process can find the clj file with the macro definition.
I'm not sure if this is the right or principled way to solve the problem. But it now seems to be working (unless I'm confused by something).
I don't understand how Lisp can be compiled and dynamic. For a language to be able to manipulate and modify and generate code, isn't it a requirement to be interpreted? Is it possible for a language to be completely compiled and still be dynamic? Or am I missing something? What is Lisp doing that allows it to be both compiled and dynamic?
Lisp is a wide family of language and implementations.
Dynamic in the context of Lisp means that the code has a certain flexibility at runtime. It can be changed or replaced for example. This is not the same as dynamically typed.
Compilation in Lisp
Often Lisp implementations have a compiler available at runtime. When this compiler is incremental, it does not need whole programs, but can compile single Lisp forms. Then we say that the compiler supports incremental compilation.
Note that most Lisp compilers are not Just In Time compilers. You as a programmer can invoke the compiler, for example in Common Lisp with the functions COMPILE and COMPILE-FILE. Then Lisp code gets compiled.
Additionally most Lisp systems with both a compiler and an interpreter allow the execution of interpreted and compiled code to be freely mixed.
In Common Lisp the compiler can also be instructed how dynamic the compiled code should be. A more advanced Lisp compiler like the compiler of SBCL (or many others) can then generate different code.
Example
(defun foo (a)
(bar a 3))
Above function foo calls the function bar.
If we have a global function bar and redefine it, then we expect in Lisp usually that the new function bar will be called by foo. We don't have to recompile foo.
Let's look at GNU CLISP. It compiles to byte code for a virtual machine. It's not native machine code, but for our purpose here it is easier to read.
CL-USER 1 > (defun foo (a)
(bar a 3))
FOO
CL-USER 2 > (compile 'foo)
FOO
NIL
NIL
[3]> (disassemble #'foo)
Disassembly of function FOO
(CONST 0) = 3
(CONST 1) = BAR
1 required argument
0 optional arguments
No rest parameter
No keyword parameters
4 byte-code instructions:
0 (LOAD&PUSH 1)
1 (CONST&PUSH 0) ; 3
2 (CALL2 1) ; BAR
4 (SKIP&RET 2)
Runtime lookup
So you see that the call to BARdoes a runtime lookup. It looks at the symbol BAR and then calls the symbol's function. Thus the symbol table serves as a registry for global functions.
This runtime lookup in combination with an incremental compiler - available at runtime - allows us to generate Lisp code, compile it, load it into the current Lisp system and have it modify the Lisp program piece by piece.
This is done by using an indirection. At runtime the Lisp system looks up the current function named bar. But note, this has nothing to do with compilation or interpretation. If your compiler compiles foo and the generated code uses this mechanism, then it is dynamic. So you would have the lookup overhead both in the interpreted and the compiled code.
Since the 70s the Lisp community put a lot of effort into making the semantics of compiler and interpreter as similar as possible.
A language like Common Lisp also allows the compiler to make the compiled code less dynamic. For example by not looking up functions at run time for certain parts of the code.
For a language to be able to manipulate and modify and generate code, isn't it a requirement to be interpreted?
No.
Is it possible for a language to be completely compiled and still be dynamic?
Yes.
Or am I missing something?
Yes.
What is Lisp doing that allows it to be both compiled and dynamic?
It is compiled on the fly, just like most implementations of java, and PyPy.
It can be compiled and dynamic in the same time because it's late-bound. You can run a list of functions and arguments and then add something to it and then run it again. Basically each part of the code can be run not just entire functions.
I'm currently playing with lispbuilder-sdl on SBCL under Windows.
My source code is as follows:
(asdf:operate 'asdf:load-op :lispbuilder-sdl)
(asdf:operate 'asdf:load-op :lispbuilder-sdl-binaries)
(asdf:operate 'asdf:load-op :lispbuilder-sdl-examples)
(sdl-examples:squashed)
When I compile the file I get the error: package "SDL-EXAMPLES" not found.
If I remove the (sdl-examples:squashed) from the file it compiles ok. I can then type (sdl-examples:squashed) at the repl and the demo game starts fine.
Why is the sdl-examples package found from the repl but not when I compile the file?
All of the compilation of that file happens before executing any of the load-ops. So when Lisp compiles the (sdl-examples:squashed) line, it hasn't run the load-op that defines your package.
You can get around this by not mentioning the sdl-examples package that requires the reader to locate its squashed symbol before the load-op is actually executed:
(funcall (symbol-function (intern (symbol-name '#:squashed)
(find-package (symbol-name '#:sdl-examples)))))
The idea is to calculate the package from its symbolic name, lookup the symbol naming your function, and fetch the function it names - but this way requires that the package exist only when the code is run, not when it is first read. Then your four statements can all be compiled, executed in order, and by the time that last statement is executed, your load-ops will have created the package.
So here's a little more info about what's happening here:
Writing '#:some-name refers to a symbol that's not part of any package. So that way we can make a reference to a symbolic name without either (1) assuming its package exists or (2) mucking up some other package with the name.
Then '(symbol-name #:some-name) extracts the name of the symbol as a string. Why not just write "some-name"? You could, and it will usually work. But this way is a little more robust for the case of running a "modern-mode" case-sensitive Lisp.
The find-package maps a string name to Lisp's representation of a package. Remember, by the time you run this line, your package will exist.
intern returns the symbol with the given name that lives in the given package.
symbol-function returns the function object (a lambda abstraction, or more likely, its compiled representation) associated with the symbol.
And then funcall invokes that function.
It is kind of clunky, but unfortunately there's not really a better way to mix calls which load code to create a package with names living in that package in the same file.