Currently, the list-node returned by an create-ast-list application uses the
given children argument list to maintain its children. In consequence, it is
possible to manipulate the children of a list node without using RACR's rewrite
API by manipulating the original argument list e.g., using set-car! or
set-cdr!. The create-ast-list function must be fixed, such that returned
list-nodes use internal data structures to maintain their children (i.e., the
given list of children must be copied).

Original issue reported on code.google.com by Christoff.Buerger on 22 Oct 2013 at 11:08

The current RACR-NET implementation has to be cleaned-up:

• Racr.cs and Test.cs have to be cleaned-up (empty lines deleted, proper indentation etc.)
• IronScheme has issues with Scheme source files ending in *.scm; it expects *.ss as file ending or *.sls for libraries. Furthermore, its good practice to compile .NET libraries to dynamic linked libraries (dll assemblies). Maybe the install-libraries.bash script can be extended to generate respective dll assemblies.
• The tests have to incorporate the most recent example refactorings, in particular regarding the Petri nets example (cf. issue #41).
• Regarding the mathexp example used for profiling the overhead of RACR-NET:
  • It contains huge generated test cases. These generated files have to be deleted from the repository.
  • The pure Scheme implementation should become a library.
  • The Scheme and C# implementations should become separate projects, each within its own directory (mathexpr and mathexpr-net respectively). Both projects should be subdirectories of profiling/racr-net-overhead.

With increasing number of supported Scheme systems, the efforts to test RACR-based applications with every system explodes, in particular to execute the examples. Common startup code is duplicated for each use case. Consider for example the current script to test RACR (run-tests.bash) and the script to execute the fUML Activity Diagram interpreter for a given diagram (examples/ttc-2015-fuml-activity-diagrams/run.bash). Both Bash scripts do similar steps to execute a Scheme program using a certain Scheme system.

The common startup steps for execution should be encapsulated in a reusable Bash script supporting all the Scheme systems RACR is tested on.

Edit

The final solution / scripts added are:

• RACR-library installation install.bash
• RACR-library execution execute.bash
• RACR-library configuration configure.bash
• supported Scheme system detection list-scheme-systems.bash
• installation testing tests/execute.bash

In the current implementation of the Petri nets example, the Petri net language
is instantiated as soon as the library is loaded. In consequence, the addition
of further attributes or AST rules is not possible, because such extensions
have to be specified before the AST rules and the attribution are compiled. To
support user specified extensions of the Petri net language, the instantiation
has to be delayed such that users can trigger it when they are sure their
extensions are properly specified. The drawback of this "user controlled
instantiation" is, that also users without extensions must instantiate the
Petri net language on their own before they can construct and use nets.

The suggested change compromises two functions, one for the compilation of the
AST rules (init-ast) and one for the compilation of the attribution
(init-attribution). Both functions expect one argument, the Petri net
specification exported by the main module. To extend the language, said
specification can be used.

Original issue reported on code.google.com by Christoff.Buerger on 25 Sep 2013 at 5:28

The C# implementation of the Questionnaires example (examples-net/questionnaires) has to be refactored regarding the following issues:

• the names of files Attributes.cs and Questionnaires.cs are missleading
  • Attributes.cs consists of widget construction and rendering attributes only; it is about the GUI and should be renamed respectively
  • Questionnaires.cs contains the actual logic implementation, i.e., AST scheme and attribution; it should be renamed to Language.cs according to the original Questionnaires implementation
• Widgets.cs is part of the GUI
• the source code should be properly formatted

To improve the error feedback for users, the (or only some?) UI library
functions should check the types of expected arguments before performing any
other action. The reason for such checks is, that errors are detected as early
as possible, such that common Scheme editors can raise a proper exception at
the place where an erroneous function call actually happened. Another reason
are possible issues with side effects taking place in functions before the type
error of an argument is detected. It would be good, if erroneous function calls
because of wrong argument types never change the state of the RACR system.
Note, that it should be possible to statically activate or deactivate argument
type checks (using for example macros). If deactivated, there should be no
runtime overhead because of argument type checks (including any overhead for
checking if argument type checks have to be performed or not!).

Original issue reported on code.google.com by Christoff.Buerger on 28 Jun 2012 at 9:05

• Merged into: #31

The own publications list in documentation/publications.md is outdated. It has to be updated with most recent publications. It should use a quotations style and properly link to a digital object identifier (doi), if available. Further, it should be referenced from the readme.md.

If a new element is inserted at the end of an AST list using rewrite-insert
the boundary check is properly passed but the insertion fails with a Scheme
runtime exception because no proper tail is defined. E.g., if l is an AST
list node without children, (rewrite-insert l 1 e), whereas e is a fitting
child, fails. Similarly, if l is an AST list node with 3 children,
(rewrite-insert l 4 e) fails. Note, that this insert scenarios are corner
cases where insertion degenerates to appending a child.

Original issue reported on code.google.com by Christoff.Buerger on 26 Oct 2014 at 3:24

Pattern specifications are missing a means to add arbitrary conditions that
must be satisfied for successful matching. Typically, such conditions will
reference nodes bound by the pattern and call their attributes, for which
reason easy access of bounded nodes should be supported. Further, conditions
may evaluate values interesting for pattern users, i.e., values that should be
added to the list of bindings returned if the pattern matches.

A possible solution for this requirements is:
(1) Conditions are functions with a single parameter, the original list of bindings (not a copy!) returned by the pattern matching machine generated for the pattern.
(2) The condition of a pattern is evaluated, if and only if the pattern matching machine code of the pattern successfully matched.
(3) If a condition is evaluated, its result determines if the pattern matches or not (if it evaluated to #f the pattern does not match, otherwise it matches).
(4) Patterns can be without any condition in which case #f instead of a condition function is given when specifying the pattern.
(5) To ease access of bounded nodes, a special syntax form, called with-bindings is provided. Given a list l of variables and an arbitrary Scheme expression, with-bindings constructs a one parameter function f. Arguments of f must be association lists representing bindings as returned by the pattern matching machine in case of successful matches. f binds each variable of l to the cdr of its respective entry within l.
(6) As before, the attribute equation code generated for a pattern (whether it has a condition or not) returns an association list representing the bindings of the pattern if it matches and #f otherwise. Because the given list of bindings is not a copy, conditions can change it, in which case the changed list is returned if the condition is satisfied. Although such side effects can be very handy in certain cases, they are not recommended in general.
(7) To ease the addition of further bindings throughout condition evaluation, with-bindings provides a special form that accepts an additional variable A. The attribute equation generated for the pattern initialises A to be a continuation that can be called within the evaluation of the body of with-bindings to abort its evaluation and consider the condition to be satisfied if, and only if, the argument of A is not #f. Further, a special additional variable called add-binding is visible within with-bindings. Each add-binding call adds another association list entry to an initially empty list l. When A is called and the condition is satisfied, all entries of l are appended to the list of bindings returned. Contrary to the side effects described in (6), the abortion of condition evaluation and addition of bindings is considered good style in general.

Original issue reported on code.google.com by Christoff.Buerger on 21 Jan 2014 at 2:45

The original Petri nets example included hierarchical nets. For didactic reasons and better modularisation, the non-hierarchical functionality was outsourced as atomic Petri nets. Conceptually, support for hierarchical nets is just an extension of the basic atomic interpreter.

The extracted atomic Petri nets interpreter is implemented according to best practices in the design of RACR-based languages; in particular query support functions are used, e.g., (->foo n) to query the foo child of n or (=att n) to query the att attribute of n etc.

The refactoring of the original Petri nets interpreter to an interpreter for hierarchical Petri nets according to these best practices and by reusing the atomic Petri nets implementation still has to be done however.

Currently the (racr core) library mixes two implementation versions: (1) a stable version used by all official examples and (2) an experimental bootstrapped version (meta-version), where RACR specifications are defined and analysed in terms of a RACR-based language -- the RACR specification language. The meta-version is kind of a metacircular RACR specification compiler.

The meta-version should be separated from the stable core, such that (racr core) is cleaned up from experimental bootstrapping code. The extracted meta-version should be named (racr-meta core).

(racr-meta core) Intention

If one queries an abstract syntax tree (AST) for its specification (lets say a Petri net of the Petri net language) it returns another abstract syntax tree representing the specification, i.e., an AST of the RACR specification language (in the example an AST encoding the specification of the Petri net language). If one queries ASTs of the RACR specification language for their specification, they return 'the mother of all specifications' -- an AST of the RACR specification language representing the RACR specification language (including its attributes for specification analyses, code generation etc). One can keep querying forever; just the very same AST is returned -- 'the mother of all specifications'.

All of that may sound inefficient, but it is not! All analyses are automatically cached, such that after evaluating the stack once, further queries are immediate cache hits. That is how the 'metacircular eternity problem' can be solved. The first 'mother of all specifications' is a manually configured cache containing the results of queries regarding the RACR specification language and thereby stops infinite further queries -- the cache hits are kind of an unproven claim that the RACR specification language is correct. This first AST is used to specify a more sophisticated version of the RACR specification language, that is from thereon used to analyse RACR specifications.

At the moment atomic Petri nets and Petri nets are listed in the examples overview. Although the atomic Petri nets entry is up to date, the Petri nets one still describes the old Petri nets implementation and therefore has to be rewritten to describe the hierarchical Petri nets example only (composed Petri nets). To do so it can refer to the atomic Petri nets entry; after all, the hierarchical Petri nets example is an extension of the atomic one.

Currently, only ASTs and attributes can be queried (e.g., their structure, node
information and values). Information regarding specifications are hidden. To
implement tooling for RACR, support language product lines or any kind of
reasoning about specifications, it must be possible to query RACR
specifications about:

• AST rules, their production and supertype
• Symbols, their type, context name, attributes and whether they are unbounded repetitions or not
• Attributes, their name, type and whether they are cached or circular.

Such meta query support must consider two pitfalls: (1) It must not invalidate
incremental attribute evaluation, i.e., if queried by means of ASTs, the
dynamic attribute dependency graph must have proper dependency edges; (2)
Information exposed to users must be either, immutable or copies, such that
changing queried results does not change the specification.

Original issue reported on code.google.com by Christoff.Buerger on 8 Feb 2013 at 5:37

The SiPLE example is not consistent with the other examples; best practices of RACR-based languages are not adapted yet, in particular the use of specialised child and attribute accessors like (->foo n) to query the foo child of n or (=bar n) to query the bar attribute of n. Refactoring to update it respectively is required.

If a list node has no parent and some new element is added or inserted, the
element is never checked if its fits, because the list node has no type
constraints. If the list is not empty however, the element must be typed w.r.t.
the RACR specification of the existing elements. Proper rewrite checks and
exceptions in case of violation must be added. E.g., the following code should
abort with a RACR exception:

(let* ((spec1 (create-specification))
       (spec2 (create-specification)))
  (with-specification
   spec1
   (ast-rule 'S->)
   (compile-ast-specifications 'S)
   (compile-ag-specifications))
  (with-specification
   spec2
   (ast-rule 'Z->)
   (compile-ast-specifications 'Z)
   (compile-ag-specifications))
  (let ((l (create-ast-list (list (create-ast spec1 'S (list))))))
    (rewrite-add l (create-ast spec2 'Z (list))))) ; Exception: List would contain ASTs constructed w.r.t. spec1 and spec2.

Original issue reported on code.google.com by Christoff.Buerger on 19 Sep 2013 at 3:55

The context-names given in AST specifications should also be permitted for
attribute specifications instead of indices only.

Original issue reported on code.google.com by Christoff.Buerger on 21 Jun 2012 at 10:45

Currently, attributes implementing patterns are always arity one functions.
Like other attributes however, also more arguments as just the node the
attribute is associated with can be supported to parameterise patterns.
Although the pattern matching machine does not support any parameterisation,
matching conditions as described in issue #27 can benefit from parameters that
tailor the condition. Using parameterised conditions, complex restrictions like
"a list has a certain number of children" or "a certain node of the pattern
equals a given node" known only at runtime by the pattern callee can be
specified.

Original issue reported on code.google.com by Christoff.Buerger on 22 Jan 2014 at 2:48

Add functions to query a RACR specification for its start symbol and an AST
rule for its symbolic representation as given when it was specified.

Assume the respective functions are named specification->start-symbol and
ast-rule->symbolic-representation; Code example for their application and
semantics:

(define racr-spec (create-specification))
(with-specification
  racr-spec
  (ast-rule 'S->A<FirstA-ter-A)
  (ast-rule 'A->)
  (compile-ast-specifications 'S)
  (compile-ag-specifications))
(assert (eq? (specification->start-symbol racr-spec) 'S))
(assert
  (eq?
   (ast-rule->symbolic-representation (specification->find-ast-rule racr-spec 'S))
   'S->A<FirstA-ter-A))

Original issue reported on code.google.com by Christoff.Buerger on 17 Jun 2013 at 11:41

Currently only attributes associated with complete ASTs (i.e., complete
derivation trees) can be evaluated. However, often attributes of AST fragments
(i.e., incomplete ASTs) are well-defined and it would be convenient, if such
attributes can be evaluated.

The issue is, that in the current implementation evaluator states are only
constructed throughout the construction of AST roots representing a derivation
w.r.t. the start symbol for which reason incomplete ASTs have no evaluator
state. Consequently, attributes of incomplete ASTs cannot be evaluated. A
solution would be to construct and distribute a new evaluator every time an AST
fragment is constructed by create-ast or create-ast-list. However, in such
a case the create-ast and create-ast-list functions must ensure, that they
are not called throughout the evaluation of an attribute associated with any of
the nodes within the trees spanned by their given child nodes.

Example for a fragment with an attribute that can be evaluated even if the
fragment is not a complete AST:

(with-specification
   (create-specification)
   (ast-rule 'S->A)
   (ast-rule 'A->)
   (compile-ast-specifications 'S)
   (ag-rule
    att
    (A 0 (lambda (n) 1)))
   (compile-ag-specifications)
   (att-value 'att (create-ast 'A (list))))</code>

Original issue reported on code.google.com by Christoff.Buerger on 10 Apr 2012 at 11:22

To ease rewriting of ASTs, RACR should provide facilities that traverse ASTs in
a well-defined manner and apply a set of rewrite rules until a normal form
w.r.t. the given rules is established.

The set of rewrite rules expected by the rewriting facilitiy to develop should
consist of transformers - functions with a single parameter which is the node
currently visited by the strategy. The rewrite strategy applies each
transformer on the currently visited node until either, one matches or all
fail. Thereby, each transformer decides, if it performs any rewrite for the
currently visited node. If it does, it performs the rewrite and returns #t,
otherwise #f. If any transformer returned #t for a node or all failed, the
rewrite strategy selects the next node to visit. If there exist no further
matches for the given transformer, the rewriting facility terminates.

Considering term rewriting, two general traversing strategies exist: (1)
outermost (leftmost redex) and (2) innermost (rightmost redex) rewriting. In
terms of ASTs, outermost rewriting prefers to rewrite the nodes closest to the
root (top-down rewriting), whereas innermost rewriting only rewrites nodes when
there does not exist any applicable rewrite within their subtree (bottom-up
rewriting). In case several topmost or bottommost rewritable nodes exist, the
leftmost is preferred in both approaches.

Original issue reported on code.google.com by Christoff.Buerger on 17 Sep 2012 at 11:21

The pattern matching API, in particular the specify-pattern function and the
with-bindings form still have to be documented in the online documentation.

Original issue reported on code.google.com by Christoff.Buerger on 21 Jan 2014 at 8:49

The file examples/ttc-2015-fuml-activity-diagrams/documentation/figures/activity-diagram->petri-net.pptx cannot be checked out in Windows when using the Git shell because of the > character.

In the current implementation, dynamic dependencies are always between
attribute instances and the AST information they depend on (e.g., other
instances). If some attribute instance queries some information throughout its
evaluation, a dependency edge from the instance to the queried information is
added, irrespective of the arguments given for evaluation. Consequentially, the
dependency graph of attribute instances queried with different arguments is an
approximation, because queried information can depend on actual attribute
arguments. To eliminate such parameter approximations, RACR's dependency
tracking has to be switched from attribute instance dependencies to attribute
cache entry dependencies.

A major advantage of a cache entry based dependency graph is, besides more
precise cache flushing, that after fixpoint computation of a circular attribute
instance not only the instance's result can be cached, but also all the other
fixpoint results.

Original issue reported on code.google.com by Christoff.Buerger on 26 Feb 2013 at 4:59

When compiling AST rules of the form 'N->N* an exception is thrown claiming the
production is not productive. But because of empty lists however, it is still
possible to construct a finite AST whose root is of type 'N, e.g.: (create-ast
'N (list (create-ast-list (list)))). Unbounded repetitions are productive by
definition. The compile-ast-specifications procedure must be fixed to support
rules like the one above.

Original issue reported on code.google.com by Christoff.Buerger on 7 Feb 2013 at 6:31

In contradiction to best practices in the design of RACR-based languages, the user-interface library instead of the actual language/analyses library defines query support functions for language analyses. In all the other examples, the language module comprises the language specification and its respective query API. This makes much more sense from a developer and user perspective.

The reason why in the Questionnaires example the user-interface library defines not only the user but also the language API is, that the loading and saving user functions are referenced when widgets are constructed throughout analyses. This has to be disentangled, such that the language module defines its API and becomes independent of the user API.

When refinement compromises terminals RACR fails with an exception: "AST node expected". When abstraction deletes terminals RACR returns the deleted terminal nodes instead of their value (this is a security issue; users should never see terminal nodes).

Currently, insertion or deletion of list elements flushes the caches of all
attributes associated with nodes within the subtrees the elements following the
insertion or deletion position span. Additionally, the caches of all attributes
depending on a node within the subtree, are flushed.

A much better, but still correct, approximation is to decide for each node
within the subtree, if an attribute "A-out" associated with a node outside the
subtree depends on it. If, and only if, that is the case, "A-out" must be
flushed. Explicit flushing of the attributes within subtrees is NOT required.

Original issue reported on code.google.com by Christoff.Buerger on 31 Mar 2012 at 12:48

GNU Guile fails some of the rewrite and Petri net tests (rewrite-basics, rewrite-lists, rewrite-refine-abstract, purchase-processing, runtime-structure-example-slide).

Further investigation for the reasons and fixes, if it is not an implementation error of GNU Guile, are required.

Note: Other R6RS Scheme systems pass these tests; most likely GNU Guile is bugged.

The documentation is broken, because Google Code wiki pages are not properly translated to GitHub Markdown. The most important problems are:

1. Links are broken
2. Figures are not properly referenced / figure sources are missing in the repository
3. Source code listings are not properly intended

Currently all errors because of invalid specifications or runtime issues are
constructed within the respective code detecting the error. In consequence,
error construction is scattered across the code. There are no means to ensure
common error message headers or specialised error types. However, for the
quality of error messages, especially consistency, it would be good to
introduce specialised assertion violation types representing common classes of
errors. To raise actual exceptions, specialised internal framework functions
could be used.

Original issue reported on code.google.com by Christoff.Buerger on 28 Jun 2012 at 8:37

The specification querying API introduced by fixing issue #17 and issue #19 still
has to be documented in the online documentation.

Original issue reported on code.google.com by Christoff.Buerger on 18 Jun 2013 at 12:22

Currently, ast-child and ast-sibling select nodes by integer indices. It would
be much more convenient to specify within AST rules names for children, such
that a selection by name becomes possible.

Original issue reported on code.google.com by Christoff.Buerger on 31 Mar 2012 at 12:54

Add ast-specification function to query ASTs for their RACR specification,
i.e., to query AST nodes for the specification used to construct, attribute, evaluate
and rewrite them. Given an AST node n, (ast-specification n) should return
the RACR specification of the AST n is part of. E.g.,

(let ((spec (create-specification)))
  (with-specification
   spec
   (ast-rule 'S->)
   (compile-ast-specifications 'S)
   (compile-ag-specifications)
   (assert
    (eq?
     (ast-specification (create-ast 'S (list)))
     spec))))

This enhancement extends issue #17.

Original issue reported on code.google.com by Christoff.Buerger on 19 Sep 2013 at 3:13

Root nodes are freely available - they can be used as replacement/addition in
rewrite-subtree, rewrite-insert and rewrite-add. One special case not
correctly handled yet is the insertion of a root within its own subtree. To
insert a root within its own subtree is an error since the resulting graph
contains a cycle, i.e., it is no tree and therefore no valid AST. For this
reason, such erroneous rewrites currently result in infinite loops because the
distribution of the "new" evaluator state expects a tree to traverse in
depth-first order and does not terminate for a cyclic graph.

Error checks for the insertion of roots within their subtree and respective
exceptions have to be implemented.

Error examples:

(with-specification
 (create-specification)
 (ast-rule 'S->A)
 (ast-rule 'A->)
 (ast-rule 'Aa:A->A)
 (ast-rule 'Ab:A->A*)
 (compile-ast-specifications 'S)
 (compile-ag-specifications)

 (let ((A
        (create-ast
         'Aa
         (list
          (create-ast 'A (list))))))
   (rewrite-subtree (ast-child 'A A) A)) ; Should abort with error; instead infinite loop!

 (let ((A
        (create-ast
         'Aa
         (list
          (create-ast
           'Ab
           (list
            (create-ast-list (list))))))))
   (rewrite-add (ast-child 'A* (ast-child 'A A)) A)) ; Should abort with error; instead infinite loop!

 (let ((A
        (create-ast
         'Aa
         (list
          (create-ast
           'Ab
           (list
            (create-ast-list (list))))))))
   (rewrite-insert (ast-child 'A* (ast-child 'A A)) 1 A))) ; Should abort with error; instead infinite loop!

Original issue reported on code.google.com by Christoff.Buerger on 13 Sep 2012 at 12:27

The current SiPLE implementation does not check for unique parameter names. The
interpretation of the following procedure declaration must abort with an
exception however:

Procedure test(Var i:Integer, Var i:Integer) Begin End;

Proper tests for unique parameter names must be added to the local-correct?
attribute of ProcedureDeclaration.

Original issue reported on code.google.com by Christoff.Buerger on 23 Oct 2013 at 11:11

The parser of the SiPLE example is rather old; better best practices for manual parser implementation have been applied for example for the binary-numbers, internal RACR AST specification and ttc-2015-fuml-activity-diagrams parsers. SiPLE's parser has to be refactored accordingly.

This task may require to make all these parsers more consistent in terms of a general parser combinator library or at least common parsing support functions.

Beside subtree and terminal value replacement and list element insertion,
addition and deletion, the refinement and abstraction of nodes are important
rewrite actions. Refinement means to change the type of a node N1 of a certain
type T1 to a subtype T2 of T1 whereby additional context children of T2 are
added. Abstraction is the opposite process, i.e., to change the type of a node
to a supertype and delete superfluous children and the trees they span. Of
course, in both cases the type change must be permitted considering the given
types, additional children and context.

Although refinement and abstraction can be achieved using subtree replacement,
a special rewrite function would be much more convenient. Further, the
computation of directly influenced attributes and therefore incremental
evaluation can benefit, because (1) in case of refinement it is known that non
of the original children is changed and how many additional children are added
and (2) in case of abstraction the deleted children are well-defined.

Original issue reported on code.google.com by Christoff.Buerger on 23 Aug 2012 at 2:36

The sle-2015 introduction example has to be refactored according to best practices in the design of RACR-based languages, for example to use :NonTerminalType for AST node instantiation and =attribute-name to query attributes. Similar refactorings like for issue #41 are required.

A summary of the fUML Activity Diagrams example in the examples overview is missing. The summary should refer to the 8th Transformation Tool Contest and its model execution case and the submitted RACR solution description.

Instead of child indices only, also the context-names given in AST
specifications should be supported by the rewrite API.

Original issue reported on code.google.com by Christoff.Buerger on 23 Aug 2012 at 2:47

The style of figures and presentations of the documentation should be consistent.

Each RACR artefact (example, core library etc.) can have a documentation. If so, the documentation is in a documentation subdirectory of the respective artefact. Figures and their sources are in a figures subdirectory of the respective documentation directory. For each figure, its source, i.e., the document it is generated from, must be provided. Manuals, and any other text documentation in general, must be provided as Markdown documents. Figures and presentations have to be made in Microsoft Power Point.

The Markdown style rules are as follows:

• Every manual has a title page, stating its authors and editors and their e-mail address. It further has a contents page.
• Each chapter is one Markdown document (web page).
• Each page has a header with links to the manual's title and contents and an optional synopsis (abstract of the document) and/or index.

The PowerPoint style rules of figures and presentations are as follows:

• The PowerPoint format to use is .pptx, compatible with PowerPoint 97-2011. The reference is PowerPoint:mac 2011. The only permitted not-downward compatible features of the 2011 edition are shadows. The compatibility messages regarding shadows are:
  • Transparency might be degraded
  • Shadows might look different in other versions of Office
• The theme master to use is the default master of the PowerPoint:mac 2011 edition, i.e., white:
  • The font is Calibri.
  • Figures should use Calibri (Body); other fonts should be used only in exceptional cases.

LaTeX documentation is only permitted for publishing reasons, i.e., for peer-reviewed publications regarding RACR in open-access journals. The respective .pdf files of such publications have to be within the documentation directory of the respective RACR artefact they are a publication of.

Many sanity checks ar performed at runtime. Examples are:

• When constructing ASTs the respective specification must be compiled
• When compiling a specification, its consistency is checked
• When querying AST information, the respective information must exists (querying the parent of a root throws an exception, likewise querying a bud-node for its type etc.)
• When rewriting, its is ensured that rewrites satisfy the AST scheme

Many of these actions are accompanied by respective internal state changes of
the specification, AST, dependency graphs, evaluator etc. If internal state
changes are intertwined with sanity checks that throw exceptions, the system
can end in an inconsistent state. It is desirable however, that RACR exceptions
are continuable, such that users have a chance to fix their request and try
again. In consequence, sanity checks should be performed before any state
change, such that respective exceptions are thrown before atomic state changes
are preformed.

The objective of this issue is to refactor all state changing functions such
that they become continuable in case of errors thrown by RACR sanity checks.
Note, that ordinary Scheme exceptions are not subject of this issue; Only RACR
exceptions as introduced by issue #8.

This issue replaces issue #9.

Original issue reported on code.google.com by Christoff.Buerger on 13 Mar 2015 at 1:43

Documentation for the C# integration is missing. This includes:

• documentation of the integration approach
• respective entries in the requirements and installation documentation
• addition in the features list

In the current implementation, the search for further fused places is only
performed if the current place is an in-port fused with an out-port, in which
case the search is proceeded at the fused out-port. Place fusion however, is
not directed, although the terms in- and out-port suggest so. I.e., it should
also be possible, that an out-port consumes tokens from an in-port it is fused
with. E.g., consider the following nets:

(make-petrinet net1 () (out1)
  ...)

(make-petrinet net2 (in2) ()
  ...)

If net1 and net2 are composed, such that out1 is glued with in2, the
current implementation only permits that the arcs of the transitions of net2
that consume tokens from in2 also can consume tokens from out1. The other
way around, that the arcs of the transitions of net1 that consume tokens from
out1 also consume tokens from in1 is not permitted, which must be fixed.

Original issue reported on code.google.com by Christoff.Buerger on 25 Aug 2013 at 2:02

To provide facilities for the construction of incomplete ASTs, which have
"holes" within their subtrees that denote places where appropriate replacements
still have to be provided is useful for two reasons: (1) when constructing ASTs
but required parts are not yet known and (2) for the deconstruction of existing
ASTs, where parts are removed such that they can be used for insertion into
other trees. The later use-case can be generalised as the reuse of AST
fragments within rewrites. The idea thereby is, to use rewrite-subtree to
insert "holes" into ASTs and extract the parts that are replaced by such
"holes".

To mark places within ASTs that represent "holes", special non-terminals have
to be provided -- a good term for such non-terminals is bud node. Special
facilities for the construction of bud nodes are required, existing AST node
construction facilities and rewrite facilities that insert or replace AST parts
have to be extended to accept bud nodes and AST information access functions
have to incorporate bud node handling. In particular the latter requires to
insert checks, that bud nodes are not queried for their type and an additional
function to test whether a node is a bud node or not.

Original issue reported on code.google.com by Christoff.Buerger on 18 Sep 2012 at 3:56

Currently it is not possible to construct list-nodes for which reason the
applicability of the rewrite-node function is hindered. A create-ast-list
function, which given a RACR specification and list L constructs a list-node
with the elements of L as children is required.

To keep the user API consistent, the create-ast function should in case of
unbounded child cardinality (Kleene closure) not expect a Scheme list, but a
list-node instead.

Original issue reported on code.google.com by Christoff.Buerger on 10 Apr 2012 at 11:32

IronScheme (version 115672, 20th November 2015) fails the following test cases of RACR's test suite:

• tests/ast-construction.scm
• tests/patterns.scm
• examples/state-machines/state-machines.scm
• composed-petrinets/examples/purchase-processing.scm
• composed-petrinets/examples/runtime-structure-example-slide.scm
• composed-petrinets/examples/syntax-tests.scm

tests/ast-construction.scm, tests/patterns.scm and composed-petrinets/examples/purchase-processing.scm:

Unhandled CLR exception during evaluation:
()

examples/state-machines/state-machines.scm:

Unhandled CLR exception during evaluation:
CLR Exception: System.InvalidProgramException
System.InvalidProgramException: Invalid IL code in eval-core(013):::run-tests (): IL_0052: call      0x0a00000a


  at eval-core(013).$77 () <0x3979a08 + 0x0068b> in <filename unknown>:0 
  at IronScheme.Scripting.ScriptCode.Run (IronScheme.Scripting.CodeContext codeContext, Boolean tryEvaluate) <0x38b5e58 + 0x000c6> in <filename unknown>:0 
  at IronScheme.Scripting.ScriptCode.Run (IronScheme.Scripting.ScriptModule module) <0x38b5db0 + 0x0008b> in <filename unknown>:0 
  at IronScheme.Runtime.Builtins+<>c__DisplayClass11.<CompileCore>b__b () <0x38b5d78 + 0x0002f> in <filename unknown>:0 
  at IronScheme.Runtime.Closure+SimpleClosure.Call () <0x388b848 + 0x0002c> in <filename unknown>:0 
  at #.psyntax.expander::compile-r6rs-top-level#anon#1#2$2586 (IronScheme.Scripting.CodeContext $context) <0x3950b00 + 0x0008b> in <filename unknown>:0 
  at IronScheme.Runtime.Closure+SimpleClosure.Call () <0x388b848 + 0x0002c> in <filename unknown>:0 
  at #.psyntax.main::load-r6rs-top-level#1#anon#1#2#3#4#5#6$2628 (IronScheme.Scripting.CodeContext $context) <0x39007a0 + 0x00057> in <filename unknown>:0 
  at IronScheme.Runtime.Closure+SimpleClosure.Call () <0x388b848 + 0x0002c> in <filename unknown>:0 
  at #.ironscheme.exceptions::dynamic-wind (System.Object in, System.Object proc, System.Object out) <0x3892f28 + 0x0017b> in <filename unknown>:0 
  at IronScheme.Runtime.Closure+SimpleClosure.Call () <0x388b848 + 0x0002c> in <filename unknown>:0 
  at #.ironscheme.exceptions::dynamic-wind (System.Object in, System.Object proc, System.Object out) <0x3892f28 + 0x0017b> in <filename unknown>:0 
  at IronScheme.Runtime.Closure+SimpleClosure.Call (System.Object[] args) <0x3838b20 + 0x001ec> in <filename unknown>:0 
  at IronScheme.Runtime.Closure+VarArgClosure.Call (System.Object[] args) <0x3838938 + 0x0018e> in <filename unknown>:0 
  at #.psyntax.main::load#1$2602 (IronScheme.Scripting.CodeContext $context) <0x38fdc80 + 0x000f0> in <filename unknown>:0 
  at IronScheme.Runtime.Closure+SimpleClosure.Call () <0x388b848 + 0x0002c> in <filename unknown>:0 
  at #.ironscheme.exceptions::with-exception-handlers#1#anon#1$1779 (IronScheme.Scripting.CodeContext $context) <0x38fdc18 + 0x0004b> in <filename unknown>:0 
  at IronScheme.Runtime.Closure+SimpleClosure.Call () <0x388b848 + 0x0002c> in <filename unknown>:0 
  at #.ironscheme.exceptions::dynamic-wind (System.Object in, System.Object proc, System.Object out) <0x3892f28 + 0x0017b> in <filename unknown>:0 
  at IronScheme.Runtime.Closure+SimpleClosure.Call (System.Object arg1) <0x3857478 + 0x00036> in <filename unknown>:0 
  at IronScheme.Runtime.Builtins.CallWithCurrentContinuation (System.Object fc1) <0x38fd230 + 0x00106> in <filename unknown>:0 
  at IronScheme.Runtime.Closure+SimpleClosure.Call () <0x388b848 + 0x0002c> in <filename unknown>:0 
  at IronScheme.Runtime.R6RS.Exceptions.WithClrExceptionHandler (System.Object handler, System.Object thunk) <0x38fd0e8 + 0x00049> in <filename unknown>:0 

composed-petrinets/examples/runtime-structure-example-slide.scm:

Stack overflow in unmanaged: IP: 0x272969, fault addr: 0xb02a2fec
Stack overflow in unmanaged: IP: 0x95f7b8c7, fault addr: 0xb02a1ffc
Stack overflow in unmanaged: IP: 0xb47dc, fault addr: 0xb02a098c
Stack overflow in unmanaged: IP: 0x95f78a41, fault addr: 0xb02a2fdc
Stack overflow in unmanaged: IP: 0x95f798e1, fault addr: 0xb02a1ffc
Stack overflow in unmanaged: IP: 0x95f798c6, fault addr: 0xb02a2ffc
Stack overflow in unmanaged: IP: 0x214e34, fault addr: 0xb02a2fec
Stack overflow in unmanaged: IP: 0x1b6c7c, fault addr: 0xb02a1fbc
Stack overflow in unmanaged: IP: 0x95f7b8c7, fault addr: 0xb02a2fec
Stack overflow in unmanaged: IP: 0x1c6a3c, fault addr: 0xb02a2d50
Stack overflow in unmanaged: IP: 0x14685c, fault addr: 0xb02a1dfc
Unhandled CLR exception reading input:
CLR Exception: System.NullReferenceException
System.NullReferenceException: Object reference not set to an instance of an object
  at #.psyntax.main::with-guard#1$2592 (IronScheme.Scripting.CodeContext $context, System.Object e) <0x3a7d448 + 0x0005f> in <filename unknown>:0 
  at IronScheme.Runtime.Closure+SimpleClosure.Call (System.Object arg1) <0x3877478 + 0x00036> in <filename unknown>:0 
  at IronScheme.Runtime.R6RS.Exceptions.WithClrExceptionHandler (System.Object handler, System.Object thunk) <0x391d0e8 + 0x00077> in <filename
 unknown>:0 
  at #.psyntax.main::with-guard (System.Object f) <0x391cee0 + 0x001cf> in <filename unknown>:0 
  at IronScheme.Scripting.ScriptCode.Run (IronScheme.Scripting.CodeContext codeContext, Boolean tryEvaluate) <0x38d5e58 + 0x000c6> in <filename
 unknown>:0 
  at IronScheme.Scripting.ScriptCode.Run (IronScheme.Scripting.ScriptModule module) <0x38d5db0 + 0x0008b> in <filename unknown>:0 
  at IronScheme.Runtime.Builtins+<>c__DisplayClass11.<CompileCore>b__b () <0x38d5d78 + 0x0002f> in <filename unknown>:0 
  at IronScheme.Runtime.Closure+SimpleClosure.Call () <0x38ab848 + 0x0002c> in <filename unknown>:0 
  at #.psyntax.expander::eval (System.Object x, System.Object env) <0x3883100 + 0x000f7> in <filename unknown>:0 
  at IronScheme.Scripting.ScriptCode.Run (IronScheme.Scripting.CodeContext codeContext, Boolean tryEvaluate) <0x38d5e58 + 0x000fa> in <filename
 unknown>:0 
  at IronScheme.Scripting.ScriptCode.Run (IronScheme.Scripting.ScriptModule module) <0x38d5db0 + 0x0008b> in <filename unknown>:0 
  at IronScheme.Scripting.Hosting.CompiledCode.Evaluate (IScriptModule module) <0x39139d0 + 0x0005b> in <filename unknown>:0 
  at IronScheme.Scripting.Hosting.CompiledCode.Execute (IScriptModule module) <0x39139a8 + 0x00017> in <filename unknown>:0 
  at IronScheme.Scripting.Hosting.ScriptEngine.ExecuteSourceUnit (IronScheme.Scripting.Hosting.SourceUnit sourceUnit, IScriptModule module) <0x38dbfd0
 + 0x00033> in <filename unknown>:0 
  at IronScheme.Scripting.Hosting.ScriptEngine.Execute (System.String code, IScriptModule module) <0x38dbf90 + 0x0002f> in <filename unknown>:0 
  at IronScheme.Scripting.Hosting.ScriptEngine.Execute (System.String code) <0x391cb00 + 0x0001f> in <filename unknown>:0 
  at IronScheme.Hosting.IronSchemeLanguageProvider+CommandLineX+<>c__DisplayClass4.<RunFile>b__2 () <0x391c940 + 0x00065> in <filename unknown>:0

composed-petrinets/examples/syntax-tests.scm:

tack overflow in unmanaged: IP: 0x13ea44, fault addr: 0xb02a2ffc
Stack overflow in unmanaged: IP: 0x95f7b8c3, fault addr: 0xb02a1ffc
Stack overflow in unmanaged: IP: 0x2c7dc, fault addr: 0xb02a096c
Stack overflow in unmanaged: IP: 0x91e84cfd, fault addr: 0xb02a2ffc
Stack overflow in unmanaged: IP: 0x95f78a41, fault addr: 0xb02a1ffc
Stack overflow in unmanaged: IP: 0x95f78a41, fault addr: 0xb02a2fec
Stack overflow in unmanaged: IP: 0x18ce2c, fault addr: 0xb02a2ff0
Stack overflow in unmanaged: IP: 0x12ec7c, fault addr: 0xb02a1f9c
Stack overflow in unmanaged: IP: 0x95f7c16d, fault addr: 0xb02a2ffc
Stack overflow in unmanaged: IP: 0x95f79c6c, fault addr: 0xb02a2ffc
Stack overflow in unmanaged: IP: 0xbe85c, fault addr: 0xb02a1ddc
Stack overflow in unmanaged: IP: 0x13ea3c, fault addr: 0xb02a1fb0
Unhandled CLR exception reading input:
CLR Exception: System.NullReferenceException
System.NullReferenceException: Object reference not set to an instance of an object
  at #.psyntax.main::with-guard#1$2592 (IronScheme.Scripting.CodeContext $context, System.Object e) <0x3b32670 + 0x0005f> in <filename unknown>:0 
  at IronScheme.Runtime.Closure+SimpleClosure.Call (System.Object arg1) <0x380b478 + 0x00036> in <filename unknown>:0 
  at IronScheme.Runtime.R6RS.Exceptions.WithClrExceptionHandler (System.Object handler, System.Object thunk) <0x38b10e8 + 0x00077> in <filename
 unknown>:0 
  at #.psyntax.main::with-guard (System.Object f) <0x38b0ee0 + 0x001cf> in <filename unknown>:0 
  at IronScheme.Scripting.ScriptCode.Run (IronScheme.Scripting.CodeContext codeContext, Boolean tryEvaluate) <0x3869e58 + 0x000c6> in <filename
 unknown>:0 
  at IronScheme.Scripting.ScriptCode.Run (IronScheme.Scripting.ScriptModule module) <0x3869db0 + 0x0008b> in <filename unknown>:0 
  at IronScheme.Runtime.Builtins+<>c__DisplayClass11.<CompileCore>b__b () <0x3869d78 + 0x0002f> in <filename unknown>:0 
  at IronScheme.Runtime.Closure+SimpleClosure.Call () <0x383f848 + 0x0002c> in <filename unknown>:0 
  at #.psyntax.expander::eval (System.Object x, System.Object env) <0x3817100 + 0x000f7> in <filename unknown>:0 
  at IronScheme.Scripting.ScriptCode.Run (IronScheme.Scripting.CodeContext codeContext, Boolean tryEvaluate) <0x3869e58 + 0x000fa> in <filename
 unknown>:0 
  at IronScheme.Scripting.ScriptCode.Run (IronScheme.Scripting.ScriptModule module) <0x3869db0 + 0x0008b> in <filename unknown>:0 
  at IronScheme.Scripting.Hosting.CompiledCode.Evaluate (IScriptModule module) <0x38a79d0 + 0x0005b> in <filename unknown>:0 
  at IronScheme.Scripting.Hosting.CompiledCode.Execute (IScriptModule module) <0x38a79a8 + 0x00017> in <filename unknown>:0 
  at IronScheme.Scripting.Hosting.ScriptEngine.ExecuteSourceUnit (IronScheme.Scripting.Hosting.SourceUnit sourceUnit, IScriptModule module) <0x386ffc0
 + 0x00033> in <filename unknown>:0 
  at IronScheme.Scripting.Hosting.ScriptEngine.Execute (System.String code, IScriptModule module) <0x386ff80 + 0x0002f> in <filename unknown>:0 
  at IronScheme.Scripting.Hosting.ScriptEngine.Execute (System.String code) <0x38b0b00 + 0x0001f> in <filename unknown>:0 
  at IronScheme.Hosting.IronSchemeLanguageProvider+CommandLineX+<>c__DisplayClass4.<RunFile>b__2 () <0x38b0940 + 0x00065> in <filename unknown>:0