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

[Daniel Sobral]

Oh, was that directed at me? :-)

Haskell is certainly a very important language. Anyone who has more than a passing interest in computer languages has to recognize that as a fact. I do think that it's inability to take the world by storm after all these years is somehow telling of how most of us humans think -- and an indictment of Haskell as a programming language.

Since you admit to have knee-jerk reactions, please note that I'm not claiming perfecthood for any other programming language. ;-)

As for mainstream... I guess that depends on what's your criteria. Me, I count books on the language by clueless people.

Anyway, going back to your number 2, sometimes "right" is not feasible in practice. Correctness goes a long way, but at some point we have to cross the road and address the likelyhood of comprehension of programs by ordinary human minds (or, at least, ordinary programmers minds), as well as ease of modification of said programs. I think sometimes some people take the easy way out when they just blame "those stupid programmers".

That, and, of course, performance. At the same time. At these times I'm always reminded of Haskell's Erathosthenes Sieve, and how it isn't really.

Anyway, I find Haskell a fascinating language on many respects, and if Scala can get closer to what Haskell does right without bringing in whatever it does wrong -- and without losing what Scala itself does right -- then I'm all for it.

On Fri, Jun 26, 2009 at 10:18 PM, Ben Hutchison <ben@...> wrote:

On Sat, Jun 27, 2009 at 10:43 AM, Ben Hutchison<ben@...> 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

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

[Meredith Gregory]

All,

This thread had certainly been edifying and many thanks to all posters. i have to say that before adding more complexity to the Scala type system, i would love to see it solidify and streamline a bit. There are weird relations between parametric and dependent types, for example. There are several strange cases in the parametric type semantics. We seen lots of recent reports of type unsoundness. i'd really like to see something just a bit more stable and with fewer moving parts -- or at least a more svelte body of relationships between the moving parts -- before we start adding effect systems.

That said, i think it would awesome if we could devise a way to start experimenting with new type features. i'm keen to implement some types-for-concurrency stuff, but have been finding the way in a bit steep, given the number of cycles i have to try out these experiments. My question is genuine: is the current implementation of Scala factored in a way that provides the optimal experience for those wanting to try out typing extensions that added syntactic annotations to the language and attendent checks in the compiler? If not, and understandably, this is really a minority case, could we make a sandbox branch that refactors the implementation to support this sort of activity? Would that be worthwhile?

Best wishes,

--greg

On Fri, Jun 26, 2009 at 5:43 PM, Ben Hutchison <ben@...> wrote:

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

--
L.G. Meredith
Managing Partner
Biosimilarity LLC
1219 NW 83rd St
Seattle, WA 98117

+1 206.650.3740

http://biosimilarity.blogspot.com

[Andrei Formiga]

On Fri, Jun 26, 2009 at 11:36 PM, Daniel Sobral<dcsobral@...> wrote:
>
> Haskell is certainly a very important language. Anyone who has more than a
> passing interest in computer languages has to recognize that as a fact. I do
> think that it's inability to take the world by storm after all these years
> is somehow telling of how most of us humans think -- and an indictment of
> Haskell as a programming language.

So does this mean that humans think "imperatively"? I am wary of this
kind of reasoning. It may well be, and I'm not saying that it is not,
but I'm not convinced. It may be that most humans think imperatively,
but it may also be that most programmers are used to think
imperatively, or it may be that the Haskell approach to purity is not
good, or many other things. Also, if we think about fields like
physics or mathematics, advancing the state of the art often means
taking things into quite unintuitive territory; e.g. we don't seem to
have been built to handle highly abstract thought, but it is essential
in these and other fields (computing probably included). So even if
humans really think imperatively, it may be best to go in "unnatural"
directions if they give better results.


--
[]s, Andrei Formiga

[Tony Morris-4]

Find a child and teach her algebra.

Now observe as she battles unsuccessfully with such an atrocity as:
x = x + 1

"That makes no sense!" according to my children at least.

Andrei Formiga wrote:

> On Fri, Jun 26, 2009 at 11:36 PM, Daniel Sobral<dcsobral@...> wrote:
>  
>> Haskell is certainly a very important language. Anyone who has more than a
>> passing interest in computer languages has to recognize that as a fact. I do
>> think that it's inability to take the world by storm after all these years
>> is somehow telling of how most of us humans think -- and an indictment of
>> Haskell as a programming language.
>>    
>
> So does this mean that humans think "imperatively"? I am wary of this
> kind of reasoning. It may well be, and I'm not saying that it is not,
> but I'm not convinced. It may be that most humans think imperatively,
> but it may also be that most programmers are used to think
> imperatively, or it may be that the Haskell approach to purity is not
> good, or many other things. Also, if we think about fields like
> physics or mathematics, advancing the state of the art often means
> taking things into quite unintuitive territory; e.g. we don't seem to
> have been built to handle highly abstract thought, but it is essential
> in these and other fields (computing probably included). So even if
> humans really think imperatively, it may be best to go in "unnatural"
> directions if they give better results.
>
>
>  

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

[Jesper Nordenberg]

Ben Hutchison wrote:
> 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.

Assuming an effect system where impurity is the default and any pure
methods must be explicitly marked with an annotation, the most important
  work is to tag all pure methods in the standard library. This work
will not become much bigger with time, but it will break some user code
as a pure method can only be overridden/implemented by another pure method.

Another issue is lambda expressions. Having to explicitly mark all pure
lambdas would be quite cumbersome, so the purity of such expressions
should be inferred by the compiler.

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

Well, it's not possible to annotate binary Java libraries, so there
should be a mechanism for specifying the purity signature of the methods
of a Java library in a separate file. There are a lot of pure methods in
the JRE for example.

Also, I think there would be a need for an purity escape mechanism
similar to performUnsafeIO as a last resort.

/Jesper Nordenberg

[Christos KK Loverdos]

> e.g. we don't seem to have been built to handle highly abstract  
> thought

Yep. My view as well. It seems I have always thought that the next  
step in Human Evolution is "Homo (Sapiens) Abstractus"

--
  __~O
-\ <,       Christos KK Loverdos
(*)/ (*)      http://ckkloverdos.com

[Ben Hutchison]

On Sat, Jun 27, 2009 at 12:38 PM, Meredith
Gregory<lgreg.meredith@...> wrote:
> This thread had certainly been edifying and many thanks to all posters. i
> have to say that before adding more complexity to the Scala type system, i
> would love to see it solidify and streamline a bit. There are weird
> relations between parametric and dependent types, for example. There are
> several strange cases in the parametric type semantics. We seen lots of
> recent reports of type unsoundness.

Hi Greg,

Are there any illustrative examples you can share or point to of these
type-system problems? Id be curious to learn more.

-Ben

[Ben Hutchison]

On Sat, Jun 27, 2009 at 12:36 PM, Daniel Sobral<dcsobral@...> wrote:
 I do
> think that [Haskells] inability to take the world by storm after all these years
> is somehow telling of how most of us humans think -- and an indictment of
> Haskell as a programming language.

Are we discussing a glass that's half-full or half-empty of Haskell? ;)

To me, Haskell has been, is, and will continue to be a very
successful, influential programming language, no qualifications
required. I have the impression its currently growing in popularity
(eg traffic on Haskell Cafe list). With a listing on "premier league"
table Langpop.com (unlike Scala, yet), it makes the lower rankings for
usage, and the upper ranks for discussion/influence.

> That, and, of course, performance.

Are you familiar with http://shootout.alioth.debian.org? I was
surprised when I first saw Haskell's (excellent) scores.

> Anyway, I find Haskell a fascinating language on many respects, and if Scala
> can get closer to what Haskell does right without bringing in whatever it
> does wrong -- and without losing what Scala itself does right -- then I'm
> all for it.

Good. I hope a future effects system will let you program in Scala
however you want, Imperative, Functional, Pure, Impure. I hope you can
write Scala like C if you want, or like Haskell if you want. No dogma,
just a free and expressive language.

I am one of many people that believe that functional purity is a
valuable quality. You are completely welcome to disagree and do
otherwise; many people do. IMO what we purity fans are seeking is just
some way for the Scala type system to let us verifiably identify which
pieces of code are, and are not, pure. Not /impose/ purity, nor any
particular programming style, simply /identify/ purity.

When I hinted earlier that I wanted Scala to be a "better Haskell"
rather than a "better Java", I did /not/ mean any of

- changing Scala towards a Haskell syntax,
- requiring any explicit knowledge of Monads
- phasing out of the familiar imperative style
- making Scala more abstract or harder to understand

..but I did mean that to simply improve Java was to aim too low, and
secondly to hope that Scala would strengthen its base in theoretical
computer science by acknowledging purity in the type system. Haskell
is built on a stronger theoretical basis than Java.

-Ben

[Robert Fischer]

Getting back to the original topic...

Is there a paper or six that would hint at the general direction Scala might take for an effect
system?  Someone got cite?

~~ Robert.

[Dave Griffith]

Andrei Formiga wrote:

On Fri, Jun 26, 2009 at 11:36 PM, Daniel Sobral<[e-mail]> wrote:
Also, if we think about fields like
physics or mathematics, advancing the state of the art often means
taking things into quite unintuitive territory; e.g. we don't seem to
have been built to handle highly abstract thought, but it is essential
in these and other fields (computing probably included). So even if
humans really think imperatively, it may be best to go in "unnatural"
directions if they give better results.

The percentage of the population that we have been able to teach to think as abstractly as
mathematicians or physicists do has been, to date, extremely small.  The percentage of
the population that we need to have developing software is projected to approximately
double over the next twenty years.    This means we need to either find some way to
program that doesn't require as much abstraction as being a mathematician does, or we need
to get vastly better at teaching.   Probably both.   This has little to do with the intrinsics of
programming languages, but pretty much everything to do with the direction that mainstream
programming languages are likely to take.

Bad luck, perhaps, but there it is.

[Daniel Sobral]

Imperative is out of fashion for a while now. We now do OO -- which was based on the premise humans think like that, though I think the present implementations are a bit misguided.

Nevertheless, "imperative" is how people tell other people what to do, so it shouldn't be surprising it was so popular. That we have abandoned the purely imperative style pretty much confirms your point about abstraction, IMHO, but remember that most people are fine with just four-operations arithmetics,

On Sat, Jun 27, 2009 at 3:47 AM, Andrei Formiga <andrei.formiga@...> wrote:

On Fri, Jun 26, 2009 at 11:36 PM, Daniel Sobral<dcsobral@...> wrote:
>
> Haskell is certainly a very important language. Anyone who has more than a
> passing interest in computer languages has to recognize that as a fact. I do
> think that it's inability to take the world by storm after all these years
> is somehow telling of how most of us humans think -- and an indictment of
> Haskell as a programming language.

So does this mean that humans think "imperatively"? I am wary of this
kind of reasoning. It may well be, and I'm not saying that it is not,
but I'm not convinced. It may be that most humans think imperatively,
but it may also be that most programmers are used to think
imperatively, or it may be that the Haskell approach to purity is not
good, or many other things. Also, if we think about fields like
physics or mathematics, advancing the state of the art often means
taking things into quite unintuitive territory; e.g. we don't seem to
have been built to handle highly abstract thought, but it is essential
in these and other fields (computing probably included). So even if
humans really think imperatively, it may be best to go in "unnatural"
directions if they give better results.


--
[]s, Andrei Formiga

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

[Florian Hars-3]

Ben Hutchison schrieb:
  > Are there any illustrative examples you can share or point to of these
> type-system problems? Id be curious to learn more.

Look for any thread started by Vladimir Reshetnikov over the last few weeks.

- Florian.

[Martin Odersky]

On Sat, Jun 27, 2009 at 2:50 PM, Robert
Fischer<robert.fischer@...> wrote:
> Getting back to the original topic...
>
> Is there a paper or six that would hint at the general direction Scala might
> take for an effect system?  Someone got cite?
>
No. Right now no published paper on effect systems seems to fit the
bill for us. Seems we have to do our research from scratch.

Cheers

 -- Martin

[Ben Hutchison]

On Sat, Jun 27, 2009 at 10:50 AM, Tony Morris<tonymorris@...> wrote:
> 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.
>
Hi Tony,

Now the thread's quietened down, I'd be interested to hear your
thoughts on above issue. By "address this statement", did you mean
Subtype polymorphism, or Late Binding of virtual method invocations (I
conceptually clump these two together), or building plugin-based
Haskell apps?

Do you think its practical to build plugin/OSGI -style apps in Haskell
that do lots of dynamic loading?

-Ben

[Michael Campbell-4]

Ricky Clarkson wrote:
> Haskell's goals were not to become mainstream.

I'm only partially playing semantics here, but as I don't know the history of
Haskell, I'm genuinely curious.

Are you saying it one of Haskell's goals was specifically to not become
mainstream, or that becoming mainstream simply wasn't a goal?

Michael

[Eric Willigers]

Michael Campbell wrote:
> Ricky Clarkson wrote:
>> Haskell's goals were not to become mainstream.
>
> I'm only partially playing semantics here, but as I don't know the
> history of Haskell, I'm genuinely curious.
>
> Are you saying it one of Haskell's goals was specifically to not become
> mainstream, or that becoming mainstream simply wasn't a goal?

http://research.microsoft.com/en-us/um/people/simonpj/papers/history-of-haskell/history.pdf

"We wanted a language that could be used,
among other purposes, for research into language features; in par-
ticular, we sought the freedom for anyone to extend or modify the
language, and to build and distribute an implementation."

"It should be usable as a basis for further language research."


http://www.computerworld.com.au/article/261007/-z_programming_languages_haskell?pp=10

"... Haskell has a sort of unofficial slogan: avoid success at all
costs. ... When you become too well known, or too widely used and too
successful ..., suddenly you can’t change anything anymore."

"... the fact Haskell hasn’t become a real mainstream programming
language, used by millions of developers, has allowed us to become much
more nimble, and from a research point of view, that’s great."




Note the above quotes are selective, for example I omitted "It should be
suitable for teaching, research, and applications, including building
large systems."

[Adriaan Moors-2]

> Is there a paper or six that would hint at the general direction Scala might
> take for an effect system?  Someone got cite?
>

No. Right now no published paper on effect systems seems to fit the
bill for us. Seems we have to do our research from scratch.

The closest related work I can think of is Ben Lippmeier's work on Disciple, a strict variant of Haskell that uses an effect system instead of monads. 

He's just submitted his PhD thesis:

http://cs.anu.edu.au/people/Ben.Lippmeier/project/thesis/thesis-lippmeier-sub.pdf 

Where Scala proved that OO and FP work great together, he set out to do the same for impurity <-> purity (from his conclusion):

If I were to distill this thesis into one single point, it would be that the distinction between “pure” and “impure” languages is an artificial one. As we can express information about effects and mutability directly in the type system, using a standard framework, the difference between pure and impure is no greater than the difference between Bool and Float. Effect typing, closure typing, type classing, regions, dependent kinds and projections were all invented by other, eminently clever people. I’ve spent the last while pasting them together into a pleasing collage and smoothing out the corners. Now the world seems shiny and new.

 

enjoy!

adriaan

[Martin Odersky]

Thanks for the pointer, Adriaan. Yes, that thesis is well worth
reading because it describes the state of the art well. But I think we
should also look for radically different solutions from this one.
State of the art is monads and region/effect variables. Monads suffer
from lack of polymorphism and composability whereas effect variables
suffer from notation overload. IMO neither will fly for Scala.

Cheers

 -- Martin

On Wed, Jul 15, 2009 at 11:14 AM, Adriaan
Moors<adriaan.moors@...> wrote:

>> > Is there a paper or six that would hint at the general direction Scala
>> > might
>> > take for an effect system?  Someone got cite?
>> >
>> No. Right now no published paper on effect systems seems to fit the
>> bill for us. Seems we have to do our research from scratch.
>
> The closest related work I can think of is Ben Lippmeier's work on Disciple,
> a strict variant of Haskell that uses an effect system instead of monads.
> He's just submitted his PhD thesis:
> http://cs.anu.edu.au/people/Ben.Lippmeier/project/thesis/thesis-lippmeier-sub.pdf
> Where Scala proved that OO and FP work great together, he set out to do the
> same for impurity <-> purity (from his conclusion):
>>
>> If I were to distill this thesis into one single point, it would be that
>> the distinction between “pure” and “impure” languages is an artificial one.
>> As we can express information about effects and mutability directly in the
>> type system, using a standard framework, the difference between pure and
>> impure is no greater than the difference between Bool and Float. Effect
>> typing, closure typing, type classing, regions, dependent kinds and
>> projections were all invented by other, eminently clever people. I’ve spent
>> the last while pasting them together into a pleasing collage and smoothing
>> out the corners. Now the world seems shiny and new.
>
>
>
> enjoy!
> adriaan

[Adriaan Moors-2]

Interesting. So, do you think the inference approach for solving the notational overhead of effect variables is doomed?

(I quite like the idea of unifying regions/effects/uniqueness/types/.... and distinguishing them using kinds. I wonder if a single inference algorithm, based on constraint solving, can reconstruct them in a unified way, using constraints to specify their precise semantics.  Furthermore, might region variables be hidden syntactically in Scala in the same way that we "hide" type parameters as type members? Perhaps each member could have an implicit associated region and the compiler could infer constraints on how these regions relate.  Chapter 3 of Lippmeier's thesis deals with type inference, but I haven't read it yet.)

cheers

adriaan

On Wed, Jul 15, 2009 at 12:51 PM, martin odersky <martin.odersky@...> wrote:

Thanks for the pointer, Adriaan. Yes, that thesis is well worth
reading because it describes the state of the art well. But I think we
should also look for radically different solutions from this one.
State of the art is monads and region/effect variables. Monads suffer
from lack of polymorphism and composability whereas effect variables
suffer from notation overload. IMO neither will fly for Scala.

Cheers

 -- Martin

On Wed, Jul 15, 2009 at 11:14 AM, Adriaan

Moors<adriaan.moors@...> wrote:

>> > Is there a paper or six that would hint at the general direction Scala
>> > might
>> > take for an effect system?  Someone got cite?
>> >
>> No. Right now no published paper on effect systems seems to fit the
>> bill for us. Seems we have to do our research from scratch.
>
> The closest related work I can think of is Ben Lippmeier's work on Disciple,
> a strict variant of Haskell that uses an effect system instead of monads.
> He's just submitted his PhD thesis:
> http://cs.anu.edu.au/people/Ben.Lippmeier/project/thesis/thesis-lippmeier-sub.pdf
> Where Scala proved that OO and FP work great together, he set out to do the
> same for impurity <-> purity (from his conclusion):
>>
>> If I were to distill this thesis into one single point, it would be that
>> the distinction between “pure” and “impure” languages is an artificial one.
>> As we can express information about effects and mutability directly in the
>> type system, using a standard framework, the difference between pure and
>> impure is no greater than the difference between Bool and Float. Effect
>> typing, closure typing, type classing, regions, dependent kinds and
>> projections were all invented by other, eminently clever people. I’ve spent
>> the last while pasting them together into a pleasing collage and smoothing
>> out the corners. Now the world seems shiny and new.
>
>
>
> enjoy!
> adriaan

Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm

[Martin Odersky]

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?
> (I quite like the idea of unifying regions/effects/uniqueness/types/.... and
> distinguishing them using kinds. I wonder if a single inference algorithm,
> based on constraint solving, can reconstruct them in a unified way, using
> constraints to specify their precise semantics.  Furthermore, might region
> variables be hidden syntactically in Scala in the same way that we "hide"
> type parameters as type members? Perhaps each member could have an implicit
> associated region and the compiler could infer constraints on how these
> regions relate.  Chapter 3 of Lippmeier's thesis deals with type inference,
> but I haven't read it yet.)
>

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.

Cheers

 -- Martin