This is the mail archive of the kawa@sourceware.org mailing list for the Kawa project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Access the AST


On 07/08/2010 11:02 AM, Daniele Benegiamo wrote:
Hi,

besides executing some Scheme scripts, I need to "inspect" them to build
a GUI that reflects the source scripts (so that users can visually view
and edit the source code).

I would like to know if it is possible, using some Kawa class, to access
(directly or indirectly, e.g. rebuilding it in some way) the AST of a
source Scheme file.

There are 3-4 things you could mean by "the AST":


(1) The raw reader-level S-expressions: lists, symbols, etc.
These do include line-number positions, though not quite as detailed
as one might like.

(2) The "syntax object" level, which is basically S-expressions
annotated with lexical context.  This is the input to (hygienic)
macro expansion.

(3) The output of macro expansion, which is a dynamic combination of (2)
(for further processing) and (4).  (A macro may return an Expression
directly.)

(4) The Expression tree, which is a non-Scheme-specific data structure
with macros expanded, identifiers bound to their definitions, etc.
This is the input to further analysis and then code generation.

I'm trying using Translator.formStack, and checking for implementation
of Iterable interface to distinguish expressions and terminals; but it
seems more an hack than a viable solution.

I don't understand this - Kawa's compiler doesn't distinguish Iterable - I can't even find the name Iterable in the Kawa source code.

I think just using form (4) makes most sense, though I'm not quite sure
what you're trying to do. Form (4) does map each identifier to its definition,
assuming one is lexically available, and this seems useful in an IDE/editor.
However, it does have some limitations - for example it doesn't track
macro expansions, so it may be tricky to figure out where something came from;
we could perhaps add some annotation mechanism for this.
Figuring out start and end positions of Expressions (something you'd want
in a GUI) may be difficult to do precisely - I've been thinking that we
might want a different way to handle those.


The MzScheme people have done some research in terms of smart Scheme editors,
type-aware macro expansions, etc, though I haven't kept up on this a much
as I'd like.
--
--Per Bothner
per@bothner.com http://per.bothner.com/



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]