Google Groups

Re: ClojureScript analyzer overview document


Rich Hickey May 2, 2012 4:08 AM
Posted in group: Clojure Dev
:children is admittedly half-baked, but remember all things that are baked were once half-baked :)

Here are the objectives:

1) The AST as data. Full stop. That is part of the CLJS experiment. We've seen enough code- and API-based expression tree libraries.

2) Supporting generic code walkers. Code walking has traditionally been a difficult and brittle thing, as everyone encodes the primitives. Thus, adding a new primitive becomes impossible. Plus, that encoded knowledge itself is quite complex and duplicated between code walkers. Given that the AST data is a mix of things that would need to be walked and other details, there needs to be a mechanism to distinguish them. While a multimethod is one way to do make it an open system, it means that to manipulate your new AST node I don't just need the AST, I need your code. What about code walkers and analyzers etc as a service?

So, the problems I see with what we currently have vs these objectives are:

a) Inconsistency in the contents and use of :children.
b) Duplication

I wonder somewhat about (b). Given they are just values, in memory at least, they are shared. But yes, when printed or otherwise reified it's a bear.

:children as a vector of keys seems promising. Next steps in that direction would be to propose a standard way to do that, determine what that would imply for each construct we currently have, and assess the sufficiency for generic code walking. Along the way, consider what other semantic clues the AST might need to provide as data. Only then, implement for what we have.

p.s. to All

Just because you have a question doesn't mean the world needs to stop to answer it right away. Nor, should a discussion not produce an immediate result, was it a failure. Make your points and let it rest. Sleep on it. Please be patient with each other and the design process.

Rich

On Apr 30, 2012, at 6:00 PM, David Nolen wrote:

> Hmm how about this compromise- an add-children multimethod?
>
> (add-children ast)
>
> People who don't plan on transforming the AST can just interact with data - and those who plan on transforming the AST have a standard way to keep nodes up to date.
>
> David
>
> On Mon, Apr 30, 2012 at 4:47 PM, Aaron Cohen <aa...@assonance.org> wrote:
> You mean have both :children and :children-keys?
>
> I suppose that would work. The duplication still makes me want to poke my eyes out, but I will work on ignoring :children both in the code and mentally.
>
> --Aaron
>
>
> On Mon, Apr 30, 2012 at 4:29 PM, David Nolen <dnolen...@gmail.com> wrote:
> Oh right. What about :children-keys?
>
>
> On Monday, April 30, 2012, Aaron Cohen wrote:
> No, with :children I have to duplicate the information about which attributes are children is if I want to walk the tree. That falls out of date, can be incorrect. It's a clearly inferior solution.
>
> I'm pretty sure I've expressed myself as clearly as possible here, and it seems pretty clear you've made up your mind, so I'm done with this.
>
> Talk you next time, hopefully more fruitfully,
>
> --Aaron
>
> On Mon, Apr 30, 2012 at 4:17 PM, David Nolen <dnolen...@gmail.com> wrote:
> Having :children works for both. You're not querying you're transforming so that information is not relevant for your use case. For people who want to query all the necessary information is already present and no more work needs to be done.
>
> On Monday, April 30, 2012, Aaron Cohen wrote:
> On Mon, Apr 30, 2012 at 3:42 PM, David Nolen <dnolen...@gmail.com> wrote:
> On Mon, Apr 30, 2012 at 3:26 PM, Aaron Cohen <aa...@assonance.org> wrote:
> Is it impossible for core.logic to say (children node) rather than (:children node)?
>
> --Aaron
>
> Certainly not. But it's not particularly declarative. I just see no reason to *prioritize* functional transformation of the AST over declarative queries over the AST.
>
> If one solution works for both, and the other solution only works for 1, I really don't see what the argument is.
>
> --Aaron
>
> --
> You received this message because you are subscribed to the Google Groups "Clojure Dev" group.
> To post to this group, send email to cloju...@googlegroups.com.
> To unsubscribe from this group, send email to clojure-dev...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/clojure-dev?hl=en.
>
> --
> You received this message because you are subscribed to the Google Groups "Clojure Dev" group.
> To post to this group, send email to cloju...@googlegroups.com.
> To unsubscribe from this group, send email to clojure-dev...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/clojure-dev?hl=en.
>
>
> --
> You received this message because you are subscribed to the Google Groups "Clojure Dev" group.
> To post to this group, send email to cloju...@googlegroups.com.
> To unsubscribe from this group, send email to clojure-dev...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/clojure-dev?hl=en.
>
> --
> You received this message because you are subscribed to the Google Groups "Clojure Dev" group.
> To post to this group, send email to cloju...@googlegroups.com.
> To unsubscribe from this group, send email to clojure-dev...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/clojure-dev?hl=en.
>
>
> --
> You received this message because you are subscribed to the Google Groups "Clojure Dev" group.
> To post to this group, send email to cloju...@googlegroups.com.
> To unsubscribe from this group, send email to clojure-dev...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/clojure-dev?hl=en.
>
>
> --
> You received this message because you are subscribed to the Google Groups "Clojure Dev" group.
> To post to this group, send email to cloju...@googlegroups.com.
> To unsubscribe from this group, send email to clojure-dev...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/clojure-dev?hl=en.