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


Per Bothner wrote:
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.

There are some classes of Kawa that can be used to parse/read these S-expressions? As Kawa already do it (and a lot more), there should be something... This would solve my problems (well, part of them ;) ).


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.

The idea of using macro is very nice. Actually the GUI should have a web front-end, using JSF. As JSF life-cycle is quite complex (converters, validators, AJAX, EJB, ...), I should spend more time to study that type of solution. But for the initial prototype I think I will go with a more "low-level" approach (mapping only a few functions). Because one problem is also to understand if final users are able to "compose" an agreement with this method instead of using big Excel tables... But for this I need to parse the S-expressions (see above).


For mapping the modifications back, as you pointed out, we have choose to re-generate the trading agreements. White-spaces and normal comments are not important (for now at least...). As JSF is already tree-based, it should not be an issue: a simple tree visitor that map back to Scheme the used JSF components.


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