Hacker News Reader

Comment by valenterry | Hacker News Reader

FP means that every expression (= part that can be evaluated) is referential transparent. Nowadays the word "functional" is used different from the original meaning (which some now call "pure functional")

> Some FP is lazy, some isn't.

The definition of FP implies that laziness is irrelevant. A language can enforce a pure functional style without being lazy or not.

> Some is immutable, some isn't

That's wrong. And it is a good example of why FP is much clearer defined. Referential transparency implies immutability. So there is no pure FP code that uses mutability.

> Some claim it's a style in any language, others that it's a type of language.

It's neither. It is a property of a program. Some languages enforce this property, others make it impossible to write a full program in this style. But that's independent of the definition itself.

I hope that explanation sheds a bit of light into it.

View on HN

Sorry, it’s my pet peeve, but referential transparency doesn’t mean what many think it does — what you mean is simply side-effect freeness.

See the top answer here: https://stackoverflow.com/questions/210835/what-is-referenti...

That answer is so informative and yet it completely misses the point.

The problem is even called out in the answer itself:

> For example, our example "Edinburgh has been the capital of Scotland since 1999" signifies the fact that "capital of Scotland" depends on the time at which it is being considered. Such context-dependence is a reality, both in natural languages and programming languages.

"Therein lies the rub." Such context-dependence doesn't have to be a reality in programming languages. "2 + 2 = 4" is an eternal verity, not subject to context-dependence. The whole point of FP (going back to Backus' Turing Award paper where he introduces and defines "FP") is to operate in the pure realm of [binary Boolean] logic.

I agree with you, but this property of FP languages is called pureness/not-having side effects, not referential transparency.

The latter is (quoting pron’s older comment: https://elarib.com/item?id=22141647 ): “an expression e is referentially transparent if any sub-term in it can be replaced with any other having the same reference (aka denotation) without changing e's reference”. Perhaps I should have linked this comment over the stackoverflow answer, as it also mentions how eg. template haskell or LISPs are actually NOT necessarily referentially transparent due to macros. So while in Java replacing the constant 2 with a variable having value 2 is always equivalent (in reference, not necessarily effect!), the same may not be true with a given macro applied.

Fair enough. (I'm getting old, it hurts my head to imagine pure-but-not-referentially-transparent language; however, imagining referentially-transparent impure language doesn't.)

Why are you so quickly assuming that you know better what I mean than I do?

Could you point out a specific point in my answer that is not compatible / or contradcits with the common definition of referential transparency?

I didn’t mean to assume anything, I just wanted to note that the common definition used in FP circles is not correct. So just exchanging ref. transparency with “not having side effects” in your otherwise perfectly fine and interesting reply will make it correct — since for example Java is also referentially transparent which I guess you would not consider being a pure FP language. (Exchanging a value with a variable referring to the same value will not change the value denoted by the expression for example neither in Java, but it is not too interesting a property in itself)

Sorry, but I find your language inappropriate.

> what you mean is simply side-effect freeness

This really makes it sound like an assumption. And:

> So just exchanging ref. transparency with “not having side effects” in your otherwise perfectly fine and interesting reply will make it correct

You implying my answer is incorrect here but you are not giving an example of what is wrong even though I asked for it.

That being said, I believe that the definition of referential transparency (and therefore FP) is not useful at all without making "semantics" a part of it. And this is the point where discussion can happen. For example, is the performance characteristics of a function part of the program semantics? I would say no. Even though it matters in practice. Same goes for logging: one can argue that logging (that can not blow up due to e.g. lack of disk space) can be considered irrelevant for program semantics and hence a function that logs something with a "print" can still be pure.

If you remove semantics from the definition then the definition becomes rather useless imho. In that case I would rather change its meaning or switch to a different definition alltogether.

I didn't want to repeat myself as the exact meaning was debated in two threads in this post already, for more details please have a look at them.

And I agree, we do have to specify what is the denotation of an expression that shall remain constant after replacing a sub-expression with that part's denotation -- for example choosing value of expression after evaluation is not too interesting, as it is shared by the majority of languages, and can only be "violated" by macros for example. Choosing the denotation as "value and side-effects" doesn't add much over saying simply that the language is pure and as you also note, purity has different levels.

If you do not point out any contradictions even after being asked twice then I have to conclude that you simply cannot. You could have also referred specifically or quoted the important lines from the other threads, but you did neither. That's not helpful in a discussion.

> Choosing the denotation as "value and side-effects" doesn't add much over saying simply that the language is pure

You are aware that, regarding the discussion between us two, it was you and not me who even used the term "side-effect" first, right?

https://news.ycombinator.com/item?id=27415670

https://news.ycombinator.com/item?id=27414992

> FP means that every expression (= part that can be evaluated) is referential transparent

> Referential transparency implies immutability

Both of these statements are false. As I said, Java is referentially transparent.

addOne(2)’s value is the same as the value of the last line in `var a = 2; addOne(a)`. And Java is most definitely not a pure FP language, and its referential transparency doesn’t imply immutability. You can argue that inserting `int two() { sideEffect(); return 2; }` ‘s invocation in place of 2 will change the semantics of the program but that is precisely the meaning of a side-effecting function — so using referential transparency is redundant in that meaning.

Thank you for explicitly pointing it out.

I disagree with you - I think you are using a different definition and there seems indeed to be discussion about what the definition really is. Wikipedia for examples uses the definition that I use, but in the Talk-section someone made a similar complaint to yours (or was that you :)). [https://en.wikipedia.org/wiki/Referential_transparency]

I stick to my definition though, because... I find it more useful and I think it is the more common one.

> FP means that every expression (= part that can be evaluated) is referential transparent.

Most real-world programming requires handling of side effects somewhere, so such programs have parts which are not referentially transparent.

It's why I distinguished between "core" and "meat" in my other response. Functional programming languages offer features that help making a larger part of the program referentially transparent (and, optionally, to ensure that property in the types).

> Nowadays the word "functional" is used different from the original meaning (which some now call "pure functional")

I don't think the meaning changed, just the tools offered and the scope of the support they offer to achieve referential transparency (pure functions). Early Lisp offered expression oriented programming which was a step towards it, but used dynamic scoping which isn't really helping. Later on both Lisps and ML offered lexical scoping. Then the purely functional trend came up via Miranda and (Clean and) Haskell, the latter encoding purity in the type system. In the last decade mainstream programming languages added functional programming features but are falling short in encoding purity in the types (just as Lisp never did), which means that it's (easily) possible for the abstractions offered (both functions but also libraries built on iterators) to not be referentially transparent, manual care (and/or culture) is required instead. The tooling doesn't help enough to guarantee referential transparency. But the core idea, the target of the efforts, is the same.

> Referential transparency implies immutability.

I didn't go into immutability in my other response because you can use mutation inside pure functions, as long as the effect doesn't leave the function. Building referentially transparent functions does not imply using immutable data structures or variable bindings inside.

> Most real-world programming requires handling of side effects somewhere, so such programs have parts which are not referentially transparent.

That's not correct though. Look at Haskell (or even stricter Idris). This is real world application code that can do whatever Java, C++, ... can do, but it is pure functional and hence doesn't contain any non referentially transparent parts. Just because an application is written in a pure functional style does not mean that it cannot e.g. write into a database when it is executed.

Of course many languages don't even allow to use a fully pure functional style. In that case, a more or less big functional "core" is the closest one can come to a pure FP style.

> I didn't go into immutability in my other response because you can use mutation inside pure functions, as long as the effect doesn't leave the function.

Sure you can do that and sometimes it is even the best practical solution. And the function might even be referential transparent - but your whole application is now not pure functional anymore, because a part of it is not referential transparent anymore.

Hence: if an application has to satisfy the criteria of being "pure functional" then every expression must be referential transparent and hence no mutation can be used.

It's funny that you defend your view using Haskell, as I was replying with Haskell in mind.

If you use the state monad, you encode local side effects. Then you use runState in a function that has a non-monadic type--a pure function.

Feel free to argue that the state monad is only having pure expressions because it can be represented using only pure functions and partial evaluation. For all practical purposes it is used to write code that exerts (local) side effects into the state maintained by the state monad.

You can a function in say, OCaml, that fills an array via mutation using only function arguments to deduct the contents, and then returns that array. That function is pure (it exerts no side effects outside and is not exposed to side effects from the outside, its result value only depends on the function argument values). Yet how is that not using mutation, non-referentially transparent parts inside?

You can write the same function with a mutable vector in Haskell (Data.Vector.Mutable, using the ST monad). How is it not exactly the same code as the one in OCaml except for the types that guarantee the purity? Yes, it may be using pure expressions underneath to guide the type system to enable the proof of purity. But does that change what I said? Both to the programmer and (after optimization) to the machine the code is using mutation. You can model mutation using only pure functions. That may be useful in some ways, but you can also take a C program, represent every memory address as an entry in a tree of immutable nodes, the outside world as an abstract entity with versions, and recreate it with only pure expressions. That may be what is useful in some contexts for developing proofs or to implement type systems, but is this relevant for a programmer interested in writing more functional programs? Why not just say that using ST is using local mutation (that the type system can guarantee will not leak outside) and be done with it?

Equivocation about purity, referential transparency, mutability, side effects etc. is not very interesting. The operative point is that, in Haskell, firstly

    x = expression
    y = expression
    ...

is the same as

    x = expression
    y = x
    ...

and that, secondly

    x = expression
    ...

is the same as

...

when x does not appear in ... . Those are the important properties of Haskell (with regard to this discussion). Whether this advances the discussion is another matter ...

I'm not deep into Haskell, but isn't the interpreter monad pattern effectively a language within the language that acts in a very conventional procedural way for interacting with IO and other external concerns? I just wonder... does Haskell really need syntactic segregation for this, and how is that better than any language which can declare/enforce pure functions/modules without the entire language being like that by default.

Well, give it a go! Or alternatively, look for languages that have been successful in enforcing any kind of purity and that also permit unrestricted use of higher order functions.

It's very hard to make Haskell look attractive to me, I deal with open systems (i.e. systems which interact with many other heterogenous systems which evolve in time), and Haskell is optimized for precisely the opposite case (a walled garden built out of elaborate types for verifying correctness). Haskell is the weird introvert guy in an extrovert world.

Interesting - for me it is the opposite. Non-functional languages usually work better if there is no concurrency involved. And 3rd party systems always introduce a certain amount of concurrency, sometimes more, sometimes less.

I would say pure FP languages such as Haskell are actually the best for such a case. Because in these languages the order/timing of lines of code are decoupled from the execution order/timing.

> I would say pure FP languages such as Haskell are actually the best for such a case. Because in these languages the order/timing of lines of code are decoupled from the execution order/timing.

... That's good in your opinion?

If your program is simple and LoC are executed one by one and that is totally fine, then FP just takes away the natural relation between LoC and execution and adds another layer of unnecessary complexity.

But when the percentage of concurrent code grows bigger, then it is better - because you lose the LoC<->execution relation anyways.

You can for example see that in Python. Python makes it really hard to break out of that model and have a line of code running while another one is running. That's why paralle and async/concurrent programming is such a PITA in python.

So, in my opinion for some problems the FP style is much better, because instead of "working your way around", you embrace the fact that LoC and execution are inherently decoupled.

Hmm, not really. See, for example, Clash, a Haskell compiler for synthesising hardware circuits, or Cardano, a massively distributed software system realising a cryptocurrency.

> Equivocation about purity, referential transparency, mutability, side effects etc. is not very interesting.

It's what the current discussion is about, since I explained why I explicitly didn't make a statement about immutability being required for FP.

> The operative point is that, in Haskell, firstly

> x = expression

> y = expression

> ...

> is the same as

> x = expression

> y = x

> ...

Sure but that's the pure part of a program.

    x <- expression
    y <- expression

is not generally the same as

    x <- expression
    let y = x in ...

and I pointed out that you can have such a program (i.e. with mutability) inside a function that is pure to the outside.

The interesting feature of Haskell / Monads is that you can have mutability be both inside and around pure expressions (impure code making use of pure code and then impure code again inside the implementation of pure code). Not everything in a Haskell program needs to be pure. Of course, pure expressions are good since they are easier to reason about. Also, they are the core idea of FP as I mentioned earlier. But, I want to avoid people taking away the impression that you then never can use mutable data structures, and that's why in my original comment I didn't make a statement about immutability being required for functional programming.

Functional programming has a core idea and that is pure expressions (referential transparency), and then features to help increase the area of programs which are pure expressions and increase the confidence / safety of them being so. With regards to that confidence, Haskell goes far (there's still unsafePerformIO (and non-total functions) so it's not completely perfect). And I'm not disputing that when I say that it still is and always was called functional programming when there were no language-provided features to give that confidence, or only "half-assed" ones if one wants to call them that. Or only culture and convention. My point in the whole discussion is to explain why functional programming doesn't mean the same thing for everyone, and how it can both be that @slver says "there's no clear definition of FP" and that there is at the same time. There is a clear definition for referential transparency, which is the core idea of FP. But the term FP also encompasses various approaches and tools with varying qualities to enable that core idea, and it's here where there's no clear definition.

> For all practical purposes it is used to write code that exerts (local) side effects into the state maintained by the state monad.

Yes, but as long as this is done with only pure expressions, then the whole program is pure functional - that is what the definition is about.

> You can a function in say, OCaml, that fills an array via mutation using only function arguments to deduct the contents, and then returns that array. That function is pure (it exerts no side effects outside and is not exposed to side effects from the outside, its result value only depends on the function argument values). Yet how is that not using mutation, non-referentially transparent parts inside?

The guarantee or at least convention of referential transparency for every expression has benefits. It means I as a developer can make certain assumptions about code that I could not make otherwise. I can do certain refactorings and changes while being sure that it will not change the program semantics.

As soon as parts of the program is not pure anymore, I know have to always re-assure myself that I'm currently working with the pure part of the code. Same for any tooling that I build.

As I said, you can make that choice and sometimes it is the best thing to do - but you cannot call your application "pure functional" anymore when you do.

> > Some is immutable, some isn't

> That's wrong. And it is a good example of why FP is much clearer defined.

OCaml and F# are two examples of functional languages with freely supported mutable data types. So maybe what I said is "wrong" about your personal idea of what FP is.

But it's clearly not "wrong" about the fact some people see immutability as optional for FP, which is the very point I'm making.

> OCaml and F# are two examples of functional languages

Both OCaml and F# are multi-paradigm languages that have FP features, but are not restricted to FP. The support for mutability comes from their imperative/OOP ancestors, not from FP.

Reply on news.ycombinator.com