R5RS "provide" issues - export

I made a program in Racket and now I have to change my code to R5RS.
But I immediately get errors.
I had the following code in Racket :
#lang racket
(provide a-function)
(define (a-function)
; Do something
#t)
(define a-variable #t)
Then I changed it to R5RS :
#lang r5rs
(#%provide a-function)
(define (a-function)
; Do something
#t)
(define a-variable #t)
Now the problem is that when I run this simple code and try to call the procedure "a-function" it tells me a-function: undefined;
cannot reference an identifier before its definition
I noticed that this problem is only with procedures, the variable "a-variable" is known but no procedures are known...
EDIT : I tried to disguise a procedure as a variable to see if he knows that procedure, but then I get the same error.
#lang r5rs
(#%provide a-function)
(define a-function (lambda (x y) (+ x y)))
I searched a lot and I think the problem must be that I'm still merging my Racket code to R5RS so certain files are still in Racket, other files are in R5RS and that this is causing troubles for a reason I don't understand (it shouldn't be a problem...)
EDIT : I reconstructed the problem as easy as possible :
R5RS file "a.rkt" :
#lang r5rs
(#%provide makePosition)
(define (makePosition x y)
(cons x y))
Racket file :
#lang racket
(require "a.rkt")
(makePosition 20 10)
When running the Racket file this gives rise to the error "undefined identifier ...".
According to one of my teachers this is a Racket bug.

For the last program (makePosition), note that R5RS is case-insensitive, so makePosition is normalized to makeposition. Racket world, however, is case-sensitive, so makePosition doesn't exist; makeposition does.
For other programs, I really couldn't reproduce the problem. Did you change anything when you posted the question to StackOverflow?

Related

.emacs: c-set-style will delay display of new style until I change the buffer (type a key)

Dealing with files of different C flavours, I defined the following function and a keyboard mapping to invoke it:
(defun my-c-set-gnu-style ()
"doc string"
(interactive)
(setq tab-width 8
indent-tabs-mode t)
(c-set-style "gnu")
)
(global-set-key (kbd "C-x :") 'my-c-set-gnu-style)
Now when I open a C file with emacs, and then type C-x: then nothing happens. Only after I hit some key (and thus I change the code, which is really bad), emacs will re-draw the code according to the new style.
How can I achieve that emacs will re-indent the code right after the respective command has been issued? The need to change the file is really bad.
Version is GNU Emacs 26.3.
The issue isn't related to c-set-style. Changing the TABs mode like in (setq tab-width 8 indent-tabs-mode t) should also have an immediate visual effect — which it does not have.
Using (redisplay t) didn't solve the problem, but what worked is (force-window-update) at the end of the defun. Dunno if that's supposed to be issued by hand or whether the requirement is an Emacs bug, though.

Non-existent hy macros runs assertions, but fails appropriately with everything else

In the following code:
(eval-and-compile (import os hy))
(eval-and-compile (import pathlib [Path]))
; (defmacro with-cwd [dir #* body]
; (setv cwd (hy.gensym))
; `(let [ ~cwd (.cwd Path) ]
; (try (.chdir os ~dir)
; ~#body
; (finally (.chdir os ~cwd)))))
(setv cookies (/ (.cwd Path) "cookies"))
; This fails with an `AssertionError'
(with-cwd cookies (assert (= (.cwd Path) cookies)))
; This fails with a `NameError'
(with-cwd cookies (.cwd Path))
Similarly, any functions or macros depending on the missing macro errors out in the same way, and if, for example, I'm importing or requiring a function or macro that depends on the missing macro, the same thing happens; basically, I have to import or require a function or macro as well as its dependencies manually.
Is this a bug, or am I missing something about the order of Python / Hy assertions? I expected the first case to fail with a NameError as well.
This is a documented quirk:
Like many programming languages, but unlike Python, Hy doesn't guarantee in all cases the order in which function arguments are evaluated. More generally, the evaluation order of the child models of a hy.models.Sequence is unspecified. For example, (f (g) (h)) might evaluate (part of) (h) before (g), particularly if f is a function whereas h is a macro that produces Python-level statements. So if you need to be sure that g is called first, call it before f.
In this case, the assert statement has gotten pulled out of the function call ((with-cmd …) being a function call, since there is no macro named with-cmd) and evaluated before the symbol with-cmd itself.

Correct way to use the iterate package in Common Lisp

On my Windows XP box with sbcl-1.4.14 I've installed the ASDF using
(load "C:\\Program Files\\clisp-2.49\\asdf\\asdf.lisp")
(require :asdf)
(push "C:\\Documents and Settings\\mayhem\\lisp\\iterate\\" asdf:*central-registry*)
On SLIME
(require :iterate)
(iterate (for i from 1 to 5) (collect (* i i)))
gives The variable I is unbound error
If I do (in-package :iterate), the code above works fine but this time familiar functions such as exit and other functions which I've defined in .sbclrc cease to work, they give The function ITERATE::EXIT is undefined type of errors, for example.
If I do (use-package :iterate), then it gives [Condition of type NAME-CONFLICT] error.
So I began to use the package like this:
(iterate:iterate (iterate:for i from 1 to 5) (iterate:collect (* i i)))
But I think you'll agree that it's a bad style.
How to use the iterate correctly?
Note: I've seen the post about the very similar problem but it didn't help. There aren't many posts or articles about this particular problem.
You need to say (use-package :iterate) before you try to refer to unqualified symbols from the iterate package.
What has happened in your case is this.
You've loaded the iterate system into the running Lisp, creating a package called "ITERATE".
In the "CL-USER" package you've typed (iterate ...), and the reader has worked out that it needs to find or create a symbol whose name is "ITERATE" and which is accessible in the "CL-USER" package.
There is no such symbol, so it creates a new one, CL-USER::ITERATE.
This is not ITERATE:ITERATE so you get an error from the evaluator as it's trying to evaluate the arguments to a function (which doesn't exist, but it doesn't know that yet). In fact the error you're getting is while it's evaluating the first argument in the (for i ...) subform.
Now you say (use-package :iterate) to tell the system to add the "ITERATE" package to "CL-USER"'s search list.
Now there's a conflict: should iterate refer to the existing CL-USER::ITERATE or the newly-accessible ITERATE::ITERATE? (And there are some other conflicts too, probably).
So the system signals an error, and there should be some useful ways to proceed from that, one of which is probably 'unintern all the conflicting "CL-USER" symbols', but you didn't take that option, I suppose.
So now everything is messed up.
And the answer is: use the packages you want to refer to unqualified symbols from before you try to refer to those symbols unqualified.
(Also: Windows XP? I'm impressed by your retroness.)

Common lisp — why isn't this symbol external?

I'm trying to run tests in ASDF, which looks like this:
;;;; foo.asd
(defsystem "foo/tests"
:depends-on ("foo"
"fiveam")
:components ((:module "tests"
:components
((:file "main"))))
:perform (test-op (op c) (symbol-call :fiveam '#:run! 'foo/tests:all-tests))
And my tests/main.lisp file starts off like this:
;;;; tests/main.lisp
(defpackage foo/tests
(:use :cl
:foo
:fiveam)
(:export :#run! :#all-tests))
(in-package :foo/tests)
When I run (asdf:test-system 'foo) in my REPL, I get dropped into the debugger with a LOAD-SYSTEM-DEFINITION-ERROR. The debugger is complaining that The symbol "ALL-TESTS" is not external in the FOO/TESTS package.
However, I am clearly exporting the symbol in the foo/tests package. Can somebody please tell me what I'm missing here and why the Lisp compiler isn't seeing the external symbol? Thank you very much.
The syntax for an uninterned symbol is #:foo, not :#foo.
You also need to resolve the symbols in the :perform form at run-time, e. g. through uiop:find-symbol*, just like you use uiop:symbol-call there.
:perform (test-op (op c)
(symbol-call :fiveam '#:run!
(find-symbol* '#:all-tests '#:foo/tests)))
Or, since you seem to export a run! function from your test package, you might want to call that instead of fiveam:run!:
:perform (test-op (op c)
(symbol-call '#:foo/tests '#:run!))

Clojure: Equivalent to Common Lisp READ function?

When I want to read in an S-expression stored in a file into a running Common Lisp program, I do the following:
(defun load-file (filename)
"Loads data corresponding to a s-expression in file with name FILENAME."
(with-open-file (stream filename)
(read stream)))
If, for example, I have a file named foo.txt that contains the S-expression (1 2 3), the above function will return that S-expression if called as follows: (load-file "foo.txt").
I've been searching and searching and have not found an equally elegant solution in Clojure. Any ideas?
Thanks!
You can do e.g.
(require '[clojure.contrib.io :as io])
(io/with-in-reader (io/file "foo.txt") (read))
; => (1 2 3)
Note that you'll likely want to rebind *read-eval* to false first. Also note that the above works with current contrib HEAD (and will almost certainly work in 1.2 when it's released); for Clojure 1.1, the same functionality is available in the clojure.contrib.duck-streams and clojure.contrib.java-utils namespaces.
I found a solution here: How do you evaluate a string as a clojure expression?
(read-string (slurp "foo.txt"))
Sorry to bother you, folks ^_^

Resources