Back to Questions
2.2k
views8
comments
Can F# be pure?
f#

Hi,

I read a lot recently about F#, but I’m worrying about side-effects in sense of doing it when not suppose to.

Can I force F# to be pure and prevent side-effects? Let’s say in safe area or maybe pure lambda?

,,,
twok

.

At the moment there is one big issue with beeing pure: peformance. You just can't produce pure functional code that is as performant as a cleverly tweaked impure one - because you memoize calculations, rewrite iterations to compute multiple connected values etc.

So F# let's you use impure code but where is the problem?

Ok you can't be sure if your code is really pure and that might be a problem with parallel computing - but if I might be so bold: the algorithms we can write that are really parallel is not that complex. An it's a improvement from writing C# code no matter what.

By on 12/15/2008 9:25 PM ()

There's nothing automatic/tool-wise you can use to flag impurity. For example, in any function/expression you write, nothing will stop you from calling System.Console.WriteLine(), for example.

That said, with F# it is a bit easier to author pure functions than in some other languages; things are not mutable by default, so if you avoid "let mutable ...", avoid calling .NET methods that have effects, avoid the byref<'T> type, etc., you are in good shape. In short, it still takes human effort/discipline to 'ensure' pureness, but the design of F# and its core library make it easier in practice to program with such discipline.

By on 12/5/2008 5:26 PM ()

well, pursim is key factor of any FP.

wished F# has somthing to cover that.

asume we labeled some basic funcs that we know theyr're pure(like +,-,sum,fact...), then when I only use them or any func that only use them, then that is pure func :)

what's wrong with that!

By on 12/15/2008 9:50 AM ()

In principle there's nothing wrong with this; it would be great to type/metadata-annotate things as pure and create islands of purity in the program. (In a sense this is the inverse strategy of Haskell, where e.g. the IO monad creates islands of effects.) In practice, F# is hosted in the CLR and its library is the .NET Framework, and this environment has no concept of purity, and since you require the transitive closure of your call graph to be pure in order for you to be pure, it's hard to gain a toehold to start a pure island. Even '+' in F# is an overloaded operator that cannot guarantee there are no effects since it can be called on user-defined types. (If you constrain yourself to e.g. the Unchecked version of '+' on the 'int' type, you're probably ok.) And to be practical you probably need purity to be expressed in the type system, and to interact with generics (e.g. "List.map f" is pure iff "f" is pure), as well as do some complicated analysis on kinds of effects and limitations of their interactions (e.g. you can author pure functions that call impure ones, provided that none of the effects 'escape').

So I guess to sum up, I think all this would be great stuff, but I would guess it's still decades away from making its way into any mainstream programming language, if ever. By then, who knows, maybe Haskell will turn out to be the winning horse instead.

By on 12/15/2008 10:23 AM ()

thank you brianmcn,

Would you be surprised when I said :)
*** I don’t care about multi-core ***

We need purism not for multi-core but because it’s better for *design* (abstraction, composition,…)

The aim of purism is that I can use it anywhere anytime without worry, no matter if I can run it in multi-core or not, but anyway multicore won’t work in impure world!

By on 12/15/2008 11:33 AM ()

If you don't want it for compiler optimizations, why is it so important to you that the compiler checks purity? In well designed APIs side effects are usually obvious from the function name and signature. In cases where the side effects are subtle they should be appropriately documented.

By on 12/15/2008 12:04 PM ()

Let’s say I need chart generator, the most powerful chart library should be designed in functions take (data and preferences) and return graphics, no more no less and more important dose nothing to do with environment around.

That was great example.

Another chart library do everything from changing environment, writing files every ware, Calling Excel!, need system configuration, unexpected requirements, and do a lot of behavior you should worry about.

Now, how compilers or languages related to this? Actually that was a big image of how can things go.

Finally compilers should approve what is pure because they are the only one can do.

By on 12/15/2008 12:51 PM ()

I don't think the compiler can prevent you from using 'bad' libraries unless you want the language to not allow any side effect at all(even haskell has modules that has side-effect, it only makes sure it doesn't leak outside of the IO monad).

But then what good would it be ? Without side effect, you cannot observe the result and all you did would be wasting some electricity.

By on 12/15/2008 6:01 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