3 ms·
What I want to see is a functional language that embraces structural typing and extensable records/variants, instead of nominal typing. This would be an excelle
by willtim 10y ago
What I want to see is a functional language that embraces structural typing and extensable records/variants, instead of nominal typing. This would be an excellent fit for a world full of SQL databases and JSON documents. It would also be a considerable implementation challenge!
- wyager 10y agoElm does this quite well. Haskell has (clunky) support through classy lenses.
- willtim 10y agoLike PureScript, Elms record system is very simple, it is extensible, but for example it cannot type a SQL join. It is possible to type a SQL join in Haskell using type level sets/maps and type families.
- jahewson 10y agoPureScript does this.
- willtim 10y agoYes it does partly, but it's mostly nominal. The records are extensible but they cannot type a SQL join (record union) and there are no structural variants. Ur/Web is probably a better example, but I'm not sure it's active.
- im_down_w_otp 10y agoThat doesn't seem to be too far adrift from how Dialyzer's success typing and Erlang work, though you'd have to create explicit spec definitions of all inputs and outputs of different shapes. There'd be little if no implicitness possible aside from implicit sub-typing.
- willtim 10y agoYes, nice example. Structural typing is a good fit for typing list/map centric code common in dynamic languages. It's probably Nominal typing that the dynamic proponents have rejected.
- cwyers 10y agoWhy do you think structural typing is a better fit for SQL than nominal?
- willtim 10y agoHow would you type a projection or join operation with nominal typing? You could define and name a set of additional result types, but this is very cumbersome, the type system can and should compute the result type for us.