Write, compile, and test a funtion in Common Lisp that takes a list and counts the total of positive integers in the List. Must compile then execute .lisp file containing the function. after compilation of that file start to pass it list where after the results for the result to be produced therefore testing the correctness of the function.
I have the function. I can run it rawly by putting if directly into the Lisp command line. Simply put I just need to figure out how to compile the file and then pass it list on the terminal to test it.
(count-if #'(lamda (x) (> x 0))
i need to compile that
then for example pass it this ex:: ( 1 2 3 4 5)
and the result should be :: 5
this is because their are 5 values that equal more then 0
Write a file:
$ echo "(defun test () (print :test))" > test.lisp
In the same directory, start you Common Lisp environment (example with CCL), you have a REPL; compile the file:
? (compile-file "test.lisp")
#P"/tmp/test.lx64fsl"
NIL
NIL
Note that if you try to run the test function, there will be an error because it is undefined in your environment.
Load the resulting object file; if you load "test", the object file is used if available; you could have called load directly on the ".lisp" file, but then there are no guarantees the file is compiled or interpreted. That's a minor detail here, you probably should not care about compiling or not at this point.
? (load "test")
Now, test is available in your environment, you can call it:
? (test)
:TEST ;; what the function printed
:TEST ;; the returned value, automatically printed by the REPL
Without restarting the Lisp environment, you can edit the file, and reload it.
This is a minimalistic setup but that should be enough for starting.
Related
I am trying to dynamically generate a bunch of test cases.
Basically I want to run the same tests several times with different values. Maybe there's a better way to do that, if so let me know, I haven't found it yet.
I found make-test-suite which says you can pass it a list of test-case instances.
So I made a for/fold loop which collects the test cases generated for each set of values into a flat list.
What I don't understand is it seems to successfully run all the tests while also raising an exception:
tests->test-suite-action received #<void> in list of tests (#<void> #<void> #<void> #<void> #<void> #<void> #<void> #<void>), which is not a test.
context...:
/usr/share/racket/pkgs/rackunit-lib/rackunit/private/test-suite.rkt:139:7
/usr/share/racket/pkgs/rackunit-lib/rackunit/private/test-suite.rkt:136:2
/usr/share/racket/pkgs/rackunit-lib/rackunit/private/test-suite.rkt:61:0: apply-test-suite
/usr/share/racket/pkgs/rackunit-lib/rackunit/text-ui.rkt:91:0: run-tests
"/write-thru-hash/tests.rkt": [running body]
temp35_0
for-loop
run-module-instance!
/usr/share/racket/pkgs/compiler-lib/compiler/commands/test.rkt:179:16
...
1 1 write-thru-hash/tests.rkt
8 tests passed
rkt-write-thru-hash_tests_1 exited with code 1
I put a writeln in each of my test cases and I see those lines printed out where I abbreviated with ... above. So I know the tests are actually running.
(The tests also ran and worked fine before I multiplied them with the for/fold loop and just built them in the body of test-suite)
My tests.rkt code looks like:
(define test-cases-list
(for/fold ([test-cases (list)])
([db-type (list 'sqlite 'postgres)])
(append test-cases
(list
(test-case/fixture "basic operations" ... )
(test-case/fixture "complex serializable keys and values" ... )
(test-case/fixture "custom table-name" ... )
(test-case/fixture "use initial src-hash" ... )))))
(define db-tests
(make-test-suite "db-tests" test-cases-list))
(I'm using the fixture library https://docs.racket-lang.org/fixture/)
UPDATE:
Actually I think the writeln in my test cases are printing at definition time ... i.e. they are running too early because they are outside of the test-suite context.
I guess the tail check in each test-case returns #<void>, so I have filled a list with the results of the tests (voids) rather than the test cases themselves and given that to the test suite, hence the error.
But then I don't see how to actually use make-test-suite...?
Eventually found a simple way to do this.
My problem was in trying to have several variations of my test cases all dynamically generated into one test-suite. I did not find a way to get that to work, I suspect I would have to write a macro.
Instead the simple way is to dynamically define multiple test-suite instances and then loop over a list of them to run them:
(define db-test-suites
(for/list ([db-type (list 'sqlite 'postgres)]
[db-conn-fixture (list sqlite-connection-delete-after-use
postgres-connection)])
(define suite-name (format "db-tests: ~a" db-type))
(test-suite suite-name
(test-case/fixture "basic operations"
#:fixture db-conn-fixture
(define db-conn (fixture-value db-conn-fixture))
...)
(test-case/fixture "complex serializable keys and values"
#:fixture db-conn-fixture
(define db-conn (fixture-value db-conn-fixture))
...))))
(for ([current-test-suite db-test-suites])
(run-tests current-test-suite))
UPDATE:
I also found a way to actually use make-test-suite:
(define all-tests (make-test-suite "db-test-suites" db-test-suites))
(run-tests all-tests)
This takes advantage of the fact that a test-suite can contain other nested test-suites. I think this form is nicer (a single run-tests call) than the one above (multiple run-tests calls in a for loop).
All my problems in the original question were in trying to pre-define a bunch of test-case instances outside of a test-suite container. But here we pass make-test-suite a list of test-suite instances, allowing the tests within them to defer running until we later call run-tests.
I will get an undefined function warning about f2 in SBCL with following code sample.
Is it possible that I can declare f2 first, like in C, to avoid the warning.
I Googled, without any clue.
(defun f ()
(print (f2)))
(defun f2 ()
(print "f2"))
If you use the function before you define it in a single compilation unit, e.g., the same file, then the compiler will not complain about the undefined function (plain load still may, so compile your code first!)
Otherwise, you can declaim ftype:
(declaim (ftype (function () t) f2)
meaning that f2 accepts no arguments and returns a single value of type t.
However, it makes much more sense to compile the file where you use the function while the definition is already loaded. You can (and should!) use asdf as a Lisp-specific make(1): specifying dependencies so that the compiler has the definitions of all the functions while it compiles their users.
If the functions are in the same file, a compiler won't give a warning.
Example SBCL:
bash-3.2$ sbcl
This is SBCL 1.3.10, an implementation of ANSI Common Lisp.
More information about SBCL is available at <http://www.sbcl.org/>.
SBCL is free software, provided as is, with absolutely no warranty.
It is mostly in the public domain; some portions are provided under
BSD-style licenses. See the CREDITS and COPYING files in the
distribution for more information.
* (compile-file "/tmp/order.lisp")
; compiling file "/private/tmp/order.lisp" (written 28 NOV 2016 12:14:37 PM):
; compiling (DEFUN F ...)
; compiling (DEFUN F2 ...)
; /tmp/order.fasl written
; compilation finished in 0:00:00.178
#P"/private/tmp/order.fasl"
NIL
NIL
* (load *)
T
*
You do not have to put functions into the same file in Common Lisp for them to be in the same compilation unit.
Doing this is an anti-pattern; large programs are, of course, constructed from modules, most of which call functions that are in another module. You cannot roll an entire program into a single physical module to avoid a warning about this.
Lisp has a mechanism by which a cluster of compiles is regarded as a single compilation unit: the with-compilation-unit macro:
(with-compilation-unit
(compile-file "file-f")
(compile-file "file-f2"))
If you use the ASDF build system, I seem to recall it does the with-compilation-unit under the hood for you, around all of the files of a system.
This approach will help eliminate those warnings which are deferred. That is to say, if the implementation warns about undefined identifiers, but defers doing so until the end of the compilation unit, then if you use this macro, the deferral is extended until the end of the total compilation unit spanning multiple files.
When warnings about undefined identifiers are deferred, the purpose is to eliminate those warnings. If the definition of a previously undefined function appears before the end of a translation unit, the warning can be suppressed. This macro allows a definition in one file to suppress a deferred warning in another file.
If an implementation doesn't defer warnings, then the macro will not help.
Just change the order of your defun's. First, define f2 and than f.
I have a code-base for a graphics program in cljx that gets compiled to Clojure and ClojureScript.
I now want to introduce my first macro.
(defmacro optional-styled-primitive [args body]
(let [extra (conj args 'style)]
`(fn (~extra (->SShape ~'style ~body))
(~args (->SShape {} ~body))
)
)
)
The purpose of this macro is to take a list of arguments, and an expression that uses those arguments to generate a geometry. And to return a function with two arities : one of which takes an optional style parameter. This macro is then to be used within the file where it's defined, to make a number of other functions that optionally take styles. For example :
(def square (optional-styled-primitive [n] [[0 0] [0 n] [n n] [n 0]]))
But introducing this macro, obviously, breaks the ClojureScript stage of the compilation.
What I can't figure out is what to do about it. The online discussions talk about ClojureScript needing to use :require-macros but I never actually export or require this macro anywhere. I just want to use it where it's defined. So how can I, in the middle of a file, tell the compiler to use Clojure to expand this macro, before it gets to the ClojureScript compiler?
OK.
I've made some progress with this.
Here's what I did.
1) I refactored my macro definition out into a separate file called macros.cljx
2) In the file where I was using the macros, I did this. (A different require for clj and cljs)
(#+clj :require #+cljs :require-macros
[myapp.macros :refer [optional-styled-primitive]])
3) I updated my leiningen project.clj file :
:cljsbuild {:builds [{
:source-paths ["target/classes" "src-cljs" ] ...
The important thing here I added "target/classes", which is the output-path where cljx puts the clj files it creates, to the cljsbuild source-paths. This is where the cljsbuild process can find the clj file with the macro definition.
I'm not sure if this is the right or principled way to solve the problem. But it now seems to be working (unless I'm confused by something).
There are languages other than Lisp (ruby, scala) that say they use REPL (Read, Eval, Print, Loop), but it is unclear whether what is meant by REPL is the same as in Lisp. How is Lisp REPL different from non-Lisp REPL?
The idea of a REPL comes from the Lisp community. There are other forms of textual interactive interfaces, for example the command line interface. Some textual interfaces also allow a subset of some kind of programming language to be executed.
REPL stands for READ EVAL PRINT LOOP: (loop (print (eval (read)))).
Each of the four above functions are primitive Lisp functions.
In Lisp the REPL is not a command line interpreter (CLI). READ does not read commands and the REPL does not execute commands. READ reads input data in s-expression format and converts it to internal data. Thus the READ function can read all kinds of s-expressions - not just Lisp code.
READ reads a s-expression. This is a data-format that also supports encoding source code. READ returns Lisp data.
EVAL takes Lisp source code in the form of Lisp data and evaluates it. Side effects can happen and EVAL returns one or more values. How EVAL is implemented, with an interpreter or a compiler, is not defined. Implementations use different strategies.
PRINT takes Lisp data and prints it to the output stream as s-expressions.
LOOP just loops around this. In real-life a REPL is more complicated and includes error handling and sub-loops, so-called break loops. In case of an error one gets just another REPL, with added debug commands, in the context of the error. The value produced in one iteration also can be reused as input for the next evaluation.
Since Lisp is both using code-as-data and functional elements, there are slight differences to other programming languages.
Languages that are similar, those will provide also similar interactive interfaces. Smalltalk for example also allows interactive execution, but it does not use a data-format for I/O like Lisp does. Same for any Ruby/Python/... interactive interface.
Question:
So how significant is the original idea of READing EXPRESSIONS, EVALuating them and PRINTing their values? Is that important in relation to what other languages do: reading text, parsing it, executing it, optionally print something and optionally printing a return value? Often the return value is not really used.
So there are two possible answers:
a Lisp REPL is different to most other textual interactive interfaces, because it is based on the idea of data I/O of s-expressions and evaluating these.
a REPL is a general term describing textual interactive interfaces to programming language implementations or subsets of those.
REPLs in Lisp
In real implementations Lisp REPLs have a complex implementation and provide a lot of services, up to clickable presentations (Symbolics, CLIM, SLIME) of input and output objects. Advanced REPL implementations are for example available in SLIME (a popular Emacs-based IDE for Common Lisp), McCLIM, LispWorks and Allegro CL.
Example for a Lisp REPL interaction:
a list of products and prices:
CL-USER 1 > (setf *products* '((shoe (100 euro))
(shirt (20 euro))
(cap (10 euro))))
((SHOE (100 EURO)) (SHIRT (20 EURO)) (CAP (10 EURO)))
an order, a list of product and amount:
CL-USER 2 > '((3 shoe) (4 cap))
((3 SHOE) (4 CAP))
The price for the order, * is a variable containing the last REPL value. It does not contain this value as a string, but the real actual data.
CL-USER 3 > (loop for (n product) in *
sum (* n (first (second (find product *products*
:key 'first)))))
340
But you can also compute Lisp code:
Let's take a function which adds the squares of its two args:
CL-USER 4 > '(defun foo (a b) (+ (* a a) (* b b)))
(DEFUN FOO (A B) (+ (* A A) (* B B)))
The fourth element is just the arithmetic expression. * refers to the last value:
CL-USER 5 > (fourth *)
(+ (* A A) (* B B))
Now we add some code around it to bind the variables a and b to some numbers. We are using the Lisp function LIST to create a new list.
CL-USER 6 > (list 'let '((a 12) (b 10)) *)
(LET ((A 12) (B 10)) (+ (* A A) (* B B)))
Then we evaluate the above expression. Again, * refers to the last value.
CL-USER 7 > (eval *)
244
There are several variables which are updated with each REPL interaction. Examples are *, ** and *** for the previous values. There is also + for the previous input. These variables have as values not strings, but data objects. + will contain the last result of the read operation of the REPL. Example:
What is the value of the variable *print-length*?
CL-USER 8 > *print-length*
NIL
Let's see how a list gets read and printed:
CL-USER 9 > '(1 2 3 4 5)
(1 2 3 4 5)
Now let's set the above symbol *print-length* to 3. ++ refers to the second previous input read, as data. SET sets a symbols value.
CL-USER 10 > (set ++ 3)
3
Then above list prints differently. ** refers to the second previous result - data, not text.
CL-USER 11 > **
(1 2 3 ...)
Seeing as the concept of a REPL is to just Read, Eval, Print & Loop it's not too suprising that there are REPLs for many languages:
C/C++
C#/LINQ
Erlang
Haskell (on windows)
Java
Javascript
Julia
Perl
Python
Ruby
Scala
Smalltalk -- I learned it on a REPL!
I think it is interesting to compare two approaches. A bare bones REPL loop in a Lisp system would look like this:
(loop (print (eval (read))))
Here are two actual Forth implementations of a REPL loop. I'm leaving nothing out here -- this is the full code to these loops.
: DO-QUIT ( -- ) ( R: i*x -- )
EMPTYR
0 >IN CELL+ ! \ set SOURCE-ID to 0
POSTPONE [
BEGIN \ The loop starts here
REFILL \ READ from standard input
WHILE
INTERPRET \ EVALUATE what was read
STATE # 0= IF ." OK" THEN \ PRINT
CR
REPEAT
;
: quit
sp0 # 'tib !
blk off
[compile] [
begin
rp0 # rp!
status
query \ READ
run \ EVALUATE
state # not
if ." ok" then \ PRINT
again \ LOOP
;
Lisp and Forth do completely different things, particularly in the EVAL part, but also in the PRINT part. Yet, they share the fact that a program in both languages is run by feeding its source code to their respective loops, and in both cases code is just data (though in Forth case it is more like data is also code).
I suspect what anyone saying only LISP has a REPL is that the READ loop reads DATA, which is parsed by EVAL, and a program is created because CODE is also DATA. This distinction is interesting in many respects about the difference between Lisp and other languages, but as far as REPL goes, it doesn't matter at all.
Let's consider this from the outside:
READ -- returns input from stdin
EVAL -- process said input as an expression in the language
PRINT -- print EVAL's result
LOOP -- go back to READ
Without going into implementation details, one can't distinguish a Lisp REPL from, for example, a Ruby REPL. As functions, they are the same.
I guess you could say that Scala's "REPL" is an "RCRPL": Read, Compile, Run, Print. But since the compiler is kept "hot" in memory, it's pretty fast for ongoing interactions--it just takes a few seconds to start up.
There are a number of people that consider a REPL to needs to behave exactly like it does in LISP, or it's not a true REPL. Rather, they consider it something different, like a CLI (command line interpreter). Honestly, I tend to think that if it follows the basic flow of:
read input from the user
evaluate that input
print the output
loop back to the read
then it's a REPL. As noted, there are a lot of languages that have the above capability.
See this reddit thread for an example of such a discussion.
How is Lisp REPL different from non-Lisp REPL?
Let's compare Common Lisp's REPL with Python's IPython.
The main two points are:
Lisp is an image-based language. There is no need to restart the process/the REPL/the whole app after a change. We compile our code function by function (with compiler warnings etc).
we don't loose state. Even more, when we update class definitions, our objects in the REPL are also updated, following rules we have control upon. That way we can hot-reload code in a running system.
In Python, typically, you start IPython or you are dropped into ipdb. You define some data until you try out your new function. You edit your source, and you want to try again, so you quit IPython and you start the whole process again. In Lisp (Common Lisp mainly), not at all, it's all more interactive.
There's a nice project called multi-repl which exposes various REPLs via Node.JS:
https://github.com/evilhackerdude/multi-repl
If you look at the list of supported languages, it's quite clear that not only Lisp has the concept of a REPL.
clj (clojure)
ghci (ghc)
ipython
irb (ruby)
js (spidermonkey)
node
python
sbcl
v8
In fact implementing a trivial one in Ruby is fairly easy:
repl = -> prompt { print prompt; puts(" => %s" % eval(gets.chomp!)) }
loop { repl[">> "] }
I'm currently playing with lispbuilder-sdl on SBCL under Windows.
My source code is as follows:
(asdf:operate 'asdf:load-op :lispbuilder-sdl)
(asdf:operate 'asdf:load-op :lispbuilder-sdl-binaries)
(asdf:operate 'asdf:load-op :lispbuilder-sdl-examples)
(sdl-examples:squashed)
When I compile the file I get the error: package "SDL-EXAMPLES" not found.
If I remove the (sdl-examples:squashed) from the file it compiles ok. I can then type (sdl-examples:squashed) at the repl and the demo game starts fine.
Why is the sdl-examples package found from the repl but not when I compile the file?
All of the compilation of that file happens before executing any of the load-ops. So when Lisp compiles the (sdl-examples:squashed) line, it hasn't run the load-op that defines your package.
You can get around this by not mentioning the sdl-examples package that requires the reader to locate its squashed symbol before the load-op is actually executed:
(funcall (symbol-function (intern (symbol-name '#:squashed)
(find-package (symbol-name '#:sdl-examples)))))
The idea is to calculate the package from its symbolic name, lookup the symbol naming your function, and fetch the function it names - but this way requires that the package exist only when the code is run, not when it is first read. Then your four statements can all be compiled, executed in order, and by the time that last statement is executed, your load-ops will have created the package.
So here's a little more info about what's happening here:
Writing '#:some-name refers to a symbol that's not part of any package. So that way we can make a reference to a symbolic name without either (1) assuming its package exists or (2) mucking up some other package with the name.
Then '(symbol-name #:some-name) extracts the name of the symbol as a string. Why not just write "some-name"? You could, and it will usually work. But this way is a little more robust for the case of running a "modern-mode" case-sensitive Lisp.
The find-package maps a string name to Lisp's representation of a package. Remember, by the time you run this line, your package will exist.
intern returns the symbol with the given name that lives in the given package.
symbol-function returns the function object (a lambda abstraction, or more likely, its compiled representation) associated with the symbol.
And then funcall invokes that function.
It is kind of clunky, but unfortunately there's not really a better way to mix calls which load code to create a package with names living in that package in the same file.