-
Notifications
You must be signed in to change notification settings - Fork 19
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Permanent syntax tree representation in background #800
Comments
…ighting fixed (fesch#881)
…pressionList(), Declaration.parse...()
…tegrated in Line, first steps to type retrieval in Root
Remark: Possibly it was not the best idea permanently to hold parsed lines on the elements, in particular since not all element text can be parsed and even small modifications in other elements or diagrams can invalidate any syntax tree derived on former diagram status. A very reasonable compromise seems to be to store the element text as lexically split token lists where the whitespace isn't mixed among the tokens but managed separately. This makes superfluous a lot of to-and-fro conversions, preserves original spacing without affecting token indices and it accelerates parsing a lot. On this occasion, the user-configurable "key phrases" (parser preferences) that may consist of several lexical tokens (like |
A consistent syntax tree representation of all element texts (or just the contained expressions) ought to be provided.
This allows to concentrate on a clean and consistent syntax analysis, also in order to improve the performance. Parts of it are ready but need more elaboration. And it must be tested with regard to memory and time complexity. The repeated tokenizations and concatenations and the frantic search for a point where certain matching and replacements should ideally take place without spoiling all what had been transformed before or will have to be transformed thereafter could be avoided this way.
If in the event there will be a central point in all generators where built-in functions are to be handled then this will be a big achievement allowing the requested clear documentation. (At least for a while...)
Some of the benefits would be:
There are of course several challenges, too:
Originally posted by @codemanyak in #462 (comment)
This also relates to several internal issues.
The text was updated successfully, but these errors were encountered: