4 ms·

Yeah ur right about the asterisk. I'll change it when I get to a desktop. As to Rust, it looks awesome.e, really. I've personally havn't used it but have been

Yeah ur right about the asterisk. I'll change it when I get to a desktop. 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.

__s 10y ago
I've been using Rust for the past year. Lack of tail calls kind of hurt the FP side of it Here's 4 esoteric programming language implementations: https://github.com/serprex/oilrs https://github.com/serprex/oilrs https://github.com/serprex/inliners https://github.com/serprex/inliners https://github.com/serprex/NULL https://github.com/serprex/NULL https://github.com/serprex/Kelxquoia 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/138217d5530b93a6161fe4f361ec895f7e302c2e#diff-40bb2a2af4768c6eb15c9e262b571d29L220 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>
- godmodus 10y ago
  i definitely commend you on the effort you're putting into this.

__s 10y ago

I've been using Rust for the past year. Lack of tail calls kind of hurt the FP side of it Here's 4 esoteric programming language implementations: https://github.com/serprex/oilrs https://github.com/serprex/oilrs https://github.com/serprex/inliners https://github.com/serprex/inliners https://github.com/serprex/NULL https://github.com/serprex/NULL https://github.com/serprex/Kelxquoia 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/138217d5530b93a6161fe4f361ec895f7e302c2e#diff-40bb2a2af4768c6eb15c9e262b571d29L220 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>

godmodus 10y ago
i definitely commend you on the effort you're putting into this.