Fork me on GitHub
Yehonathan Sharvit13:04:52

I’d like to add a test for self host and static dispatch

Yehonathan Sharvit13:04:07

It’s an edge case that illustrates why we must stay with call for the high order case where static information is missing

Yehonathan Sharvit13:04:35

The changes suggest by @mfikes and me would break again the new test case

Yehonathan Sharvit13:04:24

Here is the suggested change: (emits "(" f fprop " ? " f fprop "(" (comma-sep args) ") : " f "(" (comma-sep args) "))”) instead of (emits "(" f fprop " ? " f fprop "(" (comma-sep args) ") : " f ".call(" (comma-sep (cons "null" args)) "))”)) in emit :invoke


Would there be interest in a contribution to make cljs.test work with bootstrap? A side benefit would be enabling the compiler unit tests for that mode, thus reducing the overall bootstrap support burden.


@mfikes I was going to ask about cljs unit tests for comp + ana, does something need to happen with bootstrapping for that to work?


@pat Yes. cljs.test macros need adjustments. It is working in Planck.


@mfikes while I've got you, do I need to have special JIRA permissions to attach a patch with correct issue # when creating an issue?


Today I had this wild idea: assume :static-fns false for now, instead of passing null into all emitted .call invocations, we would pass this. By default it would be null so it would behave identically. But this would then allow extra flexibility to pass a special “context with implicit parameters” down with a function call. This context then could be used by context-aware code to lookup some state dynamically as an alternative to global namespace lookup. I believe this would allow to relatively easily adapt libraries which are written in a style with global state[1] into Sierra’s component-like model, where the code stays the same, but state lookups get just wrapped in a lookup helper. The lookup helper would emit something like this this?doContextLookup(this, “thing-id”):*normal-static-thing-lookup*. This would enable someone “at the top” to invoke library functions with different contexts (again using some helper macro, or something passing a new context as-this). In case of re-frame it would allow having multiple instances of re-frame in a single javascript context despite the way how it was written. btw. This feature has been requested multiple times, I had to write a re-frame fork to deal with that myself[2]. Also I have already experienced the pain[3] of rewriting a not-trivial codebase written in this style to use Sierra’s component model. I ended up passing those ‘context’ parameters down multiple levels into the tiniest functions in my system. Something like this would give me an option to pass contexts as implicit this, but the code would still read the same. [1] [2] [3]