Giters

grin-compiler / grin

GRIN is a compiler back-end for lazy and strict functional languages with whole program optimization support.

Home Page:https://grin-compiler.github.io/

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Extending the Grin syntax with primops

LightAndLight opened this issue · comments

commented

I've noticed that primitive ops are referenced using variables with special names - (_prim_int_print) and the like.

I think it would be better to have these primitives as a sum type, and extend Val with a Prim constructor.

data Val = Var Name | ... | Prim Prim
data Prim
  = Prim_print
  | Prim_add
  | ...

What do you think?

I'm also thinking about bringing other LLVM features in, like arrays or structs, which leads me to wonder: does this project plan to only support LLVM? Or do you intend to be able to target other backends? I ask because I think the answer might influence the design for primitives.

Also this isn't a feature request - I'm happy to implement my ideas if they're acceptable.

commented

Our vision is stick the project to LLVM and ideally (future work) we could expose LLVM prim types and primops in GRIN also.
From this perspective GRIN is LLVM + Sum Types.
LLVM saves us lots of work:

  • high quality instruction selection
  • GC compiler support in machine code generator
  • support for many CPU targets, including web assembly

It does everything what an optimizing compiler could do for an imperative language i.e. C++.
GRIN's job is to do the what LLVM can not understand.

The current GRIN primop set was created for the prototype. It needs some redesign to support real world language front-ends.

Regarding your suggestion, I do not think that Prim should be added to Val because those are for values in the first order language.

BTW, extending the current primop set is the very next on our TODO list. You can join at the design phase.
It would be better to discuss design ideas on examples. Could you give us some uses cases?

commented

I've found your GRIN_NOTES.

the entrypoint to the program is called 'grinMain' - can we make this configurable?

Maybe in the future, but this should not be a blocker issue for you.

Why is Program a constructor for Exp? It should be its own type. Those datatypes should mimic the abstract syntax from the paper.

The GRIN is AST is squeezed into a single Exp type to support recursion schemes naturally. This could be unusual because it's more common to have separated Program/Exp/Alt/etc. data types. But that is incompatible with the recursion-schemes library. In GRIN the AST well formedness is checked by the linter.

Variables in your language need to be fetched from

This is not true. The only constraint is that nodes can not contain node values, only pointers to node values.

If you have questions feel free to ask on gitter:
https://gitter.im/Grin-Development/Lobby

commented

I'll follow up on the gitter so we don't pollute this thread.

commented

I'm working on external definition support for GRIN.
This will allow front-end developers to introduce new primitive operations and primitive types easily.

commented

External definitions were added to GRIN, should we close this thread?