5 ms·

I personally want to use SML as a base to develop a new language, one which eschew's side effects. Personally I think such a thing would be 100x more approachab

I personally want to use SML as a base to develop a new language, one which eschew's side effects. Personally I think such a thing would be 100x more approachable than Haskell for newcomers, and could provide a basis for pure functional programming to make a significant impact on the industry. The main thing that SML brings to the table IMO is its definition. This specifically forces things to be well-defined, and hence well-thought-out, and thus prevents the adding of a bunch of bad features that later need to be maintained for the lifetime of the language. There are many areas in which I think formal methods are overkill, but PLs are one of the exceptions. Any mistakes early on in the language are usually VERY hard to resolve.

Zababa 5y ago
I'm curious about how your new language would work. From my (limited) understanding, the big differences between Haskell and SML are the type system and stictness/lazyness. I think a Haskell-like type system would be necessary if you want to eschew side effects (although I may be wrong), so the big difference would be that it's strict?
- Athas 5y ago
  If you took SML and removed reference cells and the parts of the standard library that involve IO, then you'd have a pure language (depending on whether you consider exceptions to be effects). It would not be useful for application programming, but would be fine for teaching functional programming.
  - Zababa 5y ago
    That's true. I think it also ties into best practices such as hexagonal architecture, DDD, and the "functional core, imperative shell" idea. You design the core of your program as data and pure functions, and then call that part from parts of the program that use IO. Maybe something like when scheme is used for teaching could work, with different "language levels", where some part disallow IO and reference cells. Or maybe a different file extension that's checked by the compiler to be pure. This could be a great way to teach functional programming but also software engineering.
  - hcarvalhoalves 5y ago
    The Hope language would be a educational SML w/o side-effects. https://en.wikipedia.org/wiki/Hope_(programming_language) https://en.wikipedia.org/wiki/Hope_(programming_language)
- c-cube 5y ago
  The future is effect systems, not monads. The next ML will be more similar to Koka than Haskell, and yes, it'll be strict. Maybe it'll even be named OCaml if the efforts to bring effect typing into it are eventually merged :-).
  - Zababa 5y ago
    So if I understand everything correctly effect systems are another way of encoding side effects into the type system? If so, why are they preferable to monads? That's the part I don't understand. For the strictness, I think now most people agree that a bit of lazyness is great when you need it (iterators, streams) but the vast majority of the language should be indeed strict. > Maybe it'll even be named OCaml if the efforts to bring effect typing into it are eventually merged :-). From what I read recently that's the plan, although they'll focus first on domains for 5.0, and merge the effects later.
    - c-cube 5y ago
      Effect systems are both a runtime thing (similar to exceptions or lisp's conditions, in some sense), and a type-level thing (have a set of effects attached to an arrow, with type inference that is able to infer the effects and compose them nicely). Both are necessary for the future ML™, I think: the runtime part gives semantics to effects and composes super well (better than monad transformers, afaict: no need to `lift` everything); the typing part keeps the code honest. The effects also have to compose nicely with higher-order functions (so that `map` carries over the effects of its functional parameter). > From what I read recently that's the plan, although they'll focus first on domains for 5.0, and merge the effects later. Yes indeed! The timeline for typed effects is not clear to me, it might take a long time, especially with the stringent constraints of backward compatibility. That said I'm not an expert, I'm just very hyped :-)
      - Zababa 5y ago
        Thank you for the explanation! I feel like I understand this better now. > The timeline for typed effects is not clear to me, it might take a long time, especially with the stringent constraints of backward compatibility. From what I understand, the "long time" will be probably less than modular implicits, which are estimated at at least a few years away. There are a few informations here https://discuss.ocaml.org/t/multicore-ocaml-may-2021/7990 https://discuss.ocaml.org/t/multicore-ocaml-may-2021/7990 and here https://discuss.ocaml.org/t/multicore-ocaml-june-2021/8134 https://discuss.ocaml.org/t/multicore-ocaml-june-2021/8134, where at least we can see that the effect branch is up to date with 4.12. The performance seems really good, I can't find it anymore but they had the same performance as Go's net/http with http/af. It's a very exciting space!
- JoelMcCracken 5y ago
  BTW (and I'm replying to directly so you see it), I think you might like to see this: https://github.com/yallop/effects-bibliography https://github.com/yallop/effects-bibliography Lots of information on varieties of effect systems

Zababa 5y ago

I'm curious about how your new language would work. From my (limited) understanding, the big differences between Haskell and SML are the type system and stictness/lazyness. I think a Haskell-like type system would be necessary if you want to eschew side effects (although I may be wrong), so the big difference would be that it's strict?

Athas 5y ago
If you took SML and removed reference cells and the parts of the standard library that involve IO, then you'd have a pure language (depending on whether you consider exceptions to be effects). It would not be useful for application programming, but would be fine for teaching functional programming.
- Zababa 5y ago
  That's true. I think it also ties into best practices such as hexagonal architecture, DDD, and the "functional core, imperative shell" idea. You design the core of your program as data and pure functions, and then call that part from parts of the program that use IO. Maybe something like when scheme is used for teaching could work, with different "language levels", where some part disallow IO and reference cells. Or maybe a different file extension that's checked by the compiler to be pure. This could be a great way to teach functional programming but also software engineering.
- hcarvalhoalves 5y ago
  The Hope language would be a educational SML w/o side-effects. https://en.wikipedia.org/wiki/Hope_(programming_language) https://en.wikipedia.org/wiki/Hope_(programming_language)
c-cube 5y ago
The future is effect systems, not monads. The next ML will be more similar to Koka than Haskell, and yes, it'll be strict. Maybe it'll even be named OCaml if the efforts to bring effect typing into it are eventually merged :-).
- Zababa 5y ago
  So if I understand everything correctly effect systems are another way of encoding side effects into the type system? If so, why are they preferable to monads? That's the part I don't understand. For the strictness, I think now most people agree that a bit of lazyness is great when you need it (iterators, streams) but the vast majority of the language should be indeed strict. > Maybe it'll even be named OCaml if the efforts to bring effect typing into it are eventually merged :-). From what I read recently that's the plan, although they'll focus first on domains for 5.0, and merge the effects later.
  - c-cube 5y ago
    Effect systems are both a runtime thing (similar to exceptions or lisp's conditions, in some sense), and a type-level thing (have a set of effects attached to an arrow, with type inference that is able to infer the effects and compose them nicely). Both are necessary for the future ML™, I think: the runtime part gives semantics to effects and composes super well (better than monad transformers, afaict: no need to `lift` everything); the typing part keeps the code honest. The effects also have to compose nicely with higher-order functions (so that `map` carries over the effects of its functional parameter). > From what I read recently that's the plan, although they'll focus first on domains for 5.0, and merge the effects later. Yes indeed! The timeline for typed effects is not clear to me, it might take a long time, especially with the stringent constraints of backward compatibility. That said I'm not an expert, I'm just very hyped :-)
    - Zababa 5y ago
      Thank you for the explanation! I feel like I understand this better now. > The timeline for typed effects is not clear to me, it might take a long time, especially with the stringent constraints of backward compatibility. From what I understand, the "long time" will be probably less than modular implicits, which are estimated at at least a few years away. There are a few informations here https://discuss.ocaml.org/t/multicore-ocaml-may-2021/7990 https://discuss.ocaml.org/t/multicore-ocaml-may-2021/7990 and here https://discuss.ocaml.org/t/multicore-ocaml-june-2021/8134 https://discuss.ocaml.org/t/multicore-ocaml-june-2021/8134, where at least we can see that the effect branch is up to date with 4.12. The performance seems really good, I can't find it anymore but they had the same performance as Go's net/http with http/af. It's a very exciting space!
JoelMcCracken 5y ago
BTW (and I'm replying to directly so you see it), I think you might like to see this: https://github.com/yallop/effects-bibliography https://github.com/yallop/effects-bibliography Lots of information on varieties of effect systems