I'd like to change the syntax of the following expression:
(> 2 1)
to something like:
(2 greater 1)
My first try is the following macro:
(define-syntax greater
(lambda (x)
(syntax-case x (greater)
[(a greater b)
(syntax (> a b))])))
Using this macro fails with: "bad syntax in: greater"
I've been surfing some Scheme docs, but I was not able to find the way to do it.
In Racket, there already exists a reader feature to allow for general infix notation: write a dot before and after the function or macro name: (2 . > . 1) It's a little verbose (the dots have to be surrounded by spaces), but I like it and use it a lot. See the documentation for more information.
The expression (2 greater 1) is an application. It expands to (#%app 2 greater 1). You must define your own version of #%app and call it, say, my-%app. If greater is present swap the first and second argument, otherwise just expand to the standard #%app.
To use your new application you must export it from the file (module) in which you define it, and then import it in the module where your want your special application syntax.
You might that the "curly-infix" notation is what you want. Just surround a list with {...}, and you can write the list contents in infix order instead of prefix order (the reader transforms it). So if you write {x + ,y} the reader maps it to (+ x ,y).
Curly-infix is defined in SRFI-105: http://srfi.schemers.org/srfi-105/
I know that the current version of GNU guile, at least, implements it.
The "sweet-expression" notation of SRFI-110 ( http://srfi.schemers.org/srfi-110/ ) builds on top of SRFI-105.
Related
I looked at the documentation https://docs.racket-lang.org/reference/input-and-output.html but I find it to be very confusing and I feel like it contains a lot of extra information I don't need for such a simple task.
I would like to read two space separated integers and store them in variables.
example input:
1 2
I would like to define and x and y whose values are 1 and 2 respectively.
There are a lot of ways to do this. I’ll give you three.
Option 1: Use the built-in read
The read function reads s-expressions. Conveniently, integers are valid s-expressions, and it skips whitespace, too. This means you can just call read twice on an input port to produce two datums:
> (let ([in (open-input-string "1 2")])
(values (read in) (read in)))
1
2
This has a drawback, though: there are a lot of things that are valid s-expressions that aren’t numbers, so you might get a lot of garbage back if you’re not careful. For example:
> (let ([in (open-input-string "#f (hello world)")])
(values (read in) (read in)))
#f
'(hello world)
You’d probably need to do some post-processing to ensure what you get back is what you expect. This also won’t necessarily consume all the input, so if it’s important there’s nothing else after the numbers, you’d need to check that separately, too.
Option 2: Use a regular expression
Regular expressions are a pretty easy way to handle simple cases like this. In this example, the regexp literal #px"^(\\d+) (\\d+)$" is a simple way to express the pattern you mention in your question. You can use this to extract the numeric parts of the string:
> (regexp-match #px"^(\\d+) (\\d+)$" "1 2")
'("1 2" "1" "2")
You can combine this with string->number to get numbers out:
> (let ([matches (regexp-match #px"^(\\d+) (\\d+)$" "1 2")])
(values (string->number (second matches))
(string->number (third matches))))
1
2
This has the advantage of ensuring the input matches precisely, and it’s safe, fast, and simple. However, one downside is that it will not provide good error messages if the parsing fails, regexp-match will simply produce #f.
Option 3: Use a parser combinator library
Racket has a number of libraries designed for parsing. These can scale to parsing far more complicated things that two numbers, but they also work fine for simple situations. I will show an example using megaparsack, since it’s my library, and I like it.
You can use megaparsack to write a parser that parses two integers separated by a space:
(require data/applicative
data/monad
megaparsack
megaparsack/text)
(define 2-integers/p
(do [x <- integer/p]
(char/p #\space)
[y <- integer/p]
(pure (cons x y))))
This parser is obviously more complicated than the regexp, but it also does more, and it’s much more extensible and composable. You can use this parser to get the numbers you want:
> (parse-result! (parse-string 2-integers/p "1 2"))
'(1 . 2)
However, unlike the regular expression, it will automatically provide good error messages when a parse fails:
> (parse-result! (parse-string 2-integers/p "1 "))
string:1:1: parse error
unexpected: end of input
expected: integer
When I was learning HTML it was very helpful for me to know that ol means ordered list, tr is table row, etc. Some of the lisp primitives/forms are easy: funcall should be function call, defmacro - define macro. Some are in the middle - incf is... increment... f??? But because common lisp is so old, this primitives/special forms/etc... don't seem to ring a bell. Can you guys, help me with figuring them out? And even more importantly: Where can I find an authoritative resource on learning the meaning/history behind each and every one of them? (I will accept an answer based on this second question)
The documentation doesn't help me too:
* (describe #'let)
#<CLOSURE (:SPECIAL LET) {10013DC6AB}>
[compiled closure]
Lambda-list: (&REST ARGS)
Derived type: (FUNCTION (&REST T) NIL)
Documentation:
T
Source file: SYS:SRC;COMPILER;INFO-FUNCTIONS.LISP
* (documentation 'let 'function)
"LET ({(var [value]) | var}*) declaration* form*
During evaluation of the FORMS, bind the VARS to the result of evaluating the
VALUE forms. The variables are bound in parallel after all of the VALUES forms
have been evaluated."
* (inspect 'let)
The object is a SYMBOL.
0. Name: "LET"
1. Package: #<PACKAGE "COMMON-LISP">
2. Value: "unbound"
3. Function: #<CLOSURE (:SPECIAL LET) {10013DC6AB}>
4. Plist: (SB-WALKER::WALKER-TEMPLATE SB-WALKER::WALK-LET)
What do the following lisp primitives/special forms/special operators/functions mean?
let, flet
progn
car
cdr
acc
setq, setf
incf
(write more in the comments so we can make a good list!)
let: LET variable-name be bound to a certain value
flet: LET Function-name be bound to a certain function
progn: execute a PROGram sequence and return the Nth value (the last value)
car: Contents of the Address Register (historic)
cdr: Contents of the Decrement Register (historic)
acc: ACCumulator
setq: SET Quote, a variant of the set function, where in setq the user doesn't quote the variable
setf: SET Function quoted, shorter name of the original name setfq. Here the function/place is not evaluated.
incf: INCrement Function quoted, similar to setf. Increments a place.
Other conventions:
Macros / Special Forms who change a place should have an f at the end: setf, psetf, incf, decf, ...
Macros who are DEFining something should have def or define in front: defun, defmethod, defclass, define-method-combination...
Functions who are destructive should have an n in front, for Non-consing: nreverse, ...
Predicates have a p or -p at the end: adjustable-array-p, alpha-char-p,...
special variables have * at the front and back: *standard-output*, ...
There are other naming conventions.
let: Well, that's a normal word, and is used like in maths ("let x = 3 in ...").
flet: I'd guess "function let", because that's what it does.
progn: This is probably related also to prog1 and prog2. I read is as "program whose nth form dictates the result value". The program has n forms, so it's the last one that forms the result value of the progn form.
car and cdr: "Contents address register" resp. "Contents decrement register". This is related to the IBM 704 which Lisp was originally implemented for.
setq: "set quote", originally an abbreviation for (set (quote *abc*) value).
setf: "set field", came up when lexical variables appeared. This is a good read on the set functions.
Where can I find an authoritative resource on learning the meaning/history behind each and every one of them?
The HyperSpec is a good place to start, and ultimately the ANSI standard. Though "Common Lisp The Language" could also shine some light on the history of some names.
(Oh, and you got defmacro wrong, that's "Definition for Mac, Read Only." ;) )
I have been trying to use Clojure tagged literals, and noticed that the reader does not evaluate the arguments, very much like a macro. This makes sense, but what is the appropriate solution for doing this? Explicit eval?
Example: given this function
(defn my-data
([[arg]]
(prn (symbol? arg))
:ok))
and this definition data_readers.clj
{myns/my-data my.ns/my-data}
The following behave differently:
> (let [x 1] (my.ns/my-data [x]))
false
:ok
So the x passed in is evaluated before being passed into my-data. On the other hand:
> (let [x 1] #myns/my-data [x])
true
:ok
So if I want to use the value of x inside my-data, the my-data function needs to do something about it, namely check that x is a symbol, and if so, use (eval x). That seems ugly. Is there a better approach?
Summary
There is no way to get at the value of the local x in your example, primarily because locals only get assigned values at runtime, whereas tagged literals are handled at read time. (There's also compile time in between; it is impossible to get at locals' values at compile time; therefore macros cannot get at locals' values either.)1
The better approach is to use a regular function at runtime, since after all you want to construct a value based on the runtime values of some parameters. Tagged literals really are literals and should be used as such.
Extended discussion
To illustrate the issue described above:
(binding [*data-readers* {'bar (fn [_] (java.util.Date.))}]
(eval (read-string "(defn foo [] #bar x)")))
foo will always return the same value, because the reader has only one opportunity to return a value for #bar x which is then baked into foo's bytecode.
Notice also that instead of passing it to eval directly, we could store the data structure returned by the call to read-string and compile it at an arbitrary point in the future; the value returned by foo would remain the same. Clearly there's no way for such a literal value to depend on the future values of any locals; in fact, during the reader's operation, it is not even clear which symbols will come to name locals -- that's for the compiler to determine and the result of that determination may be non-obvious in cases where macros are involved.
Of course the reader is free to return a form which looks like a function call, the name of a local etc. To show one example:
(binding [*data-readers* {'bar (fn [sym] (list sym 1 2 3 4 5))}]
(eval (read-string "#bar *")))
;= 120
;; substituting + for * in the string yields a value of 15
Here #bar f becomes equivalent to (f 1 2 3 4 5). Needless to say, this is an abuse of notation and doesn't really do what you asked for.
1 It's worth pointing out that eval has no access to locals (it always operates in the global scope), but the issue with locals not having values assigned before runtime is more fundamental.
I've been working on some project. It should be able to do numerical and symbolic computing. But now I stuck on one problem and I don't really know how to resolve it. To be specific and short, let's say we are in package
(in-package #:brand-new-package)
Where we have symbol database
(defvar var-symbol-database (make-hash-table :test #'equal))
Reading and setting functions
(defun var-symbol (name)
(get-hash name var-symbol-database))
(defun set-var-symbol (name value)
(setf (get-hash name var-symbol-database) value))
(set-var-symbol 'temperature 300) ;K
(set-var-symbol 'f 200) ;Hz
(set-var-symbol 'k 1.3806504e-23) ;J K^-1
and now in another file (but same package) I will try to evaluate this equation
(eval '(+ 2 (var-symbol 'f)))
It won't work. Problem is that for some particular reason the value of key in hash table is.
brand-new-package::f
I though that I will solve the problem defining function like this
(set-var-symbol 1 '(var-symbol 'f)) ;Hz
But it is interpreted as
(brand-new-package::var-symbol brand-new-package::f)
The problem is that program can create many different symbols. It will compute electronic circuit equations. Program first inspect device objects like capacitors, resistors and so. It create circuit tablo by MNA.
During it many new symbols representing node voltages and currents could be created
(v1, v2, v3, i1, i2).
I needed some method to hold count and names of variables presented in equation. Because they will be passed to symbolic derivator ie (diff '(* (+ 40 v1) u2 ...) 'v1)) I came with an idea, maybe wrong, to make them reachable by index to define them as a list
'(v 1) '(v 2) '(v 3).
To make them evaluable I added to begining var-variable funcall. So list becomed
'(var-variable v 1) '(var-variable v 2) '(var-variable v 3)
But as I have written, system changes it to
'(brand-new-package::var-variable brand-new-package::v 1) '(brand-new-package::var-variable brand-new-package::v 2) '(brand-new-package::var-variable brand-new-package::v 3)
How to allow to users to acces these variables by typing (var-symbol 'v 1). I can imagine only one way. Instead of symbols use strings and export function (var-symbol). Then it will work this way
'(var-variable "v" 1)
But it is a little bit confusing.
You are duplicating what Lisp already does. Symbols are already managed in tables, called packages. A symbol can have a value. Putting it into a package is INTERN. Finding it is FIND-SYMBOL or just using the Lisp READer.
If you want your own symbol index tables, hash tables are fine. If you don't want to deal with packages of those symbols, then just use keyword symbols. They have a single colon in front. :temperature would be an example. Keyword symbols are automagically in the package KEYWORD and they evaluate to themselves.
What you state to be a "problem" is as expected. The Common Lisp notation brand-new-package::var-symbol signifies that the symbol var-symbol is in the package brand-new-package, which was the current package at the time the symbol was read by the lisp.
I'm not very familiar with Clojure/Lisp macros. I would like to write apply-recur macro which would have same meaning as (apply recur ...)
I guess there is no real need for such macro but I think it's a good exercise. So I'm asking for your solution.
Well, there really is no need for that, if only because recur cannot take varargs (a recur to the top of the function takes a single final seqable argument grouping all arguments pass the last required argument). This doesn't affect the validity of the exercise, of course.
However, there is a problem in that a "proper" apply-recur should presumably handle argument seqs returned by arbitrary expressions and not only literals:
;; this should work...
(apply-recur [1 2 3])
;; ...and this should have the same effect...
(apply-recur (vector 1 2 3))
;; ...as should this, if (foo) returns [1 2 3]
(apply-recur (foo))
However, the value of an arbitrary expression such as (foo) is simply not available, in general, at macro expansion time. (Perhaps (vector 1 2 3) might be assumed to always yield the same value, but foo might mean different things at different times (one reason eval wouldn't work), be a let-bound local rather than a Var (another reason eval wouldn't work) etc.)
Thus to write a fully general apply-recur, we would need to be able to determine how many arguments a regular recur form would expect and have (apply-recur some-expression) expand to something like
(let [seval# some-expression]
(recur (nth seval# 0)
(nth seval# 1)
...
(nth seval# n-1))) ; n-1 being the number of the final parameter
(The final nth might need to be nthnext if we're dealing with varargs, which presents a problem similar to what is described in the next paragraph. Also, it would be a good idea to add an assertion to check the length of the seqable returned by some-expression.)
I am not aware of any method to determine the proper arity of a recur at a particular spot in the code at macro-expansion time. That does not mean one isn't available -- that's something the compiler needs to know anyway, so perhaps there is a way to extract that information from its internals. Even so, any method for doing that would almost certainly need to rely on implementation details which might change in the future.
Thus the conclusion is this: even if it is at all possible to write such a macro (which might not even be the case), it is likely that any implementation would be very fragile.
As a final remark, writing an apply-recur which would only be capable of dealing with literals (actually the general structure of the arg seq would need to be given as a literal; the arguments themselves -- not necessarily, so this could work: (apply-recur [foo bar baz]) => (recur foo bar baz)) would be fairly simple. I'm not spoiling the exercise by giving away the solution, but, as a hint, consider using ~#.
apply is a function that takes another function as an argument. recur is a special form, not a function, so it cannot be passed to apply.