Comments (19)
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.
from grin.
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?
from grin.
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.
from grin.
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.
from grin.
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 Name
s instead of values. Just like update
and fetch
do.
from grin.
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.
from grin.
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.
from grin.
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.
from grin.
Naming:
I see, basically you suggest to introduce constants using the pure
construction. v <- pure 1
.
from grin.
Please could you update the description of the proposal?
from grin.
Exactly. Constants could only be introduced in the above form. Everywhere else, we would be just passing variables around.
from grin.
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.
from grin.
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.
from grin.
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.
from grin.
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.
from grin.
Added a detailed explanation for named case alternatives.
from grin.
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>
from grin.
In the long run, we should remove the double variable @as pattern construction.
var1@var2 <- lhs
This should be only
var1 <- lhs
from grin.
I wrote a few lines about these in the as-pattern section.
from grin.
Related Issues (20)
- Clang dependency for tests HOT 2
- How to cite paper HOT 3
- Lambda/GrinCodeGenBoxed.hs does not exist
- SimpleDeadParameterElimination causes "undefined variable" errors
- Question: does GRIN requires a runtime? HOT 1
- What LLVM versions are supported by the codegen? HOT 1
- InlineApply causes non-defined function when self recursive HOT 1
- Confused about non-covered alternatives and RunPure HOT 3
- Foreign pointer primitive type HOT 5
- Binary download?
- Windows support?
- Fix E2E tests for OSX HOT 1
- Clean FFI and primitive operations. This should be modular and specific to frontends.
- Modular PrimOps HOT 4
- Specification of the undefined value semantics
- SparseCaseOptimisation removes useful alternatives HOT 8
- Stop pipeline on errors and add --continue-on-lint option for the current behavior. HOT 3
- Counting Immutable Beans HOT 6
- Improve case hoisting
- Fix data dependencies in pipeline
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from grin.