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] |
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 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.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |