I refer to 17.5.7.4 Predicates and see the demonstration:
— Function: zerop x
Returns true if x is numerically zero, in any of the Calc data types. (Note that for some types, such as error forms and intervals,
it never makes sense to return true.) In defmath, the expression ‘(= x
0)’ will automatically be converted to ‘(math-zerop x)’, and ‘(/= x
0)’ will be converted to ‘(not (math-zerop x))’.
However, it report error when apply it
ELISP> (math-zerop 0)
*** Eval error *** Symbol’s function definition is void: math-zerop
ELISP> (math-zerop 1)
*** Eval error *** Symbol’s function definition is void: math-zerop
What's the problem?
Emacs tries to lazy load (called autoloading) some of its features. math-zerop is defined as part of the calc-misc feature (in calc-misc.el).
You can load it by (require 'calc) which loads the calc-misc feature.
Related
I am trying to use a function (secondaryFunction or secondaryFunction2) passed in as a parameter to primaryFunction. However, when I run my code below:
(defun secondaryFunction (param1 param2)
NIL
)
(defun secondaryFunction2 (param1 param2))
NIL
)
(defun primaryFunction (transition param1 param2)
(transition param1 param2)
)
(primaryFunction 'secondaryFunction 0 0)
I get the following error:
*** - EVAL: undefined function TRANSITION
This seems strange, considering that I thought that I passed in secondaryFunction clearly as the transition parameter to primaryFunction?
There are separate function and value namespaces. In primary-function, you get the transition function as a value (actually the symbol here). Use funcall to call it:
(defun primary-function (transition param1 param2)
(funcall transition param1 param2))
Side Note: You are using a symbol, which means that funcall calls the function with that symbol as a name in the global environment. That's OK. You can also pass the function itself, with the function special operator (which has a shorthand #' reader macro):
(primary-function #'secondary-function 0 0)
Emacs version: 26.3
Slime version: 2.26.1
I start up Emacs.
I open up a simple .lisp file.
(defun testfn (x y)
(+ x y))
(defmacro testmc (form)
form
`(list 1 2 3))
I place my cursor over the symbol defun and issue the keyboard-command M-. (slime-edit-definition).
This should bring me to the definition of defun.
But it doesn't.
It brings me here:
I place my cursor over the symbol defmacro and issue the keyboard-command M-. (slime-edit-definition).
This should bring me to the definition of defmacro.
But it doesn't.
It brings me here:
Why does it do this & how do I fix this
Notice there is a warning in the REPL when trying to find the source of DEFUN:
WARNING: inconsistent 2 form-number-translations
You can replicate it yourself in the REPL:
CL-USER> (let ((slynk::*buffer-package* (find-package :cl))
(slynk::*buffer-readtable* *readtable*))
(slynk:find-definitions-for-emacs "DEFUN"))
WARNING: inconsistent 2 form-number-translations
(("(DEFMACRO DEFUN)"
(:LOCATION (:FILE "/home/chris/data/src/sbcl/src/code/macros.lisp")
(:POSITION 4140)
(:SNIPPET "(setq doc nil)
(let* (;; stuff shared between LAMBDA and INLINE-LAMBDA and NAMED-LAMBDA
(lambda-guts `(,#decls (block ,(fun-name-block-name name) ,#forms)))
(lambda `(lambda ,lambda-list ,#lambda-guts))
(named-lambda `("))))
To find where the warning comes from, you could do as I did first and do a textual search on the repository, or you could use the following alternate method that works better, namely invoke the debugger on warnings:
(handler-bind ((warning (lambda (c) (invoke-debugger c))))
(let ((slynk::*buffer-package* (find-package :cl))
(slynk::*buffer-readtable* *readtable*))
(slynk:find-definitions-for-emacs "DEFUN")))
This comes from SLYNK-SBCL::FORM-NUMBER-POSITION, and the interesting value in the debugger is the source location obtained from SBCL:
#<SB-INTROSPECT:DEFINITION-SOURCE {10369C50F3}>
--------------------
The object is a STRUCTURE-OBJECT of type SB-INTROSPECT:DEFINITION-SOURCE.
PATHNAME: #P"SYS:SRC;CODE;MACROS.LISP"
FORM-PATH: (5)
FORM-NUMBER: 89
CHARACTER-OFFSET: 3917
FILE-WRITE-DATE: 3825178034
PLIST: NIL
DESCRIPTION: NIL
It says the source is the fifth toplevel form in the file (which corresponds to the character offset), and from here, the FORM-NUMBER is the 89th form in a depth-first search walk of the form (this comes from the structure's docstring).
But, if I recompile the function FORM-NUMBER-POSITION with DEBUG set to 3, the toplevel form read at this position, TLF is NIL:
1: (SLYNK-SBCL::FORM-NUMBER-POSITION #S(SB-INTROSPECT:DEFINITION-SOURCE :PATHNAME #P"SYS:SRC;CODE;MACROS.LISP" :FORM-PATH (5) :FORM-NUMBER 89 :CHARACTER-OFFSET 3917 :FILE-WRITE-DATE 3825178034 :PLIST NIL..
Locals:
DEFINITION-SOURCE = #S(SB-INTROSPECT:DEFINITION-SOURCE :PATHNAME #P"SYS:SRC;CODE;MACROS.LISP" :FORM-PATH (5) :FORM-NUMBER 89 :CHARACTER-OFFSET 3917 :FILE-WRITE-DATE 3825178034 :PLIST NIL :DESCRIPTION NIL)
FORM-NUMBER = 89
PATH-TABLE = #((0 0))
POS-MAP = #<HASH-TABLE :TEST EQ :COUNT 126 {103B227EA3}>
POS-MAP#1 = #<HASH-TABLE :TEST EQ :COUNT 126 {103B227EA3}>
STREAM = #<SB-IMPL::STRING-INPUT-STREAM {7F3E0350D953}>
TLF = NIL
TLF#1 = NIL
TLF-NUMBER = 5
In read-source-form, you can see that the form is being read inside a (ignore-errors (read ...)) form, which returns NIL in case of error. I tried calling (read ...) only but this somehow did not invoke the debugger, so I did the same thing as above and explicitly invoked it on any condition.
There is an error, namely that the package "SB-XC" does not exist, which is expected since, if I am not mistaken, this is a package that only exists during the compilation of SBCL itself.
I think you should contact the SBCL SLY developers and file a bug for this directly, they would certainly have a better idea of how to fix the behaviour (feel free to link to your question in addition to giving the usual details of the bug report).
I'm seeing pretty much what you're seeing.
Defun (line 280 of defboot.lisp) is a macro, which is defined in terms of defun-expander (line 230 of defboot.lisp) which is what you're seeing.
Whereas, defmacro takes you directly to its definition (line 15 of defmacro.lisp) which is what you're seeing.
It seems to be doing useful things.
I defined a new function 'addmore'
(defun addmore (x y z)
(testfn x (testfn y z)))
I compiled it all, and M-. on 'addmore' takes me to the definition of testfn.
So I think it's all working.
I am trying to make use of function read-from-string, however i cannot make heads from tails with it.
If i understand documentation correctly, if second parameter is not true, then unbalanced expression in supplied string should not cause an error. However, if in try it out, i get:
> (read-from-string "(1 2" t 'EOF)
Condition of type: END-OF-FILE Unexpected end of file on
#<string-input stream from "(1 2">.
Available restarts:
(RESTART-TOPLEVEL) Go back to Top-Level REPL.
Broken at SI:BYTECODES. [Evaluation of: (READ-FROM-STRING "(1 2" ...)]
In: #<process TOP-LEVEL>.
>> 1
1
>> (read-from-string "(1 2" nil 'EOF)
Debugger received error of type: END-OF-FILE Unexpected end of file on
#<string-input stream from "(1 2">. Error flushed.
No matter shat i send, i always get an error.
I am using ECL 15.3.7
The eof-error-p and eof-value optional arguments control the result if you hit the end of the string before finding anything at all. So:
> (read-from-string "")
Error: ...
while
> (read-from-string "" nil 'foo)
foo
0
If the end of the string occurs part-way through an incomplete object an error is always signaled. The spec is clear on this although it's fairly far down the entry:
If the end of the supplied substring occurs before an object can be read, an error is signaled if eof-error-p is true. An error is signaled if the end of the substring occurs in the middle of an incomplete object.
I'm trying to build a simple function that gets a number, checks if the number is more the zero and return the square root of the number:
#lang pl 03
(: sqrtt: Number -> Number)
(define (sqrtt root)
(cond [(null? root) error "no number ~s"]
[( < root 0) error "`sqrt' requires a non-negative input ~s"]
[else (sqrt root)]))
but the result I get when I'm trying to compile the function is:
type declaration: too many types after identifier in: (: sqrtt: Number
-> Number)
Why am I getting that error and how do I fix it?
Try this:
(define (sqrtt root)
(cond [(null? root) (error "no number ~s")]
[(< root 0) (error "`sqrt' requires a non-negative input ~s")]
[else (sqrt root)]))
You simply forgot the () around error. Remember that error is a procedure and, like all other procedures, to apply it you have to surround it with parentheses together with its arguments.
The error message you're getting tells you that you have too many types after an identifier in a : type declaration. Now in racket, sqrtt: counts as an identifier. What you probably meant was sqrtt :, with a space in between.
(: sqrtt : Number -> Number)
The difference is that type declarations of the form (: id : In ... -> Out) are treated specially, but those of the form (: id In ... -> Out) are not. And sqrtt: is counts as the id.
There's also the problem Oscar Lopez pointed out, where you're missing parens around the error calls. Whenever you call a function in racket, including error, you need to wrap the function call in parens.
Also, the (null? root) clause is useless, since root has the type Number and null? will always return false for numbers.
And another thing, depending on what the pl language does, if you get a type error from < afterwards, that's because < operates on only Real numbers, but the Number type can include complex numbers. So you might have to change the type to Real or something.
The macro, transform!, as defined below seems to work for => (transform! ["foo" 1 2 3]). The purpose is to take in a list, with the first element being a string that represents a function in the namespace. Then wrapping everything into swap!.
The problem is that transform! doesn't work for => (transform! coll), where (def coll ["foo" 1 2 3]). I am getting this mystery exception:
#<UnsupportedOperationException java.lang.UnsupportedOperationException: nth not supported on this type: Symbol>
The function:
(defmacro transform!
" Takes string input and update data with corresponding command function.
"
[[f & args]] ;; note double brackets
`(swap! *image* ~(ns-resolve *ns* (symbol f)) ~#args))
I find it strange that it works for one case and not the other.
Macros work at compile-time and operate on code, not on runtime data. In the case of (transform! coll), the macro is being passed a single, unevaluated argument: the symbol coll.
You don't actually need a macro; a regular function will suffice:
(defn transform! [[f & args]]
(apply swap! *image* (resolve (symbol f)) args)))
Resolving vars at runtime could be considered a code smell, so think about whether you really need to do it.
You're passing a symbol to the macro, namely coll. It will try to pull that symbol apart according to the destructuring statement [f & args], which won't be possible of course.
You can also use (resolve symbol) instead of (ns-resolve *ns* symbol).