Haskell*/ML
?> a low level FP styled non-gc`ed programming language would be interesting to see rise too
Sounds like Rust. If not, what do you think disqualifies it?
Haskell*/ML
?> a low level FP styled non-gc`ed programming language would be interesting to see rise too
Sounds like Rust. If not, what do you think disqualifies it?
Rust never struck me as a functional language. It's disciplined, in the manner of ML or Haskell, but it is generally (and inextricably) an imperative language at heart. The strong type system is geared towards making imperative, stateful code safe, rather than eliminating it.
As to Rust, it looks awesome.e, really. I've personally havn't used it but have been watching it rise through the rank with greater momentum (and more serious projects) than haskell. I just don't know enough about it to have made a statement I could back. I've a few future projects that I could use it in.
Here's 4 esoteric programming language implementations: https://github.com/serprex/oilrs https://github.com/serprex/inliners https://github.com/serprex/NULL https://github.com/serprex/Kelxquoia
I wouldn't call their implementations particularly functional. Linked Lists get a bit of a spotlight in FP but in Rust their ill advised. Option<Box<List<T>>> means they can't be shared, Option<Rc<List<T>>> can be overkill. For awhile I had some code which wanted to chain references along the stack, but issue is that in each recursive call the lifetime varies, but one can't put the lifetime of the reference in the type (each level of recursion has to carry an extra lifetime parameter) so I had to instead make a ListTrait<T>, have List<'a> carry an Option<&'a ListTrait>, but now that's a virtual pointer with a virtual table. Commit of replacing the code: https://github.com/serprex/lambdaski/commit/138217d5530b93a6... . Was done by changing the code to not create copies (which had this russian doll lifetime pattern) but instead all use references to the string being parsed, thus once every reference had the same lifetime they could all be packaged into a single Vec<T>