immutability, referential transparency and third party libraries

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

There is in other languages, but not Scala - though you could write a
de facto one. Scala is not a pure functional language. Are you asking
in terms of Scala or general programming?

Ishaaq Chandy wrote:
> I've only just started to learn about monads and I'm afraid I
> haven't completely understood them yet. So forgive me if my query is
> a bit naive.
>
> So, as I currently understand it, in order to write a purely
> functional app I need to guarantee immutability/referential
> transparency. Obviously in any useful program there has to be some
> IO somewhere or else it is pretty useless and as soon as you have IO
> you lose referential transparency - that is typically why you use
> monads - (there may be other uses for them, but this is the major
> use-case) right?
>
> Ok, all well and good. However, my application does not live on an
> island. It has dependencies over which it has no control. While it
> may be functionally pure I can't ensure that its dependencies are
> equally pure as I have no control over them.
>
> So my question is this - is there a standard monad pattern that is
> used to hide away the impurity of side-effecting calls to
> dependencies? i.e. - if I have to make a call to
> SomeLibraryClassInstance.foo(bar) that I know is side-effecting then
> is there a standard monad technique that I can use to hide this
> impurity? As a further complexity assume that the bar argument in
> the call above is modified inside the call.
>
> Cheers,
> Ishaaq

- --
Tony Morris
http://tmorris.net/

S, K and I ought to be enough for anybody.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkmfqI0ACgkQmnpgrYe6r61pvgCgyQ5feeSzxgnF6FqzbBZ7FbYX
yEoAnioDziH5mBNxuvxk4nHQJc3fj+V3
=n8nr
-----END PGP SIGNATURE-----

I was asking in terms of Scala. I do realise Scala is not a pure functional language - but I was hoping that I could attempt to write my application in as functional a way as possible within the constraints of the language and the JVM.

What do you mean by "a de facto one"? I was asking for advice on a general design pattern for such situations - not necessarily an actual ready-to-use implementation - though the latter would be nice.

Ishaaq

2009/2/21 Tony Morris <tmorris@tmorris.net>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

There is in other languages, but not Scala - though you could write a
de facto one. Scala is not a pure functional language. Are you asking
in terms of Scala or general programming?

Ishaaq Chandy wrote:
> I've only just started to learn about monads and I'm afraid I
> haven't completely understood them yet. So forgive me if my query is
> a bit naive.
>
> So, as I currently understand it, in order to write a purely
> functional app I need to guarantee immutability/referential
> transparency. Obviously in any useful program there has to be some
> IO somewhere or else it is pretty useless and as soon as you have IO
> you lose referential transparency - that is typically why you use
> monads - (there may be other uses for them, but this is the major
> use-case) right?
>
> Ok, all well and good. However, my application does not live on an
> island. It has dependencies over which it has no control. While it
> may be functionally pure I can't ensure that its dependencies are
> equally pure as I have no control over them.
>
> So my question is this - is there a standard monad pattern that is
> used to hide away the impurity of side-effecting calls to
> dependencies? i.e. - if I have to make a call to
> SomeLibraryClassInstance.foo(bar) that I know is side-effecting then
> is there a standard monad technique that I can use to hide this
> impurity? As a further complexity assume that the bar argument in
> the call above is modified inside the call.
>
> Cheers,
> Ishaaq

- --
Tony Morris
http://tmorris.net/

S, K and I ought to be enough for anybody.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkmfqI0ACgkQmnpgrYe6r61pvgCgyQ5feeSzxgnF6FqzbBZ7FbYX
yEoAnioDziH5mBNxuvxk4nHQJc3fj+V3
=n8nr
-----END PGP SIGNATURE-----

I think your best bet is to make islands of purity, individual modules that don't depend on or deliver results via global mutable variables.  Then work up to continents.

2009/2/21 Ishaaq Chandy <ishaaq@gmail.com>

I've only just started to learn about monads and I'm afraid I haven't completely understood them yet. So forgive me if my query is a bit naive.

So, as I currently understand it, in order to write a purely functional app I need to guarantee immutability/referential transparency. Obviously in any useful program there has to be some IO somewhere or else it is pretty useless and as soon as you have IO you lose referential transparency - that is typically why you use monads - (there may be other uses for them, but this is the major use-case) right?

Ok, all well and good. However, my application does not live on an island. It has dependencies over which it has no control. While it may be functionally pure I can't ensure that its dependencies are equally pure as I have no control over them.

So my question is this - is there a standard monad pattern that is used to hide away the impurity of side-effecting calls to dependencies? i.e. - if I have to make a call to SomeLibraryClassInstance.foo(bar) that I know is side-effecting then is there a standard monad technique that I can use to hide this impurity? As a further complexity assume that the bar argument in the call above is modified inside the call.

Cheers,
Ishaaq

Ishaaq Chandy wrote:
> So, as I currently understand it, in order to write a purely functional
> app I need to guarantee immutability/referential transparency. Obviously
> in any useful program there has to be some IO somewhere or else it is
> pretty useless and as soon as you have IO you lose referential
> transparency - that is typically why you use monads - (there may be
> other uses for them, but this is the major use-case) right?

In Haskell you use the IO monad to handle code with side effects in a
pure way. In Scala this is not the case, side effects are the "default"
and there's no way to know if a function/method has side effects by
looking at its type.

> So my question is this - is there a standard monad pattern that is used
> to hide away the impurity of side-effecting calls to dependencies? i.e.
> - if I have to make a call to SomeLibraryClassInstance.foo(bar) that I
> know is side-effecting then is there a standard monad technique that I
> can use to hide this impurity? As a further complexity assume that the
> bar argument in the call above is modified inside the call.

In general you can't "hide" a side effecting function call in a pure
function. You can however use local state in a pure function, for
example create an array, perform some modifications on it and return it.
I suggest you read my blog post for some ideas on how functional purity
might work in Scala,
http://jnordenberg.blogspot.com/2008/10/functional-purity-in-scala.html.
Even though it's not checked by the compiler, you can use these
annotations as documentation in your code to indicate purity level.

/Jesper Nordenberg

Hmm, I am starting to wonder if there is any point in using the strict functional style when programming in Scala - especially if you depend on third party libraries in your app.

Ishaaq

2009/2/21 Jesper Nordenberg <megagurka@yahoo.com>

Ishaaq Chandy wrote:

So, as I currently understand it, in order to write a purely functional app I need to guarantee immutability/referential transparency. Obviously in any useful program there has to be some IO somewhere or else it is pretty useless and as soon as you have IO you lose referential transparency - that is typically why you use monads - (there may be other uses for them, but this is the major use-case) right?

In Haskell you use the IO monad to handle code with side effects in a pure way. In Scala this is not the case, side effects are the "default" and there's no way to know if a function/method has side effects by looking at its type.

So my question is this - is there a standard monad pattern that is used to hide away the impurity of side-effecting calls to dependencies? i.e. - if I have to make a call to SomeLibraryClassInstance.foo(bar) that I know is side-effecting then is there a standard monad technique that I can use to hide this impurity? As a further complexity assume that the bar argument in the call above is modified inside the call.

In general you can't "hide" a side effecting function call in a pure function. You can however use local state in a pure function, for example create an array, perform some modifications on it and return it. I suggest you read my blog post for some ideas on how functional purity might work in Scala, http://jnordenberg.blogspot.com/2008/10/functional-purity-in-scala.html. Even though it's not checked by the compiler, you can use these annotations as documentation in your code to indicate purity level.

/Jesper Nordenberg

On Sun, Feb 22, 2009 at 7:06 AM, Ishaaq Chandy wrote:
> Hmm, I am starting to wonder if there is any point in using the strict
> functional style when programming in Scala - especially if you depend on
> third party libraries in your app.

Pure code is easier to reason about than impure code, so you still
benefit from keeping your code as pure as possible.

Regarding your original question:

> So my question is this - is there a standard monad pattern that is used to hide away the
> impurity of side-effecting calls to dependencies? i.e. - if I have to make a call to
> SomeLibraryClassInstance.foo(bar) that I know is side-effecting then is there a standard
> monad technique that I can use to hide this impurity? As a further complexity assume that the
> bar argument in the call above is modified inside the call.

I'm too much of a Scala n00b to know if there is a standard monad
library in Scala. In general, though, you'd have to wrrap
SomeLibraryClassInstance and bar up in a monad. This basically means:

- defining some base Monad type with default impls for bind and return
- defining your concrete Monad type
- defining the two monad operations bind and return (you can inherit
these if the default implementations suit your need)
- defining whatever operations are specific to your concrete monad
type (the method foo above)

It is worth using monads for a bit to get a feel for how they work,
and to understand how to think about 'threading' state through your
program. This is useful even if you don't actual use explicit monads
in your code.

HTH,
Noel

PS: This looks good:
http://james-iry.blogspot.com/2007/09/monads-are-elephants-part-1.html

By making each function depend only on its input values, instead of on surrounding global variables, you can build up large programs from small parts more easily then when you have to inspect all the code for each function to work out what it reads from the environment (the global variables) and how it writes to the environment.

It's like the difference between def name = println("Bob") and def name = "Bob", but scaled the hell up.

For more qualified comment, see Why Functional Programming Matters by John Hughes - http://www.cs.chalmers.se/~rjmh/Papers/whyfp.html

The language doesn't have to help or force you to do FP for it to be worth doing.  Rather you might choose a language by how much it helps or forces you to do FP.

Scala helps and encourages, but doesn't force.  Forcing would be against its goal of allowing OOP, depending on your definition of OOP.

2009/2/22 Ishaaq Chandy <ishaaq@gmail.com>

Hmm, I am starting to wonder if there is any point in using the strict functional style when programming in Scala - especially if you depend on third party libraries in your app.

Ishaaq

2009/2/21 Jesper Nordenberg <megagurka@yahoo.com>

Ishaaq Chandy wrote:

So, as I currently understand it, in order to write a purely functional app I need to guarantee immutability/referential transparency. Obviously in any useful program there has to be some IO somewhere or else it is pretty useless and as soon as you have IO you lose referential transparency - that is typically why you use monads - (there may be other uses for them, but this is the major use-case) right?

In Haskell you use the IO monad to handle code with side effects in a pure way. In Scala this is not the case, side effects are the "default" and there's no way to know if a function/method has side effects by looking at its type.

So my question is this - is there a standard monad pattern that is used to hide away the impurity of side-effecting calls to dependencies? i.e. - if I have to make a call to SomeLibraryClassInstance.foo(bar) that I know is side-effecting then is there a standard monad technique that I can use to hide this impurity? As a further complexity assume that the bar argument in the call above is modified inside the call.

In general you can't "hide" a side effecting function call in a pure function. You can however use local state in a pure function, for example create an array, perform some modifications on it and return it. I suggest you read my blog post for some ideas on how functional purity might work in Scala, http://jnordenberg.blogspot.com/2008/10/functional-purity-in-scala.html. Even though it's not checked by the compiler, you can use these annotations as documentation in your code to indicate purity level.

/Jesper Nordenberg

Noel Welsh schrieb:
> I'm too much of a Scala n00b to know if there is a standard monad
> library in Scala.

Tony has something in his scalaz package
,
but then the only time I used any of Tony's code was when I fixed the scala
highlighting code in pygments and needed something to find edge cases I had
overlooked. So the code may be a bit dense for a beginner.

- Florian.

On Sun, Feb 22, 2009 at 7:06 AM, Ishaaq Chandy <ishaaq@gmail.com> wrote:

Hmm, I am starting to wonder if there is any point in using the strict functional style when programming in Scala - especially if you depend on third party libraries in your app.

There probably isn't.

My experience is that most applications have subproblems which map very well onto a mostly purely functional style. When you find those areas, it's worth writing them that way. Further it's worth taking steps to reduce use of state - in particular anything that looks like global state. But trying to write everything in a purely functional style, particularly in Scala, is often far more trouble than it's worth, so I usually end up with a fairly mutable outer layer of the application and one or two areas of mostly purely functional code inside it.

It's like everything really: Use the approach that maps best to the problem at hand. Sometimes this is mostly immutable data and purely functional code, sometimes it's ridiculously stateful code, sometimes it's a mix of both.

On Sun, Feb 22, 2009 at 6:07 AM, Noel Welsh <noelwelsh@gmail.com> wrote:

On Sun, Feb 22, 2009 at 7:06 AM, Ishaaq Chandy <ishaaq@gmail.com> wrote:
> Hmm, I am starting to wonder if there is any point in using the strict
> functional style when programming in Scala - especially if you depend on
> third party libraries in your app.

Pure code is easier to reason about than impure code, so you still
benefit from keeping your code as pure as possible.

I'll add my two cents here. These island make the general solution much nice to maintain and improve. I start a project in scala and used a lot of stateful objects, while this worked fine, the code was becoming harder to maintain and test.

 I then decided to move as much to immutable and functional approach, the resulting code is amazingly modular and I can mix complex state holding objects: like swing interfaces and transactional core processor, without worrying about breaking the code. In my case  the core processor applys functions that produces updated versions of immutable object, which are in turn save on mutable objects. Any changes to these mutable objects is pushed to the UI ( it sends the new immutable object). I'm also using actors, so I send messages asking for the changes to be done.

I summary, using immutable and functional programming in the internals of complex object is a very effective and produces a nice code. When it come to side effects, use stateful objects and imperative programming. This is a very powerful thing that Scala has, you can mix and match to make a simple solution. My recommendation is use Immutable as much as possible.

Thomas

Ishaaq,

Scaling = composition. This is true in nature, and it is true in engineering -- software engineering. The techniques identified by the functional paradigm provide a compositional means to build programs. Thus, when the techniques fit well with the other characteristics of your problem (domain), they critically support scaling and scalable software development.

The continued development of compositional techniques has considerably expanded the range of the functional paradigm. The notion of monad, for example, is one of the most powerful notions of composition devised since the axiomatic approach to symmetry via groups. It simultaneously captures design patterns underlying notions of container and notions of control, including notions of state and side-effects and other kinds of complex variation over time.

So, i would submit to you that it's not about 'pure' vs 'impure', it is about compositionality as means to support scalable design. Pure is just simplistic slogan to point in the direction of a much more powerful principle.

Best wishes,

--greg

On Sat, Feb 21, 2009 at 11:06 PM, Ishaaq Chandy <ishaaq@gmail.com> wrote:

Hmm, I am starting to wonder if there is any point in using the strict functional style when programming in Scala - especially if you depend on third party libraries in your app.

Ishaaq

2009/2/21 Jesper Nordenberg <megagurka@yahoo.com>

Ishaaq Chandy wrote:

So, as I currently understand it, in order to write a purely functional app I need to guarantee immutability/referential transparency. Obviously in any useful program there has to be some IO somewhere or else it is pretty useless and as soon as you have IO you lose referential transparency - that is typically why you use monads - (there may be other uses for them, but this is the major use-case) right?

In Haskell you use the IO monad to handle code with side effects in a pure way. In Scala this is not the case, side effects are the "default" and there's no way to know if a function/method has side effects by looking at its type.

So my question is this - is there a standard monad pattern that is used to hide away the impurity of side-effecting calls to dependencies? i.e. - if I have to make a call to SomeLibraryClassInstance.foo(bar) that I know is side-effecting then is there a standard monad technique that I can use to hide this impurity? As a further complexity assume that the bar argument in the call above is modified inside the call.

In general you can't "hide" a side effecting function call in a pure function. You can however use local state in a pure function, for example create an array, perform some modifications on it and return it. I suggest you read my blog post for some ideas on how functional purity might work in Scala, http://jnordenberg.blogspot.com/2008/10/functional-purity-in-scala.html. Even though it's not checked by the compiler, you can use these annotations as documentation in your code to indicate purity level.

/Jesper Nordenberg

--
L.G. Meredith
Managing Partner
Biosimilarity LLC
806 55th St NE
Seattle, WA 98105

+1 206.650.3740

http://biosimilarity.blogspot.com

"Scaling = composition."

Brilliant, thanks for that.

2009/2/23 Meredith Gregory <lgreg.meredith@gmail.com>

Ishaaq,

Scaling = composition. This is true in nature, and it is true in engineering -- software engineering. The techniques identified by the functional paradigm provide a compositional means to build programs. Thus, when the techniques fit well with the other characteristics of your problem (domain), they critically support scaling and scalable software development.

The continued development of compositional techniques has considerably expanded the range of the functional paradigm. The notion of monad, for example, is one of the most powerful notions of composition devised since the axiomatic approach to symmetry via groups. It simultaneously captures design patterns underlying notions of container and notions of control, including notions of state and side-effects and other kinds of complex variation over time.

So, i would submit to you that it's not about 'pure' vs 'impure', it is about compositionality as means to support scalable design. Pure is just simplistic slogan to point in the direction of a much more powerful principle.

Best wishes,

--greg

On Sat, Feb 21, 2009 at 11:06 PM, Ishaaq Chandy <ishaaq@gmail.com> wrote:

Hmm, I am starting to wonder if there is any point in using the strict functional style when programming in Scala - especially if you depend on third party libraries in your app.

Ishaaq

2009/2/21 Jesper Nordenberg <megagurka@yahoo.com>

Ishaaq Chandy wrote:

So, as I currently understand it, in order to write a purely functional app I need to guarantee immutability/referential transparency. Obviously in any useful program there has to be some IO somewhere or else it is pretty useless and as soon as you have IO you lose referential transparency - that is typically why you use monads - (there may be other uses for them, but this is the major use-case) right?

In Haskell you use the IO monad to handle code with side effects in a pure way. In Scala this is not the case, side effects are the "default" and there's no way to know if a function/method has side effects by looking at its type.

So my question is this - is there a standard monad pattern that is used to hide away the impurity of side-effecting calls to dependencies? i.e. - if I have to make a call to SomeLibraryClassInstance.foo(bar) that I know is side-effecting then is there a standard monad technique that I can use to hide this impurity? As a further complexity assume that the bar argument in the call above is modified inside the call.

In general you can't "hide" a side effecting function call in a pure function. You can however use local state in a pure function, for example create an array, perform some modifications on it and return it. I suggest you read my blog post for some ideas on how functional purity might work in Scala, http://jnordenberg.blogspot.com/2008/10/functional-purity-in-scala.html. Even though it's not checked by the compiler, you can use these annotations as documentation in your code to indicate purity level.

/Jesper Nordenberg

--
L.G. Meredith
Managing Partner
Biosimilarity LLC
806 55th St NE
Seattle, WA 98105

+1 206.650.3740

http://biosimilarity.blogspot.com

Thanks guys, you make good points. I shall continue on with my experiment. It has been a bit of a paradigm shift for me - I am so used to being able to whip up a mutable variable (mutable variable - is that a tautology?) and work with it that I find myself constantly feeling stumped when coming across a problem that would have been trivial for me to solve using the imperative style.

However, slowly, but surely I am getting there. You guys on this list have been an excellent help on my journey and I appreciate your input.

Ishaaq

2009/2/24 Ricky Clarkson <ricky.clarkson@gmail.com>

"Scaling = composition."

Brilliant, thanks for that.

2009/2/23 Meredith Gregory <lgreg.meredith@gmail.com>

Ishaaq,

Scaling = composition. This is true in nature, and it is true in engineering -- software engineering. The techniques identified by the functional paradigm provide a compositional means to build programs. Thus, when the techniques fit well with the other characteristics of your problem (domain), they critically support scaling and scalable software development.

The continued development of compositional techniques has considerably expanded the range of the functional paradigm. The notion of monad, for example, is one of the most powerful notions of composition devised since the axiomatic approach to symmetry via groups. It simultaneously captures design patterns underlying notions of container and notions of control, including notions of state and side-effects and other kinds of complex variation over time.

So, i would submit to you that it's not about 'pure' vs 'impure', it is about compositionality as means to support scalable design. Pure is just simplistic slogan to point in the direction of a much more powerful principle.

Best wishes,

--greg

On Sat, Feb 21, 2009 at 11:06 PM, Ishaaq Chandy <ishaaq@gmail.com> wrote:

Hmm, I am starting to wonder if there is any point in using the strict functional style when programming in Scala - especially if you depend on third party libraries in your app.

Ishaaq

2009/2/21 Jesper Nordenberg <megagurka@yahoo.com>

Ishaaq Chandy wrote:

So, as I currently understand it, in order to write a purely functional app I need to guarantee immutability/referential transparency. Obviously in any useful program there has to be some IO somewhere or else it is pretty useless and as soon as you have IO you lose referential transparency - that is typically why you use monads - (there may be other uses for them, but this is the major use-case) right?

In Haskell you use the IO monad to handle code with side effects in a pure way. In Scala this is not the case, side effects are the "default" and there's no way to know if a function/method has side effects by looking at its type.

So my question is this - is there a standard monad pattern that is used to hide away the impurity of side-effecting calls to dependencies? i.e. - if I have to make a call to SomeLibraryClassInstance.foo(bar) that I know is side-effecting then is there a standard monad technique that I can use to hide this impurity? As a further complexity assume that the bar argument in the call above is modified inside the call.

In general you can't "hide" a side effecting function call in a pure function. You can however use local state in a pure function, for example create an array, perform some modifications on it and return it. I suggest you read my blog post for some ideas on how functional purity might work in Scala, http://jnordenberg.blogspot.com/2008/10/functional-purity-in-scala.html. Even though it's not checked by the compiler, you can use these annotations as documentation in your code to indicate purity level.

/Jesper Nordenberg

--
L.G. Meredith
Managing Partner
Biosimilarity LLC
806 55th St NE
Seattle, WA 98105

+1 206.650.3740

http://biosimilarity.blogspot.com

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Ishaaq Chandy wrote:
> (mutable variable - is that a tautology?)
The JLS talks of "constant variables".
http://java.sun.com/docs/books/jls/third_edition/html/typesValues.html#4...

Make of that fact what you will :)

- --
Tony Morris
http://tmorris.net/

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFJozIbmnpgrYe6r60RAhH5AJ4rBDp1pldKiiFX3kdZh3B2knWQGwCeOaTL
Dq6y1ijoud5ebA4XljMrFyw=
=pqLo
-----END PGP SIGNATURE-----

Tell a mathematician about your mutable variables.

2009/2/23 Tony Morris <tmorris@tmorris.net>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



Ishaaq Chandy wrote:
> (mutable variable - is that a tautology?)
The JLS talks of "constant variables".
http://java.sun.com/docs/books/jls/third_edition/html/typesValues.html#4.12.4

Make of that fact what you will :)

- --
Tony Morris
http://tmorris.net/

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFJozIbmnpgrYe6r60RAhH5AJ4rBDp1pldKiiFX3kdZh3B2knWQGwCeOaTL
Dq6y1ijoud5ebA4XljMrFyw=
=pqLo
-----END PGP SIGNATURE-----

Remember good old grade school function definitions?  You know, like "Mr. Chandy, please graph the function f(x) = sin(2πx)  ?"

x was a variable, but could not be "mutated" in the way imperative languages allow.  Why was it a variable?  Because, unlike the constants 2 and π, x could vary.

So, no, "mutable variable" is not a tautology and "immutable variable" is not an oxymoron.


On Mon, Feb 23, 2009 at 2:19 PM, Ishaaq Chandy <ishaaq@gmail.com> wrote:

(mutable variable - is that a tautology?)