Menu
▾
▴
opencxx-users
|
From: Stefan S. <se...@sy...> - 2004-09-22 23:13:34
|
SF Markus Elfring wrote: > Hello, > > >>to illustrate a little better my current ideas about the refactored >>OpenC++ architecture, and to show what I'v been working on in Synopsis >>over recent weeks, here is a little UML sketch: >> >>http://synopsis.fresco.org/docs/Tutorial/images/opencxx.png > > > Error meessage: > The requested URL ... was not found on this server. sorry, I forgot that this was a dangerous place (the nightly build will overwrite it). It's here now: http://synopsis.fresco.org/opencxx.png I should document this stuff in the tutorial some day... Regards, Stefan |
|
From: Stefan S. <sse...@ar...> - 2004-10-19 13:03:44
|
> From: SF Markus Elfring [mailto:el...@us...] > Sent: October 19, 2004 07:47 > > Right now I'm aiming at a modular structure with three or > four (logical) > > modules: PTree, SymbolTable, AST, and Processor. That's roughly in > > alignment with the above papers, and a natural (smooth) evolution > > for the OpenC++ design itself. > > How much can be reused from the Keystone-"Clouseau API" for > the high level AST interface that was discussed before? probably nothing, for a variety of reasons: * as discussed before, OpenCxx's approach is to attach a structure (the parse tree) to a buffer, instead of constructing an independent structure that uses its own storage. It would be much more sensible to push that further and let the AST be a superstructure on top of the parse tree instead of using existing AST code, i.e. the AST should be dependent on the PTree module. * Keystone is, as you already mentioned, licensed under GPL, and so not suitable for middleware / framework development. Anyways, as Grzegorz and I discussed some months ago, an AST module can and should really be something very lightweight. It doesn't add new functionality, it only makes existing information more accessible and more convenient to use. The real information providers are the PTree and the SymbolTable modules, for syntactic and semantic analysis respectively. Regards, Stefan |
|
From: Stefan S. <sse...@ar...> - 2004-10-20 21:09:17
|
> From: SF Markus Elfring [mailto:el...@us...] > Sent: October 20, 2004 16:50 > I hope that the accessibility can be enhanced by an interface > that will be similar to the Keystone-"Inspector Clouseau API". > I am not sure when it would become too "heavy". I think the key requirement should be to keep the underlaying data representation, i.e. instead of copying data out of the buffer / parse tree the AST should be a true superstructure. If it was not, you couldn't manually modify the AST and regenerate source code from it as is possible with the PTree API. Regards, Stefan |
|
From: SF M. E. <el...@us...> - 2004-10-21 18:26:58
|
> I think the key requirement should be to keep the underlaying data > representation, i.e. instead of copying data out of the buffer / parse > tree the AST should be a true superstructure. > If it was not, you couldn't manually modify the AST and regenerate source > code from it as is possible with the PTree API. What do you have got in mind with this "superstructure"? How is it different from a "Inspector Clouseau API"? Do you think about a concrete class hierarchy for more introspection? Would you like to apply the design patterns "adaptor" or "facade" like it is done in Keystone? I suggest to consider also the term "abstract syntax/semantic graph" (ASG) besides AST. Regards, Markus |
|
From: SF M. E. <el...@us...> - 2004-10-21 18:29:05
|
> I think the key requirement should be to keep the underlaying data > representation, i.e. instead of copying data out of the buffer / parse > tree the AST should be a true superstructure. > If it was not, you couldn't manually modify the AST and regenerate source > code from it as is possible with the PTree API. What do you have got in mind with this "superstructure"? How is it different from a "Inspector Clouseau API"? Do you think about a concrete class hierarchy for more introspection? Would you like to apply the design patterns "adaptor" or "facade" like it is done in Keystone? I suggest to consider also the term "abstract syntax/semantic graph" (ASG) besides AST. Regards, Markus |
|
From: Stefan S. <sse...@ar...> - 2004-10-21 19:03:22
|
> From: SF Markus Elfring [mailto:el...@us...] > Sent: October 21, 2004 14:27 > What do you have got in mind with this "superstructure"? > How is it different from a "Inspector Clouseau API"? As in the Clouseau API identifiers (strings) are helt by value and not by reference, you can't simply modify the parse tree *in place*. What Grzegorz and I discussed a while ago was a way to access (and that includes modify) the underlaying structure. > Do you think about a concrete class hierarchy for more introspection? I don't understand the question. As I said earlier, both the parse tree as well as the symbol table (and assorted analyzers) provide the means to introspect the code. the AST API would simply be a convenient high level view on these two. There isn't any more information that is not already available through the PTree and the SymbolTable modules. > Would you like to apply the design patterns "adaptor" or > "facade" like it is done in Keystone? can you should an example of what you have in mind ? Regards, Stefan |
|
From: Stefan S. <sse...@ar...> - 2004-10-22 20:05:13
|
> From: SF Markus Elfring [mailto:el...@us...] > Sent: October 22, 2004 15:31 > > As in the Clouseau API identifiers (strings) are helt by value > > and not by reference, you can't simply modify the parse tree > > *in place*. What Grzegorz and I discussed a while ago was a way > > to access (and that includes modify) the underlaying structure. > > Which identifiers do you mean? Is it needed in that design > that they behave as value objects? Why not in OpenC++? > Are you concerned about the consequences on memory consumption? no, I'm interested in in-place code manipulation, i.e. modifications to the AST that propagate automagically down to the underlaying parse tree / source code buffer. > > > Do you think about a concrete class hierarchy for more > introspection? > > > > I don't understand the question. As I said earlier, both the parse > > tree as well as the symbol table (and assorted analyzers) provide > > the means to introspect the code. the AST API would simply be > > a convenient high level view on these two. There isn't any more > > information that is not already available through the PTree and > > the SymbolTable modules. > > I assume that your understanding of a AST/ASG API might > result in a variant of a Clouseau API. well, all AST APIs will have many similarities as they all model the same domain. > I think that you will need a couple of related classes for > your implementation. Have any plans become concrete enough so > that more details can be disussed? not yet, no. My immediate goal is to finish the SymbolTable work at least down to a degree that allows the parser to completely disambiguate its input. > Is the topic "token decoration" also on your approach? Conceptually yes, as the work to be done is the same: Get a token from the lexer, and if it is an 'Identifier' find out whether it is a known symbol. If it is, choose the production rule according to the symbol type. That's what all disambiguation is about, no matter whether you describe it as 'token decoration' or in different terms. I haven't looked closely into the keystone parser but since it's written more formally in terms of bison, I think a formal on-the-fly decoration of the incoming token is a good approach. In our case the parser is hand-written so there is no need to do it exactly the same way. > > > Would you like to apply the design patterns "adaptor" or > > > "facade" like it is done in Keystone? [...] ok, yes, the goal being to decouple the submodules as well as possible. Using a single entry point for the parser to access the SymbolTable module looks like a good idea. Regards, Stefan |
|
From: Stefan S. <sse...@ar...> - 2004-10-25 12:46:54
|
> From: SF Markus Elfring [mailto:el...@us...] > Sent: October 22, 2004 17:53 > Would any developer who is subscribed to the OpenC++ mailing > list like to vote for a specific approach? It may help if you would summarize the approaches you want to get votes on. Regards, Stefan |
|
From: SF M. E. <el...@us...> - 2004-10-25 20:47:16
|
> It may help if you would summarize the approaches you want to > get votes on. 1. Edward D. Willink: Meta-Compilation for C++ transformation and filtering of a superset to the target language 2. James F. Power, Tanton H. Gibbs and Brian A. Malloy: Keystone token decoration Is this summary too short? Would you like to look at the referenced documents? Regards, Markus |
|
From: Stefan S. <sse...@ar...> - 2004-10-25 20:55:08
|
> From: SF Markus Elfring [mailto:el...@us...] > Sent: October 25, 2004 16:47 > > It may help if you would summarize the approaches you want to > > get votes on. > > 1. Edward D. Willink: Meta-Compilation for C++ > transformation and filtering of a superset to the target language > > 2. James F. Power, Tanton H. Gibbs and Brian A. Malloy: Keystone > token decoration > > Is this summary too short? That's not a summary. That are the titles of the documents. > Would you like to look at the referenced documents? yeah, but I don't need your help for that :-) I believe presenting the outline of the ideas would be more stimulating than just pointing at papers other people have written. I have read the papers you mention. I don't think voting is an appropriate approach to agree on a design. What we need is IMO a technical discussion on the merrits of the various approaches. That's why I'm asking for a short abstract (yours, not the ones in the papers). Regards, Stefan |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X