Changes between Version 5 and Version 6 of NewFrontEnd

Timestamp:

2017-01-26T01:20:12+01:00 (8 years ago)

Author:

adrpo

Comment:

--

NewFrontEnd

@@ -1 @@
-== New FrontEnd ==
+= New FrontEnd =
 
 This page gathers all the information about the new front-end. See also #4138.
 
-=== Debugging ===
+== Debugging ==
 Whether you use MDT (make sure you keep it updated) or OMEdit you need to compile the source code with CFLAGS=-g to be able to debug the compiler.
 Delete OMCompiler/Compiler/boot/build and then rebuild with CFLAGS=-g 
 
-=== Implementation details ===
+== Implementation details ==
 
 The new frontend is divided into multiple (mostly) separate phases. 
@@ -34 +34 @@
 Also, the class tree and the instance tree are not actually separate trees, but rather one combined tree made up of InstNodes (e.g. each component knows its parent component, each components type knows its parent class, and so on).
 
-=== Known issues ===
+== Implementation directions ==
+
+=== Conditional Components ===
+This needs evaluation of structural parameters to work to evaluate the condition. 
+The components can stay in place and they can be filtered out together with the connects they are involved in.
+
+=== Inner/Outer ===
+The current front-end is handling the inner/outer via lookup and that poses problems with prefixing and handling of hierarchical inner outer.
+Bernhard has suggested to define alias equations for the inner outer pairs at the appropriate level which will also maintain a bit of the 
+hierarchical structure to be analysed by the back-end.
+
+=== Functions ===
+Instantiation and typing of functions is partially implemented. 
+We should extend the NFExpression.CALL to include a link to a unique inst node of the function that is to be called.
+Positional arguments and named arguments are supported. 
+Vectorization of functions needs to be implemented. 
+Prefixing is not yet handled correctly. 
+Support for reductions needs to be implemented. 
+Some way of storing functions during the instantiation is needed so that they 
+end up in the DAE (we can probably use the component tree directly for this).
+The back-end needs the function tree to partially evaluate functions.
+
+=== Records (Lennart & Mahder) ===
+The instantiation will instantiate the records as normal classes.
+Support for record constructors needs to be implemented, and other record things.
+We should (maybe) add a new expression type NFExpression.RECORD_CONSTRUCTOR 
+which should (as function calls) include a link to a unique inst node of the 
+records that is to be called/constructed.
+
+=== Builtin ===
+As much as possible support for builtin functions should be implemented via ModelicaBuiltin.mo file.
+
+=== Typing ===
+Typing is partially implemented, but it needs to be expanded to handle all kinds of expressions and so on.
+Care is needed to handle bindings so that cycles can be detected during the evaluation of structural parameters such as dimensions.
+The binding have a isProcessing flag that can be set to detect cycles. On error all the components / bindings can be queried for this 
+flag to produce at least the components / bindings involved in the cycles.
+
+=== Type Checking ===
+NFTypeCheck handles most of the type checking. NFFunction and NFRecord handle the type checking for functions respective records.
+Type checking is currently called from typing but it could be performed as a separate phase (remains to be seen if is possible)  
+
+=== Connection Handling ===
+Handling of connect equations will be performed on the DAE and the instance tree can be use for additional information.
+Care is needed to handle in a scalable way:
+* connection sets
+* overconstrained connections (equalityConstraint type) and breakable branches
+* expandable connectors
+* inner/outer in the connection sets
+
+
+=== Operator Overloading ===
+The support for operator overloading from the current front-end (which was reimplemented by Martin for high scalability) 
+could be partially reused for the new front-end.
+
+=== Constant Evaluation ===
+Constant evaluation of structural parameters (minimal) or any other constant/parameter bindings (not by default) should be included.
+Care should be taken to NOT evaluate anything that is not needed so that optimization of certain parameters can be done in the runtime.
+A new type of expression for the component reference that contains a link to the instantiated component can be use to do evaluation of bindings.
+
+=== Function Evaluation ===
+This works in connection to Constant Evaluation.
+To evaluate structural parameters one needs to (sometimes) evaluate functions. 
+The current front-end is using an environment to interpret functions. This might 
+not be needed for the new front-end as constant evaluation and substitution could
+be used instead.
+
+=== Local balance checking ===
+This has a connection to typing / type checking / constant evaluation.
+This will check the balance checking for each model so that errors can be detected sooner. 
+We had no such support in the current front-end.
+It is highly desired that the balance checking is done symbolically using expressions for 
+the number of equations and components. For the final check one could use constant evaluation 
+of these size expressions.
+
+== Known issues ==
 
 [[TicketQuery(status=accepted&status=assigned&status=new&status=reopened&component=~NF&group=priority&col=id&col=summary&col=status&col=type&col=priority&col=milestone&col=component&order=priority,format=table)]]