cljs.repl.reflect/clojure.reflect refactoring

[Chas Emerick]

In the process of bringing http://dev.clojure.org/jira/browse/CLJS-489 home, I need to carry forward the functionality of cljs.repl.reflect, which was (is) bound up with the implementation details of the browser-REPL's custom HTTP server.

I've posted a comment on that ticket (@ http://dev.clojure.org/jira/browse/CLJS-489?focusedCommentId=30849#comment-30849) that discusses what cljs.repl.reflect does (I'd never used it myself, and I suspect most others are in the same boat), and what I plan on doing with it and its user-facing API, clojure.reflect.

If you use these facilities in your ClojureScript REPL-ing, please take a look and either add a comment there or reply here if you see any problems with the plan. This would be a breaking change, but very much for the better IMO.

Cheers,

- Chas

[David Nolen]

Given the division between the compilation and runtime environment in ClojureScript the idea behind cljs.repl.reflect is to provide general facilities for any REPL to reflect on information collected by the analyzer not just docstrings or macroexpansion and to provide this functionality as *functions* not macros. Now that doesn't mean the current implementation is fully baked but any changes to the REPL should carry the idea forward.

--
Note that posts from new members are moderated - please be patient with your first post.
---
You received this message because you are subscribed to the Google Groups "ClojureScript" group.
To unsubscribe from this group and stop receiving emails from it, send an email to clojurescrip...@googlegroups.com.
To post to this group, send email to clojur...@googlegroups.com.
Visit this group at http://groups.google.com/group/clojurescript?hl=en.

[Chas Emerick]

OK, I only now discovered http://dev.clojure.org/display/design/Reflection (I had previously passed it over because the search results listed it as being in the Clojure design wiki)

The objectives are great.  Perhaps I'm missing the forest for the trees though, as I don't see how they can all be met with the current set of abstractions at hand.  The current implementation certainly isn't general-purpose (it's very tightly tied to a particular browser-REPL impl), but that aside, I don't see any clear route for a function-based implementation to work across different REPL environments.  ClojureScript macros almost definitionally have privileged access to the compiler/analyzer/etc; the browser-REPL can only get around this because it has a persistent side-channel to the compiler host as an implementation detail.  Rhino could be made to work as well, but only because it's in-process.  Something like node-cljsrepl would have a very hard time supporting `clojure.reflect` without e.g. adding a method to IJavaScriptEnv or another protocol that implied reflection capability to offer a similar side-channel.  (Not actually proposing anything here, just thinking aloud about what the distance might be between here and a complete solution.)

All that said, I'm happy to carry the reflection functionality along with the improved browser-REPL.  But, if my assessment above is essentially accurate, my secondary proposal would be to at least put the user-facing reflection functions into something that indicates their implementation limits/targets (cljs.repl.browser.reflect? — similar to the clojure.java.* arrangement), which can later just delegate to `clojure.reflect` bits if and when a general contract is settled and "clojure.reflect" is indeed where fns like `doc` and `macroexpand` are to live in ClojureScript.

Thanks,

- Chas

--
You received this message because you are subscribed to the Google Groups "Clojure Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to clojure-dev...@googlegroups.com.
To post to this group, send email to cloju...@googlegroups.com.
Visit this group at http://groups.google.com/group/clojure-dev?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[David Nolen]

On Sat, Mar 30, 2013 at 10:51 PM, Chas Emerick <ch...@cemerick.com> wrote:

OK, I only now discovered http://dev.clojure.org/display/design/Reflection (I had previously passed it over because the search results listed it as being in the Clojure design wiki)

The objectives are great.  Perhaps I'm missing the forest for the trees though, as I don't see how they can all be met with the current set of abstractions at hand.  The current implementation certainly isn't general-purpose (it's very tightly tied to a particular browser-REPL impl), but that aside, I don't see any clear route for a function-based implementation to work across different REPL environments.

Agreed. I think the idea here is just determine some accepted communication format and some protocols around transmission?

 

All that said, I'm happy to carry the reflection functionality along with the improved browser-REPL.  But, if my assessment above is essentially accurate, my secondary proposal would be to at least put the user-facing reflection functions into something that indicates their implementation limits/targets (cljs.repl.browser.reflect? — similar to the clojure.java.* arrangement), which can later just delegate to `clojure.reflect` bits if and when a general contract is settled and "clojure.reflect" is indeed where fns like `doc` and `macroexpand` are to live in ClojureScript.

This sounds like a good plan. 

David 

[Chas Emerick]

A new patch is now attached to CLJS-489, described here:

http://dev.clojure.org/jira/browse/CLJS-489?focusedCommentId=31267#comment-31267

Those not wanting to bother downloading the patch can see the changes in my branch here:

https://github.com/cemerick/clojurescript/commit/ef1cfd46a6e0b879cdf018eb3bd012e3e3828cff

I believe this now addresses the reflection facilities as well.  Check it out, feedback welcome, etc.

- Chas