Re: So is Scala going to add an Effect System... or what?

It seems that the design work on Scala 2.8.0 is done and the next few
months are will be about hammering out working, bug-free code.
Meanwhile, the closest thing to the annual Scala conference happened a
couple of weeks ago in San Fran, to a happy sounding conclusion.
Thoughts seems to be turning to "Whats next"?

So is Scala going to add an Effect System... or what?  That is, some
extension to the type system allowing functionally pure code to be
distinguished from other code that may contain side effects, state
mutation or IO. I gather that some modern effect systems can address
concerns beyond functional purity, but for me, purity is an important
one.

As most of you will know, Scala's "cousin" and (arguably) preeminent
functional language Haskell has functional purity by default and an
effect system in the form of the IO Monad. I have read or listened to
the words of a great many of the thought leaders of that community,
and are struck by the near unanimous agreement that verifiable
functional purity is Haskell's single greatest strength. We in the
Scala community would be foolish to ignore the wisdom that has
accumulated around Haskell in the past 2 decades re: purity.

The clock is ticking. Consider a hypothetical scenario where an
ideally suited Effect System for Scala is added in 2.8.0, that doesnt
break any existing Scala code. What happens to all the Scala code now
in existence? It seems we would need to presume that every line of
Scala yet written was impure until proven otherwise. I dont know how
costly in effort terms the process of approving existing code as pure
could be. Can purity checking be reliably automated by examining
code's inputs, assuming some axiomatic platform from the Scala core
and J2SE libs were first designated pure? Also, verifiable purity must
restrict subtyping; for abstract members to be considered pure,
implementers must be also. This will be disruptive, eg common traits
like Ordered.

The longer we wait, as around the globe people write more Scala code
(a rising share of it for applied/industrial use rather than
research), the more the cost and impact of introducing an effect
system increases.

I guess Martin and the team at EPFL have given this issue plenty of
thought. Its just too big and obvious to ignore. I, for one, would
like to know what the plan is.

- October 4 2008 Jesper Nordenberg's proposal for verifiable
functional purity on this list gets zero replies.
[http://www.nabble.com/Verifiable-functional-purity-td19811080.html#a19811080]

- October 20 2008, Martin writes on Daniel Spiewaks blog "As to
side-effects, I agree that they are a double-edged sword. I believe
the right way to tame them is through an effect system. Let’s see what
we can come up with." Uman queries this, no details forthcoming.
[http://www.codecommit.com/blog/scala/is-scala-not-functional-enough].

- April 2009, Christos KK Loverdos mentions a relevant paper on Effect
Systems, but no replies.
[http://www.nabble.com/-scala--Paper-on-Effect-Systems-td23254989.html#a23254989]


<poetic license>I see a fork in the road.

In one future universe, Scala pursues stability, and is very
successful, loved by pragmatists the world over as a "better Java".

In the other universe, there's some complaining as Scala keeps
evolving, but it finally learns to control its own side-effects, goes
on to integrate non-local type-inference with subtype polymorphism,
somebody writes a compiler plugin for default lazy evaluation, and is
finally recognized as a "better Haskell".

What do you aspire to?

-Ben