I have read a lot of the suggested questions but I am still stuck with my learning problem right now, I am trying to write a simple Lisp s-expression parser and I cannot figure out how to tackle the recursive nature of an s-expression without tying my brain into knots!
Here is what I have, the input is a list of tokenised terms from the source file from my lexer module which works fine: (GNU Prolog by the way)
lisp_term(T) -->
(
null(T)
;
token(T)
;
sexp_open(_), lisp_term(T2), sexp_close(_), {T = lnode(T2)}
).
lisp_term(T) --> [], {T=end}.
sexp_open(Pos) --> [popen(Pos)].
sexp_close(Pos) --> [pclose(Pos)].
token(token(Pos,Token)) --> [token(Pos,Token)].
null(null(Pos1)) --> [popen(Pos1), pclose(_)].
and here is my calling code...
lisplex('../test.lisp',X),
lexpp(X),
phrase(lisp_term(A), X, Y),
format("Result: ~w~n", [A]),
format("Remainder: ~w~n", [Y]).
the output from the lexer is a list like this, the source: "(hello)"
[popen(pos(1,1)),token(pos(1,2),[h,e,l,l,o]),pclose(pos(1,7))]
I continually get tied up trying to figure out how to deal with an expression like:
(defun whizzle (a1 b2)
(munge (* 10 a1) (+ b2 a1)))
That is, how to deal generally with turning the lexer stream into a parse tree. You can see that my DCG rules are attempting to do that.
I would really appreciate some help and pointers to good stuff to read or advice on how to better understand dealing with right-recursive situations. I have been teaching myself Prolog for a few months now and love it to bits BUT I am stuck on being able to proceed with my understanding of DCG-s and situations like this.
Thanks,
Sean.
I think you are missing the list ! Try (untested)
lisp_term(T) --> token(T).
lisp_term(lnode(T)) -->
sexp_open(_), lisp_list(T), sexp_close(_).
lisp_list([H|T]) -->
lisp_term(H), lisp_list(T).
lisp_list([]) --> [].
Then take a look to Lisprolog, available from Markus Triska' page.
Related
By accident, I recently came across a latent coding error in one of my functions, dealing with a when statement. A reduced paraphrase might look like:
(defparameter a 0)
(when (or (= a 0)
(= a 1)
(* a a)))
The problem is a misplaced parenthesis, so it actually is
(when (or (= a 0)
(= a 1)
(* a a)))
In a situation like this, wouldn't it be useful for the compiler to generate either a style warning or note? It seems to me that the meaning of a when statement normally implies a condition and a body, even though the body is strictly optional. Of course, a print pretty would have caught this in the editor, but I had copied it from elsewhere. Is there a reason that SBCL does not check for these kinds of mistakes?
a print pretty would have caught this in the editor
To discuss the options, I know about:
trivial-formatter will format the source code.
(trivial-formatter:fmt :your-system :supersede)
cl-indentify indents the source code. Has a command line utility. I tried it once and it was not bad, but different than Emacs' indentation, thus annoying for me.
$ cl-indentify bar.lisp
It links to lispindent but I was less happy with its result.
However, the best would be to not only format the code and re-read it ourselves, but to
run checks against a set of rules to warn against code smells
This is what proposes the lisp-critic. It can critique a function or a file. However:
(edit) it doesn't really have a Slime integration, we have to either critique a function or a whole file.
if you feel adventurous, see an utility of mine here. It could be an easier way to test snippets that you enter at the REPL.
it hasn't the rule about when without a body (we can easily add it)
And it would be best that the run failed with an error status code if it found a code smell. Again, a little project of mine in beta tries to do that, see here. It doesn't have much rules now, but I just pushed a check for this. You can call the script:
$colisper.sh tests/playground.lisp
it shows an error (but doesn't write it in-place by default):
|;; when with no body
|(when (or (= a 0)
| (= a 1)
!| (* a a))
!| (error "colisper found a 'when' with a missing body. (we should error the script without this rewrite!)"))
and returns with an exit code, so we can use it has a git hook or on a CI pipeline.
The problem is that if a human writes (when x) (or whatever that expands into, perhaps (if x (progn) nil)) this is probably a mistake, but when a program writes it it may well not be: it may be just some edge case that the program hasn't been smart enough to optimize completely away. And a huge amount of code that the compiler processes is written by programs, not humans.
In Isabelle/HOL, how do I find where a given type was instantiated for a given class? For the sake of this post for example, where real was instantiated as a conditionally_complete_linorder. To justify the question: I might want to know this for inspiration for a similar instantiation, for showing it to someone(s), for Isabelle/HOL practice reading, for curiosity, and so on. My process at the moment:
First, check it actually is: type instantiation real :: conditionally_complete_linorder begin end and see if I get the error message "No parameters and no pending instance proof obligations in instantiation."
Next, ideally before where I'd need to know how i.e. whether it was direct, or implicit via classes C_1[, C_2, C_3, etc]. Then, I would need to find where those instantiations are, either an explicit instantiation real :: conditionally_complete_linorder or the implicit ones for the C_i (same process for either case ofc). I don't know how to find out how, so I have to check for an explicit instantiation, then all possible implicit instantiations.
For explicit, I can do a grep -Ern ~/.local/src/Isabelle2019 -e 'instantiation real :: conditionally_complete_linorder' (and hope the whitespace isn't weird, or do a more robust search :)). Repeat for AFP location. Alternatively, to stay within the jEdit window:
I can find where the class itself was defined by typing term "x::'a::conditionally_complete_linorder" then Ctrl-clicking the class name, and then check if real is directly instantiated in that file with Ctrl-f.
I could then check if it's instantiated where the type real is defined by typing term "x::real" and Ctrl-clicking real, then Ctrl-f for conditionally_complete_linorder in that file.
(If it is in either place it'll be whichever is further down in the import hierarchy, but I find just going through those two steps simpler.) However, if neither two places turn it up then either, for whatever reason, it is explicitly instantiated somewhere else or is implicitly instantiated. For that reason grep is more robust.
If explicit turns nothing up then I check implicit. Looking at the class_deps graph I can see that conditionally_complete_linorder can follow from either complete_linorder or linear_continuum. I can then continue the search by seeing if real is instantiated as either of them (disregarding any I happen to know real can't be instantiated as). I can also check to see if it's instantiated as both conditioanlly_complete_lattice and linorder, which is what I can see conditionally_complete_linorder is a simple (no additional assumptions) combination of*. Repeat for all of these classes recursively until the instantiations are found. In this case, I can see that linear_continuum_topology implies linear_continuum, so kill two birds with one stone with grep -Ern ~/.local/src/Isabelle2019 -e "instantiation.*real" | grep continuum and find /path/to/.local/src/Isabelle2019/src/HOL/Real.thy:897:instantiation real :: linear_continuum.
This process is quite tedious. Less but still quite tedious** would be to get the class_deps graph up and Ctrl-f for "instantiation real" in Real.thy and look for instantiations of: the original class, the superclasses of it, or the classes which imply it. Then in the files each those classes are defined search for "instantiation real". Do this recursively till done. In this case I would have found what I needed in Real.thy.
Is there an easier way? Hope I just missed something obvious.
* I can't Ctrl-click in Conditionally_Complete_Lattices.thy to jump to linorder directly, I guess because of something to do with it being pre-built, so I have to do the term "x::'a::linorder" thing again.
** And also less robust, as it is minus grep-ing which can turn up weirder instantiation locations, then again I'm not sure if this ever comes up in practice.
Thanks
You can import the theory in the code listing below and then use the command find_instantiations. I will leave the code without further explanation, but please feel free to ask further questions in the comments if you need further details or suspect that something is not quite right.
section ‹Auxiliary commands›
theory aux_cmd
imports Complex_Main
keywords "find_instantiations" :: thy_decl
begin
subsection ‹Commands›
ML ‹
fun find_instantiations ctxt c =
let
val {classes, ...} = ctxt |> Proof_Context.tsig_of |> Type.rep_tsig;
val algebra = classes |> #2
val arities = algebra |> Sorts.arities_of;
in
Symtab.lookup arities c
|> the
|> map #1
|> Sorts.minimize_sort algebra
end
fun find_instantiations_cmd tc st =
let
val ctxt = Toplevel.context_of st;
val _ = tc
|> Syntax.parse_typ ctxt
|> dest_Type
|> fst
|> find_instantiations ctxt
|> map Pretty.str
|> Pretty.writeln_chunks
in () end
val q = Outer_Syntax.command
\<^command_keyword>‹find_instantiations›
"find all instantiations of a given type constructor"
(Parse.type_const >> (fn tc => Toplevel.keep (find_instantiations_cmd tc)));
›
subsection ‹Examples›
find_instantiations filter
find_instantiations nat
find_instantiations real
end
Remarks
I would be happy to provide amendments if you find any problems with it, but do expect a reasonable delay in further replies.
The command finds both explicit and implicit instantiations, i.e. it also finds the ones that were achieved by means other than the use of the commands instance or instantiation, e.g. inside an ML function.
Unfortunately, the command does not give you the location of the file where the instantiation was performed - this is something that would be more difficult to achieve, especially, given that instantiations can also be performed programmatically. Nevertheless, given a list of all instantiations, I believe, it is nearly always easy to use the in-built search functionality on the imported theories to narrow down the exact place where the instantiation was performed.
I'm trying to make a library that I'm writing portable between the different Common Lisp implementations, I need a function like SBCL called sb-debug:list-backtrace which returns a list with stake-trace, but I did not find any of them, I'm looking for your documentation, and I'll continue, and I'll update with what I can get here, but I ask for help from anyone who has already used it and you know which function of the implementations below can return me a stack-trace list.
(defun get-stack-trace ()
#+sbcl (sb-debug:list-backtrace)
#+clisp (?)
#+cmu (?)
#+mcl (?)
#+excl (?)
#+abcl (?)
#+cll (?)
#+clasp (?)
#+ecl (?)
#+mezzano (?)
#+mkcl (?))
True that I do not need all this portability, but since it's just this function, I do not see why not try to port for as many implementations as you can get.
I've been using noir in a web project and I came up to the point of restricting access to users, depending on their access level (and sublevel) to all possible routes defined by a defpage macro. So originally I had
(defpage [:post "/mysite"] {:as input}
(if-not (has-reqd-user-level? :levelX :sublevelY "/grantedRoute")
(noir.response/redirect "/insufficientRights")
...))
And then I thought this would get rid of boilerplate code:
(defmacro defpage-with-user-level [level sublevel granted-route route data expr]
`(defpage ~route ~data
(if-not (has-reqd-user-level? ~level ~sublevel ~granted-route)
(noir.response/redirect "/insufficientRights")
~expr)))
Finally, we use it as follows:
(defpage-with-user-level :levelX :sublevelY "/grantedRoute"
[:post "/mysite"] {:as input}
(html
[:body [:h1 (str "Hello " (:name input) "!")]]))
But as mentioned in this post made by Rich Hickey, https://groups.google.com/forum/#!msg/clojure/4II-HKr_Pu0/2IcKit99cagJ , it feels a little bit awkward because of positional binding, which is not idiomatic when there already exist maps.
However, I've been looking for some examples or discussions regarding the use of destructuring bindings in macros, and sadly, I hadn't found any clear use of them, because of its unevaluated expressions being passed through all along.
So, the following solution came to my mind:
(defmacro defpage-with-user-level [dts expr]
`(defpage (:route ~dts) (:data ~dts)
(if-not (has-reqd-user-level? (:level ~dts) (:sublevel ~dts) (:granted-route ~dts))
(noir.response/redirect "/insufficientRights")
~expr)))
But now, it's not clear how to pass the data map that maps locals from :get and :post into a local as in the examples above.
Am I doing right leaving my first attempt untampered or do I really need to use the second approach? I hope not. Is there any other option? Please, let me know.
Your first solution is fine. What Rich was talking about was using plain old maps to passing data around rather then creating new types/classes for each type of data. Ex: you can represnt a user information using a simple map rather than creating a class to represent user data.
As far as your second attempt is concerned, you can use map de-structuring in macro as:
(defmacro defpage-with-user-level [{:keys [route data level sublevel granted-route]} expr]
`(defpage ~route ~data
(if-not (has-reqd-user-level? ~level ~sublevel ~granted-route)
(noir.response/redirect "/insufficientRights")
~expr)))
(defpage-with-user-level {:level :levelX
:sublevel :sublevelY
:granted-route "/grantedRoute"
:route [:post "/mysite"]
:data {:as input}}
(html
[:body [:h1 (str "Hello " (:name input) "!")]]))
I'm looking for a way to mimic Textmate's CSS editing behavior in Emacs.
In Textmate, when adding a CSS property:
#element {} <-- Braces auto close.
#element {background: ;} <-- after typing the colon, the semi-colon is automatically inserted and the cursor is placed between them.
I have taken a look at several css-modes (and textmate.el) but cannot see that anyone has implemented this.
I have absolutely zero knowledge of emacs-lisp would be be willing to give it a shot and write something myself, but does anyone know if this has been done already?
You want to look at some examples of electric functions (the naming convention used when additional input or formatting is performed when particular visible characters are typed).
There's nothing special about the implementation. The key in question is bound within the mode's keymap to a function which does the work. Aside from the fact that you must handle the insertion of the character typed, it's just like any other keybinding.
cc-mode has several examples. The basic approach looks like this:
(define-key c-mode-base-map "{" 'c-electric-brace)
(defun c-electric-brace (arg)
(interactive "*P")
;; [...]
(self-insert-command (prefix-numeric-value arg))
;; [...]
)
Admittedly c-electric-brace is a far more complicated function than you might be expecting, but it would be trivial to have a function which simply inserted the same number of }s after inserting the {s.
(defun my-electric-brace (arg)
"Automatically add a closing '}' for every '{' inserted."
(interactive "*P")
(let ((count (prefix-numeric-value arg)))
(self-insert-command count)
(save-excursion
(insert-char ?} count))))
(defun my-css-mode-hook ()
(local-set-key (kbd "{") 'my-electric-brace))
(add-hook 'css-mode-hook 'my-css-mode-hook)
You might find that is a little simplistic, and there are circumstances in which you don't want the matching brace to be inserted, however. You would probably also want to deal with automatically removing matching braces when you delete one of them, by defining electric delete functions.
Your electric colon requirement is also less trivial than the brace, as it should only occur in the right context (although in practice you might get away with a naive implementation, as I don't think you would be typing colons in a CSS file that were not in the correct context.)
Hopefully this points you in the right direction, if you decide to write your own solutions.
Obviously you would want to read some tutorials on elisp, but for understanding the code above, just note that you can use C-h f (describe-function) to read the documentation for any elisp function (or M-x find-function to view the code).
For general purpose autopairing of all sorts of braces, etc you might want to take a look at autopair-mode.