Lisp simple question - lisp

I have some not understanding actions from gnu clisp
Suppose, I have some code like (let ((x "Hi!"))(print x)).
If I execute it from console (like, clisp fileName.lisp) I see
Hi!
But, when I execute it from interpreter, I see this text twice. Why?
Help me, please.

The interpreter always outputs the value of the last expression.
print also returns the parameter as a value, "Hi!" in your case.
That's why you see it twice.
(print "Hi!")
will give the same result.

Related

Why do quoted objects stay quoted in lisp?

I have made a simple implementation of LISP using SICP metacircular evaluator as a reference, but even though I know and see the code I don't quite understand something about it. In the apply function that applies a closure to its arguments there is a piece of code that calls eval on each of it's arguments. If I quote an argument, then eval of that argument will give the raw form of that argument.
For clarity of the nature of the question and to present my current understanding of what is happening I will walk through an example.
(define f (lambda (x) (print x)))
(define g (lambda (x) (f x)))
; prints "bar" into the console
(g (quote bar))
First we call g with (quote bar) as the first parameter. The argument to g is evaluated to a symbol bar.
When g is evaluated, it passes it should evaluate it's argument and pass it to function f. But evaluating a symbol will cause a lookup from the environment, which doesn't seem to happen (if it did I should have printed an error, or something like that).
So what I want to know is why does the code print bar and not an error.
I walked through the code with the debugger and now I believe I understand. When g was called, a new environment was created with x associated with the symbol bar. And when a function is executed it's parameters are being evaluated to the things that are stored in the environment. So it's not bar that got evaluated, it's x that got evaluated to bar. And after x is evaluated there's no second-time evaluation.
The reason why quoted things appear to stay quoted is because they actually do get unquoted, but they don't get evaluated as arguments (they only get evaluated once you explicitly call eval on them).

`apply` or `funcall` for macros instead of functions

In Lisp, a function's arguments are evaluated first before entering the function body. Macro arguments stay not evaluated.
But sometimes, one wants to inject code pieces stored in variables into a macro. This means evaluating the argument for the macro first, and then apply the macro-of-choice on this evaluated result.
One has to resort to
(eval `(macro ,arg))
To achieve this - but eval does not behave correctly in different environments.
The best thing would be, if one could do:
(apply macro (list arg))
or
(funcall macro arg)
But since the macro is not a function this doesn't work.
Is it possible to achieve something like this? - To circumvent that problem oder to make the macro available in the functions namespace?
Or am I missing some other ways to solve such problems?
I came to this question while trying to answer How to produce HTML from a list. but also in Generate TYPECASE with macro in common lisp, Evaluate arguments passed to a macro that generates functions in lisp, and How to convert a list to code/lambda in scheme?. But I always thought while answering them it would be good to have an apply or funcall-like function which can take macros.
It is not clear what you are trying to do, although it is almost certain that you are confused about something. In particular if you are calling eval inside macroexpansions then in almost all cases you are doing something both seriously wrong and seriously dangerous. I can't ever think of a case where I've wanted macros which expand to things including eval and I have written Lisp for a very very long time.
That being said, here is how you call the function associated with a macro, and why it is very seldom what you want to do.
Macros are simply functions whose domain and range is source code: they are compilers from a language to another language. It is perfectly possible to call the function associated with a macro, but what that function will return is source code, and what you will then need to do with that source code is evaluate it. If you want a function which deals with run-time data which is not source code, then you need that function, and you can't turn a macro into that function by some magic trick which seems to be what you want to do: that magic trick does not, and can not, exist.
So for instance if I have a macro
(defmacro with-x (&body forms)
`(let ((x 1))
,#forms))
Then I can call its macro function on a bit of source code:
> (funcall (macro-function 'with-x)
'(with-x (print "foo")) nil)
(let ((x 1)) (print "foo"))
But the result of this is another bit of source code: I need to compile or evaluate it, and nothing I can do will get around this.
Indeed in (almost?) all cases this is just the same as macroexpand-1):
> (macroexpand-1 '(with-x (print "foo")))
(let ((x 1)) (print "foo"))
t
And you can probably write macroexpand-1 in terms of macro-function:
(defun macroexpand-1/equivalent (form &optional (env nil))
(if (and (consp form)
(symbolp (first form))
(macro-function (first form)))
(values (funcall (macro-function (first form)) form env)
t)
(values form nil)))
So, if the result of calling a macro is source code, what do you do with that source code to get a result which is not source code? Well, you must evaluate it. And then, well, since the evaluator expands macros for you anyway, you might as well just write something like
(defun evaluate-with-x (code)
(funcall (compile nil `(lambda ()
(with-x ,#code)))))
So you didn't need to call the macro's function in any case. And this is not the magic trick which turns macros into functions dealing with data which is not source code: it is a terrible horror which is entirely made of exploding parts.
A concrete example: CL-WHO
It looks like this question might have its origins in this one and the underlying problem there is that that's not what CL-WHO does. In particular it is a confusion to think that something like CL-WHO is a tool for taking some kind of list and turning it into HTML. It's not: it's a tool for taking the source code of a language which is built on CL but includes a way of expressing HTML output mingled with CL code, and compiles it into CL code which will do the same thing. It happens to be the case that CL source code is expressed as lists & symbols, but CL-WHO isn't really about that: it's a compiler from, if you like, 'the CL-WHO language' to CL.
So, let's try the trick we tried above and see why it's a disaster:
(defun form->html/insane (form)
(funcall
(compile nil `(lambda ()
(with-html-output-to-string (,(make-symbol "O"))
,#form)))))
And you might, if you did not look at this too closely, think that this function does in fact do the magic trick:
> (form->html/insane '(:p ((:a :href "foo") "the foo")))
"<p></p><a href='foo'>the foo</a>"
But it doesn't. What happens if we call form->html/insane on this perfectly innocuous list:
(:p (uiop/run-program:run-program "rm -rf $HOME" :output t))
Hint: don't call form->html/insane on this list if you don't have very good backups.
CL-WHO is an implementation of a programming language which is a strict superset of CL: if you try to turn it into a function to turn lists into HTML you end up with something involving the same nuclear weapon you tinker with every time you call eval, except that nuclear weapon is hidden inside a locked cupboard where you can't see it. But it doesn't care about that: if you set it off it will still reduce everything within a few miles to radioactive ash and rubble.
So if you want a tool which will turn lists – lists which aren't source code – into HTML then write that tool. CL-WHO might have the guts of such a tool in its implemenentation, but you can't use it as it is.
And this is the same problem you face whenever you are trying to abuse macros this way: the result of calling a macro's function is Lisp source code, and to evaluate that source code you need eval or an equivalent of eval. And eval is not only not a terrible solution to almost any problem: it's also a nuclear weapon. There are, perhaps problems for which nuclear weapons are good solutions, but they are few and far between.

Racket Error: Expected a procedure that can be applied to arguments [duplicate]

This question already has an answer here:
My code signals the error "application: not a procedure" or "call to non procedure"
(1 answer)
Closed 4 years ago.
Sorry, I just started using racket. I'm pretty new at this. I've written this piece of code:
(define (save_sheets lst num)
(if(= num (- (length lst) 1))
('())
(
(my_save_image (join_sheet (list-ref lst num)) num)
(save_sheets lst (+ num 1)))))
Of course, when I run this I get this error:
application: not a procedure;
expected a procedure that can be applied to arguments
given: (object:image% ...)
arguments...: [none]
(join_sheet (list-ref lst num)) should return an image, which the error shows, but the my_save_image should take it in right? It's parameters is the image and a number. Thanks!
Remember that parentheses in Racket (and other Lisp-like languages) are not like parentheses in other languages… they are important! In many languages, there is no difference between x, (x), ((x)), and ((((x)))), but in Racket, these are all very different expressions.
In Racket, parentheses mean function application. That is, (f) is like writing f() in other languages, so ((f)) is like writing f()(), and so on. This is important, since it means things like (3) are quite nonsensical in Racket—that would be like writing 3() in other languages, and 3 is definitely not a function.
Now, let’s consider the problem you’re having. You are using if, which has the following grammar:
(if conditional-expression then-expression else-expression)
This means that each of the pieces of code inside the if must be valid expressions on their own. However, take a close look at your then-expression, which is ('()). This is kind of like the (3) example from earlier, isn’t it? '() is not a function, so it should not be surrounded in parentheses!
Your else-expression exhibits a similar problem, but it is a little more complicated, since you seem to wish to run two functions there. If you want to run the first function for side-effects, you would not use parentheses alone for grouping, you would use begin, but it’s not clear to me if that’s what you actually want here or not. In any case, as-written, your program will attempt to apply the result of the call to my_save_image as a function, passing it the result of the recursive call to save_sheets as an argument, which is almost certainly not what you want.
Mind your parentheses. In Racket, they are to be treated with care.

Common Lisp: getting an error using readtable-case

When I enter this at the REPL prompt:
(setf (readtable-case *readtable*) :invert)
I get this error message:
Error in SETF [or a callee]: Cannot expand the SETF form (READTABLE-CASE
*READTABLE*).
Why do I get this error?
(format nil "~A ~A" (lisp-implementation-type) (lisp-implementation-version)) says "Kyoto Common Lisp GCL 2.6.2". The result of (eq 'readtable-case 'cl:readtable-case) is T. What does this all mean please?
The second expression means you're using the correct symbol. The first indicates which Lisp implementation you're using: That should be GNU Common Lisp 2.6.2
After some search I found this message on the gcl-devel list saying ...
The problem appears to be this line:
(setf (readtable-case *readtable*) readcase)
in randomly-check-readability. I'd recommend this as the next
ansi issue to resolve, since it's blocking the tests.
... with a subject line "ansi-tests in 2.7.0". The message is from 2004.
Bottom line: I guess you need a more recent or even* a different Lisp implementation.
(* as mentioned by Rainer Joswig the issue also affects the current 2.6.12 release)
I guess all major Lisp implementations support this. CLISP 2.49 does, SBCL and CCL probably do, as far as I know ECL does also.

How can I make emacs keyboard macros work properly when pasting the results of clojure evaluation?

There's a phenomenally useful feature of emacs lisp where you can evaluate the result of an expression and paste the result directly into a buffer.
Say I want to check addition works. Then I type:
(* 3 2)
and I define the keyboard macro:
(setq last-kbd-macro
[down ?\( ?i ?s ?= ? ?\C-\M-f ? ?\C-u ?\C-x ?\C-e ?\) home])
If I then place point above the expression, and press F4 to execute the macro, the expression turns into:
(is= (* 3 2) 6)
Which makes a nice regression test.
Unfortunately the same keyboard macro executed in a clojure/nrepl buffer results in:
(* 8 9)(is= )
and an error from clojure about not being able to resolve the symbol is=
So I think that something weird is happening to the ordering of things, and the macro is trying to evaluate the wrong thing.
Can anyone get this to work with clojure? (And in fact solve the general problem so that arbitrary keyboard macros work OK with C-u C-x C-e like they do with emacs lisp)
Edit since people seem to be misunderstanding:
Doing the keypresses by hand works fine in either an elisp or a clojure buffer. In one C-u C-x C-e evals with emacs lisp and in the other evals in the external clojure process.
The problem comes when trying to run a keyboard macro (recorded in a clojure buffer) which contains C-u C-x C-e
Running the macro in the clojure buffer, things get re-ordered somehow. It looks like the macro may be carrying on executing even though the eval-paste has not completed yet.
I was wondering if there was a way of forcing the keyboard macro (or corresponding function) to execute in the same order as it would by hand.
I'm quite happy to turn the keyboard macro into a proper elisp function if necessary.
Keyboard macros are a quick and dirty way to repeat a certain sequence of actions. They are very fragile because they remember the keys pressed, not the functions they invoke, so they may produce wildly different results depending on the buffer they are invoked in, the current command history, window configuration and what not.
In your case, chances are that one of the keys in the macro invoke a different command in the clojure/nrepl buffer than in the buffer in which you tested the macro. You really need to define the macro in the buffer in which it will be used.
If you are going to re-use the macro, I suggest that you write a emacs
lisp function which does what you want instead of messing with macros.
You might find the output of (format-kbd-macro nil t) useful, but note that you should not use the commands like eval-last-sexp in your function, use a lower-level function which returns the evaluation result instead of inserting it into the current buffer.
Addressing a problem you haven't had yet, but will soon: don't forget to insert a ' character before the result of evaluating the expression: you want (= (cons 1 nil) '(1)), not (= (cons 1 nil) (1)).