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/09/2010 03:18 AM, Daniele Benegiamo wrote:
On 07/08/2010 11:02 AM, Daniele Benegiamo wrote:
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.

My comment below, but I think point 2 or 4 is what I need (e.g. I don't want the output of macros).

I think you want to work at the level of (1) - the actual reader S-expressions.

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 mean the standard java.lang.Iterable interface. It /seems/ that all expressions implement (usually indirectly) that interface, while terminal symbols don't. But I've done only few very simple tests.

They only implement Iterable, because they're lists, and lists implement Iterable (indirectly, via java.util.List).


I should don't need macro expanded, I try to explain better my
application because I don't have to create a generic Scheme GUI, but
only a GUI for a subset of it (for a DSL): I have to "encode" trading
agreements, this can be done using only a few expression types (mainly
some conditionals, "set!", and some custom functions). Who will usually
edit those agreements of course don't know how/why a computer works, so
we have to implement a GUI to allow them to read/edit those encoded
agreements without showing them the Scheme source code. A short
hypothetic agreement could be encoded as:

(output-var vat percentage EUR "VAT to apply")
(output-var profit value EUR "Absolute profit")

(case destination-location-country
((IT FR ES) .2)
((US) .175))

(set! profit 100)
(if (is-festival-day delivery-date)
(set! profit (* profit 1.1))

Each of these expressions have to be mapped to some GUI control. E.g.
"output-var" could be a Scheme macro or Java function, but the user have
to see a simple block that, if clicked, open a form to insert the
currency, the variable type and a comment. So I've to parse the same
expression that appears into the source code, without expansions: if the
expression maps to some known name (e.g. "output-var", "case", "set!",
etc.) I know what GUI controls to use, otherwise a nice black-box will
be used. Is this the form (4) that you have described? Or the (2)?

Part of this is fairly simple list-processing: Assume each agreement is represented in a file. Then to generate the GUI you just read such expression/statement using the (read) function, recursively transform that some other program that displays blocks etc that GUI, and evaluate that transformed program. E.g. output-var is transformed to some expression that creates various Swing components.

(It is possible to use a special set of macro definitions for this.)

The tricky part, presumably, is mapping that back: If the user modifies
a field of the GUI, you want presumably want to modify the original
trading agreement. One mechanism is to keep track of line and column
number in the original trading agreement, so you can back-patch any changes.
The read function does have an option for that - used when reading Scheme programs.


But probably easier and better would be to re-generate the trading
agreements:  You have an "unparser" that translates the GUI tree-structure
back to a Scheme program.

This approach makes it harder to maintain whites-space and comments
in the trading agreements; I don't know if that is an issue.
--
	--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]