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

[Ben Hutchison-2]

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

[Scot McSweeney-Roberts-6]

On Fri, Jun 26, 2009 at 15:24, Ben Hutchison <[hidden email]> wrote:

<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

For me, "better Java". So "functional purity" isn't that important (or, to be honest, needed).

[Paul Phillips-3]

See also this paper:

  Verifiable Functional Purity in Java
  http://www.eecs.berkeley.edu/~daw/papers/pure-ccs08.pdf

And:

  http://code.google.com/p/joe-e/

If you look at what they went through with joe-e you will get a taste of
how big the job is here.  Like a lot of things, it's a nice idea but who
is going to do the work?

On Fri, Jun 26, 2009 at 03:30:17PM +0100, Scot McSweeney-Roberts wrote:
> For me, "better Java". So "functional purity" isn't that important
> (or, to be honest, needed).

Are we not yet tired of building on sand? Computer software is pitifully
unreliable compared to any kind of real engineering.  Scala pushes hard
in one of the key areas for improving this situation (types) but this
one is at least as important.

--
Paul Phillips      | If this is raisin, make toast with it.
Stickler           |
Empiricist         |
pal, i pill push   |----------* http://www.improving.org/paulp/ *----------

[Daniel Sobral]

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 <[hidden email]> 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.

[Randall R Schulz-2]

On Friday June 26 2009, Ben Hutchison wrote:

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

Perfection, of course.

And as we all know, the better is the enemy of the good.

But if the upwardly compatible effects system for Scala is possible
(well, feasible), then what's the rush?

Any deployed system that lacks certification as pure (or as having its
impure portions suitably identified and segregated) is still a
functioning system. Introducing purity can be done by its creators as
deemed necessary, including not at all.

Presumably those that care about functional purity and the proper
segregation of impure code are probably pretty close with what they
write, now, and bringing their code up to verifiable conformance won't
be a big problem.

If the setting is commercial software, then those people will, if
there's true value in functionally pure code, have an advantage in the
marketplace. The manifestation of that advantage will be that more and
more software projects will be managed in such a way as to prefer or
even demand functionally pure code. This next stage of improvement in
software engineering, if it's to take place at all, will have to be
evolutionary, not revolutionary.

So again... What's the rush?

And the flip side is the question: who is willing to defer the 2.8
release to get this major addition designed and incorporated? (Unless
it was a typo where you said "... an ideally suited Effect System for
Scala is added in 2.8.0, ...")


> -Ben


Randall Schulz

[Ricky Clarkson]

Haskell's goals were not to become mainstream.

Scala cannot really be a 'better Haskell' without losing subtyping.

Scala isn't even a 'better Java', as you can't use Scala to write
libraries for Java programmers to use.  Foo$.MODULE$ is not pleasant.

Instead of siding with what Scala should be a better version of, I'd
like to suggest that Scala should be a better version of Scala.
Effect systems are genuinely useful, but hard to get right.  I hope
one of the people asking for them can work on an implementation.  I'd
be interested to see how far you could go just writing one as a
library.

2009/6/26 Daniel Sobral <[hidden email]>:

> 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 <[hidden email]>
> 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.
>

--
Ricky Clarkson
Java Programmer, AD Holdings
[phone]
Skype: ricky_clarkson
Google Talk: [hidden email]

[Ray Racine]

It can be argued that the very reason Haskell has not made in roads is precisely because of its rigorous Monadic I/O.  Haskell has been around a looong time.  Yes, it's the "most unbroken language" ever conceived by mere mortals, yet, outside of ICFP contests, few inroads.

Every time, I get re-enthused about Haskell I always stop and look at the Haskell IRC bot code, the nested monads, the triple hoops to do some sort of monadic composition, the tossing up of hands and resorting to UnsafeIO here or there...

Its an IRC bot !! and its border line incomprehensible.  Unfair?, yes.  But most enterprise business applications are nothing more than the tsunamis of data moving hither and yon all over the place.  Its all about data and I/O to a huge extent.   Monadic I/O is not "practical" (yet).    Uniqueness types, IMHO, are more amenable to the practical problems of today...

In general, I do not believe that adding Monadic I/O will enhance Scala adoption in a number of areas we'd all like to see it succeed.  But we all have different lists of what those areas are.

Ray


I, like I'm sure everyone else on this list, at one or another has played with Haskell.  A few even wrote programs

On Fri, Jun 26, 2009 at 10:24 AM, Ben Hutchison <[hidden email]> 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 Spiewak]

Actually, I disagree that Scala is unusable for writing libraries for Java consumption, you just have to be careful around things like traits and objects.  As for Scala being a "better Java" or a "better Haskell", I do agree that is the wrong approach.  It doesn't take much to be a "better Java", and I'm not even sure it's *possible* to be a "better Haskell".

The real question is: what *is* Scala?  What is it trying to be?  This is where we get into things like the merging of functional and object-oriented styles that we've all experienced in Scala, and yet can't quite define.  Scala should be aiming to become a "better Scala", that's true, but if we don't even know what it means for our language to be "Scala", what could it possibly mean for it to be a "better Scala"?

Personally, I like effect systems, but I don't think they have a place in Scala.  One of Scala's main goals from the very beginning AFAIK was Java interoperability.  As soon as you start introducing the more esoteric functional features like effect systems and Hindley-Milner type inference, you lose more and more of that compatibility.  Ricky pointed out that singleton objects are intensely painful to use from within Java.  This is just a small example of "purity over compatibility" (even if it is object-oriented rather than functional purity).  Given the trouble this causes, could you imagine what would happen if we started enforcing overloading via typeclasses rather than the current ad hoc system?

I think we need to be very careful about features like this.  I would want to see clear, demonstrable and *practical* benefits to an effect system *in Scala* before I would be convinced of its necessity.

Daniel

Ricky Clarkson wrote

Haskell's goals were not to become mainstream.

Scala cannot really be a 'better Haskell' without losing subtyping.

Scala isn't even a 'better Java', as you can't use Scala to write
libraries for Java programmers to use.  Foo$.MODULE$ is not pleasant.

Instead of siding with what Scala should be a better version of, I'd
like to suggest that Scala should be a better version of Scala.
Effect systems are genuinely useful, but hard to get right.  I hope
one of the people asking for them can work on an implementation.  I'd
be interested to see how far you could go just writing one as a
library.

[Randall R Schulz-2]

On Friday June 26 2009, Ricky Clarkson wrote:
> Haskell's goals were not to become mainstream.
>
> Scala cannot really be a 'better Haskell' without losing subtyping.
>
> Scala isn't even a 'better Java', as you can't use Scala to write
> libraries for Java programmers to use.  Foo$.MODULE$ is not pleasant.

I'd venture to suggest that Java's static imports make that manageable.
The ugliness is then confined to the import prefix of any given source
file.


> Instead of siding with what Scala should be a better version of, I'd
> like to suggest that Scala should be a better version of Scala.

I agree. It's useful to compare languages as to their relative merits
and shortcomings, but Scala is sufficiently distinct from either Java
or Haskell (and probably others with which it is meaningfully compared;
perhaps OCaml) to conceive of it as a "++" of any existing language.

Henceforth (or "going forward," in today's parlance) Scala should evolve
in terms of itself and in terms of principles of programming and
software engineering, not the specifics of other languages.


> Effect systems are genuinely useful, but hard to get right.  I hope
> one of the people asking for them can work on an implementation.  I'd
> be interested to see how far you could go just writing one as a
> library.

Or as an independent analysis and verification tool.

Surely that should at least be attempted before grafting more deeply
into the language or its compiler.


> ...


Randall Schulz

[David MacIver]

2009/6/26 Ray Racine <[hidden email]>:
> It can be argued that the very reason Haskell has not made in roads is
> precisely because of its rigorous Monadic I/O.  Haskell has been around a
> looong time.  Yes, it's the "most unbroken language" ever conceived by mere
> mortals, yet, outside of ICFP contests, few inroads.
>
> Every time, I get re-enthused about Haskell I always stop and look at the
> Haskell IRC bot code, the nested monads, the triple hoops to do some sort of
> monadic composition, the tossing up of hands and resorting to UnsafeIO here
> or there...

I think you should be careful about generalising from lambdabot to
Haskell overall. lambdabot is an acknowledged rats nest of a project -
it has a lot of contributions from various ends of the spectrum, both
newbies getting to know Haskell and excessively clever people using it
as a playground. As such it really runs the full gamut of bad Haskell
code.

That being said, I'm not particularly enthused about Haskell these
days either, so this shouldn't be taken as an endorsement, merely a
caution against overgeneralising. :-)

[Seth Tisue]

>>>>> "Ricky" == Ricky Clarkson <[hidden email]> writes:

 Ricky> Scala isn't even a 'better Java', as you can't use Scala to
 Ricky> write libraries for Java programmers to use.  Foo$.MODULE$ is
 Ricky> not pleasant.

That's fixable, though.  The ticket is
https://lampsvn.epfl.ch/trac/scala/ticket/1735
I'd include this on even a very short list of things I wish would be
addressed in 2.8.  (though as always, if wishes were beggars...)

--
Seth Tisue / http://tisue.net
lead developer, NetLogo: http://ccl.northwestern.edu/netlogo/

[Alex Cruise-2]

Ben Hutchison wrote:
> 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.
>  
I see many benefits in an effect system but I want 2.8.0 to come out in
a finite timeframe and with high quality; it's already very ambitious.

 From an "intuitive psychology of release engineering" standpoint, a
change of this magnitude sounds to me like the kind of major innovation
that a 3.0 should be built around. :)

-0xe1a

[Martin Odersky]

Effect systems are certainly a post 2.8 feature. The main person
slated to work on this is Lukas Rytz, and he was busy so far getting
the named and default arguments into 2.8.

I'd rather not talk about effects before we have progressed a bit
further, because it really would be too premature at the present
stage.

Cheers

 -- Martin


On Fri, Jun 26, 2009 at 7:20 PM, Alex Cruise<[hidden email]> wrote:

> Ben Hutchison wrote:
>>
>> 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.
>>
>
> I see many benefits in an effect system but I want 2.8.0 to come out in a
> finite timeframe and with high quality; it's already very ambitious.
>
> From an "intuitive psychology of release engineering" standpoint, a change
> of this magnitude sounds to me like the kind of major innovation that a 3.0
> should be built around. :)
>
> -0xe1a
>

[Alex Cruise-2]

martin odersky wrote:
> Effect systems are certainly a post 2.8 feature. The main person
> slated to work on this is Lukas Rytz, and he was busy so far getting
> the named and default arguments into 2.8.
>
> I'd rather not talk about effects before we have progressed a bit
> further, because it really would be too premature at the present
> stage.
Are there any papers you can point us to that might provide us with some
hints about what it might look like? :)

-0xe1a

[Tony Morris]

Daniel Sobral wrote:
> 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.
There are a lot of things -- where shall I start? Though it must be
said, I find a pure, lazy-by-default language to be most practical. The
mistakes of Haskell sit atop this.

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

[Raoul Duke]

> There are a lot of things -- where shall I start? Though it must be
> said, I find a pure, lazy-by-default language to be most practical. The
> mistakes of Haskell sit atop this.

to keep things getting ever more OT,
http://tinyurl.com/n8o5py
:-)

[Tony Morris]

I think you know by now that I've never found "I don't get it" to be a
particularly convincing argument.

Raoul Duke wrote:

>> There are a lot of things -- where shall I start? Though it must be
>> said, I find a pure, lazy-by-default language to be most practical. The
>> mistakes of Haskell sit atop this.
>>    
>
> to keep things getting ever more OT,
> http://tinyurl.com/n8o5py
> :-)
>
>  

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

[Ben Hutchison-2]

I'd like to clarify & respond to several points that have have made on
the topic.

1. I never intended to suggest an Effect System should or could be
introduced in 2.8. My hypothetical case was purely to pose the problem
that simply inventing a system is not enough. You then have to
integrate all the existing code with it, a problem I feel may worsen
with time.


2. "a better Haskell": This was a deliberately evocative/emotive
remark. The key idea is that Scala should deeply understand what
Haskell does well and right, and makes sure it incorporates those
lessons into its own design. For me, purity is perhaps the most
important of those lessons.


3. Remarks like "Haskell is not mainstream/important" et al. Haskell
is often jibed by those who know little about it. Those outside the
Haskell ecosystem have a tendency to underestimate (a) how much good
Haskell software has been written, (b) how performant Haskell is, (c)
just how much influence this language has on other languages. Do your
research, avoid slogans.


4. Purity and Java compatibility. I would assume that impure is the
Scala default, and most Java code (save for core classes like String)
would be considered impure. In this scenario, what are the Java
compatibility barriers that purity would present?

Obviously , you cant call impure Java from pure Scala, but no one
would force Scala code to be pure. Do you mean the subtyping problem I
mentioned? ( "verifiable purity must restrict subtyping; for abstract
members to be considered pure,implementers must be also.") I agree
that one's thorny.


5. "how could Haskell be better?" IMHO, a Haskell's limitation is the
lack of late binding/subtype polymorphism. You couldn't build
something plugin based like Eclipse in Haskell. Another one seems to
be a lack of support for dependent types (types that depend on values,
eg in scala "self.type"), though I know very little about this. Scala
maybe can do better in both these areas.

-Ben

[Tony Morris]

Hi Ben,

Ben Hutchison wrote:
> "how could Haskell be better?" IMHO, a Haskell's limitation is the
> lack of late binding/subtype polymorphism. You couldn't build
> something plugin based like Eclipse in Haskell.
I'd like to address this statement some time, but I shall let the thread
take its path.

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

[Ben Hutchison-2]

On Sat, Jun 27, 2009 at 10:43 AM, Ben Hutchison<[hidden email]> wrote:
> 3. Remarks like "Haskell is not mainstream/important" et al. Haskell
> is often jibed by those who know little about it. Those outside the
> Haskell ecosystem have a tendency to underestimate (a) how much good
> Haskell software has been written, (b) how performant Haskell is, (c)
> just how much influence this language has on other languages. Do your
> research, avoid slogans.

Ooops.

On a re-reading, neither Daniels nor Rays comments should have drawn
this response.

I think the above was a reflexive reaction on my part, derived from
past experiences.

-Ben