Fork me on GitHub

@jjttjj true, sci can be used for "safe" code execution. by default it allows no interop, not even println


for extra control you can use :deny to deny certain functions, like swap!, just to name some silly example


there is also :allow which only explicitly allows certain functions. also :realize-max to prevent evaluating infinite lazy seqs


very cool, I think it might be just what I'm looking for then


@jjttjj you mean having sci on the server and client, right? I first read public cljs sci client, but I hope that's not what you meant


@jeroenvandijk basically sending quoted sci forms from a cljs front end to a clj server to be eval'd and the results sent back to the front end. Basically I want to use it as a sort of query langauge, where I send the quoted sci code to the server, which has :bindings for a few db access functions


Is there a way to add data readers to sci? Basically looking to get this to work:

 "(println #time/zoned-date-time \"2020-02-12T11:51:28.428005-05:00[America/New_York]\")"
 {:bindings {'println println}
  :classes {'java.time.ZonedDateTime

;;[line 1, col 84] No reader function for tag time/zoned-date-time.


@jjttjj Sci uses edamame for code parsing. Edamame does support a :readers option:


But I don't think this option is currently supported in the sci options map. We could just add it very easily.


I'm currently on my way to a meetup to do a talk on babashka and sci, so I have very little time today, but maybe you can figure it out and make a PR?


Sure, I'll take a look, thanks! You mean to expose it in sci right?


the options parsing is done in sci.impl/opts. that needs to parse a :readers key from the options provided by the user. and that one must then be passed to the options passed to edamame in sci.impl/parser.cljc


it's straightforward, you'll probably figure it out


great will take a crack at it