@Pure annotation?

The scala/scala-user mailing list has a bi-weekly thread on reinventing
really crappy effect tracking systems. The current thread is in
scala-user regarding null and const.

Ian Clarke wrote:
> This seems like such an obvious idea it must have been discussed at a
> minimum.
>
> What about having a compiler-enforced @Pure annotation on methods,
> which guarantees that no state will be modified by them (neither the
> state of objects passed to them, nor any other state)?
>
> Ian.
>

Am I to take it that the current consensus among the decision makers is that such a thing would not be desirable then, or is that just your opinion?
Also, I'm having trouble identifying the thread you refer to, the last mention of "const" on that list is back in May.
Ian.

On Sun, Nov 29, 2009 at 5:48 PM, Tony Morris <tonymorris@gmail.com> wrote:

The scala/scala-user mailing list has a bi-weekly thread on reinventing
really crappy effect tracking systems. The current thread is in
scala-user regarding null and const.

Ian Clarke wrote:
> This seems like such an obvious idea it must have been discussed at a
> minimum.
>
> What about having a compiler-enforced @Pure annotation on methods,
> which guarantees that no state will be modified by them (neither the
> state of objects passed to them, nor any other state)?
>
> Ian.
>
> --
> Ian Clarke
> CEO, Uprizer Labs
> Email: ian@uprizer.com <mailto:ian@uprizer.com>
> Ph: +1 512 422 3588

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

--
Ian Clarke
CEO, Uprizer Labs
Email: ian@uprizer.com
Ph: +1 512 422 3588

Sorry, I meant more jest than anything.

The current thread in scala-user is "Cost of Option / Some of null."
They are reinventing a crappy effect-tracking system over there too.
It's a common recurrence on these mailing lists. My understanding of
effect-tracking systems is something best not displayed here, but I
admit that it is frustrating to watch others endlessly fumble around in
the dark, hence my remark.

FWIW, it has been suggested on numerous occasions to write a RealWorld
type constructor (monad) for Scalaz, but I question the merits of such
an endeavour in a language with details such as those evident in Scala.
Regardless, an annotation is definitely not the right way to do it --
encode it in the type system at the least.

Ian Clarke wrote:
> Am I to take it that the current consensus among the decision makers
> is that such a thing would not be desirable then, or is that just your
> opinion?
>
> Also, I'm having trouble identifying the thread you refer to, the last
> mention of "const" on that list is back in May.
>
> Ian.
>
> On Sun, Nov 29, 2009 at 5:48 PM, Tony Morris > wrote:
>
> The scala/scala-user mailing list has a bi-weekly thread on
> reinventing
> really crappy effect tracking systems. The current thread is in
> scala-user regarding null and const.
>
> Ian Clarke wrote:
> > This seems like such an obvious idea it must have been discussed
> at a
> > minimum.
> >
> > What about having a compiler-enforced @Pure annotation on methods,
> > which guarantees that no state will be modified by them (neither the
> > state of objects passed to them, nor any other state)?
> >
> > Ian.
> >
> > --
> > Ian Clarke
> > CEO, Uprizer Labs
> > Email: ian@uprizer.com
> >
> > Ph: +1 512 422 3588
>
> --
> Tony Morris
> http://tmorris.net/
>
>
>
>
>

Tony Morris writes:

> Regardless, an annotation is definitely not the right way to do it --
> encode it in the type system at the least.

That's what D does with its "pure functions":

http://www.digitalmars.com/d/2.0/function.html
http://www.digitalmars.com/d/2.0/faq.html#pure

Martin has mentioned the possibility of an effects system for Scala several times in the past.

As with many other good ideas for Scala, this one probably suffers from a lack of implementers. (AFAIK, no one is working on an effects system.)

--j

On Sun, Nov 29, 2009 at 3:44 PM, Ian Clarke <ian.clarke@gmail.com> wrote:

This seems like such an obvious idea it must have been discussed at a minimum.
What about having a compiler-enforced @Pure annotation on methods, which guarantees that no state will be modified by them (neither the state of objects passed to them, nor any other state)?

Ian.
--
Ian Clarke
CEO, Uprizer Labs
Email: ian@uprizer.com
Ph: +1 512 422 3588

On Sunday November 29 2009, Jorge Ortiz wrote:
> Martin has mentioned the possibility of an effects system for Scala
> several times in the past.
>
> As with many other good ideas for Scala, this one probably suffers
> from a lack of implementers. (AFAIK, no one is working on an effects
> system.)

To what extent is this a specification wanting for an implementation and
to what extent is it a research project to define what an effects
system for Scala would actually be?

> --j

Randall Schulz

I'm pretty sure it's a research project wanting for a grad student.

--j

On Sun, Nov 29, 2009 at 5:46 PM, Randall R Schulz <rschulz@sonic.net> wrote:

On Sunday November 29 2009, Jorge Ortiz wrote:
> Martin has mentioned the possibility of an effects system for Scala
> several times in the past.
>
> As with many other good ideas for Scala, this one probably suffers
> from a lack of implementers. (AFAIK, no one is working on an effects
> system.)

To what extent is this a specification wanting for an implementation and
to what extent is it a research project to define what an effects
system for Scala would actually be?


> --j


Randall Schulz

Precisely.

Steven E. Harris wrote:
> Tony Morris writes:
>
>
>> Regardless, an annotation is definitely not the right way to do it --
>> encode it in the type system at the least.
>>
>
> That's what D does with its "pure functions":
>
> http://www.digitalmars.com/d/2.0/function.html
> http://www.digitalmars.com/d/2.0/faq.html#pure
>
>

On Sun, 2009-11-29 at 17:33 -0800, Jorge Ortiz wrote:
> Martin has mentioned the possibility of an effects system for Scala
> several times in the past.
>
> As with many other good ideas for Scala, this one probably suffers
> from a lack of implementers. (AFAIK, no one is working on an effects
> system.)

https://lampsvn.epfl.ch/trac/scala/browser/compiler-plugins/immutability

Best,
Ismael

On Mon, Nov 30, 2009 at 2:48 AM, Jorge Ortiz wrote:
> I'm pretty sure it's a research project wanting for a grad student.
>
Not exactly. Lukas Rytz is working on that. Or rather, is working on
that besides a lot of other stuff, including the named and default
arguments, part of the build structure, and parts of the .Net port, to
name but a few. That's the problem of many people here; they get
sidetracked with too many different problems.

Cheers