Syntactical extensions for GRIN about grin

[andorp]

named case scrutinees
named node fields
name function arguments
named store argument

Please could you give examples how they are now and what will be the intended result?
We have named function arguments, probably you meant at the call side.

[andorp]

data FName
  = F { fName :: Name }
  | E { fname :: Name }

How FName will fit to the current analyses? Currently we have unified Names everywhere. When projecting back to source code, type env, chould this introduce difficulties?

[andorp]

Last return

Lets use the pure as it is already established in the syntax, as also doesn't give the
false sense of return point of a function.

[andorp]

Program, function, definition
The above mentioned notions should be different syntactic constructs.

This design decision was taken to be compatible with the recursion schemes library, which already
had the tradeoff. Combining base functors would leave the intermix of the different levels.
Using GADTs and indexed recursion schemes would mean reimplementing the recursion-schemes library supporting indexes.

I was considering introduce a type safe layer which would use a GADT to construct only meaningful programs, but I rejected the idea out of pure laziness (pun intended). Maybe it is a good idea to have that layer for the future frontends, forcing them (another pun intended) to create a correct syntax. But for us GRIN contributors I think it is overkill to create such a type-safety when implementing transformations, analyses, at least for now, as we plan to refactor the IR. If we want to do such a type safe internal representation, I would suggest to implement it when we plan to do the first official release.

[Anabra]

named case scrutinees
named node fields
name function arguments
named store argument

Please could you give examples how they are now and what will be the intended result?
We have named function arguments, probably you meant at the call side.

The arguments to the respective data constructors would require Names instead of values. Just like update and fetch do.

[Anabra]

data FName
  = F { fName :: Name }
  | E { fname :: Name }

How FName will fit to the current analyses? Currently we have unified Names everywhere. When projecting back to source code, type env, chould this introduce difficulties?

FName would only be present in the application node, nowhere else. This way, if the analysis/transformation does not want to differentiate normal functio apps from external apps, they could just pattern patch on App and get the stored name via the getter. If someone do want to differentiate them, they will be able to pattern patch on the respective FName data ctors.

During pretty printing, I don't think it would introduce any difficulties. These are just wrappers.

[Anabra]

Last return

Lets use the pure as it is already established in the syntax, as also doesn't give the
false sense of return point of a function.

Alright.

[Anabra]

Program, function, definition
The above mentioned notions should be different syntactic constructs.

This design decision was taken to be compatible with the recursion schemes library, which already
had the tradeoff. Combining base functors would leave the intermix of the different levels.
Using GADTs and indexed recursion schemes would mean reimplementing the recursion-schemes library supporting indexes.

I was considering introduce a type safe layer which would use a GADT to construct only meaningful programs, but I rejected the idea out of pure laziness (pun intended). Maybe it is a good idea to have that layer for the future frontends, forcing them (another pun intended) to create a correct syntax. But for us GRIN contributors I think it is overkill to create such a type-safety when implementing transformations, analyses, at least for now, as we plan to refactor the IR. If we want to do such a type safe internal representation, I would suggest to implement it when we plan to do the first official release.

Makes sense. I did not consider this.

[andorp]

Naming:
I see, basically you suggest to introduce constants using the pure construction. v <- pure 1 .

[andorp]

Please could you update the description of the proposal?

[Anabra]

Exactly. Constants could only be introduced in the above form. Everywhere else, we would be just passing variables around.

[Anabra]

The separation of external and ordinary function application has been scrapped.

The reason being is that it makes writing code for function application cumbersome. Whenever we need the fact that the function is an external, we will usually have to look it up from the external mapping anyway. This lookup will determine whether the function is an external or not. This means, that the pattern match on the type of the function application is redundant.

[Anabra]

Extended the proposal with the removal of low-level GRIN construct.

VarTag node and indexed Fetch will be removed. These constructs were originally needed for RISC code generation. Since then, GRIN transitioned to LLVM, and over the years these constructs proved to be unnecessary.

[andorp]

As part of the ICFP tutorial there is a GADT, which helps to create syntactically expected GRIN programs. The rule indexed expressions show what can be combined how.

This approach will live in the Syntax.GADT module. This change can be found in the #44 PR.

[Anabra]

I added a brief description for the GADT-style AST, and the new datalog based model for the AST. The DL model will need named case alternatives.

[Anabra]

Added a detailed explanation for named case alternatives.

[andorp]

Looking at the code from the latest PR, we realized that it is confusing to have two different forms for the @as pattern

case v of
  (CNil)       @ v1 -> <code>
  (CCons x xs) @ v2 -> <code>

v@(CInt k) <- pure nis 
<both v and k can be referenced here>

This should be:

case v of
  (CNil)       @ v1 -> <code>
  (CCons x xs) @ v2 -> <code>

(CInt k)@v <- pure nis 
<both v and k can be referenced here>

[andorp]

In the long run, we should remove the double variable @as pattern construction.

var1@var2 <- lhs

This should be only

var1 <- lhs

[Anabra]

I wrote a few lines about these in the as-pattern section.