Back to Questions
1.3k
views3
comments
Side-effects, Purity, Safety of F#
f#

Hi,

Looking through some of the older posts in this forum, I found [link:cs.hubfs.net] "Is F# Pure?" That thread ran about a year back, and things may have changed since.

I had heard the terms "Side-effects" and "Safe" before (and assume "Pure" means something like "safety from side-effects"), and have an idea of what they mean in regards to F#. My working assumption is that the terms refer to not allowing changes in the larger environment (outside the F# code) to cause unintentional changes to the functionality of an F# program- a sort of firewall between F# code and the CLR, OS and .Net framework.

I'm hoping for a more authoritative definition. I'd also like to know just where F# in practice (current implementation), fits into what I take is a continuum "purity."

Coming from a perspective of regarding data integrity of paramount importance, I hope that F# purity, or purism, is inline with that value system.

Data within a database can't be any more free from data anomalies than the design of the DBMS permits. To what extent is well written F# code at the mercy of its implementation as a .Net language?

There's usually a trade-off between safety and functionality (use of ActiveX controls in earlier versions of IE, for example). I hope someone will comment of what trade-offs F# is making, from what I suppose is an ideal of purity.

To the degree that the F# developer has control over safety, are there any best practices available, to keep code as pure as the larger environment will allow?

Thanks,

BRN..

.

A pure function is one that will compute the same value for the same inputs each time (so it can't depend on an externally mutable value or IO), and it performs no externally visible changes (has no side effects). Side effects are any changes visible outside the function. That might be due to a call to another method that's not pure, or directly or indirectly changing a mutable value in F#. It's unrelated to any difference between F# and other .NET code.

Neither F# nor .NET have any specific support for pure functions (other than some metadata attributes via state your function is pure, for the sake of static analysis tools). Purity is left up to the programmer, as in most other languages. F# makes this easier to achieve via the style it promotes (such as immutability and recursion).

In many scenarios and in many languages, it's a good idea to try to keep functions as pure as possible. This makes your code easier to test and reason about.

By on 12/7/2009 8:59 AM ()

Hi Michael,

Thank you for the notes on F# purity and safety. I've also read another interpretation of purity in functional programming: limiting the code to the use of functions exclusively. That seems an even more of an ideal - and less attainable goal.

What are the meta-data attributes you mentioned? Do you have a link for more info (maybe some sample code that includes them)?

Just picked up a book on functional programming (using Haskel), to get a better feel for the pattern/style advocated. Having someone voice F#'s implementation helps make that it clearer.

Thanks again,

BRN..

By on 12/8/2009 5:31 AM ()

The metadata is via Code Contracts. Code Contracts: [link:msdn.microsoft.com]

By on 12/8/2009 1:02 PM ()

    Topic tags

    IntelliFactory Offices Copyright (c) 2011-2012 IntelliFactory. All rights reserved.
    Home | Products | Consulting | Trainings | Blogs | Jobs | Contact Us | Terms of Use | Privacy Policy | Cookie Policy     		Built with WebSharper