I'm trying to implement higher level functions in my Racket code, specifically with regards to this function:
(define (indivisible e L)
(map (remove 0 ((map ((lambda (x y) (modulo x y))) L e)))))
Essentially, I'm trying to remove all the elements that are divisible by e from the list. However, it keeps giving me an error that says that "the expected number of arguments did not match the given number (0 vs 2)". Why is this so?
Several places you have two sets of parentheses. Unless the parentheses are a part of a special form or macro, eg. let, it represent an application. Ie.
((lambda (x y) (modulo x y)))
Here the form (lambda ...) is evaluated and become a function. The second set of parentheses calls this function with no arguments. Since you have two arguments, x and y and not supplying any in your application it signals an error.
Another place where you do the same is around (map ....). Since I know map always evaluates to a list or null it looks kind of strange that you call it as a function ((map ...)).
If you are more familiar with algol languages like python, what you are doing is like someFunc(arg1 args2)() where you clearly see someFunc needs to return a function wince it's immediately called afterwards. The same in Scheme looks like ((some-func arg1 arg2)).
remove removes the first argument from the second argument list. It does not return a function so the outer map won't work.
To solve this I think you are looking for filter. You only need to make a predicate that is #f for the elements you don't want and you're done.
Related
I have a function that will simplify something like:
(or x false) => x
Then function definition takes in the unevaluated expression as its parameter.
I am trying to nest my input like this now:
(or x (and true))
Everywhere I look I see articles about flattening nested input, but that won't work in this case because of the logical operator at the beginning of each list so the innermost list must be processed first, with the result being sent to the next outer list as an argument.
I know I need to call my function within it's own body with the result of the innermost list until I reach the outermost list, but I'm not sure of the way to go about that or what to research in Clojure on how to to this.
What you are describing is nearly exactly the semantics of expression evaluation in clojure :-) so the brief answer would be to run the code :-D though i suspect you are looking for a more interesting answer.
Here is a simple recursive version that works by
recursively simplify each nested expression
apply the simplification rules to the existing expression
This uses an overly-simple rule just as an example:
user> (defn my-eval [e]
(let [expanded-form (if (seq? e)
(map (fn [i]
(if (seq? i) ;; if this is a sequence,
(my-eval i) ;; eval the sequence and include the result here
i)) ;; otherwise use the value unchanged.
e)
e)] ;; if it's not a seq with something in it, leve it unchanged
(if (and
(seq? expanded-form)
(= (first expanded-form) 'or)
(= 2 (count (remove false? expanded-form))))
(second (remove false? expanded-form))
expanded-form)))
#'user/my-eval
First a base case test:
user> (my-eval '(or x (or y false)))
(or x y)
Then with a little recursion:
user> (my-eval '(or (or x false) (or y false)))
(or x y)
For Racket programming language, why is lambda not considered a function?
For example, it can't be defined as a higher order function like this.
(define (my-lambda args body)
(lambda args body))
There's a key distinction that your question is missing:
lambda is syntax.
Procedures are values.
A lambda form is a form of expression whose value is a procedure. The question whether "lambda is a function" starts off with a type error, so to speak, because lambdas and procedures don't live in the same world.
But let's set that aside. The other way to look at this is by thinking of it in terms of evaluation rules. The default Scheme evaluation rule, for the application of a procedure to arguments, can be expressed in pseudo-code like this:
(define (eval-application expr env)
(let ((values
;; Evaluate each subexpression in the same environment as the
;; enclosing expression, and collect the result values.
(map (lambda (subexpr) (eval subexpr env))
expr)))
;; Apply the first value (which must be a procedure) to the
;; other ones in the results.
(apply (car values) (cdr values))))
In English:
Evaluate all of the subexpressions in the same environment as the "parent".
apply the first result (which must have evaluated to a procedure) to the list of the rest.
And now, another reason lambda can't be a procedure is that this evaluation rule doesn't work for lambda expressions. In particular, the point of lambda is to not evaluate its body right away! This, in particular, is what afflicts your my-lambda—if you try to use it this way:
(my-lambda (x) (+ x x))
...the (x) in the middle must be immediately evaluated as an invocation of a procedure named x in the environment where the whole expression appears. The (+ x x) must also be immediately evaluated.
So lambda requires its own evaluation rule. As Basile's answer points out, this is normally implemented as a primitive in the Scheme system implementation, but we can sketch it in pseudocode with something like this:
;;;
;;; Evaluate an expression of this form, returning a procedure:
;;;
;;; (lambda <formals> <body> ...)
;;;
(define (eval-lambda expr env)
(let ((formals (second expr))
(body (cddr expr)))
;; We don't evaluate `body` right away, we return a procedure.
(lambda args
;; `formals` is never evaluated, since it's not really an
;; expression on its own, but rather a subpart that cannot
;; be severed from its enclosing `lambda`. Or if we want to
;; say it all fancy, the `formals` is *syncategorematic*...
(let ((bindings (make-bindings formals args)))
;; When the procedure we return is called, *then* we evaluate
;; the `body`--but in an extended environment that binds its
;; formal parameters to the arguments supplied in that call.
(eval `(begin ,#body) (extend-environment env bindings))))))
;;;
;;; "Tie" each formal parameter of the procedure to the corresponding
;;; argument values supplied in a given call. Returns the bindings
;;; as an association list.
;;;
(define (make-bindings formals args)
(cond ((symbol? formals)
`((,formals . args)))
((pair? formals)
`((,(car formals) . ,(car args))
,#(make-bindings (cdr formals) (cdr args))))))
To understand this pseudocode, the time-tested thing is to study one of the many Scheme books that demonstrate how to build a meta-circular interpreter (a Scheme interpreter written in Scheme). See for example this section of Structure and Interpretation of Computer programs.
lambda needs to be a core language feature (like if, let, define are) in Scheme because it is constructing a closure so needs to manage the set of closed or free variables (and somehow put their binding in the closure).
For example:
(define (translate d) (lambda (x) (+ d x)))
When you invoke or evaluate (translate 3) the d is 3 so the dynamically constructed closure should remember that d is bound to 3. BTW, you generally want the result of (translate 3) and of (translate 7) be two different closures sharing some common code (but having different bindings for d).
Read also about λ-calculus.
Explaining that all in details requires an entire book. Fortunately, C. Queinnec has written it, so read his Lisp In Small Pieces book.
(If you read French, you could read the latest French version of that book)
See also the Kernel programming language.
Read also wikipage about evaluation strategy.
PS. You could, and some Lisp implementations (notably MELT and probably SBCL) do that, define lambda as some macro -e.g. which would expand to building some closure in an implementation specific way (but lambda cannot be defined as a function).
A function call (e0 e1 e2) is evaluated like this
e0 is evaluated, the result is (hopefully) a function f
e1 is evaluated, the result is a value v1
e2 is evaluated, the result is a value v2
The function body of f is evaluated in an environment in which
the formal parameters are bound to the values v1 and v2.
Note that all expressions e0, e1, and, e2 are evaluated before the body of the function is activated.
This means that a function call like (foo #t 2 (/ 3 0)) will result in an error when (/ 3 0) is evaluated - before control is handed over to the body of foo.
Now consider the special form lambda. In (lambda (x) (+ x 1)) this creates a function of one variable x which when called with a value v will compute (+ v 1).
If in contrast lambda were a function, then the expressions (x) and (+ x 1) are evaluated before the body of lambda is activated. And now (x) will most likely produce an error - since (x) means call the function x with no arguments.
In short: Function calls will always evaluate all arguments, before the control is passed to the function body. If some expressions are not to be evaluated a special form is needed.
Here lambda is a form, that don't evaluate all subforms - so lambda needs to be a special form.
In Scheme lingo we use the term procedure instead of function throughout the standard report. Thus since this is about scheme dialects I'll use the term procedure.
In eager languages like standard #!racket and #!r6rs procedures get their arguments evaluated before the body is evaluated with the new lexical environment. Thus since if and lambda has special evaluation rules than for procedures special forms and macros are the way to introduce new syntax.
In a lazy language like #!lazy racket evaluation is by need and thus many forms that are implemented as macros/special forms in an eager language can be implemented as procedure. eg. you can make if as a procedure using cond but you cannot make cond using if because the terms themselves would be evaluated as forms on access and eg (cond (#t 'true-value)) would fail since #t is not a procedure. lambda has similar issue with the argument list.
(defun triangle-using-cond (number)
(cond
((<= number 0) 0) ; 1st
((= number 1) 1) ; 2nd
((> number 1) ; 3rd
;; 4th
(+ number
(triangle-using-cond (1- number))))))
Things that I know about Cond
It allows multiple test and alternative expressions
It has pre-specified evaluation order. For instance, the first condition will always evaluated whether it is right or not
One thing that I cannot distinguish is that what makes cond different from a function!
A function call (e0 e1 e2) is evaluated like this
1. e0 is evaluated, the result is (hopefully) a function f
2. e1 is evaluated, the result is a value v1
3. e2 is evaluated, the result is a value v2
4. The function body of `f` is evaluated in an environment in which
the formal parameters are bound to the values `v1` and `v2`.
Note that all expressions e0, e1, and, e2 are evaluated before the body of the function is activated.
This means that a function call like (foo #t 2 (/ 3 0)) will result in an error when (/ 3 0) is evaluated - before control is handed over to the body of foo.
Now consider the special form if. In (if #t 2 (/ 3 0)) the expressions #t is evaluated and since the value non-false, the second expression 2 is evaluated and the resulting value is 2. Here (/ 3 0) is never evaluated.
If in contrast if were a function, then the expressions #t, 2, and, (/ 3 0) are evaluated before the body of is activated. And now (/ 3 0) will produce an error - even though the value of that expressions is not needed.
In short: Function calls will always evaluate all arguments, before the control is passed to the function body. If some expressions are not to be evaluated a special form is needed.
Here if and cond are examples of forms, that don't evaluate all subexpressions - so they they need to be special forms.
If cond were not a special form then the expression:
((> number 1) ;;3rd
(+ number (triangle-using-cond (1- number))))
would cause either:
an infinite loop because triangle-using-cond would keep calling itself recursively via the tail call (triangle-using-cond (1- number)).
or, the last expression would try to apply the value #f or #t as a function (which in a type-2 Lisp such as ANSI Common Lisp is possible, but not possible in a type-1 Lisp such as Racket or Scheme) and produce an error.
What makes cond a special form is that its arguments are evaluated lazily whereas functions in Scheme or Common Lisp evaluate their arguments eagerly.
As already answered, all arguments to a call to some function f are evaluated before the result of applying f is computed. Does it however mean that cond, or if, or both should be special forms?
Well, first, if you have if, you can easily simulate a cond with nested tests. Conversely, if is just a degenerate form of cond. So you can say that it is sufficient to have one of them a special form. Let's choose if because it is simpler to specify.
So shall if be special?
It doesn't really need to...
If the underlying question is "is if expressible in terms of a smaller set of special forms?", then the answers is yes: just implement if in terms of functions:
(define true-fn (lambda (then else) (then)))
(define false-fn (lambda (then else) (else)))
Whenever you can return a boolean, you return one of the above function instead.
You could for example decide to bind #t and #f to those functions.
Notice how they call one of the two input parameters.
((pair? x) ;; returns either true-fn or false-fn
(lambda () (+ x 1))
(lambda () x))
...but why code in lambda calculus?
Evaluating code conditionally is really a fundamental operation of computing. Trying to find a minimal special forms where you cannot express that directly leads to a poorer programming language from the perspective of the programmer, however "clean" the core language is.
From a certain point of view, the if form (or cond) is necessary because without them it becomes really hard to express conditional execution in a way that a compiler/interpreter can handle efficiently.
This document referenced by uselpa discuss using closures to implement if, and concludes:
However, the syntactic inconvenience would be so great that even
Scheme defines if as a special form.
Here are some sample codes from text of OnLisp.
My question is that why it bothers to use a lambda function,
`(funcall (alrec ,rec #'(lambda () ,base)) ,#lsts))
as second argument to alrec in the definition of on-cdrs?
What is the difference if I just define it without using lambda?
`(funcall (alrec ,rec ,base) ,#lsts))
(defun lrec (rec &optional base)
(labels ((self (lst)
(if (null lst)
(if (functionp base)
(funcall base)
base)
(funcall rec (car lst)
#'(lambda ()
(self (cdr lst)))))))
#'self))
(defmacro alrec (rec &optional base)
"cltl2 version"
(let ((gfn (gensym)))
`(lrec #'(lambda (it ,gfn)
(symbol-macrolet ((rec (funcall ,gfn)))
,rec))
,base)))
(defmacro on-cdrs (rec base &rest lsts)
`(funcall (alrec ,rec #'(lambda () ,base)) ,#lsts))
You don't say how this is intended to be called and this code is a bit of a tangle so at a quick glance I couldn't say how it's supposed to work. However, I can answer your question.
First, let me say that
(if (functionp base) (funcall base) base)
is terrible programming style. This effectively puts a whole in your semantic space, creating a completely different handling of functions as objects than other things as objects. In Common Lisp, a function is supposed to be an object you can choose to pass around. If you want to call it, you should do so, but you shouldn't just say to someone "if I give you a function you should call it and otherwise you should not." (Why this matters will be seen as you read on.)
Second, as Barmar notes, if you write ,base you are basically saying "take the code and insert it for evaluation here". If you write
#'(lambda () ,base)
you are saying put the code inside a function so that its execution is delayed. Now, you're passing it to a function that when it receives the function is going to call it. And, moreover, calling it will evaluate it in the lexical environment of the caller, and there is no intervening change in dynamic state. So you'd think this would be the same thing as just evaluating it at the call site (other than just a little more overhead). However, there is a case where it's different.
If the thing you put in the base argument position is a variable (let's say X) or a number (let's say 3), then you'll either be doing (lrec ... X) or (lrec 3) or else you'll be doing
(lrec ... #'(lambda () X))
or
(lref ... #'(lambda () 3))
So far so good. If it gets to the caller, it's going to say "Oh, you just meant the value of X (or of 3)." But there's more...
If you say instead an expression that yields a function in the base argument position of your call to on-cdrs or your call to alrec, you're going to get different results depending on whether you wrote ,base or #'(lambda () ,base). For example, you might have put
#'f
or
#'(lambda () x)
or, even worse,
#'(lambda (x) x)
in the base argument position. In that case, if you had used ,base, then that expression would be immediately evaluated before passing the argument to lrec, and then lrec would receive a function. And then it would be called a second time (which is probably not what the macro user expects unless the documentation is very clear about this inelegance and the user of the macro has cared enough to read the documentation in detail). In the first case, it will return 3, in the second case, the value of x, and in the third case an error situation will occur because it will be called with the wrong number of arguments.
If instead you implemented it with
#'(lambda () ,base)
then lrec will receive as an argument the result of evaluating one of
#'(lambda () #'f)
or
#'(lambda () #'(lambda () 3))
or
#'(lambda () #'(lambda (x) x))
depending on what you gave it as an argument from our examples above. But in any case what lrec gets is a function of one argument that, when evaluated, will return the result of evaluating its body, that is, will return a function.
The important takeaways are these:
The comma is dropping in a piece of evaluable code, and wrapping the comma'd experession with a lambda (or wrapping any expression with a lambda) delays evaluation.
The conditional in the lrec definition should either expect that the value is already evaluated or not, and should not take a conditional effect because it can't know whether you already evaluated something based purely on type unless it basically makes a mess of functions as first-class data.
I hope that helps you see the difference. It's subtle, but it's real.
So using
#'(lambda () ,base)
protects the macro from double-evaluation of a base that might yield a function, but on the other hand the bad style is something that shouldn't (in my view) happen. My recommendation is to remove the conditional function call to base and make it either always or never call the base as a function. If you make it never call the function, the caller should definitely use ,base. If you make it always call the function, the caller should definitely include the lambda wrapper. That would make the number of evaluations deterministic.
Also, as a purely practical matter, I think it's more in the style of Common Lisp just to use ,base and not bother with the closure unless the expression is going to do something more than travel across a function call boundary to be immediately called. It's a waste of time and effort and perhaps extra consing to have the function where it's really not serving any interesting purpose. This is especially true if the only purpose of the lrec function is to support this facility. If lrec has an independent reason to have the contract that it does, that's another matter and maybe you'd write your macro to accommodate.
It's more common in a functional language like Scheme, which has a different aesthetic, to have a regular function as an alternative to any macro, and to have that function take such a zero-argument function as an argument just in case some user doesn't like working with macros. But mostly Common Lisp programmers don't bother, and your question was about Common Lisp, so I've biased the majority of my writing here to that dialect.
This is from the SICP book that I am sure many of you are familiar with. This is an early example in the book, but I feel an extremely important concept that I am just not able to get my head around yet. Here it is:
(define (cons x y)
(define (dispatch m)
(cond ((= m 0) x)
((= m 1) y)
(else (error "Argument not 0 or 1 - CONS" m))))
dispatch)
(define (car z) (z 0))
(define (cdr z) (z 1))
So here I understand that car and cdr are being defined within the scope of cons, and I get that they map some argument z to 1 and 0 respectively (argument z being some cons). But say I call (cons 3 4)...how are the arguments 3 and 4 evaluated, when we immediately go into this inner-procedure dispatch which takes some argument m that we have not specified yet? And, maybe more importantly, what is the point of returning 'dispatch? I don't really get that part at all. Any help is appreciated, thanks!
This is one of the weirder (and possibly one of the more wonderful) examples of exploiting first-class functions in Scheme. Something similar is also in the Little Schemer, which is where I first saw it, and I remember scratching my head for days over it. Let me see if I can explain it in a way that makes sense, but I apologize if it's not clear.
I assume you understand the primitives cons, car, and cdr as they are implemented in Scheme already, but just to remind you: cons constructs a pair, car selects the first component of the pair and returns it, and cdr selects the second component and returns it. Here's a simple example of using these functions:
> (cons 1 2)
(1 . 2)
> (car (cons 1 2))
1
> (cdr (cons 1 2))
2
The version of cons, car, and cdr that you've pasted should behave exactly the same way. I'll try to show you how.
First of all, car and cdr are not defined within the scope of cons. In your snippet of code, all three (cons, car, and cdr) are defined at the top-level. The function dispatch is the only one that is defined inside cons.
The function cons takes two arguments and returns a function of one argument. What's important about this is that those two arguments are visible to the inner function dispatch, which is what is being returned. I'll get to that in a moment.
As I said in my reminder, cons constructs a pair. This version of cons should do the same thing, but instead it's returning a function! That's ok, we don't really care how the pair is implemented or laid out in memory, so long as we can get at the first and second components.
So with this new function-based pair, we need to be able to call car and pass the pair as an argument, and get the first component. In the definition of car, this argument is called z. If you were to execute the same REPL session I had above with these new cons ,car, and cdr functions, the argument z in car will be bound to the function-based pair, which is what cons returns, which is dispatch. It's confusing, but just think it through carefully and you'll see.
Based on the implementation of car, it appears to be that it take a function of one argument, and applies it to the number 0. So it's applying dispatch to 0, and as you can see from the definition of dispatch, that's what we want. The cond inside there compares m with 0 and 1 and returns either x or y. In this case, it returns x, which is the first argument to cons, in other words the first component of the pair! So car selects the first component, just as the normal primitive does in Scheme.
If you follow this same logic for cdr, you'll see that it behaves almost the same way, but returns the second argument to cons, y, which is the second component of the pair.
There are a couple of things that might help you understand this better. One is to go back to the description of the substitution model of evaluation in Chapter 1. If you carefully and meticulously follow that substitution model for some very simple example of using these functions, you'll see that they work.
Another way, which is less tedious, is to try playing with the dispatch function directly at the REPL. Below, the variable p is defined to refer to the dispatch function returned by cons.
> (define p (cons 1 2))
#<function> ;; what the REPL prints here will be implementation specific
> (p 0)
1
> (p 1)
2
The code in the question shows how to redefine the primitive procedure cons that creates a cons-cell (a pair of two elements: the car and the cdr), using only closures and message-dispatching.
The dispatch procedure acts as a selector for the arguments passed to cons: x and y. If the message 0 is received, then the first argument of cons is returned (the car of the cell). Likewise, if 1 is received, then the second argument of cons is returned (the cdr of the cell). Both arguments are stored inside the closure defined implicitly for the dispatch procedure, a closure that captures x and y and is returned as the product of invoking this procedural implementation of cons.
The next redefinitions of car and cdr build on this: car is implemented as a procedure that passes 0 to a closure as returned in the above definition, and cdr is implemented as a procedure that passes 1 to the closure, in each case ultimately returning the original value that was passed as x and y respectively.
The really nice part of this example is that it shows that the cons-cell, the most basic unit of data in a Lisp system can be defined as a procedure, therefore blurring the distinction between data and procedure.
This is the "closure/object isomorphism", basically.
The outer function (cons) is a class constructor. It returns an object, which is a function of one argument, where the argument is equivalent to the name of a method. In this case, the methods are getters, so they evaluate to values. You could just as easily have stored more procedures in the object returned by the constructor.
In this case, numbers where chosen as method names and sugary procedures defined outside the object itself. You could have used symbols:
(define (cons x y)
(lambda (method)
(cond ((eq? method 'car) x)
((eq? method 'cdr) y)
(else (error "unknown method")))))
In which case what you have more closely resembles OO:
# (define p (cons 1 2))
# (p 'car)
1
# (p 'cdr)
2