Trait system #24
Labels
A-syntax
Area: Syntax
A-type-system
Area: Type system
design
Open design questions that need to be solved
T-feature-request
Type: Feature that is part of the language spec but not implemented
There are several ideas already (in the design document) but there is no "final" decision yet.
My tendency since forever is a manual trait system meaning records + implicit parameters type 2 (no normal type inference but a search through module-local bindings with unifiable types).
1st Design Proposal: Records and Automatic Parameters
Trait (type class, interface, …) definitions are just records (#18, #42) and trait bounds (type class constraints) are automatic parameters.
Automatic parameters show similarities to implicit ones but the algorithm for "inferring" them is vastly different.
For implicits, the type checker applies type inference (applying inference rules and synthesizing values to fill inference variables).
For "automatics", the type checker searches the module scope (!) (implies trait impls need to be
use
d) for bindings matching the required type probably substituting implicits or whatever. It will throw an error on ambiguity. Has a depth to not search endlessly (seems to be necessary in Idris 1 for some good reason). Temporary syntax is two single quotes ("double ticks") mirroring implicits which have merely a single single quote (assuming #63).Example:
Pros:
Cons:
Monoid.monoid.<>
aliasingMonoid.monoid.append
)2nd Design Proposal: Records with Syntactic Sugar and Automatic Parameters
Introduce trait declarations (beginning with the keyword
trait
) which are lowered to records (but probably with the information of them being desugared traits preserved).Meta: Expand upon this description.
3rd Design Proposal
Meta: Design.
The text was updated successfully, but these errors were encountered: