awf / coconut Goto Github PK

F~ is a subset of F# with several constraints.
Many transformation phases (specially the one for inferring cardinality and translating into DPS representation) are based on the assumption that the given program is in this subset.
It would be great to have a phase which checks these constraints.

Currently, in order to define that a higher-order rule should NOT have a variable in the context, we just do not mention it in the context. For example, the DCE rules is specified as follows

<@ let x = %E1 in %E2 <==> %E2 @>

This is in essence very similar to the HOL theorem prover. However, it is a bit confusing for the people without enough prerequisite on using them. It would be great to come up with a more understandable syntax for such rewrite rules.
Furthermore, for the moment the rewrite engine will substitute all the occurrences in the case of higher-order rules, which is not what we want. For example, the let inlining rule which is specified as follows:

<@ let x = %E1 in (%B) x <==> (%B) %E1 @>

will substitute all occurrences of the variable x bound to a particular expression e in a particular context with e, which is not we want in many cases. It would be great to change the semantic of the higher-order matcher to only substitute x in one particular place with e. And then the previous rule should be changed to the following rule:

<@ let x = %E1 in (%B) x <==> let x = %E1 in (%B) %E1 @>

The previous rule (which inlines the whole thing completely) will be achieved by applying the former rule many times followed by a DCE rule to get rid of the unnecessary let binding.

Although there is almost no problem with supporting recursion in F~ (definitely there will be less guarantees), supporting mutual recursion could be a little bit more complicated.

For example, the code motion rule cannot be expressed in the current rewrite engine.
This is because there is no way to express a rule that will match a Call expression term in F# quotation.

Coconut's documentation for the data keyword states that it lets you create immutable ADTs. I see beautifully concise immutable product types, but not an algebra. My (inexpert) understanding of the term "algebra" is that it implies both addition and multiplication, and that for types "multiplication" is the conjunction (and) operator, while "addition" is the disjunction (or) operator. (That interpretation seemed very weird to me until I noticed its implications for the size of the sets in question: If type A has 5 members and type B has 6, then their sum has 11 members, while their product has 30.)

The data keyword lets us multiply two types. For instance, we can multiply the int type with the string type by making a type T that has two fields, one of them an int and the other a string. In every instance of T both fields are mandatory.

If we could add the types int and string, it would mean we could create a new type T for which every instance could include either a string or an int, without including the other.

Right?

Currently, the rewrite engine accepts rewrite rules in the form of quotation expressions, and converts them to partial functions.
This can be improved a lot in many directions. For example, the higher-order matcher will find the failure of the matches very late.
There are many ideas of improving the performance of the matcher of expressions. This is somehow related to #5.

Supporting product and sum types is really important for expressing many programs.
Handling them efficiently in the generated C code seems to be challenging.

Add rules to compute derivatives of expressions, which will also provide many more optimization opportunities.

Currently, the whole system is using F# quotation as the underlying data structure for performing transformations. This has some overheads (such as always type checking the code, which could be useful as a verification tool, but causes overhead), which can be removed by using an alternative data structure for terms.