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

[Ben Hutchison]

On Wed, Jul 15, 2009 at 10:15 PM, martin odersky<martin.odersky@...> wrote:
> On Wed, Jul 15, 2009 at 1:54 PM, Adriaan
> Moors<adriaan.moors@...> wrote:
>> Interesting. So, do you think the inference approach for solving the
>> notational overhead of effect variables is doomed?
>>
> Type inference is no panacea. At the latest when you see the error
> messages those type variables are going to get you. Scala has gone out
> as far out as it can on that road. I think we are not able to go any
> further without seriously compromising our user base.

Well, Scala's user base seems a pretty broad church; OO people and
Functional people and hybrids thereof, pragmatists and theoreticians,
industry and researchers.

With an extensible compiler and source code annotations, its
inevitable that people will experiment with creating various
sub-dialects of Scala to scratch their particular itches, and surely
means for controlling effects will feature among these.

If an "effect system" (of some sort) isn't a standardized part of the
Scala language, I expect some future Scalans will "opt-in" by using an
augmented compiler, while others prefer a less constrained style.

If the alternatives could co-exist nicely together, this could
actually be a workable compromise, to meet a spectrum of needs from "a
better Java" through to a cutting-edge research language. Where
"co-exist nicely together" might mean:

* Effect-constraints could be layered onto existing Scala source code
by recompiling or post-processing (/not/ rewriting).
* Standard and Effect-constrained Scala can call each other without
unintended compatibility problems
* Effect-constrained Scala clients & compilers are limited in what
they can do with Standard Scala code they call,
* but Standard Scala clients are not limited in what they can do with
Effect-constrained Scala code


-Ben

[Florian Weimer]

* Ben Hutchison:

> 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.

I'm not sure if this is true.  It's pretty common to hide side effects
when the programmer feels that they do not matter.  For instance, the
getContents and readFile functions from the prelude have these types:

  getContents :: IO String
  readFile   :: FilePath -> IO String

Yet they are required to read the input lazily.  This means that
pattern matches in Haskell have undeclared side effects, and that the
language is not referentially transparent.

If the standard library intentionally violates the constraints of
Haskell's effect system, it can't be that important and practical, can
it?

> We in the Scala community would be foolish to ignore the wisdom that
> has accumulated around Haskell in the past 2 decades re: purity.

I think for full effect, you need to solve the null pointer problem
first.

[Tony Morris-4]

Florian Weimer wrote:

> * Ben Hutchison:
>
>  
>> 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.
>>    
>
> I'm not sure if this is true.  It's pretty common to hide side effects
> when the programmer feels that they do not matter.  For instance, the
> getContents and readFile functions from the prelude have these types:
>
>   getContents :: IO String
>   readFile   :: FilePath -> IO String
>
> Yet they are required to read the input lazily.  This means that
> pattern matches in Haskell have undeclared side effects, and that the
> language is not referentially transparent.
>
> If the standard library intentionally violates the constraints of
> Haskell's effect system, it can't be that important and practical, can
> it?
>  

My brain just hit the inside of my skull. Was it just me?

>  
>> We in the Scala community would be foolish to ignore the wisdom that
>> has accumulated around Haskell in the past 2 decades re: purity.
>>    
>
> I think for full effect, you need to solve the null pointer problem
> first.
>
>  

Null represents the uninhabited type. I heard someone on rentacoder
promised to solve this particular problem.

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

[Florian Weimer]

* Tony Morris:

> My brain just hit the inside of my skull. Was it just me?

Huh?

To be honest, my message was mostly a cheap shot at Haskell because
getContents et al. probably predate the IO monad.  But there's quite a
bit of Haskell code which has picked up this pattern, using pure, lazy
lists as streams, despite that producing more elements does indeed
have side effects (Data.ByteString.Lazy comes to my mind).  On the
other hand, it means many of the transformations which are valid for
pure languages (such as agressive common subexpression and dead code
elimination) change the behavior of real-world and arguably correct
Haskell programs.