I believe this is valid Clojure code - and runs fine in a Lein console REPL - but errors inside the Cursive REPL:
Connecting to local nREPL server...
Clojure 1.8.0
nREPL server started on port 41303 on host 127.0.0.1 - nrepl://127.0.0.1:41303
*ns*
=> #object[clojure.lang.Namespace 0x4394b860 "user"]
(defn concat-some
[f vec1 vec2]
((fn [x] (filter f x)
(concat vec1 vec2))))
=> #'user/concat-some
(concat-some even? [1 2 3] [4 5 6])
clojure.lang.ArityException: Wrong number of args (0) passed to: user/concat-some/fn--4953
Am I missing something here?
Thank you for your help!
Edit and Follow-up:
This is definitely a Parinfer issue. This code:
(defn concat-some
[f vec1 vec2]
((fn [x] (filter f x))
(concat vec1 vec2)))
(concat-some even? [1 2 3] [4 5 6])
when pasted into the Cursive REPL with Parinfer turned on produces an incorrect paste and the resulting ArityException above. The same code pasted into the same REPL with Paredit turned on or Structural Editing turned off produces the expected output:
;; => #'user/concat-some
;; => (2 4 6)
I did not know that Structural Editing when active in Cursive is used in the editor - AND the REPL. I would still hope that valid code is valid code regardless of mode and wonder if this is the intended result of pasting into a Cursive/Parinfer REPL.(?)
Thank you again for your help with this.
Your editor might have a slurp/barf command that you accidentally triggered with a keyboard shortcut, but this copy/paste has gone awry.
You have (( which is generally a bad sign unless done correctly like in the examples:
(defn concat-some
[f vec1 vec2]
((fn [x] (filter f x))
(concat vec1 vec2)))
(concat-some even? [1 2 3] [4 5 6])
In yours the last paren on the line with filter is missing, and put at the end of the function instead. this means you are calling a function with 0 arguments, but your call to fn produces a function that takes 1 argument x
Related
In python objects, overriding the methods __repr__ and __str__ of an object allows one to provide "unambiguous" and "human-readable" representations of the object, respectively. How does one achieve similar behavior in Racket?
I came across the printable<%> interface here, which seems like it should be usable for this purpose, but I haven't been able to get it to work quite as I expect it to. Building on the standard "fish" example from the docs:
(define fish%
(class* object% (printable<%>)
(init size) ; initialization argument
(super-new) ; superclass initialization
;; Field
(define current-size size)
;; Public methods
(define/public (get-size)
current-size)
(define/public (grow amt)
(set! current-size (+ amt current-size)))
(define/public (eat other-fish)
(grow (send other-fish get-size)))
;; implement printable interface
(define/public (custom-print port quoting-depth)
(print "Print called!"))
(define/public (custom-write port)
(print "Write called!"))
(define/public (custom-display port)
(print "Display called!"))))
This is the output I get:
> (define f (new fish% [size 10]))
> f
"Display called!""Display called!""Print called!"
> (print f)
"Write called!""Print called!"
> (display f)
"Display called!""Display called!"
> (write f)
"Write called!""Write called!"
>
So the question is threefold:
Why does it behave this way, i.e. with the multiple methods being invoked on an apparently singular rendering of the object?
What should the methods custom-print, custom-write, and custom-display evaluate to? Should they simply return a string, or should they actually entail the side effect of printing, writing, or displaying, as the case may be? E.g. should the custom-write method invoke the write function internally?
Is this the right construct to use for this purpose at all? If not, is there one / what is it?
As for
Why does it behave this way, i.e. with the multiple methods being invoked on an apparently singular rendering of the object?
You have accidently used print in write, so writing the value, will first print the value.
(define/public (custom-write port)
(print "Write called!"))
A similar problem is present in display.
Also remember to print/write/display to the proper port.
Try
#lang racket
(define fish%
(class* object% (printable<%>)
(init size) ; initialization argument
(super-new) ; superclass initialization
;; Field
(define current-size size)
;; Public methods
(define/public (get-size)
current-size)
(define/public (grow amt)
(set! current-size (+ amt current-size)))
(define/public (eat other-fish)
(grow (send other-fish get-size)))
;; implement printable interface
(define/public (custom-print port quoting-depth)
(print (~a "Print " current-size "\n") port))
(define/public (custom-write port)
(write (~a "Write " current-size "\n") port))
(define/public (custom-display port)
(display (~a "Display " current-size "\n") port))))
In the repl you will see:
> (define f (new fish% [size 10]))
> f
"Print 10\n"
> (display f)
Display 10
> (write f)
"Write 10\n"
Another answer has already helped you find the problem in your code—you need to use the port given as an argument, not the implicit (current-output-port)—but the explanation isn't quite right. To tackle your questions in reverse order:
Is this the right construct to use for this purpose at all? If not, is there one / what is it?
Yes, printable<%> is the right construct to use to customize printing of a class-based object. More generally, a struct type that is not a class can customize printing for instance through the gen:custom-write generic interface or the low-level prop:custom-write struct type property, which is used to implement printable<%>.
What should the methods custom-print, custom-write, and custom-display evaluate to? Should they simply return a string, or should they actually entail the side effect of printing, writing, or displaying, as the case may be? E.g. should the custom-write method invoke the write function internally?
The methods should actually do the side-effect of performing IO on the port they are given as an argument. They should use the corresponding function (e.g. write for custom-write, print for custom-print) internally for recursively printing/writing/displaying values in fields. On the other hand, when directly emitting particular characters, they should generally use functions like write-char, write-string, or printf. The docs for gen:custom-write give an example of a tuple datatype that prints as <1, 2, "a">: it uses write-string for the angle-brackets and commas, but recursive print/write/display for the elements of the tuple.
Why does it behave this way, i.e. with the multiple methods being invoked on an apparently singular rendering of the object?
This is the most involved part of your question. Printing in Racket is customizable through several hooks: for a few examples, see current-print, port-write-handler, global-port-print-handler, and make-tentative-pretty-print-output-port. Many of these customization hooks use intermediate ports in the process of producing output.
One thing that is not a part of the explanation is the fact that you used print in your implementation, particularly as print is bound to the normal Racket function by lexical scope, not to a method of your object.
As an illustration, consider the following adaptation of your example, which reports to the (current-output-port) the identity of the port given as an argument to the method:
#lang racket
(define report
(let ([next-id 0]
[id-cache (make-hash)])
(λ (op port)
(printf "~a ~a ~v\n"
op
(hash-ref id-cache
port
(λ ()
(define id next-id)
(hash-set! id-cache port id)
(set! next-id (add1 next-id))
id))
port))))
(define fish%
(class* object% (printable<%>)
(super-new)
;; implement printable interface
(define/public (custom-print port quoting-depth)
(report "custom-print " port))
(define/public (custom-write port)
(report "custom-write " port))
(define/public (custom-display port)
(report "custom-display" port))))
(define f (new fish%))
f
(print f)
(newline)
(display f)
(newline)
(write f)
In DrRacket, this generates the output:
custom-display 0 #<output-port:null>
custom-display 1 #<output-port:null>
custom-print 2 #<printing-port>
custom-display 3 #<output-port:null>
custom-display 4 #<output-port:null>
custom-print 5 #<printing-port>
custom-display 6 #<output-port:null>
custom-display 7 #<printing-port>
custom-display 8 #<output-port:null>
custom-write 9 #<printing-port>
while at the command line, the output is:
$ racket demo.rkt
custom-write 0 #<output-port:null>
custom-print 1 #<output-port:redirect>
custom-write 2 #<output-port:null>
custom-print 3 #<output-port:redirect>
custom-display 4 #<output-port:null>
custom-display 5 #<output-port:redirect>
custom-write 6 #<output-port:null>
custom-write 7 #<output-port:redirect>
No breakpoint can be set on line 5, which contains [x].
IntelliJ won't let me do so. I used different plugin, such as La Clojure and Cursive. Both stop at line 3 rather than line 5.
So, how people step into the code in Clojure?
Is there any syntax suggestion or maybe tool to help with?
(defn flattenlist
([x & more]
(concat (if (vector? x)
(apply flattenlist x)
[x]
)
(if (= more nil)
nil
(apply flattenlist more))))
)
(flattenlist [[1 [[2]]] 3 [4 5] 6])
First, by convention, all trailing parentheses are on the same line, something like this:
(defn flattenlist
([x & more]
(println x)
(concat (if (vector? x)
(apply flattenlist x)
[x])
(if (= more nil)
nil
(apply flattenlist more)))))
(flattenlist [[1 [[2]]] 3 [4 5] 6])
Secondly, when you use composable functions, it is easy to insert a println and run/test just that function because it is referentially transparent. I am only a Clojure hobbyist, but I typically debug with printlns and unit tests. Using breakpoints isn't really that reliable.
If you really want something similar to setting a breakpoint, you can try using this debugging macro (not mine).
I tried to run a multi line while statement in the Rebol REPL (aka, command line),
like in http://www.rebol.com/docs/expert-intro.html
if size [
print "ok"
]
I typed it line by line but after if size [, it says:
>> size: 0
== 0
>> if size [
** Syntax error: missing "]" at "end-of-script"
** Near: (line 1) if size [
>>
Is this a problem with the REPL, the way I am typing it, or something else?
In the Rebol 2 REPL, this should just work. After the first line, the prompt should change into a "continuation prompt":
>> if size [
[ ;<cursor here>
In Rebol 3, the REPL currently (2013-02) does not support multi-line expressions.
I too got very frustrated with this issue.
But I found a truly terrible work-around, namely: Pack up your code into a string and 'do it.
So for your example the way it can be entered is like this:
>> size: 0
== 0
>> do {if size [^/^-print "ok"^/]}
ok
>>
I warned you it was terrible, right?
So, I have read from
setq and defvar in lisp,
http://www.cs.ucf.edu/courses/cop4020/spr2006/plsetup.html, and
In Lisp, how do I fix "Warning: Assumed Special?"
among other places about the difference between setf and defvar. So I decided to play around with the idea a bit:
CL-USER> (defun foo ()
(setf x 10)
(print x))
; in: DEFUN FOO
; (SETF X 10)
; ==>
; (SETQ X 10)
;
; caught WARNING:
; undefined variable: X
;
; compilation unit finished
; Undefined variable:
; X
; caught 1 WARNING condition
FOO
CL-USER> x
; Evaluation aborted on #<UNBOUND-VARIABLE X {10040F1543}>.
CL-USER> (foo)
10
10
CL-USER> x
10
Okay, I know that setf should be used to change the value of an existing variable, but the undefined variable warning seems to be handled pretty well in SBCL (though I have read that different CL implementations may handle this differently, thus it isn't the best thing to do).
Enter the second test:
CL-USER> (defun bar ()
(defvar y 15)
(print y))
; in: DEFUN BAR
; (PRINT Y)
;
; caught WARNING:
; undefined variable: Y
;
; compilation unit finished
; Undefined variable:
; Y
; caught 1 WARNING condition
BAR
CL-USER> y
; Evaluation aborted on #<UNBOUND-VARIABLE Y {10045033D3}>.
CL-USER> (bar)
15
15
CL-USER> y
15
As per the links, I changed the setf to defvar which I think should create and bind the variable all at once. Now my undefined variable warning gets pushed into the (print y) line ... what is going on here?
As a secondary question, I am expecting the values of any variables assinged within a funciton to be inaccessible outside of the function, as is the case in Python:
>>> def foo():
... x = 10
... print x
...
>>> foo()
10
>>> x
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
NameError: name 'x' is not defined
I am guessing this has something to do with the way common lisp deals with scope, ie defvar creates a "global special variabe" ... So I tried one last time with (let ...)
CL-USER> (defun baz ()
(let ((z 10)) (print z))
(incf z 10)
(print z))
; in: DEFUN BAZ
; (INCF Z 10)
; --> LET*
; ==>
; (SETQ Z #:NEW0)
;
; caught WARNING:
; undefined variable: Z
;
; compilation unit finished
; Undefined variable:
; Z
; caught 1 WARNING condition
And after reading What's difference between defvar, defparameter, setf and setq, this one seems to work right:
CL-USER> (defun apple ()
(defparameter x 10)
(print 10))
APPLE
CL-USER> x
; Evaluation aborted on #<UNBOUND-VARIABLE X {1004436993}>.
CL-USER> (apple)
10
10
CL-USER> x
10
Just to reiterate my questions:
1) what is really going on with setf, defvar and let?
2) is there a way to get common lisp to scope the variables inside a function as in the python example?
answering 2) DEFVAR defines a variable. But it has not been executed. So the compiler does not know about the variable in the print form - when compiling the DEFUN form.. It's also inside a DEFUN. Thus it is not on the top-level. As a top-level form the compiler would recognize the DEFVAR and would notice that y is a global special variable.
Just to reiterate my questions: 1) what is really going on with setf, defvar and let?
2) is there a way to get common lisp to scope the variables inside a function as in the python example?
1) SETF sets a variable value, but does not define it. If that variable is undefined, then the Common Lisp standard does not really say what happens. Most Common Lisp implementations will do something useful. Typically it gets executed as if the variable would have been declared special (thus you also get a warning).
DEFVAR is used as a top-level form (usually not inside functions) to define global special variables. Since DEFVAR declares the variable name to be special, it is a very useful convention to write a variable with stars around it: *y* instead of just y.
LET defines a scope for local variables.
2) Common Lisp functions have the parameter list to introduce variables. Other than that they don't define a variable scope. If you want to introduce a local variable inside a function, use LET.
>>> def foo():
... x = 10
... print x
Is
(defun foo ()
(let ((x 10))
(print x)))
Again: a function does not provide a scope for variables, such that assigning a variable inside a function will automagically define it to be function-local. Use LET instead.
Note also that LET is syntactic sugar, mostly: (let ((a 1) (b 2)) (+ a b)) is basically doing the same as ((lambda (a b) (+ a b)) 1 2). It's just a simple function application written differently to improve it for the human reader.
There is also support in Common Lisp for an older syntax:
(defun foo (&aux (x 10))
(print x))
Above defines a local variable X, just like a LET would do.
I'll keep it short and simple:
1) what is really going on with setf, defvar and let?
defvar and defparameter are used to declare and set globally special variables. They only differ when the name is already bound.
setf is used for assignment (to special variables, lexical variables, and other – possibly custom – setfable places.)
let (and let*) creates new variable bindings that are visible inside its body. It may create either lexical or special bindings, depending on (global or local) declarations. If there are no special declarations, lexical bindings will be created.
2) is there a way to get common lisp to scope the variables inside a
function as in the python example?
Put the code inside let's body, where the binding is visible:
CL-USER> (defun baz ()
(let ((z 10))
(print z)
(incf z 10) ; i.e. (setf z (+ z 10))
(print z)))
BAZ
CL-USER> (baz)
10
20
20
CL-USER> z
; Evaluation aborted on #<UNBOUND-VARIABLE #x186C611E>.
Given the program:
import Debug.Trace
main = print $ trace "hit" 1 + trace "hit" 1
If I compile with ghc -O (7.0.1 or higher) I get the output:
hit
2
i.e. GHC has used common sub-expression elimination (CSE) to rewrite my program as:
main = print $ let x = trace "hit" 1 in x + x
If I compile with -fno-cse then I see hit appearing twice.
Is it possible to avoid CSE by modifying the program? Is there any sub-expression e for which I can guarantee e + e will not be CSE'd? I know about lazy, but can't find anything designed to inhibit CSE.
The background of this question is the cmdargs library, where CSE breaks the library (due to impurity in the library). One solution is to ask users of the library to specify -fno-cse, but I'd prefer to modify the library.
How about removing the source of the trouble -- the implicit effect -- by using a sequencing monad that introduces that effect? E.g. the strict identity monad with tracing:
data Eval a = Done a
| Trace String a
instance Monad Eval where
return x = Done x
Done x >>= k = k x
Trace s a >>= k = trace s (k a)
runEval :: Eval a -> a
runEval (Done x) = x
track = Trace
now we can write stuff with a guaranteed ordering of the trace calls:
main = print $ runEval $ do
t1 <- track "hit" 1
t2 <- track "hit" 1
return (t1 + t2)
while still being pure code, and GHC won't try to get to clever, even with -O2:
$ ./A
hit
hit
2
So we introduce just the computation effect (tracing) sufficient to teach GHC the semantics we want.
This is extremely robust to compile optimizations. So much so that GHC optimizes the math to 2 at compile time, yet still retains the ordering of the trace statements.
As evidence of how robust this approach is, here's the core with -O2 and aggressive inlining:
main2 =
case Debug.Trace.trace string trace2 of
Done x -> case x of
I# i# -> $wshowSignedInt 0 i# []
Trace _ _ -> err
trace2 = Debug.Trace.trace string d
d :: Eval Int
d = Done n
n :: Int
n = I# 2
string :: [Char]
string = unpackCString# "hit"
So GHC has done everything it could to optimize the code -- including computing the math statically -- while still retaining the correct tracing.
References: the useful Eval monad for sequencing was introduced by Simon Marlow.
Reading the source code to GHC, the only expressions that aren't eligible for CSE are those which fail the exprIsBig test. Currently that means the Expr values Note, Let and Case, and expressions which contain those.
Therefore, an answer to the above question would be:
unit = reverse "" `seq` ()
main = print $ trace "hit" (case unit of () -> 1) +
trace "hit" (case unit of () -> 1)
Here we create a value unit which resolves to (), but which GHC can't determine the value for (by using a recursive function GHC can't optimise away - reverse is just a simple one to hand). This means GHC can't CSE the trace function and it's 2 arguments, and we get hit printed twice. This works with both GHC 6.12.4 and 7.0.3 at -O2.
I think you can specify the -fno-cse option in the source file, i.e. by putting a pragma
{-# OPTIONS_GHC -fno-cse #-}
on top.
Another method to avoid common subexpression elimination or let floating in general is to introduce dummy arguments. For example, you can try
let x () = trace "hi" 1 in x () + x ()
This particular example won't necessarily work; ideally, you should specify a data dependency via dummy arguments. For instance, the following is likely to work:
let
x dummy = trace "hi" $ dummy `seq` 1
x1 = x ()
x2 = x x1
in x1 + x2
The result of x now "depends" on the argument dummy and there is no longer a common subexpression.
I'm a bit unsure about Don's sequencing monad (posting this as answer because the site doesn't let me add comments). Modifying the example a bit:
main :: IO ()
main = print $ runEval $ do
t1 <- track "hit 1" (trace "really hit 1" 1)
t2 <- track "hit 2" 2
return (t1 + t2)
This gives us the following output:
hit 1
hit 2
really hit 1
That is, the first trace fires when the t1 <- ... statement is executed, not when t1 is actually evaluated in return (t1 + t2). If we define the monadic bind operator as
Done x >>= k = k x
Trace s a >>= k = k (trace s a)
instead, the output will reflect the actual evaluation order:
hit 1
really hit 1
hit 2
That is, the traces will fire when the (t1 + t2) statement is executed, which is (IMO) what we really want. For example, if we change (t1 + t2) to (t2 + t1), this solution produces the following output:
hit 2
really hit 2
hit 1
The output of the original version remains unchanged, and we don't see when our terms are really evaluated:
hit 1
hit 2
really hit 2
Like the original solution, this also works with -O3 (tested on GHC 7.0.3).