RegexParsers implicits confusing my code

I'm trying to define a regex parser that ignores case, so "do" and "Do" and "DO" all match.

Why does the following object compile:

    Process inferior-scala finished
    Welcome to Scala version 2.7.2.RC3 (Java HotSpot(TM) Client VM, Java 1.6.0).
    Type in expressions to have them evaluated.
    Type :help for more information.
    scala> object MyParser {

          type Elem = Char

          def ire(s:String) : String = s.map((c:Char) => "(" + c.toUpperCase + "|" + c.toLowerCase + ")").reduceLeft(_+_)
          def tokeni(s:String) = ire(s).r

          val DO                        = tokeni("DO")
          val WHILE                     = tokeni("WHILE")
        }
    defined module MyParser,

This works as I expect:

    scala> MyParser.DO
    res0: scala.util.matching.Regex = (D|d)(O|o)

    scala> MyParser.WHILE
    res1: scala.util.matching.Regex = (W|w)(H|h)(I|i)(L|l)(E|e)

However, the following fails when I add RegexParsers:

The continue keyword

Hi,

Would it be possible to add support for the "continue" keyword? Note: there
has been discussion on a similar topic before [1]. But that dealt
with "continue" _and_ "break". From my limited knowledge it appears
that "continue" by itself should be much more straight forward to implement
than "break". We just need to jump to the position after the last operation
in the closest surrounding Unit (?)

Even if "break" is not actually supported, it might be easier to
emulate "break" when "continue" is supported. Eg,

// Java code
while (!done) {
  if (x) {
    if (y)
      break;
  }
  if (z)
    // blah blah
}

// Scala equivalent without continue / break
while (!done) {
  var yHit = false
  if (x) {
    if (y) {
      yHit = true
      done = true
    }

Actor and blocking IO calls

The arrangement:

* Master Actor which start a server on given port

* DataActor (handles, certain type, but not all, incoming requests)
  act() of DataActor looks like following. Also, there will be
  only one instance of DataActor for this app.

        loop = {
          receiveWithin(10) {
             case data: Foo => processFoo(data)
             case bar: Bar => processBar(data)
             case _ => doSomeHouseKeeping()
          }
        }
       def processFoo(data: Foo) = {
         // processing of foo usually needs another Actor, just for this session
         val fooActor = allFooActors.getOrElseUpdate(data.session,new
FooActor())
       }

* FooActor:
    loop = {
      receiveWithin(10) {
         case data: Foo => openBlockingChannelForFoo()
         case Actor.stop => stopThis()
         case _ => readFromBlockingChannel()
      }
    }
   def openBlockingChannel() = //opens a HttpURLConnection, which may block

Meeting of the BASE tomorrow night

Meeting of the LSUG tomorrow night

This may be short notice for a lot of people, but the recently dormant London Scala Users Group will be
meeting tomorrow at 7 for beers and talk just north of Oxford Circus at the Dover Castle pub. For a map,
follow this link: http://maps.google.co.uk/maps?f=q&hl=en&geocode=&q=the+dover+castle+london&sll=51.129684,1.321449&sspn=0.007474,0.023539&ie=UTF8&ei=I4MtSJC6CIW02gKYwLinDg&cd=1&cid=51519985,-146213,2836351369175925366&li=lmd&ll=51.522149,-0.142822&spn=0.02964,0.094156&z=14&iwloc=A

As always, please email me if you'd like my mobile number.

Hope to see you there.

Aaron

illegal match allowed by scalac

class file of a Symbol (compiler question)

I'm trying to get the class file that a Symbol was loaded from in a compiler 
plugin.  Specifically, inside the run method of a Phase I am doing something 
like:

for(unit <- currentRun.units; sym <- unit.depends)
  println(sym.toplevelClass.asInstanceOf[ClassSymbol].classFile)

but this always seems to print null.  From what I can tell, 
ClassSymbol.classFile is not set anywhere in the compiler.  It looks to me 
like this used to happen in ClassfileParser.parse around line 66, but was 
commented out in changeset 12705.

So, instead, I have to do something like

val name = sym.fullNameString(File.separatorChar) + 
(if(sym.hasFlag(MODULE)) "$" else "")
    println(classPath.root.find(name, false).classFile)

(as is done in DefaultDocDriver) and this works as expected but is relatively 
slow.

Should ClassSymbol.classFile work the way I think it should or am I doing 
something wrong?

Thanks,
Mark

self type is not inherited

Given that,

trait A
trait B {this: A =>}

Each time we extend B, we need to explicitly specify the self type as A:

trait C extends B {this: A =>}
trait D extends B {this: A =>}
trait E extends B {this: A =>}

Can't this repetition be avoided? Shouldn't self type of C, D and E default
to A unless explicitly specified otherwise? Currently, this gives the
following error:

trait F extends B
error: illegal inheritance; self-type F does not conform to B's selftype B
with A

Regards,
Mushtaq
--

-- 
View this message in context: http://www.nabble.com/self-type-is-not-inherited-tp19934242p19934242.html
Sent from the Scala mailing list archive at Nabble.com.

Illegal Java generics and ticket #1263

Hi all,

First of all I would like to say that I don't generally like to bring
issues to the mailing list claiming them to be of crucial importance and
that the sky is going to fall if they're not fixed. As the story goes,
if the release team listened to everyone that had similar claims there
would never be any releases. Anyway, I will do so anyway (although it
took some prodding on IRC by David MacIver ;)).

As the subject implies, my problem is with ticket #1263[1]. It has
actually been fixed in trunk[2], but it hasn't been backported to the
2.7.2 branch and I have verified that 2.7.2-rc3 does not contain the
fix. I have tested that trunk does solve the problem.

So, this is not a case of having to fix the problem, all that is needed
is a backport. It is not clear to me why it hasn't been done. Was it
just due to a lack of time, or is it considered a potentially dangerous
fix?

The reason why I think the bug is so severe is that the illegal Java
generics signatures generated by Scalac cause frameworks that rely on
reflection to analyse methods to die with a
java.lang.reflect.GenericSignatureFormatError. This is a regression from
2.7.1 and effectively means that you can't use Scala classes as
dependencies in Spring beans if you don't want to run into runtime
exceptions (that you can't even easily predict). I find this very sad
because so much work has been done to improve Java/Scala
interoperability and this one issue makes it almost useless for some of
us and there _is_ a fix for it in trunk.

I should also probably mention that this bug causes the Eclipse compiler
to throw a NPE and basically die if you try to reference any
scala.collection.immutable.Map in your Java code, but I find that less
severe than the runtime errors and easier to workaround (although it's
pretty bad too).

Given that 2.7.2 is not out yet, I hope there's still time to backport
the fix instead of having to wait for several months for it to hit a
release (especially given that the next release is meant to be a feature
release). To be totally honest, I am not actually too concerned about
our usage because I can get our company to use a special build of Scala
(although undesirable for obvious reasons), but think about all the
people that will be trying Scala 2.7.2 now that the tooling is catching
up. Runtime errors and NPEs in the Eclipse compiler caused by illegal
bytecode (even though just in the attributes) will certainly not impress
them.

Regards,
Ismael

[1] https://lampsvn.epfl.ch/trac/scala/ticket/1263
[2] https://lampsvn.epfl.ch/trac/scala/changeset/16168

Illegal Java generics and ticket #1263

Hi all,

First of all I would like to say that I don't generally like to bring
issues to the mailing list claiming them to be of crucial importance and
that the sky is going to fall if they're not fixed. As the story goes,
if the release team listened to everyone that had similar claims there
would never be any releases. Anyway, I will do so anyway (although it
took some prodding on IRC by David MacIver ;)).

As the subject implies, my problem is with ticket #1263[1]. It has
actually been fixed in trunk[2], but it hasn't been backported to the
2.7.2 branch and I have verified that 2.7.2-rc3 does not contain the
fix. I have tested that trunk does solve the problem.

So, this is not a case of having to fix the problem, all that is needed
is a backport. It is not clear to me why it hasn't been done. Was it
just due to a lack of time, or is it considered a potentially dangerous
fix?

The reason why I think the bug is so severe is that the illegal Java
generics signatures generated by Scalac cause frameworks that rely on
reflection to analyse methods to die with a
java.lang.reflect.GenericSignatureFormatError. This is a regression from
2.7.1 and effectively means that you can't use Scala classes as
dependencies in Spring beans if you don't want to run into runtime
exceptions (that you can't even easily predict). I find this very sad
because so much work has been done to improve Java/Scala
interoperability and this one issue makes it almost useless for some of
us and there _is_ a fix for it in trunk.

I should also probably mention that this bug causes the Eclipse compiler
to throw a NPE and basically die if you try to reference any
scala.collection.immutable.Map in your Java code, but I find that less
severe than the runtime errors and easier to workaround (although it's
pretty bad too).

Given that 2.7.2 is not out yet, I hope there's still time to backport
the fix instead of having to wait for several months for it to hit a
release (especially given that the next release is meant to be a feature
release). To be totally honest, I am not actually too concerned about
our usage because I can get our company to use a special build of Scala
(although undesirable for obvious reasons), but think about all the
people that will be trying Scala 2.7.2 now that the tooling is catching
up. Runtime errors and NPEs in the Eclipse compiler caused by illegal
bytecode (even though just in the attributes) will certainly not impress
them.

Regards,
Ismael

[1] https://lampsvn.epfl.ch/trac/scala/ticket/1263
[2] https://lampsvn.epfl.ch/trac/scala/changeset/16168

Scala 2.7.2 RC3

Once again, we have a new release candidate for the next
version of Scala: version 2.7.2.RC3. In this release candidate
we fixed additional bugs, and we are now close to a final release.
A new version of the Scala plugin for Eclipse is also included:
you can update your installation via the Eclipse software update
facility. Scala 2.7.2.RC3 is available for download, as usual,
from our download page at http://www.scala-lang.org/downloads

What's new in Scala 2.7.2?

* Generic Signatures

   The Scala compiler now generates Java's generic
   signatures, so that Scala generics are visible to Java.

* Java/Scala Combined Projects
   The compiler can now parse (but not translate) Java source
   files. This makes it possible to have mixed Java/Scala
   projects with recursive dependencies between them.
   In such a project, you can submit first all the Java and Scala
   sources to the Scala compiler. In a second step, the Java
   sources are compiled using the Scala generated .class files
   and the Scala sources are compiled again using the Java
   generated .class files.

* ScalaSwing
   Another major addition is the first beta version of the
   ScalaSwing library, which is now bundled with the distribution.

* Scala Collections
   There are new implementations of collection classes, contributed
   by David MacIver: IntMap, LongMap, and TreeHashMap (immutable),
   ArrayStack and OpenHashMap (mutable).

--

-- 
The Scala Team