rise-lang / rise Goto Github PK

#18 (comment)

Currently we have a makeArray primitive that works very much like an array literal, except that it works with elements that are expressions, instead of plain data like literals do. Currently we only generate code for makeArray if indices are constant (we know which element to pick at codegen time).

1. Why can our normal array literals not contain arbitrary expressions?
2. Should we generate code for non-constant indices, and how?
3. Why do we need array literals when we can use array constructors like makeArray?

Personally, I would like to solve both of these questions by removing the makeArray primitive. Instead of plain data, normal array literals would take elements of expression kind.

Additonnaly, a selectArray -- or differently named high-level construct -- would also allow to create arrays as a combination of generate and select. This would generate C code with if statements or ternaries to pick the right element. If indices are constant, we should simplify the branching away.

@rise-lang/core

TypePlaceholder was introduced to deal with expressions instantiated to different types at call sites by delaying the creation of fresh type identifiers. It can also be used as a "placeholder" when we erase the type of expressions. With a properly implemented type identifier instantiation mechanism, TypePlaceholder can be removed from this implementation.

Currently we don't have sufficiently good type inference error messages, and it is hard to locate the actual source of the error. Potential solutions include type inference on construction and constraint decomposition trace.

Some primitive types are currently under-constrained. Some type variables should only accept scalar types (vector primitives) or basic types (cast primitive). Ideally, type inference and type checking should deal with these constraints.

Dependent primitives and dependent types are currently not well supported. In particular, type inference needs to be properly implemented.