Martin v. Löwis wrote: >> This leaves us with a few options: >> > > 5. Reuse/Abuse Num(object) for arbitrary constants. > AFAICT, this should work out of the box. > > Eek. It *does* seem like Num would work out of the box, but would this be a good idea? What about *replacing* Num with Const? Might make optimizations specifically for numeric values slightly hairier, and semantically I think they might be different enough to warrant separate AST nodes despite the similarity in implementation at the compiler level. FWIW, I read Num as "numeric literal" and Const as "arbitrary constant", but that's probably only because I've seen the immediate need for constants with non-Num values in the process of writing the AST optimizer. >> 1. A new AST expr node for constant values for types other than Str/Num >> >> I imagine this to be something like Const(PyObject* v), which is >> effectively translated to a "LOAD_CONST v" by the compiler. This trades >> the purity of the AST for a little practicality. A "Const" node has no >> real source representation, it would exist solely for the purpose of >> injecting PyObject constants into the AST. >> > > I think this is the way to go. It doesn't violate purity: it is an > *abstract* syntax, meaning that there doesn't need to be a 1:1 > relationship to source syntax. However, it is still possible to > reproduce source code from this Const node. > > I'm leaning toward this, too. It's dirt simple and quite clean to implement. > I also don't worry about Jython conflicts. The grammar has a version > number precisely so that you can refer to a specific version if you > need to. > > Any Jython folk care to weigh in on this? If there are no major objections I think I'm going to forge ahead with an independant Const() node. Cheers, T
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