I'm used to (quote x) evaluating to x, (quote (x y z)) evaluating to (x y z), and (car (quote (x y z)) evaluating to x. The reasoning is simple: quote is a special form that does not evaluate its argument, but simply returns it as is.
I just started using Racket, and it thinks that (quote x) evaluates to (quote x), (quote (x y z)) evaluates to (quote (x y z)), and (car (quote (x y z)) evaluates to (quote x).
Well, actually, it prints these as 'x, '(x y z), and 'x, respectively, but that's the same thing.
Can someone explain the reasoning here? If, for some reason, (quote (x y z)) evaluates to (quote (x y z)), shouldn't the car of that then be quote? Where does (quote x) come from?
As far as I can tell, Racket, throughout the entire computation, internally behaves just as I'm used to, except that when it comes time to print the final result, it wraps it in a quote form. Is this correct in all cases? And if so, why would it want to do that?
Racket evaluates the expressions in the same way as any Scheme. Racket however has in a special writer in the teaching languages. In DrRacket you can change the way values are printed. In the language menu, click the advanced button, and then take a look at the printing options.
Racket (language) prints out the result of top level forms, not only when entered in the interaction window (REPL), but always. It's to ease developing I guess and in real world applications you don't have statements that doesn't amount to anything so a real application wouldn't have these lines displayed since you have define and an expression to start your program and you could return (void) from it to force no output..
If you were to change language to either #!r6rs or #!r5rs you quickly see that the only way to get the result of an evaluation in the definitions window would be if you explicitly used display on the result.
No matter the language used, display displays it correctly. For a REPL-print the language and setting control how it displays. Standard #!racket is to display in such way that putting it in a new expression wrapped with display would print exactly the same as if you would have wrapped the original expression with display.
(define test 'hello-world)
(display test) ;; displays hello-world and not 'hello-world
test ;; displays 'hello-world in #!racket, nothing in R6RS unless in interactions window
Related
Ok, this is a fairly basic question: I am following the SICP videos, and I am a bit confused about the differences between define, let and set!.
1) According to Sussman in the video, define is allowed to attach a value to avariable only once (except when in the REPL), in particular two defines in line are not allowed. Yet Guile happily runs this code
(define a 1)
(define a 2)
(write a)
and outputs 2, as expected. Things are a little bit more complicated because if I try to do this (EDIT: after the above definitions)
(define a (1+ a))
I get an error, while
(set! a (1+ a))
is allowed. Still I don't think that this the only difference between set! and define: what is that I am missing?
2) The difference between define and let puzzles me even more. I know in theory let is used to bind variables in local scope. Still, it seems to me that this works the same with define, for instance I can replace
(define (f x)
(let ((a 1))
(+ a x)))
with
(define (g x)
(define a 1)
(+ a x))
and f and g work the same: in particular the variable a is unbound outside g as well.
The only way I can see this useful is that let may have a shorter scope that the whole function definition. Still it seems to me that one can always add an anonymous function to create the necessary scope, and invoke it right away, much like one does in javascript. So, what is the real advantage of let?
Your confusion is reasonable: 'let' and 'define' both create new bindings. One advantage to 'let' is that its meaning is extraordinarily well-defined; there's absolutely no disagreement between various Scheme systems (incl. Racket) about what plain-old 'let' means.
The 'define' form is a different kettle of fish. Unlike 'let', it doesn't surround the body (region where the binding is valid) with parentheses. Also, it can mean different things at the top level and internally. Different Scheme systems have dramatically different meanings for 'define'. In fact, Racket has recently changed the meaning of 'define' by adding new contexts in which it can occur.
On the other hand, people like 'define'; it has less indentation, and it usually has a "do-what-I-mean" level of scoping allowing natural definitions of recursive and mutually recursive procedures. In fact, I got bitten by this just the other day :).
Finally, 'set!'; like 'let', 'set!' is pretty straightforward: it mutates an existing binding.
FWIW, one way to understand these scopes in DrRacket (if you're using it) is to use the "Check Syntax" button, and then hover over various identifiers to see where they're bound.
Do you mean (+ 1 a) instead of (1+ a) ? The latter is not syntactically valid.
Scope of variables defined by let are bound to the latter, thus
(define (f x)
(let ((a 1))
(+ a x)))
is syntactically possible, while
(define (f x)
(let ((a 1)))
(+ a x))
is not.
All variables have to be defined in the beginning of the function, thus the following code is possible:
(define (g x)
(define a 1)
(+ a x))
while this code will generate an error:
(define (g x)
(define a 1)
(display (+ a x))
(define b 2)
(+ a x))
because the first expression after the definition implies that there are no other definitions.
set! doesn't define the variable, rather it is used to assign the variable a new value. Therefore these definitions are meaningless:
(define (f x)
(set! ((a 1))
(+ a x)))
(define (g x)
(set! a 1)
(+ a x))
Valid use for set! is as follows:
(define x 12)
> (set! x (add1 x))
> x
13
Though it's discouraged, as Scheme is a functional language.
John Clements answer is good. In some cases, you can see what the defines become in each version of Scheme, which might help you understand what's going on.
For example, in Chez Scheme 8.0 (which has its own define quirks, esp. wrt R6RS!):
> (expand '(define (g x)
(define a 1)
(+ a x)))
(begin
(set! g (lambda (x) (letrec* ([a 1]) (#2%+ a x))))
(#2%void))
You see that the "top-level" define becomes a set! (although just expanding define in some cases will change things!), but the internal define (that is, a define inside another block) becomes a letrec*. Different Schemes will expand that expression into different things.
MzScheme v4.2.4:
> (expand '(define (g x)
(define a 1)
(+ a x)))
(define-values
(g)
(lambda (x)
(letrec-values (((a) '1)) (#%app + a x))))
You may be able to use define more than once but it's not
idiomatic: define implies that you are adding a definition to the
environment and set! implies you are mutating some variable.
I'm not sure about Guile and why it would allow (set! a (+1 a)) but
if a isn't defined yet that shouldn't work. Usually one would use
define to introduce a new variable and only mutate it with set!
later.
You can use an anonymous function application instead of let, in
fact that's usually exactly what let expands into, it's almost
always a macro. These are equivalent:
(let ((a 1) (b 2))
(+ a b))
((lambda (a b)
(+ a b))
1 2)
The reason you'd use let is that it's clearer: the variable names are right next to the values.
In the case of internal defines, I'm not sure that Yasir is
correct. At least on my machine, running Racket in R5RS-mode and in
regular mode allowed internal defines to appear in the middle of the
function definition, but I'm not sure what the standard says. In any
case, much later in SICP, the trickiness that internal defines pose is
discussed in depth. In Chapter 4, how to implement mutually recursive
internal defines is explored and what it means for the implementation
of the metacircular interpreter.
So stick with it! SICP is a brilliant book and the video lectures are wonderful.
The book defines block structure in Chapter 1, allowing you to 'package' defines inside a procedure definition.
Consider this mean-square definition for example:
(define (mean-square x y)
(define (square x) (* x x))
(define (average x y) (/ (+ x y) 2))
(average (square x) (square y)))
when I run (mean-square 2 4) I correctly get 10.
My question is, are the internal definitions ( square and average in this toy case ) run each time I invoke the mean-square procedure via the interpreter? If so, isn't that inefficient? and if not, why?
If the code is somewhat naively compiled, there could be some overhead. The reason is that the inner functions are defined in a brand new lexical environment that is freshly instantiated on each entry into the function. In the abstract semantics, each time the function is called, new lexical closures have to be captured and wired into the correct spots in that environment frame.
Thus it boils down to how much of this can the compiler optimize away. For instance it can notice that neither of the functions actually references the surrounding lexical environment. (The x and y references in these functions are to their own parameters, not to those of the surrounding mean-square). Which means they both be moved to the top level without changing semantics:
(define (__anon1 x) (* x x))
(define (__anon2 x y) (/ (+ x y) 2))
(define (mean-square x y)
(define square __anon1)
(define average __anon2)
(average (square x) (square y)))
And since now square and average are effectively simple aliases (aliases for global entities that are generated by the compiler, which the compiler knows aren't being manipulated by anything outside of its control), the values they denote can be propagated through:
(define (mean-square x y)
(__anon2 (__anon1 x) (__anon1 y)))
It's not a problem. When the mean-square procedure is compiled, all the nested procedures are also compiled. It doesn't need to re-compile them every time you invoke the mean-square procedure.
I think the other answers have probably convinced you that the case you give really doesn't need to have any overhead: the local definitions can be just compiled away. But it's worth thinking about how a system might approach cases where this can't be done.
Consider a definition like this:
(define (make-searcher thing)
(define (search in)
(cond [(null? in)
#f]
[(eqv? (first in) thing)
in]
[else (search (rest in))]))
search)
Well, the local search procedure definitely can't be compiled away here, because it's returned from make-searcher. And it's even worse than that: (make-searcher 1) and (make-searcher 2) need to return different procedures, because ((make-searcher 1) '(1 2 3)) is (1 2 3) while ((make-searcher 2) '(1 2 3)) is (2 3).
So this sounds completely hopeless: the local search procedure not only has to be a procedure (it can't be compiled away), it has to be remade each time.
But in fact things are not nearly so bad. Lexical scope means that the system can know exactly what bindings are visible to search (in this case, a binding for thing as well as its argument). So what you can do, for instance, is compile a bit of code which looks up the values of these bindings in a vector. Then, the thing that is returned from make-search packs together the compiled code of search with a vector of bindings. The compiled code is always the same, only the vector needs to be created and initialised each time.
Imagine this code:
(let ((a expr))
(do-something-with a))
It is the same as:
((lambda (a)
(do-something-with a))
expr)
In an interpreter it might create the lambda each time before calling it while other
languages might turn it into (do-something-with expr). The report doesn't want to touch non functional requirements other than guaranteed tail recursion. In all the serious implementations lambdas are cheap.
Since you mention racket:
File test_com.rkt
#lang racket
(define (mean-square x y)
(define (square x) (* x x))
(define (average x y) (/ (+ x y) 2))
(average (square x) (square y)))
(display (mean-square 2 4))
Terminal commands:
raco make test_com.rkt
raco decompile compiled/test_com_rkt.zo
Resulting output:
(module test_com ....
(require (lib "racket/main.rkt"))
(provide)
(define-values
(mean-square)
(#%closed
mean-square49
(lambda (arg0-50 arg1-51)
'#(mean-square #<path:/home/westerp/compiled/test_com.rkt> 2 0 14 136 #f)
'(flags: preserves-marks single-result)
(/ (+ (* arg0-50 arg0-50) (* arg1-51 arg1-51)) '2))))
(#%apply-values print-values (display '10)) ; the only code that matters!
(void)
(module (test_com configure-runtime) ....
(require '#%kernel (lib "racket/runtime-config.rkt"))
(provide)
(print-as-expression '#t)
(void)))
While mean-square has got their local procedures inlined, because I gave it literal values it will never call it so all it does is (display '10) and then exit.
This is of course if you do make or exe. From DrRacket the language options that enabled debugging and better trace and error messages will run slower.
For what I know in functional languages is common to use lambda for referring to anonymous functions, but I do not see to be really useful to use:
(define square
(lambda (x) (* x x)))
instead of
(define (square x)
(* x x))
why is the first form used in almost all documents that I found regarding Scheme?
Thanks
I always use this syntax because it is explicit. lambda defines a function. Functions have no name. Then you assign this function to a variable. Variables have names. The form (define (f x) ...) is merely syntactic sugar for a very common case, but obscures the fact that scheme is a lisp-1.
I've been learning Scheme through the Little Schemer book and it strikes me as odd that a file in Scheme / Lisp isn't a list of statements. I mean, everything is supposed to be a list in Lisp, but a file full of statements doesn't look like a list to me. Is it represented as a list underneath? Seems odd that it isn't a list in the file.
For instance...
#lang scheme
(define atom?
(lambda (x)
(and (not (pair? x)) (not (null? x)))))
(define sub1
(lambda (x y)
(- x y)))
(define add1
(lambda (x y)
(+ x y)))
(define zero?
(lambda (x)
(= x 0)))
Each define statement is a list, but there is no list of define statements.
It is not, because there is no practical reasons for it. In fact, series of define statements change internal state of the language. Information about the state can be accessible via functions. For example , you can ask Lisp if some symbol is bound to a function.
There is no practical benefit in traversing all entered forms (for example, define forms). I suppose that this approach (all statements are elements of a list) would lead to code that would be hard to read.
Also, I think it not quite correct to think that "everything is supposed to be a list in Lisp", since there are also some atomic types, which are quite self-sufficient.
When you evaluate a form, if the form defines something, that definition is added to the environment, and that environment is (or can be) a single list. You can build a program without using files, by just typing definitions into the REPL. In Lisp as in any language, the program “lives” in the run-time environment, not the source files.
(define a 42)
(set! 'a 10)
(define a 42)
(define (symbol) 'a)
(set! (symbol) 10)
(define a (cons 1 2))
(set! (car a) 10)
I tried running them in DrScheme and they don't work. Why?
Think of set! is a special form like define which does not evaluate its first operand. You are telling the scheme interpreter to set that variable exactly how you write it. In your example, it will not evaluate the expression 'a to the word a. Instead, it will look for a variable binding named "'a" (or depending on your interpreter might just break before then since I think 'a is not a valid binding).
For the last set of expressions, if you want to set the car of a pair, use the function (set-car! pair val) which works just like any scheme function in that it evaluates all of its operands. It takes in two values, a pair and some scheme value, and mutates the pair so that the car is now pointing to the scheme value.
So for example.
>(define pair (cons 1 2))
>pair
(1 . 2)
>(set-car! pair 3)
(3 . 2)
Because the first argument of set! is a variable name, not an "lvalue", so to speak.
For the last case, use (set-car! a 10).
The issue is with (set! 'a 10), as you shouldn't be quoting the symbol a.
It sounds like you're trying to learn Scheme, and you don't know Lisp, yes? If so, I strongly recommend trying Clojure as an easier to learn Lisp. I failed to grasp the interaction between the reader, evaluation, symbols, special forms, macros, and so forth in both Common Lisp and Scheme because those things all seemed to interact in tangled ways, but I finally really understand them in Clojure. Even though it's new, I found Clojure documentation is actually clearer than anything I found for Scheme or CL. Start with the videos at http://clojure.blip.tv/ and then read the docs at clojure.org.