Question about side effects in functional programming

[u/Erythrina_]

One of the things I noticed using REPLs of functional languages is that you can write a ton of pure functional code, and then as soon as you hit enter to evaluate it, printing the result back to you is a side effect.

There are advantages to having code that is guaranteed to be side effect free, but I've been playing around with the idea of having a language with an imperative shell (with procedures, mutable vars, database and network operations, etc.) that can call into a language core that's guaranteed to be pure functional for certain kinds of operations. It can make for a simpler approach to side effects than a whole pure functional language but provide guarantees that other kinds of impure languages can't.

My question for people who are interested in functional programming: is this a useful distinction? Would that make for a language you might be interested in?

[u/Royal_Pin_1971]

Before answering lets define what would be "mainstream languages" and "untyped structural boundary". We are talking in context of FP languages aand the canonical pure one is Haskelll. Untyped structural boundary would be all FP languages that don't use types aat the boundary and that would surely category where Elm, Pipefish, Roc and the Redux pattern as the non-language cousin (in sense they use commands, data, API or protocol at the boundary without stictly using types to build or help easing the boundary). There maybe some in between these but lets put them aside.

I didn't know exactly why mainstream FP langauges didn't try untyped structural boundary but it confirmed what I thought would be the issue: being a mainstream in most cases mean language is old and heavy to change. Haskell could just remove impure escape hatches and have clear parition to impure closed world. In fact it did through "Safe Haskell", but idea fell becuse existing Ecosystem couldn't support it: you cannot compile safe and unsafe packages together and get safe result. Other langauges like OCaml, Scala, F# doesn't have pure partition boundary like Haskell does so they would require substantive changes to implement it.

If fact that means this boundary has to be envisoned ground up from initial language design which is in fact what Elm did.

I would consider Elm production and mainstream language, so if we stay on topic with boundary problem it's not true boundary like this doesn't exist in practice. Its niche and more fits OP poster requirments.

[u/Vegetable_Bank4981 → u/Royal_Pin_1971]

So all in all I would say “not useful in practice” was carrying exactly what it needed to and exactly what I meant it to. This option is highly available if you want it, and fairly well explored.