5 ms·

Statically typed Lisp for the win https://carp-lang.github.io/carp-docs/core/Pointer.html https://carp-lang.github.io/carp-docs/core/Pointer.html

tmtvl 3y ago
Indeed, I also like statically typed Lisp: https://quickref.common-lisp.net/defstar.html https://quickref.common-lisp.net/defstar.html EDIT: to be fair, Coalton seems even more interesting than defstar, but it has issues with mutation.
- reikonomusha 3y ago
  Hindley-Milner has the very standard and well-known problem with polymorphic mutation [1]. There is no issue with setting an array of floats or something like that. It's only when you assign a polymorphic value cell with one type, then subsequently with another type. This is not unique to Coalton. Any HM-based language that defines mutation primitives has it, including Haskell and OCaml. These languages don't "solve" it a sense most people think, instead they provide some sort of restriction or workaround to the HM theory to make mutation constructs feasible. There's a huge space of possible solutions, including ensuring functional purity with monads (Haskell) to using weak polymorphism (OCaml) to using Wright's value restriction (eliminate invalid mutations, but also eliminate tons of reasonable, valid programs). Coalton developers know of the HM deficiency and described it very well here [2]. It looks like they're building out more important parts of the language that affect their users more seriously (e.g., adding records) before making a hugely consequential design decision around mutation, which people don't seem to bump into much. It doesn't seem to have stopped them from building interesting software in the slightest. [3] [1] https://en.wikipedia.org/wiki/Value_restriction#A_Counter_Example_to_Type_Safety https://en.wikipedia.org/wiki/Value_restriction#A_Counter_Ex... [2] https://github.com/coalton-lang/coalton/issues/84 https://github.com/coalton-lang/coalton/issues/84 [3] https://coalton-lang.github.io/20220906-quantum-compiler/ https://coalton-lang.github.io/20220906-quantum-compiler/
  - medo-bear 3y ago
    There are plenty of people who are curious about Coalton but dont know enough about static typing it implements and see the github issue and become concerned and think that Coalton should be avoided. Lately there seems to be alot of parroting that Coalton is broken. Obvioisly it is not and I think that developers should write an explanation about what is going on here.

tmtvl 3y ago

Indeed, I also like statically typed Lisp: https://quickref.common-lisp.net/defstar.html https://quickref.common-lisp.net/defstar.html EDIT: to be fair, Coalton seems even more interesting than defstar, but it has issues with mutation.

reikonomusha 3y ago
Hindley-Milner has the very standard and well-known problem with polymorphic mutation [1]. There is no issue with setting an array of floats or something like that. It's only when you assign a polymorphic value cell with one type, then subsequently with another type. This is not unique to Coalton. Any HM-based language that defines mutation primitives has it, including Haskell and OCaml. These languages don't "solve" it a sense most people think, instead they provide some sort of restriction or workaround to the HM theory to make mutation constructs feasible. There's a huge space of possible solutions, including ensuring functional purity with monads (Haskell) to using weak polymorphism (OCaml) to using Wright's value restriction (eliminate invalid mutations, but also eliminate tons of reasonable, valid programs). Coalton developers know of the HM deficiency and described it very well here [2]. It looks like they're building out more important parts of the language that affect their users more seriously (e.g., adding records) before making a hugely consequential design decision around mutation, which people don't seem to bump into much. It doesn't seem to have stopped them from building interesting software in the slightest. [3] [1] https://en.wikipedia.org/wiki/Value_restriction#A_Counter_Example_to_Type_Safety https://en.wikipedia.org/wiki/Value_restriction#A_Counter_Ex... [2] https://github.com/coalton-lang/coalton/issues/84 https://github.com/coalton-lang/coalton/issues/84 [3] https://coalton-lang.github.io/20220906-quantum-compiler/ https://coalton-lang.github.io/20220906-quantum-compiler/
- medo-bear 3y ago
  There are plenty of people who are curious about Coalton but dont know enough about static typing it implements and see the github issue and become concerned and think that Coalton should be avoided. Lately there seems to be alot of parroting that Coalton is broken. Obvioisly it is not and I think that developers should write an explanation about what is going on here.