Fork me on GitHub
#babashka
<
2019-11-07
>
mauricio.szabo00:11:04

Thanks! I'm using rewrite-cljs to parse Clojure sourcecode, but sometimes things get slow, so I'm seeing if there are any alternatives, even if I have to "hack" a little bit the library đŸ™‚

dominicm04:11:29

@borkdude forgot to mention, for auto resolved keywords. :)

borkdude09:11:24

@mauricio.szabo I just added support for reading auto-resolved namespaced maps, so I think edamame should be pretty complete as a full code reader now... although I've only tested it on clojure/CLJS core.clj(s) and my own babashka / sci scripts

borkdude09:11:52

It probably needs more testing if it's going to be used in IDEs to parse any random clojure code

dominicm10:11:18

The thing you might find with IDEs is partial parsing. Depending on where you use it.

borkdude10:11:44

@dominicm are you suggesting that edamame might be used for partial parsing? I guess that can work given the right options

dominicm11:11:30

depends where it's being used đŸ˜„ I'm not using it for that. But someone might.

dominicm11:11:51

I'm told one really hard part of vim-sexp was making it work with invalid code.

borkdude11:11:20

@dominicm one option for the location problem is to wrap non-metadatable items in a wrapper, if the caller is willing to unpack those during processing

borkdude11:11:51

e.g. 1 becomes edamame.Wrapper[1] with the right metadata or something

dominicm11:11:54

Yeah, records around everything (oops, we created rewrite-clj! đŸ˜„)

borkdude11:11:16

you'd have to do a walk over the data structure to make it into normal EDN, but you get a chance to look at the locations before that. yes, it's rewrite-clj like, but optional and maybe configurable

borkdude11:11:54

or storing the locations of the keys + vals as arrays of locations on the metadata on maps/vectors

borkdude11:11:07

but that would be an ordering problem for maps and sets

borkdude11:11:33

hammock time

mauricio.szabo14:11:36

Yes, partial parsing is really complicated. Currently, my code just ignores things that are not valid, and keep trying to find something. It can (and do!) generate some really bizarre trees

sogaiu19:11:05

@mauricio.szabo i'm running into the "how to deal with not-valid code" issue now. was hoping to have some way to cope with it using rewrite-clj, but i don't find anything may be the tree-sitter stuff is worth examining -- apparently there is already a clojure grammar for it (https://github.com/oakmac/tree-sitter-clojure) and iiuc, atom has tree-sitter built-in now.

mauricio.szabo21:11:41

@UG1C3AD5Z What kind of code are you having trouble, and what did you expect?

sogaiu21:11:13

i'm sending the content of an editor buffer to an external program to "detect the current expression". e.g. in the editor buffer, if i have:

(-> (rz/of-string "(+ 1 1)")
  rz/down
  rz/right
  rz/string)
and want to try something different for a moment:
(-> (rz/of-string "(+ 1 1)")
  rz/down
  rz/tag) ; request detection of expression here

  rz/right
  rz/string)
the latter code is not going to be parseable by rewrite-clj if i send the entire editor buffer content.

mauricio.szabo21:11:14

The thing is, what should happen here?

mauricio.szabo21:11:28

Maybe automatically remove the last paren?

sogaiu21:11:37

ah sorry, let me correct the code

sogaiu21:11:18

what should be detected is:

(-> (rz/of-string "(+ 1 1)")
  rz/down
  rz/tag)

sogaiu21:11:05

one thought is to send text up to the cursor position plus some number of appropriate closing delimiters. don't know if that's really a good idea or how easy it would be to implement (e.g. it's not always going to be a right-paren that i need).

mauricio.szabo14:11:23

Like, (+ 1 [ (+ 2 3)), my core currently detects (+ 2 3) as the only "valid" part of the code... The problem is that it also detects it as a "top-level" :face_with_rolling_eyes: