lang: add type aliases - Githubissues

nim-works / phy

compiler and vm experiments

MIT License

3 stars 2 forks source link

lang: add type aliases #44

Closed zerbina closed 1 month ago

zerbina commented 1 month ago

Summary

Add the TypeDecl declaration to the source language, for introducing type aliases.

Details

implement the TypeDecl declaration and identifiers in type expressions
add the Entity type and adjust lookup to be able handle different kinds of entities (instead of just procedures)
- instead of a case object, the separate entity kinds use separate types and separate sequences
- this allows for faster and easier access and a more terse memory layout
change declToIL to not return anything. Querying the return type of procedure has to be done separately now
adjust the tester and REPL to the declToIL change
fix source2il crashing for erroneous type expressions in return type positions

Notes For Reviewers

the Entity-related changes are also a prerequisite for local variables and parameters

zerbina commented 1 month ago

An observation regarding the tests: the number prefix naming system for language tests doesn't seem like it'll work out. Grouping by feature seems better, and the dependencies are also not clear (e.g., what language feature does/can a t06_x test actually rely on?).

Of course, it could also be that I'm just holding it wrong and that a feature-centric language testing would actually be worse -- I'm not fully sure.

saem commented 1 month ago

Of course, it could also be that I'm just holding it wrong and that a feature-centric language testing would actually be worse -- I'm not fully sure.

Sorry, having trouble parsing "holding it wrong", could you clarify? I'm right now taking it to mean "not thinking about it correctly".

I too am struggling a bit with the numbering scheme. I think the numbers make a bit of sense to suggest feature x, likely depends upon the stuff that came before it, but that's still pretty subtle. I kinda think numbering to define "functionality layers", as in big broad cross cutting features that change the stuff that came before, makes sense, but within those layers per feature is likely better. I'm reminded a bit of the diagram for Cake Lang, I can see a language with and without closures, generics, macros, etc... requiring a number as these features sorta touch everything. But it's harder to see that with say if and loop, those exist at the same/similar layer imo.