Clojurians Log v2

Ah I see, yeah I am always using submit top-level form to REBL to evaluate my code as I go, not sure if this is the usual/recommended way for a normal workflow

I am not understanding why evaluate selection works and top-level form doesn't? I was reading in the book something about the difference between forms and expressions and what makes a valid form - does that have anything to do with it?

And thanks for looking into it 🙂

To explain why, I'll need to dive a little bit on internals of Chlorine 😆 Evaluating a selection is just capturing what's selected in the screen and sending to the REPL. It's quite easy code

To evaluate blocks, we need to parse parts of the code, to detect where a block starts and ends. I use a ClojureScript library to do it.

Top blocks are even worse, because the whole file must be parsed so it's possible to detect when the "top block" starts and ends.

The problematic part is that when the code have an error, Chlorine needs to figure out how to behave. Currently, it ignores the wrong code and tries to keep parsing (sometimes getting the wrong result in the process, as it's happening with the issue you opened 😅)

(and it's also worth mentioning that if you're using my eval extensions, the selected code to be evaluated is expected to be valid in a (let [value code] ...) expression, so it has to be a valid single form)

In the built-in eval, I think selection can be multiple forms, @mauricio.szabo?

Yes, they'll be wrapped in an implicit do

My extensions don't wrap it in do because the code is submit'd to REBL and you want it to be the actual code being evaluated rather than being wrapped in do, but in the new tap>-based logic, I could do it -- and just give up on the veracity of what is passed to REBL 🙂

Even so, wrapping a selection of 123) (map inc is (do ..) isn't going to help you -- some selections just aren't going to be valid, no matter what you do 🙂

@flyingpython So, was that enough detail? 🙂

Ah OK I get the general picture thanks!

@mauricio.szabo did you see the ClojureScript site issue I tagged you in? Rewriting the broken ProtoREPL instructions to working Chlorine instructions...?

@mauricio.szabo could https://github.com/borkdude/edamame help?

Not really, because it's not that configurable (and actually slower than the rewrite-cljs). For example: with rewrite-cljs I can ignore the #_ literals when parsing text, or I can keep or remove newlines, and it'll not change tags like '( 1 2) (edamame will try to expand quotes and ::symbols for example)

slower? have you done any benchmarks? should not be much slower than rewrite-clj(c)(s)

edamame has configuration for how you want to resolve these things

I believe it was an old version, to be honest 🙂

I haven't done any benchmarks myself, but last time I checked it was pretty much the same (since both solutions are based on tools.reader)

user=> (require '[edamame.core :as e])
nil
user=> (e/parse-string "#_(+ 1 2 3)")
nil

user=> (e/parse-string "'(+ 1 2 3)" {:quote (fn [x] x)})
(+ 1 2 3)

The thing is, what I do need on Chlorine is to parse a string, lazily, ignore syntax errors if possible, then re-construct the original parsed string without any changes (or with minimum changes). Rewrite-cljs does exactly this. Edamame / tools.reader / other tools do different things

For example, what I do want to do is to be able to: (parse "'(+ 1 2)") => "'(+ 1 2)" (parse "'(+\n1 2)") => "'(+\n1 2)" (parse "(+ 1 2))") => "(+ 1 2)" (parse "#_(+ 1 2)") => "(+ 1 2)"

And even (parse "(+ #_1 2)") => "(+ #_1 2)" I don't really need to convert things to EDN at this moment because I'm only interested in the structure of the code

True (rewrite-cljs is still based on tools.reader as a library though, like edamame, hence performance should be roughly the same). Yes, if you want to "rewrite" then obviously rewrite-clj(s)(c) is a better fit. Also when you want to parse and ignore errors. That's why I ended up with rewrite-clj in clj-kondo initially. Edamame has a different focus: you want to parse code to actually run it. So it should crash when there's something wrong

@borkdude exacly! That's the point I missed on the first versions of Chlorine 😄

you were never actually using edamame back then right? it didn't even exist

or, how long does chlorine go back in history? :)

No, I never published any version that used edamame, but I tried once to change the code when I was using tools.reader. The "detection of forms" changed a lot: 1st version used Atom API to get the blocks (it's faster than what I'm using now, but it had to go because it only works in Atom, and also because it did detect parenthesis inside string and comments as "valid code" 😢

I almost used rewrite-clj inside babashka, but I figured it would be faster if I would work with the sexprs directly

The 2nd version used tools.reader, but to be reliable it needed to parse the code multiple times to get around errors in source (not ideal, and never worked 100%)

yeah, rewrite-clj(s)(c) is perfect for that. you should maybe try at some point, since it's going to be the successor of both: https://github.com/lread/rewrite-cljc-playground

and it will be maintained under clj-commons

@lee ^

hey ho! 👋 yep, toiling away at rewrite-cljc as we speak!

great! As soon as these namespaces are supported (don't know if they already are) I'll migrate: https://github.com/mauricioszabo/repl-tooling/blob/master/src/repl_tooling/editor_helpers.cljs#L5-L10 🙂

should be there I think. I'm also using some of this in carve

you can try it as a drop-in library in a branch. the only thing you need to change is rewrite-clj -> rewrite-cljc.

Yeah that’s all available. The last hurdle I am working on is how to support namespaced keywords and namespaced maps. Note that zip.base and zip.move are considered internal, you can now access what you need from zip. The reader namespace is also considered internal, but I’ve not broken compatibility therein, so should be ok for you to use. And until I get a release up on clojars, you will be frustrated if you want to release your work on clojars.

I noticed you were using reader a while ago, and have a todo to look into your usage.

Is that still about this one? https://github.com/xsc/rewrite-clj/issues/54#issuecomment-493038733 I thought you already solved that a long time ago.

@lee well, every usage of rewrite-cljs should be contained into this single namespace I sent to you 🙂. There's also a test namespace to understand why I need all this "zip dance" 😄

@borkdude, there are shortcomings to my original solution when in comes to sexpring and also cljs so I am :hammock: ing on it. I’m going to be so bold to ping you for your feedback when I flesh out a plan.

alrighty!

I guess carve doesn't suffer from this, since it doesn't do much sexpr-ing.

oh it does, btw

but it's not critical

@mauricio.szabo I’ll have to take some time to study that code to understand what it is doing, looking forward to it.

@borkdude, yeah I think carve should be fine, with current sexpr shortcomings.