This is the mail archive of the
kawa@sourceware.org
mailing list for the Kawa project.
Re: Access the AST
- From: Per Bothner <per at bothner dot com>
- To: kawa at sourceware dot org
- Date: Thu, 08 Jul 2010 11:56:53 -0700
- Subject: Re: Access the AST
- References: <4C3612A9.4040501@fastwebnet.it>
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/