4 ms·
I’m reading Thinking Forth at the moment and there’s a part in the description of Forth about how it decouples words from their parameters and return types by o
by throwaway316943 6y ago
I’m reading Thinking Forth at the moment and there’s a part in the description of Forth about how it decouples words from their parameters and return types by only allowing stack manipulation. This means that all words share a common interface and so they’re infinitely composable. The reason I started reading this book is due to learning how WebAssembly works which turns out to be quite similar to Forth. It got me thinking if there might be a way to make all code modules interoperable. Being able to compose an application or client out of many independent parts would be a dream come true.
- carapace 6y agoYup yup. I'm on the trail of just this using a purely functional Forth-like language called Joy. Your hunch is correct, you're intuiting the "Categorical" (as in Category Theory) nature of "point-free" format: http://conal.net/papers/compiling-to-categories/ http://conal.net/papers/compiling-to-categories/ > It is well-known that the simply typed lambda-calculus is modeled by any cartesian closed category (CCC). This correspondence suggests giving typed functional programs a variety of interpretations, each corresponding to a different category. ... This paper describes such an implementation and demonstrates its use for a variety of interpretations including hardware circuits, automatic differentiation, incremental computation, and interval analysis. ... The general technique appears to provide a compelling alternative to deeply embedded domain-specific languages.
- ssivark 6y agoThat Conal Elliot paper is being my current level, and I don’t see the relation to the comment about composability in Forth. Is there a simplified explanation somewhere? (Preferable less mathematical and more verbal, but I’ll take what I can get) Thanks.
- carapace 6y agoI don't know if it's written up anywhere like that, sorry. The very brief section on mathematical purity of Joy in the Wikipedia article describes it but in (IMO) an unhelpful way: https://en.wikipedia.org/wiki/Joy_(programming_language)#Mathematical_purity https://en.wikipedia.org/wiki/Joy_(programming_language)#Mat... > In Joy, the meaning function is a homomorphism from the syntactic monoid onto the semantic monoid. That is, the syntactic relation of concatenation of symbols maps directly onto the semantic relation of composition of functions. It is a homomorphism rather than an isomorphism, because it is onto but not one-to-one; that is, no symbol has more than one meaning, but some sequences of symbols have the same meaning (e.g. "dup +" and "2 *"). > Joy is a concatenative programming language: "The concatenation of two programs denotes the composition of the functions denoted by the two programs".[2] [2] "Mathematical foundations of Joy" by Manfred von Thun https://web.archive.org/web/20111007025556/http://www.latrobe.edu.au/phimvt/joy/j02maf.html https://web.archive.org/web/20111007025556/http://www.latrob...
- Too 6y ago> make all code modules interoperable. > Being able to compose an application or client > out of many independent parts would be a dream come true. You can stop dreaming, this exists and it's called json and npm install. Some would argue this particular implementation of it is a nightmare rather than a dream though :) At some point you also have to integrate all this interop. Possibility to compose doesn't mean composition automatically puzzles itself together.