Weird bug

[Vassil Dichev <vd...@apache.org>]

Fastest way to reproduce:

In ESME directory, invoke

mvn scala:console

Then execute the following commands ("scala>" denotes a new prompt)

scala> import org.apache.esme.model.Message
scala> val msg = Message.create
scala> if(true) msg.replyTo(1)

This should raise the following error message:

<console>:7: error: value apply is not a member of Long
       if(true) msg.replyTo(1)

The weirdest thing, though, is that this works!

scala> msg.replyTo(1)

Whatever the problem is, how could it be that a statement works fine
on its own, but doesn't even compile when it's in an "if" statement?

Sounds like a compiler bug to me.

Is anyone able to reproduce this? Any ideas- maybe David?

When I have some time to gather information and if I confirm it's a
compiler bug, I'll report to the scala lang developers.


Vassil

Re: Weird bug

[Vassil Dichev <vd...@apache.org>]

I'm bringing back this old thread to let you know that this weird bug
has been fixed. I just tried this recently and it worked:

val msg = org.apache.esme.model.Message.create
if (true) msg.replyTo(1)

In the past this used to throw off the Scala compiler, now it works.
Not sure if it was a change in Lift, or in Scala. Hopefully the
latter, as it really seemed like the compiler was doing an implicit
conversion where it was not supposed to.

Re: Weird bug

[Vassil Dichev <vd...@apache.org>]

> That's weird because the return type of an if w/o else is always Unit.
>
> You may have a little trouble simulating this without Lift as the input type
> to replyTo (the thing that the type inferencer seems to be cranky about) is
> a view bounds and then the subclass is Long (superclass trait Thing[Owner <:
> Mapper[Owner], T]{ def apply[U <% T]: Owner = ... }
> ReplyToThing[MappedMessage, Long]{ ... })

The "bug" can be experienced with any of the members extending
MappedLongForeignKey, but not MappedLong.

As seems to be the case with most complicated Scala typing puzzles,
implicits are involved. Using the -Xprint:typer debugging option, I
have confirmed that replyTo is converted to Long using MappedField's
mapToType implicit. What's really strange, though, is that this
implicit is only used when the problematic statement is at the end of
a Unit block.

> Also, this may be fixed in 2.7.4.  Once we get Lift 1.1M1 out the door this
> weekend, we're going to turn to doing a maintenance release of 1.0 by
> upgrading to 2.7.4 and patching a few bugs (e.g., there are textile parsing
> bugs.)  This issue may be fixed in 2.7.4.

Alas, it's not fixed in 2.7.4, but I don't consider it critical. I was
hoping I would understand more about Scala's typing rules,
specifically regarding implicits.

At this point it's too much time for me to delve into this, but I
wanted to share some details to anyone who's interested in debugging
this.

Vassil

Re: Weird bug

[David Pollak <fe...@gmail.com>]

On Fri, May 1, 2009 at 10:57 PM, Vassil Dichev <vd...@apache.org> wrote:

> > try:
> > if (true) msg.replyTo(1L)
>
> Doesn't work, same error. What does work is either:
>
> if (true) {msg.replyTo(1L); None}


That's weird because the return type of an if w/o else is always Unit.

You may have a little trouble simulating this without Lift as the input type
to replyTo (the thing that the type inferencer seems to be cranky about) is
a view bounds and then the subclass is Long (superclass trait Thing[Owner <:
Mapper[Owner], T]{ def apply[U <% T]: Owner = ... }
ReplyToThing[MappedMessage, Long]{ ... })

Also, this may be fixed in 2.7.4.  Once we get Lift 1.1M1 out the door this
weekend, we're going to turn to doing a maintenance release of 1.0 by
upgrading to 2.7.4 and patching a few bugs (e.g., there are textile parsing
bugs.)  This issue may be fixed in 2.7.4.

Thanks,

David


>
>
> or
>
> if (true) msg.replyTo(1L)
> else msg.replyTo(2L)
>
> So the bug must be related to figuring out the return value of the if
> statement. I'll try and simulate this without a dependency on Lift.
>



-- 
Lift, the simply functional web framework http://liftweb.net
Beginning Scala http://www.apress.com/book/view/1430219890
Follow me: http://twitter.com/dpp
Git some: http://github.com/dpp

Re: Weird bug

[Vassil Dichev <vd...@apache.org>]

> try:
> if (true) msg.replyTo(1L)

Doesn't work, same error. What does work is either:

if (true) {msg.replyTo(1L); None}

or

if (true) msg.replyTo(1L)
else msg.replyTo(2L)

So the bug must be related to figuring out the return value of the if
statement. I'll try and simulate this without a dependency on Lift.

Re: Weird bug

[David Pollak <fe...@gmail.com>]

try:
if (true) msg.replyTo(1L)



On Fri, May 1, 2009 at 2:32 PM, Vassil Dichev <vd...@apache.org> wrote:

> Fastest way to reproduce:
>
> In ESME directory, invoke
>
> mvn scala:console
>
> Then execute the following commands ("scala>" denotes a new prompt)
>
> scala> import org.apache.esme.model.Message
> scala> val msg = Message.create
> scala> if(true) msg.replyTo(1)
>
> This should raise the following error message:
>
> <console>:7: error: value apply is not a member of Long
>       if(true) msg.replyTo(1)
>
> The weirdest thing, though, is that this works!
>
> scala> msg.replyTo(1)
>
> Whatever the problem is, how could it be that a statement works fine
> on its own, but doesn't even compile when it's in an "if" statement?
>
> Sounds like a compiler bug to me.
>
> Is anyone able to reproduce this? Any ideas- maybe David?
>
> When I have some time to gather information and if I confirm it's a
> compiler bug, I'll report to the scala lang developers.
>
>
> Vassil
>



-- 
Lift, the simply functional web framework http://liftweb.net
Beginning Scala http://www.apress.com/book/view/1430219890
Follow me: http://twitter.com/dpp
Git some: http://github.com/dpp