> By "raw data structures", you mean the concrete implementing classes, a
la clojure.lang.PersistentVector?
Yes.
"(quote 1)" ->
> {:head :list :body [quote 1]}
>
You're not going far enough with this. Here's how my code is representing
that:
{:composite :list, :items [{:value quote} {:value 1}]}
That approach encodes non-composite types into the concrete class of the
:value field. However, you can encode that too. Here's an alternative:
{:type :list, :items [{:type :symbol :value quote} {:type :long :value 1}]}
All syntax is turned into first class representations. Reader macros and
> datastructure literals are indexed by special keywords; primitives stand
> for themselves without extra wrapping.
>
The key benefit of going all the way with the maps is that all of your
nodes always have space for :extra/keys
Take a look at :op :constant in CLJS for an example of how useful this is
for analysis. At minimum, you want to be able to store :line and :column
and the like, but Keywords and numbers and such don't implement IMeta.
> Clojure code is EDN data + a set of non-EDN constructs; doing with with
> 100% EDN is the problem I'm trying to solve.
>
Right. At this point, the Clojure reader is a superset of the EDN reader,
but all of the Clojure-specific forms can be (and often are) encoded as
both EDN forms and in-memory types objects. The notable exception being the
lack of an in memory representation of tagged literals.
Right now, the Clojure reader does some inline evaluation of Clojure-forms
like unquote and unquote-splicing. In theory, the reader could return a
'(clojure.core/unquote ...) list in memory, of a {:composite ...} AST node
shape. I think that https://github.com/clojure/tools.reader could probably
be made pluggable for returning the desired shapes.
> Random java objects and whatnot.
Random java objects and whatnot can only enter into your forms as the
result of tagged literal or macro functions. In both cases, there really
needs to be a separation between the reading of the value and the
construction of the value. CLJS is currently bugged for #inst literals with
respect to quoting, since the reader is returning code instead of Date
objects. If the literal's result is read by a macro, then you need a java
date, but if it's read by runtime code you need a js date, so it's a tricky
issue.
Every program that computes from the source code can just add its results
> as new attributes. This includes both the traditional compiler passes, as
> well as additional testing & analysis, or even the results of running the
> code.
>
I've been thinking about this issue a bit. Datomic's model is absolutely
great for the normalized core data of things, but I'm not convinced that
it's ideal for the results of observations. I rather not get into this in
this thread. I think that there's enough work at the reader level before we
can even discuss the analysis level.
--
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
