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

> It's telling that Haskell, though arguably a most perfect achievement of
> what it tried to be, has very little traction outside a few niches.
>
> As I write programs to fulfill more mundane needs I'll firmly side with "a
> better Java" against "a better Haskell" every time the two goals get in
> conflict. Case in point, I'd like an effect system, as long as it doesn't
> make getting the job done a chore -- and I might add that "the job" is
> rewritting/improving 80% of the time.
>
> Besides, I honestly don't see what's the purpose of trying to be "a better
> Haskell". What is it about Haskell that needs bettering? I ask this in all
> seriousness. To me is very clear what there is to be gained about being "a
> better Java", and that makes it possible to evaluate proposals. Without
> really knowing what's a "better Haskell", I can't do that. What Scala has to
> avoid at all costs is being a "Haskell wannabe". There's nothing to be
> gained that way.
>
> On Fri, Jun 26, 2009 at 11:24 AM, Ben Hutchison <ben@...>
> wrote:
>>
>> 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
>
>
>
> --
> Daniel C. Sobral
>
> Something I learned in academia: there are three kinds of academic reviews:
> review by name, review by reference and review by value.
>