mnieper
commented
3 years ago Yes, we have voiced a lot of opinions here on what Steme should be and what should go into Steme, and what not (from our respective perspectives). Many ideas are probably not even mutually compatible.
In particular, your and my ideas are probably divergent. I understand what you have in mind. While I think that it is a project worth pursuing, I have to admit that it doesn't interest me enough from a programming language theory point of view to invest my free time in it. But that's fine because we can just work on two different projects.
PS The only thing I don't understand with your approach how you want to model purity when you don't have a monad or effect handlers or linear types or whatever.
Am Di., 6. Apr. 2021 um 19:09 Uhr schrieb John Cowan < @.***>:
I've come back to Steme after a long hiatus, and I have a whole lot of comments on many of the issues that have been discussed. But I've realized that there is a fundamental divergence between my idea of Steme and what I think everyone else is calling for. Unless that can be resolved or at least clarified, I don't know how much point there is in my detailed comments.
Scattered through the issues are what seems to me like a view of Steme in which it is a functional programming language such as SML or Haskell or some idealization of them, represented using a Lispy syntax so that such things as syntax-rules and syntax-case macros can be applied to it.
This is not the idea I had at all. I view Scheme and Steme as a pair of closely intertwined languages in which Steme provides a (Haskell-)pure component (that is, the only effects possible are non-termination and exception raising) and Scheme provides the impure component directly rather than monadically. Therefore, in a Scheme/Steme system you can avoid writing Steme, but you cannot avoid writing Scheme, because a program with no effects just sits there and does nothing. Users would typically write as much Steme as possible, but no more. (In addition, code in Scheme can be used as if it were Steme, provided you specify the argument types and assume the proof obligation that the code is externally speaking Haskell-pure.)
This is exactly analogous to Haskell, with Scheme taking the role of code in the I/O monad and Steme taking the role of non-I/O-monad code. It is also analogous to C as a functional programming language http://conal.net/blog/posts/the-c-language-is-purely-functional; the linked article points out that so-called C programmers actually program in cpp, a pure functional language (that is, if you ignore the rarely-used
undef):
[...] when evaluated (not executed), a cpp expression yields a (pure) value of type C, which is an ADT (abstract data type) that represents imperative programs. That value of type C is then executed (not evaluated) by the cpp language’s RTS (run-time system). As a clever optimization, cpp’s RTS actually includes a code generator, considerably improving performance over more naïve implementations of the C abstract data type.
Of course, most of a Haskell program is pure and a little bit is in the I/O monad, whereas most of a cpp program is in the monad and only a little is pure. Scheme/Steme are meant to be a more balanced situation.
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/pre-srfi/static-scheme/issues/28, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAHDTQ5DWJB667CCT3THPRLTHM54RANCNFSM42PEJKCA .
I've come back to Steme after a long hiatus, and I have a whole lot of comments on many of the issues that have been discussed. But I've realized that there is a fundamental divergence between my idea of Steme and what I think everyone else is calling for. Unless that can be resolved or at least clarified, I don't know how much point there is in my detailed comments.
Scattered through the issues are what seems to me like a view of Steme in which it is a functional programming language such as SML or Haskell or some idealization of them, represented using a Lispy syntax so that such things as syntax-rules and syntax-case macros can be applied to it.
This is not the idea I had at all. I view Scheme and Steme as a pair of closely intertwined languages in which Steme provides a (Haskell-)pure component (that is, the only effects possible are allocation, non-termination, and exception raising) and Scheme provides the impure component directly rather than monadically. Therefore, in a Scheme/Steme system you can avoid writing Steme, but you cannot avoid writing Scheme, because a program with no effects just sits there and does nothing. Users would typically write as much Steme as possible, but no more. (In addition, code in Scheme can be used as if it were Steme, provided you specify the argument types and assume the proof obligation that the code is externally speaking Haskell-pure.)
This is exactly analogous to Haskell, with Scheme taking the role of code in the I/O monad and Steme taking the role of non-I/O-monad code. It is also analogous to C as a functional programming language; the linked article points out that so-called C programmers actually program in cpp, a pure functional language (that is, if you ignore the rarely-used
#undef):Of course, most of a Haskell program is pure and a little bit is in the I/O monad, whereas most of a cpp program is in the monad and only a little is pure. Scheme/Steme are meant to be a more balanced situation.