M.-A. Lemburg writes:
> Here's a simple strawman for the syntax:
...
> The compiler would scan these pragma defs, add them to an
> internal temporary dictionary and use them for all subsequent
> code it finds during the compilation process. The dictionary
> would have to stay around until the original compile() call has
> completed (spanning recursive calls).
Marc-Andre,
The problem with this proposal is that the pragmas are embedded in
the comments; I'd rather see a new keyword and statement. It could be
defined something like:
pragma_atom: NAME | NUMBER | STRING+
pragma_stmt: 'pragma' NAME ':' pragma_atom (',' pragma_atom)*
The biggest problem with embedding it in comments is that it is no
longer part of the syntax tree generated by the parser. The pragmas
become global to the module on a de-facto basis. While this is
probably reasonable for the sorts of pragmas we've thought of so far,
this seems an unnecessary restriction; future tools may support scoped
pragmas to help out with selection of optimization strategies, for
instance, or other applications.
If we were to go with a strictly global view of pragmas, we'd need
to expose the dictionary created by the parser. The parser module
would need to be able to expose the dictionary and accept a dictionary
when receiving a parse tree for compilation. The internals just can't
be *too* internal! ;)
-Fred
--
Fred L. Drake, Jr. <fdrake at acm.org>
Corporation for National Research Initiatives
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4