New Sindarin implementation

[kilian]

The current state of those modules is a mess. Moreover, the expressions module is separated from the commands module by a big gap in the source code, although only both together constitute the Sindarin language.

Refactoring should realize the obvious polymorphism in the tree-like data structures. It should move the expressions module to top level. The new structure should prepare simplification, generalization, and a more consistent definition of the Sindarin language, and it should provide a sensible user interface for things like jet algorithms etc.

This is a major piece of work, so I postpone this to 2.3.

[Juergen Reuter]

Just for clarification: so this is basically the "big SINDARIN revision" ticket, right? Please note existing possibly related tickets #410 and #416.

[kilian]

The current ticket reminds us about the way to get there. Once the internals are in better shape, we can address the 'big picture' (how Sindarin should look like on the long run), also from the user's viewpoint. The mentioned tickets concern details.

[kilian]

Some progress recorded in and before r6311. Model variables are no longer special (rather, models are treated almost like variable records.) The previous expression type has become abstract, so the Sindarin representation is separate from expression evaluation. Variable-objects have become simpler, and scoping rules are now transparent.

Nevertheless, Sindarin objects are still rather diverse in their internal representation.

[Juergen Reuter]

Guess this is part of the variables refactoring at the moment. WK, what is the status here ... ?

[kilian]

This issue also covers #543.

[kilian]

It's time to do some real work here ... (after 2.2.5 release).

[kilian]

Status as of r6905:

A new Sindarin engine exists, with workflow from script parsing to execution. However, it supports just a tiny subset of the language (Boolean algebra), no Whizard functionality at all.

Still a long way to go ... I'll pursue this further in parallel to bug fixes and improvements.

Here is an incomplete list of features that are not available in Sindarin 1 at present, but should be supported by Sindarin 2 eventually:

• magic characters for types ($ and ?) can be omitted (but still allowed)
• arrays/lists
• more flow-control structures and statements
• map/reduce functionality for parameter scans [cf. #410]
• custom I/O [cf. #542]
• Lorentz algebra (data types)
• user-defined functions as observables, e.g., for improved handling of subevt objects [cf. #430]
• readable diagnostics [cf. #94]

[Juergen Reuter]

This is at the moment completely blocked by too complicated code. Moving.

[kilian]

Moving back. The blocker was not caused by complicated code.

[Juergen Reuter]

Milestone renamed

[Juergen Reuter]

Milestone renamed

[Juergen Reuter]

Transferred to Gitlab issue 327.