Feature/typed core draft #203
Conversation
…again, or use the DB
|
I think this PR is now ready for review. A review should mostly focus on the design (also wrt to how we can also port lifted at some point). Symbols should be treated as opaque starting from core (in the future). Some backends still use symbol information instead of looking up the information in the declarations section of the core module. |
|
@marzipankaiser I added you as a reviewer since you are most affected by it, since you want to implement type-boxing/unboxing based on typed core. |
|
@fritzladwig this PR could also really help you, since the new representation might be easier to test. We could easily write a parser for this core representation. The parsed trees then could be used in your tests for optimization. |
| case Record(id: Symbol, fields: List[Symbol]) | ||
| case Interface(id: Symbol, operations: List[Symbol]) | ||
| case Data(id: Id, tparams: List[Id], constructors: List[Constructor]) | ||
| case Record(id: Id, tparams: List[Id], constructor: Constructor) |
There was a problem hiding this comment.
Consider absorbing Record into Data (and likewise on the object language type level). Keep Select (it happens to work on all data types with a single constructor).
There was a problem hiding this comment.
I agree, let's do this. However, we should do this after this PR since we also need to push this change through lifted and I don't want to touch lifted too much in this PR.
|
Thanks @phischu for the comments. We should address them in a separate PR |
This is very much WIP. Baby steps towards a typed version of core.
TODO
cargsagain (since they are always bargs_i.capt).