Combinator Parsers trait is not thread safe ?!

On Thu, Dec 09, 2010 at 02:30:40AM +0100, Alexander Efremov wrote:
> as far as I understand scala is functional / immutable language.

That's only true if we don't go beyond handwaving. It would be more
accurate to say that scala gently hints immutability would be great, but
if you're not into it scala will still consort with you.

> Taking look at Parsers:131, lastNoSuccess catches my eyes. then I see
> declaration var lastNoSuccess: ... at line 125. Then how It can be
> thread safe?

It isn't.

http://scala-programming-language.1934581.n4.nabble.com/Scala-Parsers-ar...

> Definitely I misunderstand something.

I don't think you misunderstand anything, but your expectations might be
too high. There's no mechanism in the language to keep someone from
introducing mutable state, and all the software in trunk was written by
fallible and not terribly numerous humans.

Alexander Efremov wrote:
> Nothing tells me about what I can
> use with actors and what I don't.

I feel with you. My hope is that scala in some not too distant future
gains some sort of effects system. Right now all (?) there can be done
is to document thread-safety on a case-by-case,
best-effort-but-nothing-guaranteed basis.

Brian Goetz et al. are suggesting documenting a class' thread safety
with annotations (@Immutable and @ThreadSafe or @NotThreadSafe) in their
book "Java concurrency in practice". Maybe it would be worth considering
doing this for the classes in the scala library (in the absence of an
effect system).

Kind regards
Andreas

>Brian Goetz et al. are suggesting documenting a class' thread safety with annotations (@Immutable and @ThreadSafe or >@NotThreadSafe) in their book "Java concurrency in practice". Maybe it would be worth considering doing this for the classes in >the scala library (in the absence of an effect system).

+1

-----Original Message-----
From: Andreas Flierl [mailto:andreas [at] flierl [dot] eu]
Sent: December-09-10 1:45 AM
To: Alexander Efremov
Cc: scala-user [at] listes [dot] epfl [dot] ch
Subject: Re: [scala-user] Combinator Parsers trait is not thread safe ?!

Alexander Efremov wrote:
> Nothing tells me about what I can
> use with actors and what I don't.

I feel with you. My hope is that scala in some not too distant future gains some sort of effects system. Right now all (?) there can be done is to document thread-safety on a case-by-case, best-effort-but-nothing-guaranteed basis.

Brian Goetz et al. are suggesting documenting a class' thread safety with annotations (@Immutable and @ThreadSafe or @NotThreadSafe) in their book "Java concurrency in practice". Maybe it would be worth considering doing this for the classes in the scala library (in the absence of an effect system).

Kind regards
Andreas

2010/12/9 Andreas Flierl <andreas [at] flierl [dot] eu>

Brian Goetz et al. are suggesting documenting a class' thread safety with annotations (@Immutable and @ThreadSafe or @NotThreadSafe) in their book "Java concurrency in practice". Maybe it would be worth considering doing this for the classes in the scala library (in the absence of an effect system).

+1 by me, too. Those annotations have proved to be useful in the past already.

Actually I am afraid ThreadSafe can mean different things to different people. Things can be synchronized but can yet cause race conditions and dead locks. I guess what matters is referential transparency. So an annotation of ReferentiallyTransperent can mean that the interface is intended to be though and any observable effect is rather a bug. An example is a Stream. A Stream has mutation internally (caching). The internal mutation is not intended to surface on the interface, Stream is a good candidate for ReferentiallyTransperent annotation (though I am not sure how safe the synchronisation there is). Just my 2 cents.
Sadek

On Sun, Dec 12, 2010 at 1:56 PM, Philipp Dörfler <phdoerfler [at] googlemail [dot] com> wrote:

2010/12/9 Andreas Flierl <andreas [at] flierl [dot] eu>

Brian Goetz et al. are suggesting documenting a class' thread safety with annotations (@Immutable and @ThreadSafe or @NotThreadSafe) in their book "Java concurrency in practice". Maybe it would be worth considering doing this for the classes in the scala library (in the absence of an effect system).

+1 by me, too. Those annotations have proved to be useful in the past already.

--
www.sadekdrobi.com
ʎdoɹʇuǝ