search

albrow / fo

An experimental language which adds functional programming features to Go.
Other
1.24k stars 34 forks source link

support for immutable values #5

Open campoy opened 6 years ago

campoy commented 6 years ago

Hey there,

So I'm actually quite interested on this project, but the first thing I expected to find in a functional version of Go was some form of immutability.

Have you considered adding such a feature? I'd be curious on how it would match the rest of the language!

ondrajz commented 6 years ago

Could you give some concrete example for this?

blak3mill3r commented 6 years ago

This project doesn't seem to be focused on data structures...

You could try https://github.com/tobgu/peds to get immutability a la carte

andradei commented 6 years ago

@TrueFurby I think @campoy is talking about a something like let for immutable bindings and var for mutable ones (which Go already has). Something like this:

type MyType struct {
    X int
    Y string
}

let m = MyType{X: 1, Y: "Immutable"}

// You can't then, modify the internals of a composite structure.
m.X = 2
m.Y = "Can't mutate me"

// You also can't change the binding to something else.
m = MyType{X: 2, Y: "Can't rebind variable m either"}

Please correct me if I'm wrong, but that's what I understood from "some form of immutability".

bruth commented 6 years ago

I think @campoy may be referring to persistent data structures?

andradei commented 6 years ago

Oh, I see. Thanks for pointing it out! That would be a huge change right (even compared to adding generics)? Go isn't even partially persistent.

albrow commented 6 years ago

I recognize that immutability is a core part of functional programming. However, I'm not sure how we could enforce this at the compiler level, especially given the existence of the reflect package in Go.

I think immutability may be something best left to libraries to implement. For example, if you are writing a list package, it is easy to make list.List externally immutable by only exposing exported methods that always return a copy of the list. This even works against reflect (since reflect can only mutate exported values).

campoy commented 6 years ago

Yeah, but I would expect at least slices to be immutable?

albrow commented 6 years ago

@campoy I'm not sure what you are proposing exactly. Can you elaborate? How would this work with the existing slice type in Go?

campoy commented 6 years ago

I'm not sure how it would be implemented. Everything I'm saying is that it seems important to have a concept of immutability in a purely functional language. Otherwise the referential transparency will be broken which leads to issues with concurrency.

This is more of a question / proposal rather than a "you need to fix this" issue.