Is it possible to extend a whole type to a new IPrintWriter, but only in the scope of particular print action?

Like, say I want to print a whole collection, but I want to do something funny with the strings or functions or objects, but only during this printing, not globally at all times.

I think I can do scoped tagged readers... looking for the other direction

I want to tell the writer, "for each node in this collection, if you get to this type, write it this way instead"

Without having to pre-walk the collection and tag things

And if I had to walk it, is it even possible to get js type info during a macro time walk? Does the analyzer have that info?

I could walk it at runtime, it just seems excessive

I think you want to extend a particular JS object to IPrintWriter?

have you looked at specify! @john?

Yeah, I'd just have to walk the whole thing before writing it

It would be more efficient to instrument the write's walk

so basically ou want to extend-type, print it, and then un-extend-type 😛

right 🙂 scoped-extend-type. or with-extensions or something

interesting

Could be done with the generic isa? hierarchies

Doubt it with the protocols

hmmm. Can you use isa? hierarchies to override type dispatches?

Probably not for a writer...

I don’t think this is a use case anticipated / supported by Clojure, typically. I guess it’s all about how much we can get at the protocol impl

I can think of a pretty bad way to do this

Well I'm doing some real bad things 😉

in CLJS we happen to know that protocol implementations end up like

Bar.prototype.cljs$core$IPrintWithWriter$_pr_writer$arity$3 = function (this$ writer$ opts$) { ... }

(i wrote that from memory so might be wrong)

so you could save the current value of the -pr-writer impl, extend the type, then when you’re done swap it back 😛

lol

I’m expecting dnolen or mfikes to come in at any second to swat my hand away

(or to tell us it’s trivially easy using something I don’t know)

I’ve been circling around a similar problem with printing hiccup. I’d like to take a React element and print it to something like #hiccup/react [:div "foo"], but React elements are just bare objects 😕 hard to handle

ironically the use of plain data in JS bites us when it’s in fact special

I'm essentially trying to experiment with strategies to pickle certain kind of objects and functions over the .postMessage wire in a webworker environment

it’s been awhile since I used IPrintWithWriter. doesn’t it require you to call it recursively?

so couldn’t you make that a recursive call to your own printer that handles these objects specially?

So, for any given cljs collection, printing it will pickle certain types into a tag with an id, add the object as another parameter to the message, send the message, read-string the edn, then the tag-reader will grab the object for that id and the collection is restored on the other side.

I don't think so

I'm not sure

Well, it may be recursive for some types

My other option, instead of printing collections to edn, would be to clj->js the coll and extend IEncodeJS for the types I care about

But the edn path already has more fidelity for clojure datastructures... I'd have to add a lot of IEncodeJS writers and readers

do you even need to use IPrintWithWriter?

Maybe not?

maybe it’s better to implement your own protocol, IPickle, and create your own printing function

you could fall back on IPrintWithWriter if the object doesn’t implement IPickle

At the moment, I'm experimenting with pickling anything that answers to fn?

I think the only thing that answers to fn? is function

So, extend-type js/Function is pretty aggressive

Wouldn't IPickle have to implement IPrintWithWriter?

Does polymorphism in JS even have any performance benefits?

yes

well, it has performance implications. sometimes it’s faster

I think it can be done by walking the whole collection and specify!ing a special printer that hands off the object and drops in a tagged id for fn? args

What's interesting is that certain functions print out in a self contained way, such that if all of your workers (or js environments) have the same compiled artifacts, the strings act as byte code that can be shuffled between them.

@yogthos presented a video where they’re serializing functions to a DB and then reading them into a CLJS app

ah, yes, there are some libs that serialize to local-storage

the whole function impl was in the serialization though, so it sounds like you’re getting like a reference to a function and then passing that over the wire?

I don't think they're storing compiled snippets of cljs as bytecode though

not really sure what you mean “as bytecode”. I think they were just passing EDN back and forth from the DB to the app

and evaling it

I'm doing this (((read-string (pr-str (fn->special-fn (fn [] inc))))) 1) where special fn reifies a special print writer and a tagged reader calls js/eval on it.

where the output is 2

Or (((read-string (pr-str (fn->ray-fn inc)))) 1), rather

wild 🙂 all to avoid including self-hosting?

But (fn [] inc) evals to:

#object[ret__6694__auto__ "function (){
return cljs.core.inc;
}"]

Yup 🙂 Works in advanced mode too 🙂

And if you ((js/eval *1)) you'll get back cljs.core.inc, the function

It's definitely a little wild. Not a supported use case... But the utility of it is pretty surprising. Especially when you use it mostly as an rpc mechanism for already statically compiled code, even though it feels kinda like your talking between threads like back in clojure-land

yeah. starts to tickle at some things I’ve run into while developing a REBL clone for CLJS

Yeah, you're not getting the same object on both sides of the wire here, in an equality sense, necessarily

But you can get blocking back if you are willing to keep it inside a worker

I do have a cool SAB backed atom thing though that can be shared between workers, and that is the same object on both sides of the wire. And a cool on macro that knows how to transfer them, so you can do like (let [sa (shared-atom 1)] (-> wkr1 (on #(swap! %1 + %2) sa 1)) (println (wait sa))) or just ... (-> wkr1 (on swap! sa + 1)) ... as all arguments to the right of the function passed to on will be applied to it.

Still thinking through the api

on also sends a sab to the worker for the return value of the function you pass, so that you can dereference the return value of the on to get the result, or wait on the result, like (-> wkr1 (on swap! sa + 1) wait (->> (println :result)))

or (-> wkr1 (on fib large-number) wait (->> (println :result))) would probably be more likely, if you're just using the return value sab to get the result.

I've already got the on macro doing the function wrapping jazz and it seems to work for common functions you might pass to a swap. Just building out the ability to transfer clojure collections now, but not sure whether to go through the trouble of trying to build out all this machinery to convert all functions in an arbitrary clojure datastructure

if anyone’s interested, I whipped up an example of using reader tags for hiccup parsing: https://github.com/Lokeh/hiccup-tag/blob/master/src/hiccup_tag/examples.cljs#L17

That's pretty awesome

It'd be interesting to make a static site/blog edn format where all behaviors are in an approved set of tagged readers, where all the logic is guaranteed to run deterministically and terminate.

You could use some subset of react for building out the view. Some bounded for-looping.

And then possibly page snippets could be shared between untrusted users. Essentially, sandbox the logic but allow for new complex components that are built in clojure but are guaranteed to be safe at runtime

meanwhile I’m happy if my reagent counter works when I click the button.

joke aside, cool idea.

lol

I’m thinking of ripping out the hiccup interpreter in hx and using tagged literals instead

I haven’t really run into a use-case yet where I wanted the dynamicity of runtime interpretation. it’s been more a concession because the ergonomics of macros are bad

I need to assess if the ergonomics of tagged literals are also bad 😛

Yeah, what's the tradeoff?

tagged literals are actually even more static

but IMO they’re easier to write ad-hoc

#h/r [:div (for [n [1 2 3]] 
             #h/r [:div {:key n} n])]

;; vs

(h/r [:div (for [n [1 2 3]]
             (h/r [:div {:key n} n])])

Yeah, that's a happy-to-glad for me

One interesting thing about tagged literals - because they run before macro expansion, you can write things in macros that transform prior to macro expansion

an upside to the reader literal is being able to use it with cljs.reader to receive stuff over the wire, though that’s not something I’m actively using it for

Not sure where I'd use that yet, outside of the ns macro

true

Though you can dip into that using register-tag-reader! without having to have a reader file, if you're just converting stuff from io

actually the change that I think makes either macros or reader tags tenable is the thing I’m doing with props

I haven’t implemented it completely yet, but I’m testing a new syntax for dynamic props:

(let [stuff {:style {:color "green"}}]
  #h/r [:div {& stuff} "foo"])

what happens to stuff?

which will merge the stuff map onto the actual props object given to React

it’s the equivalent of the JSX:

<div {...stuff}>foo</div>

mmm, can you get access to cljs locals at tag expansion time?

I think the analyzer might be different at tag reader vs macro compile time

atm I just expand it to:

(merge-obj+map (js-obj ...) stuff)

merge-obj+map awaits implementation 😛

oh gotcha

but it solves the ambiguity of parsing a form like this:

[:div stuff "foo"]

Yeah writing tagged readers can be a little mind-bending too though. If you pull it off, I'm sure it'll be very interesting.

yeah 😅 I’m still not sure I did it right, but it seems to be working in my example

Hello, is there a way to require clojure libaries into clojurescript? I am getting this error:

Unexpected error (ExceptionInfo) compiling at (<cljs repl>:1:1).
No such namespace: clojure-csv.core, could not locate clojure_csv/core.cljs, clojure_csv/core.cljc, or JavaScript source providing "clojure-csv.core" (Please check that namespaces with dashes use underscores in the ClojureScript file name) at line 1 <cljs repl>

no, you cannot use clojure libraries in clojurescript

some libraries provide code for both

@lilactown Understood. Thanks!