sthg like a class diagram, only that better

An update. I was taking a look at the source and the output of Scaladoc2
(for example the long long list of subtypes of Tree).

It would be interesting to abstract Scala code into diagrams (again, the
type lattice ...) along the lines of Spinelli's http://www.umlgraph.org/

Miguel
http://www.sts.tu-harburg.de/people/mi.garcia

Miguel,

I think that read-only tools like these could use a good data structure to
work with instead of directly interfacing with the compiler.

Towards that goal, I've been working on very limited mirroring of Scala code.
By limited, I mean that I'm only working above the method level and
introspection only.

The idea is to provide a standard, documented[1], serializable, immutable data
structure[2] external to the compiler that represents the full compile-time
information in source files according to the specification. I've written a
compiler phase as part of sbt that does this down to method signatures[3].

Relating back to the topic of your email a bit, I wrote a compiler plugin that
extracted inheritance relationships [4] to a basic graph representation, but
it was only at the class/object level. I was planning to move the plugin to
use the external data structure as a sample usage of the mirroring outside of
my immediate purposes (the original use of this mirroring is for improved
partial recompilation in sbt).

Relating to your email further, this mirroring could be useful if you are
looking to make graphs at or above the method level. If you are looking at
expressions and statements, then perhaps you'd be interested in expanding the
data structure and compiler phase to mirror below the method level as well.

I see the possibility for tools like scaladoc, Scala X-Ray, dependency
analyzers, graph generators (UML if you like), and schema generators to
operate on this data structure. Most of these need information below the
method level, though. That is not currently in my scope, so I thought I would
put it out for discussion.

-Mark

(first two are works in progress)
[1] http://github.com/harrah/xsbt/blob/master/api.specification
[2] http://github.com/harrah/xsbt/blob/master/interface/definition
[3] http://github.com/harrah/xsbt/blob/master/compile/interface/API.scala
[4] http://github.com/harrah/inherit

On Monday 21 December 2009, Miguel Garcia wrote:
> An update. I was taking a look at the source and the output of Scaladoc2
> (for example the long long list of subtypes of Tree).
>
> It would be interesting to abstract Scala code into diagrams (again, the
> type lattice ...) along the lines of Spinelli's http://www.umlgraph.org/
>
> Miguel
> http://www.sts.tu-harburg.de/people/mi.garcia
>

Damn Mark that is some nice stuff.  EMACS is merging in CEDET as part of core emacs.  Think of CEDET and ECB as the elisp library that gives emacs the capabilities of Eclipse with regards to semantic/syntax awareness of the project code allowing things such as smart completion et al.   I have to find time somehow to get the data your extracting into the CEDET semantic DB.  It would make for a truly outstanding development environment option along with the current Eclipse JetBrains(?) and NetBeans options.

On Mon, Dec 21, 2009 at 4:24 PM, Mark Harrah <harrah@bu.edu> wrote:

Miguel,

I think that read-only tools like these could use a good data structure to
work with instead of directly interfacing with the compiler.

Towards that goal, I've been working on very limited mirroring of Scala code.
By limited, I mean that I'm only working above the method level and
introspection only.

The idea is to provide a standard, documented[1], serializable, immutable data
structure[2] external to the compiler that represents the full compile-time
information in source files according to the specification.  I've written a
compiler phase as part of sbt that does this down to method signatures[3].

Relating back to the topic of your email a bit, I wrote a compiler plugin that
extracted inheritance relationships [4] to a basic graph representation, but
it was only at the class/object level.  I was planning to move the plugin to
use the external data structure as a sample usage of the mirroring outside of
my immediate purposes (the original use of this mirroring is for improved
partial recompilation in sbt).

Relating to your email further, this mirroring could be useful if you are
looking to make graphs at or above the method level.  If you are looking at
expressions and statements, then perhaps you'd be interested in expanding the
data structure and compiler phase to mirror below the method level as well.

I see the possibility for tools like scaladoc, Scala X-Ray, dependency
analyzers, graph generators (UML if you like), and schema generators to
operate on this data structure.  Most of these need information below the
method level, though.  That is not currently in my scope, so I thought I would
put it out for discussion.

-Mark

(first two are works in progress)
[1] http://github.com/harrah/xsbt/blob/master/api.specification
[2] http://github.com/harrah/xsbt/blob/master/interface/definition
[3] http://github.com/harrah/xsbt/blob/master/compile/interface/API.scala
[4] http://github.com/harrah/inherit

On Monday 21 December 2009, Miguel Garcia wrote:
> An update. I was taking a look at the source and the output of Scaladoc2
> (for example the long long list of subtypes of Tree).
>
> It would be interesting to abstract Scala code into diagrams (again, the
> type lattice ...) along the lines of Spinelli's http://www.umlgraph.org/
>
> Miguel
> http://www.sts.tu-harburg.de/people/mi.garcia
>

--
The object of life is not to be on the side of the majority, but to escape finding oneself in the ranks of the insane. - Marcus Aurelius