On Fri, Jun 21, 2013 at 6:08 PM, Brandon Bloom <[email protected]>wrote:
> You've outlined 2 out of the 3 interesting (to me) shapes: 1) raw data
> structures and 2) datoms. I think that the 3rd interesting one is a
> map/vector tree, like the CLJS analyzer output.
>
By "raw data structures", you mean the concrete implementing classes, a la
clojure.lang.PersistentVector?
What I had in mind was more like #3, a map/vector tree, but you're right
theres an extra interesting shape there.
Here's a minimal design for what I'm talking about:
"(quote 1)" ->
{:head :list :body [quote 1]}
" '1 " ->
{:head :quote :body [1]}
#{1 2 3} ->
{:head :set :body [1 2 3]}
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 original structure of the source is preserved 100%. You would then have
an EDN-to-in-memory-raw-datastructures reader to read from this into live
running code.
(this is basically the EDN-ified form of Mathematica expressions, and its
particularly well suited to symbolic manipulation and pattern matching)
One can then go from this, in a series of passes, into an AST (this is the
"convert to normal form and add semantics" step) and then into compiled
code. And have a chance at mapping exceptions back to the original source,
and do analysis between the source, the AST, and the error.
The two languages to describe are EDN and Clojure. You can further break
> Clojure down by host platform, and even potentially further (for example:
> pre and post macro expansion variants of the language).
>
I think I understand what you mean, though lemme try to rephrase it:
Clojure code is EDN data + a set of non-EDN constructs; doing with with
100% EDN is the problem I'm trying to solve.
When attempting to output EDN data, a different but related set of non-EDN
constructs messes things up.
I definitely agree that's also a problem, TLs are one case and definitely
agree with the direction there, though what about the other cases? Random
java objects and whatnot.
Those should be output in an EDN way, though its unclear what they would
mean when read. Would there be any attempt to convey their contents or
characteristics?
Issues around this are a big headscratcher for Session, so I'd be happy
with some standard solution here.
> As for the Code variant, the tools.analyzer library and CLJS compilers
> have an internal AST representation that should eventually be standardized.
> The important thing there for me is that we differentiate fundamental
> properties of AST nodes and synthesized/derived attributes that are
> attached to each node.
>
The datomic representation is particularly interesting for this.
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.
So there is a single source of truth about the source code and its
consequences, and different layers have access to the big picture.
--
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to [email protected]
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
[email protected]
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 [email protected].
For more options, visit https://groups.google.com/groups/opt_out.
