More specifically what I am interested in is the one particular property of begin where definitions in its body added to the surrounding scope. E.g.
(begin (define a 1)
(define b 2))
(+ a b) ; 3
It would be reasonably simple to define a new macro my-begin that is translated to a standard begin, but in my particular use case I need a list of all identifiers that are being bound in the begin, such that I can introduce/use them elsewhere.
Being more specific as to what I want to achieve: I am figuring out how to build a PAR/AND operator that evaluates two branches at the same time (or at least give the impression, given the context). The branches may contain blocking operations. The PAR/AND itself returns once both branches return. Any definitions become available in the outlying scope. For example:
(PAR/AND
(define a (do-something)) ; branch 1
(define b (do-something-else))) ; branch 2
(+ a b)
I'm not quite certain yet how to implement it (since I have some extra stuff to worry about), but making a and b available outside the scope of par/and is definitely something that needs to happen at some point.
I would have skipped the part about define totally and just made sure the expression are done in parallel and then when the threads are joined use values. In racket you have define-values where you can bind multiple values to global names and it can be used to name the values you have computed:
(define-values (a b)
(parallel/values (do-something) (do-something-else)))
(+ a b)
; ==> 1337
paralell/values need to be syntax here, but since the expressions themselves are thunks you could in fact keep is a procedure that takes thunks:
(define-values (a b)
(parallel/values do-something do-something-else))
(+ a b)
; ==> 1337
As you see this does not require a customized begin at all. I expect the expressions in parallel would introduce closures that will affect define so this circumvent that can of worms as well. define-values is the actual define primitive in racket if you look at full expanded programs from the macro expander with macro hiding disabled.
There are complicated ways to do this, but it looks like there's an easy way as well: can't you just have your PAR/AND macro expand into a begin ?
In elisp, the if statement logic only allows me an if case and else case.
(if (< 3 5)
; if case
(foo)
; else case
(bar))
but what if I want to do an else-if? Do I need to put a new if statement inside the else case? It just seems a little messy.
Nesting if
Since the parts of (if test-expression then-expression else-expression) an else if would be to nest a new if as the else-expression:
(if test-expression1
then-expression1
(if test-expression2
then-expression2
else-expression2))
Using cond
In other languages the else if is usually on the same level. In lisps we have cond for that. Here is the exact same with a cond:
(cond (test-expression1 then-expression1)
(test-expression2 then-expression2)
(t else-expression2))
Note that an expression can be just that. Any expression so often these are like (some-test-p some-variable) and the other expressions usually are too. It's very seldom they are just single symbols to be evaluated but it can be for very simple conditionals.
I thought racket does inner reduction always for evaluation but I found out e.g. "if" (and cond?!) is lazy evaluation in racket...why is this needed?
Is it impossible to realize an if-statement via inner reduction?
I can not figure out where lazy evaluation is better than inner and vice versa? Could someone supply an example?
if and cond are not "lazy", they just have different evaluation rules. For example, in the following expression only the consequent part of the if is executed, because the condition happens to be true:
(if (= 1 1)
'ok
(/ 1 0))
=> 'ok
If the alternative part were executed, we'd have a division by zero error. This is not lazy evaluation, it's just the way an if expression works in Scheme. Compare the above example with this one:
(define (my-if condition consequent alternative)
(if condition
consequent
alternative))
(my-if (= 1 1) 'ok (/ 1 0))
=> /: division by zero
Now we're using the standard evaluation rules for procedures, which in a non-lazy interpreter specify that all the arguments are evaluated before executing the procedure's body - hence an error is raised. That's why if can not be implemented as a normal procedure, it has to be a special form because it requires different evaluation rules.
I'm trying to learn and understand the Lisp programming language to a deep level. The function + evaluates its arguments in applicative order:
(+ 1 (+ 1 2))
(+ 1 2) will be evaluated and then (+ 1 3) will be evaluated, but the if function works differently:
(if (> 1 2) (not-defined 1 2) 1)
As the form (not-defined 1 2) isn't evaluated, the program doesn't break.
How can the same syntax lead to different argument evaluation? How is the if function defined so that its arguments aren't evaluated?
if is a special operator, not an ordinary function.
This means that the normal rule that the rest elements in the compound form are evaluated before the function associated with the first element is invoked is not applicable (in that it is similar to macro forms).
The way this is implemented in a compiler and/or an interpreter is that one looks at the compound form and decides what to do with it based on its first element:
if it is a special operator, it does its special thing;
if it is a macro, its macro-function gets the whole form;
otherwise it is treated as a function - even if no function is defined.
Note that some special forms can be defined as macros expanding to other special forms, but some special forms must actually be present.
E.g., one can define if in terms of cond:
(defmacro my-if (condition yes no)
`(cond (,condition ,yes)
(t ,no)))
and vice versa (much more complicated - actually, cond is a macro, usually expanding into a sequence of ifs).
PS. Note that the distinction between system-supplied macros and special operators, while technically crisp and clear (see special-operator-p and macro-function), is ideologically blurred because
An implementation is free to implement a Common Lisp special operator
as a macro. An implementation is free to implement any macro operator
as a special operator, but only if an equivalent definition of the
macro is also provided.
sds's answer answers this question well, but there are a few more general aspects that I think are worth mentioning. As that answer and others have pointed out, if, is built into the language as a special operator, because it really is a kind of primitive. Most importantly, if is not a function.
That said, the functionality of if can be achieved using just functions and normal function calling where all the arguments are evaluated. Thus, conditionals can be implemented in the lambda calculus, on which languages in the family are somewhat based, but which doesn't have a conditional operator.
In the lambda calculus, one can define true and false as functions of two arguments. The arguments are presumed to be functions, and true calls the first of its arguments, and false calls the second. (This is a slight variation of Church booleans which simply return their first or second argument.)
true = λ[x y].(x)
false = λ[x y].(y)
(This is obviously a departure from boolean values in Common Lisp, where nil is false and anything else is true.) The benefit of this, though, is that we can use a boolean value to call one of two functions, depending on whether the boolean is true or false. Consider the Common Lisp form:
(if some-condition
then-part
else-part)
If were were using the booleans as defined above, then evaluating some-condition will produce either true or false, and if we were to call that result with the arguments
(lambda () then-part)
(lambda () else-part)
then only one of those would be called, so only one of then-part and else-part would actually be evaluated. In general, wrapping some forms up in a lambda is a good way to be able delay the evaluation of those forms.
The power of the Common Lisp macro system means that we could actually define an if macro using the types of booleans described above:
(defconstant true
(lambda (x y)
(declare (ignore y))
(funcall x)))
(defconstant false
(lambda (x y)
(declare (ignore x))
(funcall y)))
(defmacro new-if (test then &optional else)
`(funcall ,test
(lambda () ,then)
(lambda () ,else)))
With these definitions, some code like this:
(new-if (member 'a '(1 2 3))
(print "it's a member")
(print "it's not a member"))))
expands to this:
(FUNCALL (MEMBER 'A '(1 2 3)) ; assuming MEMBER were rewritten
(LAMBDA () (PRINT "it's a member")) ; to return `true` or `false`
(LAMBDA () (PRINT "it's not a member")))
In general, if there is some form and some of the arguments aren't getting evaluated, then the (car of the) form is either a Common Lisp special operator or a macro. If you need to write a function where the arguments will be evaluated, but you want some forms not to be evaluated, you can wrap them up in lambda expressions and have your function call those anonymous functions conditionally.
This is a possible way to implement if, if you didn't already have it in the language. Of course, modern computer hardware isn't based on a lambda calculus interpreter, but rather on CPUs that have test and jump instructions, so it's more efficient for the language to provide if a primitive and to compile down to the appropriate machine instructions.
Lisp syntax is regular, much more regular than other languages, but it's still not completely regular: for example in
(let ((x 0))
x)
let is not the name of a function and ((x 0)) is not a bad form in which a list that is not a lambda form has been used in the first position.
There are quite a few "special cases" (still a lot less than other languages, of course) where the general rule of each list being a function call is not followed, and if is one of them. Common Lisp has quite a few "special forms" (because absolute minimality was not the point) but you can get away for example in a scheme dialect with just five of them: if, progn, quote, lambda and set! (or six if you want macros).
While the syntax of Lisp is not totally uniform the underlying representation of code is however quite uniform (just lists and atoms) and the uniformity and simplicity of representation is what facilitates metaprogramming (macros).
"Lisp has no syntax" is a statement with some truth in it, but so it's the statement "Lisp has two syntaxes": one syntax is what uses the reader to convert from character streams to s-expressions, another syntax is what uses the compiler/evaluator to convert from s-expressions to executable code.
It's also true that Lisp has no syntax because neither of those two levels is fixed. Differently from other programming languages you can customize both the first step (using reader macros) and the second step (using macros).
It would not make any sense to do so. Example: (if (ask-user-should-i-quit) (quit) (continue)). Should that quit, even though the user does not want to?
IF is not a function in Lisp. It is a special built-in operator. Lisp a several built-in special operators. See: Special Forms. Those are not functions.
The arguments are not evaluated as for functions, because if is a special operator. Special operators can be evaluated in any arbitrary way, that's why they're called special.
Consider e.g.
(if (not (= x 0))
(/ y x))
If the division was always evaluated, there could be a division by zero error which obviously was not intended.
If isn't a function, it's a special form. If you wanted to implement similar functionality yourself, you could do so by defining a macro rather than a function.
This answer applies to Common Lisp, but it'll probably the same for most other Lisps (though in some if may be a macro rather than a special form).
I wrote this piece of code in common lisp (ignore the ... as it is pointless to paste that part here).
(case turn
(*red-player* ...)
(*black-player* ...)
(otherwise ...))
red-player and black-player are variables that were defined using defvar statement, in order to "simulate" a #define statement in C.
(defvar *red-player* 'r)
(defvar *black-player* 'b)
As you can imagine, when the variable turn receives either *red-player*'s value ('r) or *black-player*'s value ('b), the case statement doesn't work properly, as it expects that turn contains *red-player* as a literal, not the content of the variable *red-player*.
I know that I can easily fix that using a cond or if + equal statements, as the content of the variable is evaluated there, but I am curious. Maybe there is a way to create something like C's macros in Lisp, or there is some kind of special case statement that allows the use of variables instead of literals only.
Thank you in advance!
You can enter the value of expressions into your forms with read-time evaluation
CL-USER 18 > (defvar *foo* 'a)
*FOO*
CL-USER 19 > (defvar *bar* 'b)
*BAR*
CL-USER 20 > '(case some-var (#.*foo* 1) (#.*bar* 2))
(CASE SOME-VAR (A 1) (B 2))
Note that read-time evaluation is not necessarily the best idea for improving code maintenance and security.
Note also that the idea that there is a variable with a descriptive name for some internal value like is not necessary in Lisp:
dashedline = 4
drawLine(4,4,100,100,dashedline)
would be in Lisp
(draw-line 4 4 100 100 :dashed-line)
In Lisp one can pass descriptively named symbols. The sort of API that uses integer values or similar is only need in APIs to external software typically written in C.
The short answer is "yes, you can do it, sort of".
And the seeds of the longer answer involve the use of defmacro to create your own version of case, say mycase, that will return a regular case form. The macro you define would evaluate the head of each list in the case body.
You would call:
(mycase turn
(*red* ...)
(*black* ...)
(otherwise ...))
which would return
(case turn
((r) ...)
((b) ...)
(otherwise ...))
to the evaluator. The returned case form would then be evaluated in the way you want.
You'd then be free to continue programming in your c-esque fashion to the dismay of lispers everywhere! Win-win?
You can abuse Lisp in any way you like. It is flexible like that, unlike C.
It doesn't always like the uses you put it to. Why push Lisp around?
Try this approach:
(defvar *turn* nil)
(cond
((eq *turn* 'red)
...
(setq *turn* 'black)))
((eq *turn* 'black)
...
(setq *turn* 'red)))
(t
.......))