https://wiki.event-b.org/index.php?title=Stronger_AST_Library&feed=atom&action=historyStronger AST Library - Revision history2020-09-18T11:01:59ZRevision history for this page on the wikiMediaWiki 1.33.3https://wiki.event-b.org/index.php?title=Stronger_AST_Library&diff=9529&oldid=previmported>Mathieu: New page: {{TOCright}} The AST library in Rodin 2.x contains some flaws that, in some corner cases, could lead to misinterpreting mathematical formulas. These flaws were either present in the orig...2012-07-22T15:34:32Z<p>New page: {{TOCright}} The AST library in Rodin 2.x contains some flaws that, in some corner cases, could lead to misinterpreting mathematical formulas. These flaws were either present in the orig...</p>
<p><b>New page</b></p><div>{{TOCright}}<br />
<br />
The AST library in Rodin 2.x contains some flaws that, in some corner cases, could lead to misinterpreting mathematical formulas. These flaws were either present in the original design of the library or were overlooked when introducing mathematical extensions. This page lists these flaws and analyses the possible remedies for them.<br />
<br />
==String Rendering==<br />
In Rodin 2.x, there are several methods for rendering a formula as a {{Class|String}}. They all start with the {{Method|toString}} prefix.<br />
<br />
However, none of these methods takes the actual language as argument. Therefore, the rendering is done for some arbitrary {{Class|FormulaFactory}} which the AST library tries to derive from the formula itself. This is not safe, as clashes with reserved words can be introduced (especially, when rendering bound identifier declarations).<br />
<br />
The various string rendering methods should take a {{Class|FormulaFactory}} parameter defining the language of the formula. This is an incompatible change to the API.<br />
<br />
''N.B.:'' There is no need to pass a {{Class|ITypeEnvironment}} as the names introduced for bound identifiers only have a local scope.<br />
<br />
<br />
[[Category:Design proposal]]</div>imported>Mathieu