Fork me on GitHub

I found that load-string is available from within a Scittle script, which makes it easy to expose evaluation of multi-line user entered ClojureScript from a single HTML file. Really nice!! (That is: for a lazy tinkerer like myself who really likes not needing an actual build/compilation step, if at all possible... 🙂 ) I am finding though that errors that might occur lack position information, which is unfortunate. This seems the case for both reader/parser errors as well as exceptions thrown during evaluation. E.g.

(load-string "
(defn f [x]
  (inc n)) ; clearly an error (line 3, form starts at column 3)
results in #error {:message Could not resolve symbol: n, :data {:type :sci/error, :line nil, :column nil, :file nil, :phase analysis}}. As Sci is clearly perfectly capable of providing position information, as any error in the Scittle script itself reveals, I wonder why :line and :column get a nil value here. I'm guessing I just don't fully appreciate yet how exactly Sci is jumping through the hoops to facilitate it all, specifically w.r.t. the 'ctx' and 'current-namespace'. So I wonder if there is some low hanging fruit that I am missing that might help getting to the error's line and column number within the user entered string after all. Or is this fundamental to what is(n't) possible in a Scittle script? Thanks a lot! (The Clojure REPL provides position information:
user=> (load-string "
(defn f [x]
  (inc n)) ; clearly an error (line 3, form starts at column 3)
Syntax error compiling at (REPL:3:3).
Unable to resolve symbol: n in this context
For this case Babashka does not however, which makes me wonder again if this is fundamental to Sci after all... :thinking_face: Scanning the source code I do wonder whether a lack of explicit position logic in the catch clause in sci.impl.parser/parseNext might have something to do with it, but I am sure that there's a lot more to it. Interestingly, the following works nicely in Babashka:
user=> (load-string "

   (throw (ex-info \"!\" {}))

clojure.lang.ExceptionInfo: ! [at <repl>:3:4]
but the same load-string expression in Scittle does not yield a useful stacktrace with relevant position info. Any pointers are very much appreciated!)


@jurjanpaul502 Yes, this is possible and I'm not sure why this doesn't happen properly. You could also try scittle.core.eval_string


@U04V15CAJ Thank you so much for your quick response (even this late in the day)! I found eval-string in the source code and wanted to invoke that, because it would be the perfect 'strange loop' 😉 but I was so far failing to actually invoke it from within a Scittle script. Attempting to invoke it directly by name yields an Could not resolve symbol: eval-string error. An attempt to require scittle.core yields a Could not find namespace scittle.core error. But I just found the string scittle.core.eval_string inside scittle.js and tried invoking it like (js/scittle.core.eval_string s) and that does give me the same result as the load-string invocation! Thanks! Even so, at the moment I still get a nil value for both :line and :column.


it might be something in SCI where there's a check if *file* is bound, so doing (binding [*file* ...] (load-string ..)) might also help. If that doesn't, issue welcome


Tried it by binding *file* to the string "buffer" and that caused the :file entry in the error map to get the value "buffer", but kept the values of the :line and :column entries nil. At some other time I will pursue your suggestion that SCI might need something specific, by reading some more of the source code. 🙂


Issue welcome anyway. Did you also try scittle.core.eval_string ?


👍 Yes, I will file an issue when I find some time. 🙂 [mentioned in other reply that] Invoking (js/scittle.core.eval_string s) yields the same result as (load-string s), so also no line number and/or column. I’ll construct a minimal Scittle page that reproduces this.