3 ms·

Very interesting stuff! I didn't even thought is possible to implement a low level functional languages, I always thought a functional language requires a ton o

Very interesting stuff! I didn't even thought is possible to implement a low level functional languages, I always thought a functional language requires a ton of abstractions.

epolanski 4y ago
At the end of the day what prevents functional languages from being a good fit for low-level programming is that effective low-level programming cannot be referentially transparent. Might be my 2 cents, but i think Rust can hit a very sweet spot for functionally-leaning low-level effective programming.
- chriswarbo 4y ago
  > At the end of the day what prevents functional languages from being a good fit for low-level programming is that effective low-level programming cannot be referentially transparent. I'm not sure I agree. "Straightforward" FP, e.g. a bunch of functions defining local vars and calling other functions, can be pretty hard to make low-level (it pretty much assumes a GC, and indirected closures; although tech like linear types can help). However, the more abstract, point-free, pattern-heavy FP seems like a reasonable fit (e.g. pipes/conduit)
- actionfromafar 4y ago
  I can't see why not - in normal computing, there is I/O. On embedded it also just "I/O" but a little more brutal than streams. Still pretty much the same though, at some point you must reference the outside world. What am I missing?
- throwaway17_17 4y ago
  I disagree, the reason almost all ‘functional’ programming can not be said to be referentially transparent is because of the level of abstract the designers take as a base. The work Greg Morrisette did (which include Robert Harper for some branches) on Typed and Dependently-Typed Assembly could be used as the basis for a ‘C-level’ programming language that is ‘functional’. At a slightly higher level, if memory is explicit, and that would include input and output buffers and the like, then it is possible to make functions exist inside a ‘memory monad’, similar to Haskell’s state monad. Then any and all operations involving the memory used can be made referentially transparent. Now, the real question is would anyone want to program in such a style? I know I wouldn’t mind, it’s while I broke down and designed a personal programming language for my daily use. But it’s a matter of taste and tolerance.
chriswarbo 4y ago
It's certainly possible, although certain styles are more appropriate than others. For example, ATS is ostensibly an ML-like language; but its "low level" examples look more like "C with stricter types" (e.g. its Cairo examples) https://en.wikipedia.org/wiki/ATS_(programming_language) https://en.wikipedia.org/wiki/ATS_(programming_language)
pjmlp 4y ago
Not at all, there only needs to exist enough low level primitives (aka compiler intrisics) to build the whole stack. That is how Lisp Machines and Xerox PARC workstation OSes used to be built, or Mirage OS for a more recent example. And I do consider Lisp functional, since when I reached university, the options were Lisp dialects, Mirada was fresh, Standard ML and Caml Light were rather new. There was yet to appear the mentality that OCaml / Haskell === FP.
dgb23 4y ago
Aside from Lisps being yet again an example of "Simpsons already did it.", there are also other examples and projects that go roughly into this direction. Like Roc[0]. Tim Sweeney[1] seems to be working on integrating functional programming into games development, which is highly competitive and very performance sensitive. John Carmack also has been advocating for using functional programming techniques in game development (partially). Generally I think FP has a bit of a misguided bad rep when it comes to performance. What makes code slow is indirection that a compiler cannot reason about and work that doesn't need to be done. There are FP techniques that can help a compiler or CPU to generate/transform efficient code and ones that can confuse them so to speak. Needless mutation can sometimes lead to bad code as well (from a compiler or CPU perspective), because it solidifies control. Functional programming is fundamentally a constraint, computers, interpreters and so on like constraints, because they can then go about shuffling around stuff without breaking those constraints if that makes sense. [0] https://www.roc-lang.org/ https://www.roc-lang.org/ [1] https://en.wikipedia.org/wiki/Tim_Sweeney_(game_developer) https://en.wikipedia.org/wiki/Tim_Sweeney_(game_developer)

Very interesting stuff! I didn't even thought is possible to implement a low level functional languages, I always thought a functional language requires a ton of abstractions.

epolanski 4y ago

At the end of the day what prevents functional languages from being a good fit for low-level programming is that effective low-level programming cannot be referentially transparent. Might be my 2 cents, but i think Rust can hit a very sweet spot for functionally-leaning low-level effective programming.

chriswarbo 4y ago
> At the end of the day what prevents functional languages from being a good fit for low-level programming is that effective low-level programming cannot be referentially transparent. I'm not sure I agree. "Straightforward" FP, e.g. a bunch of functions defining local vars and calling other functions, can be pretty hard to make low-level (it pretty much assumes a GC, and indirected closures; although tech like linear types can help). However, the more abstract, point-free, pattern-heavy FP seems like a reasonable fit (e.g. pipes/conduit)
actionfromafar 4y ago
I can't see why not - in normal computing, there is I/O. On embedded it also just "I/O" but a little more brutal than streams. Still pretty much the same though, at some point you must reference the outside world. What am I missing?
throwaway17_17 4y ago
I disagree, the reason almost all ‘functional’ programming can not be said to be referentially transparent is because of the level of abstract the designers take as a base. The work Greg Morrisette did (which include Robert Harper for some branches) on Typed and Dependently-Typed Assembly could be used as the basis for a ‘C-level’ programming language that is ‘functional’. At a slightly higher level, if memory is explicit, and that would include input and output buffers and the like, then it is possible to make functions exist inside a ‘memory monad’, similar to Haskell’s state monad. Then any and all operations involving the memory used can be made referentially transparent. Now, the real question is would anyone want to program in such a style? I know I wouldn’t mind, it’s while I broke down and designed a personal programming language for my daily use. But it’s a matter of taste and tolerance.

chriswarbo 4y ago

It's certainly possible, although certain styles are more appropriate than others. For example, ATS is ostensibly an ML-like language; but its "low level" examples look more like "C with stricter types" (e.g. its Cairo examples) https://en.wikipedia.org/wiki/ATS_(programming_language) https://en.wikipedia.org/wiki/ATS_(programming_language)

pjmlp 4y ago

Not at all, there only needs to exist enough low level primitives (aka compiler intrisics) to build the whole stack. That is how Lisp Machines and Xerox PARC workstation OSes used to be built, or Mirage OS for a more recent example. And I do consider Lisp functional, since when I reached university, the options were Lisp dialects, Mirada was fresh, Standard ML and Caml Light were rather new. There was yet to appear the mentality that OCaml / Haskell === FP.

dgb23 4y ago

Aside from Lisps being yet again an example of "Simpsons already did it.", there are also other examples and projects that go roughly into this direction. Like Roc[0]. Tim Sweeney[1] seems to be working on integrating functional programming into games development, which is highly competitive and very performance sensitive. John Carmack also has been advocating for using functional programming techniques in game development (partially). Generally I think FP has a bit of a misguided bad rep when it comes to performance. What makes code slow is indirection that a compiler cannot reason about and work that doesn't need to be done. There are FP techniques that can help a compiler or CPU to generate/transform efficient code and ones that can confuse them so to speak. Needless mutation can sometimes lead to bad code as well (from a compiler or CPU perspective), because it solidifies control. Functional programming is fundamentally a constraint, computers, interpreters and so on like constraints, because they can then go about shuffling around stuff without breaking those constraints if that makes sense. [0] https://www.roc-lang.org/ https://www.roc-lang.org/ [1] https://en.wikipedia.org/wiki/Tim_Sweeney_(game_developer) https://en.wikipedia.org/wiki/Tim_Sweeney_(game_developer)