Dennis Hackethal’s Blog

My blog about philosophy, coding, and anything else that interests me.

History of post ‘Guaranteeing Referential Transparency’

Versions are sorted from most recent to oldest with the original version at the bottom. Changes are highlighted relative to the next, i.e. older, version underneath. Only changed lines and their surrounding lines are shown, except for the original version, which is shown in full.

Revision 3 · · View this (the most recent) version (v4) 

@@ -14,6 +14,6 @@ Having such functions seems to me a great step toward guaranteeing referential t

To solve this problem, you may choose to have the transpiler throw an exception whenever a function you declare to be referentially transparent takes referentially intransparent functions as arguments.

EDIT: The notion of a referentially transparent function is now implemented in the form of +a 'strict' -functions+function as part of the [Berlin programming language](https://github.com/dchacke/berlin-lang/).

*If you enjoyed this article, [follow me on Twitter](https://twitter.com/dchackethal) for more content like it.*

Revision 2 · · View this version (v3)

Be more specific about what Berlin implements

@@ -14,6 +14,6 @@ Having such functions seems to me a great step toward guaranteeing referential t

To solve this problem, you may choose to have the transpiler throw an exception whenever a function you declare to be referentially transparent takes referentially intransparent functions as arguments.

EDIT: -This feature+The notion of a referentially transparent function is now implemented +in the form of 'strict' functions as part of the [Berlin programming language](https://github.com/dchacke/berlin-lang/).

*If you enjoyed this article, [follow me on Twitter](https://twitter.com/dchackethal) for more content like it.*

Revision 1 · · View this version (v2)

Fix broken link, use em-dashes, replace non-breaking spaces with regular spaces

@@ -2,18 +2,18 @@

![Glasses](/assets/1_2RdfimeWaFU2lsGSgWVViw.jpg)

<small class="caption">*Photo -by [Bud Helisson](https://unsplash.com/@budhelisson?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText) on [Unsplash](https://unsplash.com/s/photos/transparency?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText)*</small>+by [Bud Helisson](https://unsplash.com/@budhelisson?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText) on [Unsplash](https://unsplash.com/s/photos/transparency?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText)*</small>

The other day, I saw a video -on [Brian+on [Brian Will's YouTube -channel](https://www.youtube.com/user/briantwill) --- I'm+channel](https://www.youtube.com/user/briantwill)—I'm afraid I don't remember which video it -was --- in+was—in which he mentioned how cool it would be if a programming language offered a special kind of function that can only access the parameters it was given and nothing else. The function would then be referentially transparent and, therefore, truly modular: you could cut it out of any arbitrary code and paste it into any arbitrary code and it would still work.

His idea came at a good time. For the past few days, I have been dabbling with creating a new programming language. My main motivation is just to learn how to write a transpiler, but I also want to build a language that makes learning functional concepts easier for JavaScript developers. Ideally, the language's syntax will look very similar to that of JavaScript while applying functional concepts we know and love from Clojure.

I think Brian's idea could be implemented relatively easily. The transpiler could check the generated abstract syntax tree for any symbols within the body of a function that are not part of that function's argument list.

Having such functions seems to me a great step toward guaranteeing referential transparency. Alas, it's not itself a complete guarantee yet, because you could still pass an impure -function *g* that+function *g* that then gets invoked by your newly declared -function *f*. If *f*'s+function *f*. If *f*'s return value changes depending -on *g*'s+on *g*'s return -value, *f* is+value, *f* is not referentially transparent.

To solve this problem, you may choose to have the transpiler throw an exception whenever a function you declare to be referentially transparent takes referentially intransparent functions as arguments.

EDIT: This feature is now implemented as part of -the [Berlin+the [Berlin programming -language](http://berlinlang.org/).+language](https://github.com/dchacke/berlin-lang/).

*If you enjoyed this -article, [follow+article, [follow me on -Twitter](https://twitter.com/dchackethal) for+Twitter](https://twitter.com/dchackethal) for more content like it.*

Original · · View this version (v1) 

# Guaranteeing Referential Transparency

![Glasses](/assets/1_2RdfimeWaFU2lsGSgWVViw.jpg)

<small class="caption">*Photo by [Bud Helisson](https://unsplash.com/@budhelisson?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText) on [Unsplash](https://unsplash.com/s/photos/transparency?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText)*</small>

The other day, I saw a video on [Brian Will's YouTube channel](https://www.youtube.com/user/briantwill) --- I'm afraid I don't remember which video it was --- in which he mentioned how cool it would be if a programming language offered a special kind of function that can only access the parameters it was given and nothing else. The function would then be referentially transparent and, therefore, truly modular: you could cut it out of any arbitrary code and paste it into any arbitrary code and it would still work.

His idea came at a good time. For the past few days, I have been dabbling with creating a new programming language. My main motivation is just to learn how to write a transpiler, but I also want to build a language that makes learning functional concepts easier for JavaScript developers. Ideally, the language's syntax will look very similar to that of JavaScript while applying functional concepts we know and love from Clojure.

I think Brian's idea could be implemented relatively easily. The transpiler could check the generated abstract syntax tree for any symbols within the body of a function that are not part of that function's argument list.

Having such functions seems to me a great step toward guaranteeing referential transparency. Alas, it's not itself a complete guarantee yet, because you could still pass an impure function *g* that then gets invoked by your newly declared function *f*. If *f*'s return value changes depending on *g*'s return value, *f* is not referentially transparent.

To solve this problem, you may choose to have the transpiler throw an exception whenever a function you declare to be referentially transparent takes referentially intransparent functions as arguments.

EDIT: This feature is now implemented as part of the [Berlin programming language](http://berlinlang.org/).

*If you enjoyed this article, [follow me on Twitter](https://twitter.com/dchackethal) for more content like it.*