On Fri 23 May 2014 at 01:29:54AM +0200, Bronsa wrote: > When using tools.analyzer.jvm you have to remember that its primary > use-case is as a front-end for a compiler, in this case :tag and > :o-tag serve to inform tools.emitter.jvm when to emit a cast thus > might not always reflect the :tag meta of the expression :form.
I see, that makes sense. In that case I will attempt to preserve the
type hints in a namespaced metadata entry before calling the analyzer.
> Regarding the :tag/:o-tag difference, :o-tag (you can read it as
> "original tag") holds the static type of the node known at that point
> and might be either inferred by the :tag of some children nodes or from
> the class of the :form of the node in case it's a literal, :tag on the
> other hand can be either the same of :o-tag or hold the Class that node
> needs to be cast to, usually because of an explicit type-hint.
>
> For example, ^IPersistentCollection [] will have :o-tag PersistentVector
> and :tag IPersistentCollection.
>
> :class is an attribute of some nodes that deal with host interop forms,
> like :new, :instance-call and others and holds the Class that node deals
> with; for example it might hold the Class a :new node is going to
> instantiate, the Class an :instance-method belongs to etc.
This is very helpful, thank you very much.
> BTW, you don't need to roll your own `analyze` function providing those
> bindings, jvm/analyze already sets up the right bindings for you.
Ah, I should have looked at the source of jvm/analyze. That's much
friendlier.
Thank you for the reply!
guns
pgpp_1NFoctow.pgp
Description: PGP signature
