The definition is from src/code/array.lisp of sbcl. It looks like an infinite loop? I didn't find any clue to get it. Any hint? Thank you!
(defun row-major-aref (array index) |
#!+sb-doc |
"Return the element of array corressponding to the row-major index. This is |
SETF'able." |
(declare (optimize (safety 1))) |
(row-major-aref array index))
In src/compiler/array-tran.lisp you can also find this code:
(deftransform row-major-aref ((array index))
`(hairy-data-vector-ref array
(%check-bound array (array-total-size array) index)))
I'm not an expert in SBCL internals, but I assume that row-major-aref is treated by the compiler as the "basic" operation that is not reduced to other Lisp function calls, but rather transformed to machine code.
Related
I am trying to learn Common Lisp with the book Common Lisp: A gentle introduction to Symbolic Computation. In addition, I am using SBCL, Emacs, and Slime.
In the advanced section of chapter 8, the author presents the labels special function. Actually, he draws a contrast between defining things on top-level (main and helper functions) versus using label expression inside a function.
For instance, this would be a reverse list function with tail call using the top-level approach:
(defun reverse-top-level-helper (xs-left accu)
(cond ((null xs-left) accu)
(t (reverse-top-level-helper (cdr xs-left)
(cons (car xs-left)
accu)))))
(defun reverse-top-level-main (xs)
(reverse-top-level-helper xs nil))
On the other hand, the code below would do the same using labels:
(defun reverse-labels (xs)
(labels ((aux-label (xs-left accu)
(cond ((null xs-left) accu)
(t (aux-label (cdr xs-left)
(cons (car xs-left) accu))))))
(aux-label xs nil)))
So, the label approach avoids the chance that people will mess-up with the helper function on the top-level. Differently from the top level approach, the label way gives access to the local variables of the main function.
Unfortunately, according to the author, there is no way to trace functions inside label expressions in most lisp implementations. This seems to be my case since I get this from the REPL:
CL-USER> (trace aux-label)
WARNING: COMMON-LISP-USER::AUX-LABEL is undefined, not tracing.
NIL
The point that intrigues me is the fact that the author does not show a third approach that is quite common in Racket. I will call it nested defuns.
The same problem would be solved as:
(defun reverse-racket-style (xs)
(defun aux (xs-left accu)
(cond ((null xs-left) accu)
(t (aux (cdr xs-left) (cons (car xs-left) accu)))))
(aux xs nil))
In this approach the helper function can access the local variables from the main function. It can also be traced by the REPL.
I have been using it all day. So I know it works in a file with many functions using it. Actually, I do not even know how trace works so well considering that I am using a bunch of different helper functions and all of them have the same name being called aux under the racket style. The trace knows which aux I wanna see.
Above all, this omission really intrigues me. Specially because I am really enjoying the book. I guess I am probably missing something.
1 - Why this approach was not mentioned? Is this "racket style" with nested defuns considered bad style in Common Lisp?
2 - Did I miss some important detail (e.g. this approach could be the source of hard to find bugs or generate performance issues)?
3 - Is there some historical reason for this omission?
Yes, there are good reasons. In Racket, we have define
In an internal-definition context, a define form introduces a local binding; see Internal Definitions. A the top level, the top-level binding for id is created after evaluating expr
So, as you said, a define in a local context (such as a function body) defines a local function, with access to the enclosing variables and which only exists during that function.
Now compare that to Common Lisp's defun
Defines a new function named function-name in the global environment.
So, regardless of where a defun appears, it always defines a name at the global scope, with no access to local variables and with a name that becomes globally available. So your suggestion for a nested defun is really equivalent to defining the defun at the top-level (in the sense that the name is available at the top-level and in the sense that local variables are inaccessible), except that the name doesn't exist until you've called the original function at least once, which is, frankly, fairly unintuitive behavior.
Incidentally, the labels approach is the thing you want. In Common Lisp, if we want local helper functions, we use flet (for non-recursive functions) or labels (for recursive functions).
As to why this is, Common Lisp tries to enforce a very clear variable scope at all times. In any function, local variables are introduced with (let ...) and only exist inside of the block, and local functions are introduced with (flet ...) and (labels ...). Racket has similar constructs but also allows the more Scheme-like paradigm (Racket is a Scheme dialect, after all) of using define to define local variables for the rest of the current scope, similar to how you'd do it in more imperative languages.
Don't write nested defuns.
Writing nested defuns is usually a mistake. defun (and most other defsomething operators) are thought to be used at top-level. Top-level usually means as a top-most expression or nested only in prognor eval-when. Then a file compiler will recognize these macros.
As a nested function, the compiler does not recognize a defun. Calling the outer function will define the inner function on each call and globally.
Example:
(defun foo ()
(defun bar ()
20))
(defun baz ()
(defun bar ()
30))
Now do:
(bar) ; -> error undefined function BAR
(foo)
(bar) ; -> 20
(baz)
(bar) ; -> 30
(foo)
(bar) ; -> 20
(baz)
(bar) ; -> 30
...
Oops! The global function BAR gets overwritten on each call of FOO and of BAZ.
Nested functions
Use FLET and LABELS for defining local functions.
DEFUN does not define local lexical functions. It defines global functions with symbols as their names.
CL-USER 77 > (defun one ()
(defun two ()
40))
ONE
CL-USER 78 > (fboundp 'two)
NIL
CL-USER 79 > (one)
TWO
CL-USER 80 > (fboundp 'two)
T
Tracing local functions
(trace aux-label)
Above is typically not how one traces local functions. That syntax traces global functions.
To trace local functions consult the manual of your Lisp implementation for the documentation of the trace macro. It may support tracing local functions, but then has a special syntax for doing so.
If you need to trace, labels can be annoying to use. Here is a little helper macro that defines labels*, a variant of labels that traces the execution of the functions being called.
Here is the function printing the trace:
(defun depth-trace (io depth name args)
(let ((*standard-output* *trace-output*))
(fresh-line)
(dotimes (i depth) (princ (case io (:in "| ") (:out ": "))))
(format t "~a. ~a ~s~%" depth name args)))
The macro uses alexandria:with-gensyms, defines a local special depth variable that keep tracks of recursion levels, and add side-effects to the defined functions to print the trace.
(defmacro labels* ((&rest bindings) &body body)
(alexandria:with-gensyms ($depth $result $args)
(loop
with special = `(declare (special ,$depth))
for (name args . fn-body) in bindings
collect `(,name (&rest ,$args)
,special
(depth-trace :in ,$depth ',name ,$args)
(let ((,$result
(multiple-value-list
(let ((,$depth (1+ ,$depth)))
,special
(apply (lambda (,#args) ,#fn-body) ,$args)))))
(depth-trace :out ,$depth ',name ,$result)
(values-list ,$result)))
into labels-bindings
finally
(return
`(let ((,$depth 0))
,special
(labels ,labels-bindings ,#body))))))
For example:
(labels* ((a (b) (if (> b 0) (* 2 (a (- b 2))) (- b))))
(a 11))
This prints:
0. A (11)
| 1. A (9)
| | 2. A (7)
| | | 3. A (5)
| | | | 4. A (3)
| | | | | 5. A (1)
| | | | | | 6. A (-1)
: : : : : : 6. A (1)
: : : : : 5. A (2)
: : : : 4. A (4)
: : : 3. A (8)
: : 2. A (16)
: 1. A (32)
0. A (64)
It also works with mutually recursive functions:
(labels* ((a (x) (* x (b x)))
(b (y) (+ y (c y)))
(c (z) (if (> z 0) (* 2 z) (a (- z)))))
(a -5))
The trace is:
0. A (-5)
| 1. B (-5)
| | 2. C (-5)
| | | 3. A (5)
| | | | 4. B (5)
| | | | | 5. C (5)
: : : : : 5. C (10)
: : : : 4. B (15)
: : : 3. A (75)
: : 2. C (75)
: 1. B (70)
0. A (-350)
I've been trying to write a recursive loop in clojure that will print me out the very last number in the list. The point is not that I need to get the last number (for which I'm sure there's a built in function for that) but that I want to better understand recursion and macros in clojure. So I have this macro...
(defmacro loop-do [the-list]
`(if (= (count '~the-list) 1)
(println (first '~the-list))
(loop-do (rest '~the-list))))
But I get a stackoverflow error. What am I doing wrong?
How will people use your macro?
Somewhere, someone will call:
(loop-do list)
As a piece of code, those are only two symbols in a list. The first one is recognized as your macro, and the second one, list, is a symbol that represents a variable that will be bound at runtime. But your macro only knows that this is a symbol.
The same goes for:
(loop-do (compute-something))
The argument is a form, but you do not want to get the last element of that form, only the last element of the list obtained after evaluating the code.
So: you only know that in your macro, the-list will be bound to an expression that, at runtime, will have to be a list. You cannot use the-list as-if it was a list itself: neither (count 'list) nor (count '(compute-something)) does what you want.
You could expand into (count list) or (count (compute-something)), though, but the result would only be computed at runtime. The job of the macro is only to produce code.
Recursive macros
Macros are not recursive: they expand into recursive calls.
(and a b c)
might expand as:
(let [a0 a] (if a0 a0 (and b c)))
The macroexpansion process is a fixpoint that should terminate, but the macro does not call itself (what would that mean, would you expand the code while defining the macro?). A macro that is "recursive" as-in "expands into recursive invocations" should have a base case where it does not expand into itself (independently of what will, or will not, happen at runtime).
(loop-do x)
... will be replaced by:
(loop-do (rest 'x))
... and that will be expanded again.
That's why the comments say the size actually grows, and that's why you have a stackoverflow error: macroexpansion never finds a fixpoint.
Debugging macros
You have a stackoverflow error. How do you debug that?
Use macroexpand-1, which only performs one pass of macroexpansion:
(macroexpand-1 '(loop-do x))
=> (if (clojure.core/= (clojure.core/count (quote x)) 1)
(clojure.core/println (clojure.core/first (quote x)))
(user/loop-do (clojure.core/rest (quote x))))
You can see that the generated code still contains a call to usr/loop-do , but that the argument is (clojure.core/rest (quote x)). That's the symptom you should be looking for.
I'm looking for a simple way to return a new structure which is a copy of an existing one with some fields changed, without modifying the original.
I get that you can use setf to change the data in one of the fields, like so:
[1]> (defstruct foo bar)
FOO
[1]> (defvar quux (make-foo :bar 12))
QUUX
[1]> (foo-bar quux)
12
[1]> (setf (foo-bar quux) 15)
15
[1]> (foo-bar quux)
15
But as I stated, this essentially destroys the original data, which isn't what I'm going for.
I could of course do something like this:
(defstruct foo bar baz) ; define structure
(defvar quux (make-foo :bar 12 :baz 200)) ; make new instance
(defvar ping (copy-foo quux)) ; copy instance
(setf (foo-bar ping) 15) ; change the bar field in ping
But it seems more like a work-around than anything.
In Erlang you can do something like this:
-record(foo, {bar, baz}). % defines the record
example() ->
Quux = #foo{bar = 12, baz = 200}, % creates an instance of the record
Ping = Quux#foo{bar = 15}. % creates a copy with only bar changed
No data modified.
PS Yes I'm aware that Common Lisp isn't Erlang; but Erlang made it convenient to work with records/structures immutably, and since functional style is encouraged in Common Lisp, it would be nice if there was a similar option available.
Erlang records are similar to Prolog structures. The Prolog I know implements this as a predicate named update_struct/4 which admits a macro expansion: it takes a type parameter and expands into two unifications. The same kind of processing is done in Erlang, according to the documentation. In Common Lisp, we don't need to pass the type explicitly, as shown with the following update-struct function:
(defun update-struct (struct &rest bindings)
(loop
with copy = (copy-structure struct)
for (slot value) on bindings by #'cddr
do (setf (slot-value copy slot) value)
finally (return copy)))
Example
CL-USER> (defstruct foo bar baz)
FOO
CL-USER> (defparameter *first* (make-foo :bar 3))
*FIRST*
CL-USER> (defparameter *second* (update-struct *first* 'baz 2))
*SECOND*
CL-USER> (values *first* *second*)
#S(FOO :BAR 3 :BAZ NIL)
#S(FOO :BAR 3 :BAZ 2)
Specification
Rainer Joswig kindly pointed out that:
There is one thing which is undefined by the standard: using SLOT-VALUE on structure objects is undefined. But it should work on most implementations, as they provide this feature. The only implementation where it does not seem to work is GCL.
Indeed, the HyperSpec says about SLOT-VALUE:
Note in particular that the behavior for conditions and structures is not specified.
An implementation might behave differently if the structured is backed by a list or vector (see the ̀:TYPE option). Anyway, if you need to be portable you'd better use classes.
This topic was also explained in detail by Rainer in common lisp: slot-value for defstruct structures.
Other immutable data-structures
Consider also using property lists, which play nicely with an immutable approach.
Say your initial list x is:
(:a 10 :b 30)
Then (list* :b 0 x) is the following list:
(:b 0 :a 10 :b 30)
... where the most recent value associated with :b shadows the ones after (see GETF).
Loop details
The bindings list is a property list, with alternation of keys and values (like keyword parameters).
In the LOOP expression above, I am iterating over the list of bindings using ON, which means that I am considering each sublist instead of each element. In other words (loop for x on '(a b c d)) successively binds x to (a b c d), (b c d), (c d) and finally (c).
However, since I provide a custom BY argument, the next element is computed using CDDR, instead of the default CDR (so, we advance by two cells instead of by one).
That allows me to consider each pair of key/value elements in the list, and bind them to slot and value thanks to the destructuring syntax.
Why there is no syntax sugar for funcall? We need it a lot. Won't it be great to write something like (&#do-something arg0 arg1 arg2) instead of (funcall do-something arg0 arg1 arg2) Why not add something like Ruby's &:method notation? Is there something already in the language?
There's nothing like that built into the language; you can easily assign the function to an additional name though, and use that. E.g., if you want to use &, you can:
CL-USER> (setf (symbol-function '&) (symbol-function 'funcall))
#<FUNCTION FUNCALL>
CL-USER> (&'list 1 2 3)
(1 2 3)
CL-USER> (&'cons 'x 'y)
(X . Y)
(There was a recent question on Stack Overflow about different ways to do that first line: How to stop evaluating lisp form when passed as function parameter?.)
Won't it be great to write something like (&#do-something arg0 arg1 arg2) instead of (funcall do-something arg0 arg1 arg2)?
Probably not. Common Lisp is a language that prefers expressive names for functions and macros. The name funcall is recognized, and it makes it clear that there's an indirect function call happening. Why would we want to obscure that? Evidently most people find funcall has the right balance between "short enough to write" and "long enough to be descriptive".
Why there is no syntax sugar for funcall?
You might call macros "syntax sugar" in Common Lisp, but there's no need for it here. Funcall is a function, not a special form or macro, so it's really very easy to alias it with another name, as shown above. The fact that most people don't do this should say something about how desirable it is.
There is no syntax for funcall, because we don't need it a lot (or else, define "we"). I mean, in a Lisp-2, such as Common Lisp, that's the trade-off, and unless you're doing some heavy lambda calculus, you get used to it.
If you really want to use a more succint syntax, you can define a dispatch macro character:
(set-dispatch-macro-character
#\# #\&
#'(lambda (stream subchar arg)
(let ((args-var (gensym)))
`(lambda (&rest ,args-var)
(declare (dynamic-extent ,args-var))
(apply ,(read stream t nil t) ,args-var)))))
(let ((my-function #'max))
(#&my-function 1 3 2))
Check if your compiler will optimize lambda forms and dynamic-extent &rest arguments passed to apply.
I advise against defining the single character & as a macro character, because it's a constituent character mostly used in the symbols &optional, &rest, &key, &allow-other-keys, &aux, &whole, &body and &environment.
If you're inclined to black magic:
(defun black-magic (stream sub-char numarg)
(declare (ignore sub-char numarg))
`(funcall ,#(read stream)))
(set-dispatch-macro-character
#\# #\! #'black-magic)
Rough example:
CL-USER> (defun foo (fn x y z)
#!(fn x y z))
FOO
CL-USER> (foo #'* 1 2 3)
6
CL-USER> (foo #'+ 1 1 1)
3
(It's better to use apply however... but it's even better to keep things simple and use nothing of this sort.)
Of couse we anyone can define something like that by reader macros, but i think it's not a very good idea to do such thing if you expecting than someone will read your code somtime.
Actually this sort of reader macro is syntactic sugar you're asking for. Do you reject your own idea now? Every time, when you use non-conventional syntactic sugar, you probably make things worse for your future code-readers.
This is with SBCL 1.0.55 on Debian squeeze. I'm probably missing something obvious, but I'm a beginner, so please bear with me.
CL-USER> (defparameter x 0)
CL-USER> (case x (t 111) )
111
So it looks like case here is matching the variable x with the truth symbol t. This happens with everthing I've tried; this x is just an example. I don't see why this would happen. Since case uses eql for matching, I tried
CL-USER> (eql x t)
NIL
So, eql does not match x and t. What am I missing? Thanks in advance.
Described in the CASE documentation.
otherwise-clause::= ({otherwise | t} form*)
The syntax says that an otherwise clause is either (otherwise form-1 ... form-n) or (t form-1 ... form-n). Note that the syntax says {otherwise | t}. The vertical bar is an OR in a syntax specification. So the marker for an otherwise clause is either otherwise or t.
That means, if your case clause begins with otherwise or t, then we have an otherwise-clause.
In the case construct in Common Lisp, t, used by itself, is equivalent to default in C; that is, it's evaluated if the expression doesn't match any of the other cases. If you want to match the actual symbol t, use (t) instead.