In regular Racket, ((curry * 2) 3) works as expected, with 6 as a result.
However, in Typed Racket:
> ((curry * 2) 3)
; readline-input:3:0: Type Checker: could not apply function;
; wrong number of arguments provided
; expected: 0
; given: 1
; in: ((curry * 2) 3)
; [,bt for context]
Why?
I believe it has something to do with the fact that * can take only one argument, so when you curry it with a parameter, it is returning a procedure that takes no additional arguments. Type (curry * 2) at the command line in typed/racket and observe the result: (-> Number).
Note that there is only a return type and no parameter. I don't see a way around this in typed racket, but I hope that at least explains why it is happening. You should be safe to use currying with more complex procedures as long as they do not have an option to take only one parameter.
Related
I'm new in LISP and I'm trying to understand recursion.
What I know is that recursion needs a STOP condition. In my code below, can you explain to me why (equal x 0) 1 is my STOP condition SINCE fact(- X 1) could continue indefinitely as in my second condition, I have set to t the second line of my cond which means it should continue.
BUT when I run the program, it works fine though. Below is my code (found by chance)
(defun fact(x)
(cond
((equal x 0) 1)
(t (*(fact(- x 1)) x))
)
)
cond expresssions have a number of clauses. Each clause is of the form (expr1 expr2). If the expr1 evaluates to true then expr2 is evaluated and that is the returned value of thecond`. No other clauses are evaluated.
So, once x becomes 0 the first clauses of cond evaluates to true and that call to fact returns 1.
The other clause of cond has a first expression of t which is true by definition; thus if the first clause is not used it always uses the second clause. (A cond clause with t is like an "else" in an "if" statement in other langugaes.)
This function is recursive, if you call it with an argument of 2, it checks if 2 == 0, it doesn't so then it multiplies 2 with the value returned by recursively calling itself with 1. Since 1 != 0 it will return the value of 1 multiplied by the value of recursively calling itself with 0. Since 0 does equal 0 it just returns 1, which is used one layer to return 1 which is then used at the top layer of this recursion to return 2.
Common Lisp has a function trace which will let you see when your function is called and with what arguments. Typically each recursive call will be indented so you can see something like this:
(fact 2)
(fact 1)
(fact 0)
Which can be helpful for understanding this function.
(As mentioned in a comment - this function doesn't catch the case of a negative input - but that is error handling and could be easily fixed).
I have written this in CoffeeScript:
expect (#controllerInstance[fn]).toHaveBeenCalled()
and it's been compiled to this:
return expect(this.controllerInstance[fn].toHaveBeenCalled());
Why has it re-arranged the method call parenthesis? And how would I make it compile to what I want?
what I need to see is:
expect(this.controllerInstance[fn]).toHaveBeenCalled()
Parentheses serve two purposes in CoffeeScript:
Expression grouping, e.g. (6 + 11) * 23 or f (-> 6), (-> 11).
Function calling, e.g. f(), g('pancakes').
Since parentheses are sometimes optional in a function call, there is some ambiguity in:
f (expr)
Are those parentheses being used to call f with expr as its argument or are the parentheses really a part of f's argument? CoffeeScript chooses the latter interpretation.
You'll see similar problems if write:
f (x) + 1
CoffeeScript sees that as:
f((x) + 1)
Similarly, if you write:
f (x, y)
you'll get an unexpected , error; CoffeeScript doesn't have a comma operator so x, y is not a valid expression.
You can remove the ambiguity by removing the whitespace before the opening parenthesis:
expect(#controllerInstance[fn]).toHaveBeenCalled()
Removing the space after expect forces CoffeeScript to view the parentheses around #controllerInstance[fn] to be seen as function-calling parentheses.
My question is quite similar to this one, but with a difference. I want to create a macro (or whatever) that behaves this way:
julia> #my-macro x + 2
:(x + 2)
(note that x + 2 is not enclosed in quotes). Is there something like that in Julia? And if there is not, how do I do it? (Please, give a detailed explanation about why it works.)
The input expression to the macro needs to be quoted because a macro returns an expression, which are evaluated, while you would like to get the expression itself, hence you need an extra quoting. The quoting can be done as:
macro mymacro(ex)
Expr(:quote,ex) # this creates an expression that looks like :(:(x + 2))
end
e=#mymacro x + 2 #returns :(x + 2)
Another shorter possibility:
macro mymacro(ex)
QuoteNode(ex)
end
e = #mymacro x + 2 #returns :(x + 2)
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).
I was messing around in SLIME (connected a Clozure REPL) when I discovered this:
It looks like the variables +, *, and / are all bound to some variation on recent input, + is the input itself, * is the result of evaluating that input, and / is the result contained in a list.
Is this right? Who is responsible for this, SLIME or Clozure? I couldn't find anything in the SLIME manual.
Thanks!
; SLIME 2010-05-13
CL-USER> +
NIL
CL-USER> *
NIL
CL-USER> /
(NIL)
CL-USER> -
-
CL-USER> +
-
CL-USER> (list 1 2)
(1 2)
CL-USER> +
(LIST 1 2)
CL-USER> /
((LIST 1 2))
CL-USER> (+ 1 2)
3
CL-USER> /
(3)
CL-USER> *
(3)
CL-USER> (* 1 2)
2
CL-USER> *
2
CL-USER>
Those are all, and more, specified by the Common Lisp standard. Search the environment dictionary for 'Variable'.
+
++
+++
While a form is being evaluated by the top-level loop, the variable + is bound to the previous form read by the loop. The variable ++ holds the previous value of + (that is, the form evaluated two interactions ago), and +++ holds the previous value of ++.
-
While a form is being evaluated by the top-level loop, the variable - is bound to the form itself; that is, it is the value about to be given to + once this interaction is done.
*
**
***
While a form is being evaluated by the top-level loop, the variable * is bound to the result printed at the end of the last time through the loop; that is, it is the value produced by evaluating the form in +. If several values were produced, * contains the first value only; * contains nil if zero values were produced. The variable ** holds the previous value of * (that is, the result printed two interactions ago), and * holds the previous value of **.
/
//
///
While a form is being evaluated by the top-level loop, the variable / is bound to a list of the results printed at the end of the last time through the loop; that is, it is a list of all values produced by evaluating the form in +. The value of * should always be the same as the car of the value of /. The variable // holds the previous value of / (that is, the results printed two interactions ago), and /// holds the previous value of //. Therefore the value of ** should always be the same as the car of //, and similarly for * and ///.
From Common Lisp the Language, 2nd Edition 20.2