Interpreter does not handle ref properly

[BitPuffin]

This code:

def Haha(ref a as int):
    a = 28

mm as int
Haha(mm)

Compiles just fine with booc, no errors.

However, when executing code like that in the interpreter you get an error like this:

ERROR: The best overload for the method 'TestModule.Haha(int)' is not compatible with the argument list '(int)'.

[masonwheeler]

That's very strange. It looked like an obvious Ducky vs. non-Ducky issue, but I just tested it with interpreter.Ducky = false and got the same error.

I'll look at this later on today.

[BitPuffin]

@masonwheeler Do you mean that for now I can work around it by turning ducky on/off?

[masonwheeler]

No, I mean you can't work around it by turning ducky on/off. That was mostly written as a note to myself: "on the surface this looks like an obvious Ducky problem, but it actually isn't so don't bother investigating that."

[BitPuffin]

Ah yeah sorry I should have read what you said more carefully.

[masonwheeler]

The root of the problem is in CallableResolutionService.CanLoadAddress, which allows variables to be passed to a ref parameter if their Entity.EntityType is Local, Parameter or Field. Because mm was declared in the interpreter, its entity is an InterpreterEntity, with an EntityType of Custom.

Fixing this won't be easy. It'll take a bit of research first...

[BitPuffin]

Sounds to me then maybe that things that implement ITypedEntity should perhaps specify, or at least be able to specify, if they CanLoadAddress ?

[masonwheeler]

It goes deeper than that, actually.

namespace Struct_test

import System

struct Mmm:
    public mm as int

    override def ToString() as string:
        return mm.ToString()

class Hmmm:
    public mm as int

    override def ToString() as string:
        return mm.ToString()


def Haha(ref a as int):
    a = 28

mm as int
Haha(mm)
print mm

mmm as Mmm
Haha(mmm.mm)
print mmm

hmm = Hmmm()
Haha(hmm.mm)
print hmm

mmm.mm = 5
print mmm

Console.ReadKey(true)

Run this as a console app, and you get 28 3 times, followed by a 5, as expected. Run it in the interpreter, and it's a mess. The first time, with a local value, you get an error. The second time, as a field on a struct, you get 0. The third time, as a field on a class, you get 28, and the fourth time, directly assigning to a field on a local-declared struct, you still get 0. It appears that Boo.Lang.Interpreter doesn't deal well with value semantics for interpreter-declared variables.

@bamboo Would you be able to take a look at this?

[BitPuffin]

Yeah I was already aware of the third one when it's a field of a class, because we worked around the other issue I had (with object conversion to bool) that somehow worked when we put it in a class called Box[of T] that just wraps a (usually struct) value in a class and we noticed that the ref code worked when we used that as well.

But yes it makes me a little uncomfortable how the semantics differ so much in the interpreter. Makes me wonder if I'll soon need to swap it out for taking the region of text and compiling it and running or something, since all I'm doing is running a snippet of code..

Ideally though, Interpreter should share semantics with the compiler more or less exactly.

[BitPuffin]

Also experiencing problems with out parameters I think, probably related to this. Unless I'm just being stupid, as far as I can remember boo handles the "out" syntax part for you unlike C#, not that it matters, tried both.