Dereferencing pony_actor_t* — type inference bug?

[TobiasWrigstad]

The following code:

class Main
  def main() : void
    let f = new Foo in 
      { f.run(); (); }

class Foo
  state : int
  def run() : void 
    let n = new Foo in n.state = 42

generates

../release/encorec -clang test.enc
test.pony.c:280:11: error: incomplete definition of type 'struct pony_actor_t'
  (*_tmp1).state = _tmp2;;;;;
  ~~~~~~~~^
mybigpony/release/./inc/pony/pony.h:16:16: note: forward     declaration of 'struct pony_actor_t'
typedef struct pony_actor_t pony_actor_t;
               ^

[TobiasWrigstad]

To get the fields of the current actor, use pony_get(). The emitted code should be

Foo_data tmp = pony_get()
tmp->state = tmp2; 

[EliasC]

The "bug" you're seeing is because pony actors are opaque. You are not supposed to read the fields of active objects (even less write to them) unless the reference is this. In my opinion, the bug here is that the type checker allows reading the fields of active objects at all.

[TobiasWrigstad]

Yes and no. I was thinking the same thing. OTOH, allowing reading and actor's fields seems like the performative thing to do… I am happy to disallow it for now, though.

[TobiasWrigstad]

But I also agree that I would have been a lot less surprised if the type checker had informed me of what I was doing… 

[kaeluka]

Yeah, that's one terrible error message. We're waiting on encore semantics developments here.

[EliasC]

Typechecker complains when accessing fields of active objects (that are not this) as of bd0e159

[supercooldave]

This should be a big No-no. It breaks the actor abstraction, which is the core of all things good.

Sent from my iPhone

On 23/07/2014, at 16:19, TobiasWrigstad notifications@github.com wrote:

Yes and no. I was thinking the same thing. OTOH, allowing reading and actor's fields seems like the performative thing to to… I am happy to disallow it for now, though.

—
Reply to this email directly or view it on GitHub.

Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm

[TobiasWrigstad]

This should be a big No-no. It breaks the actor abstraction, which is the core of all things good.

Not necessarily. There are cases in which this is safe,
let’s say for final fields of a ”safe capability”.

Performance first, not safety first!

[supercooldave]

Abstraction first, then performance, then safety. Otherwise, why not just use C.

On 23 Jul 2014, at 16:49, TobiasWrigstad notifications@github.com wrote:

This should be a big No-no. It breaks the actor abstraction, which is the core of all things good.

Not necessarily. There are cases in which this is safe,
let’s say for final fields of a ”safe capability”.

Performance first, not safety first!
—
Reply to this email directly or view it on GitHub.

Dave.Clarke@cs.kuleuven.be
Dept. of Computer Science
Celestijnenlaan 200A
B-3001 Heverlee
BELGIUM
Tel: +32 16 327866

Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm

[TobiasWrigstad]

Abstraction first, then performance, then safety. Otherwise, why not just use C.

Performance first, then abstract!

[supercooldave]

Abstract performance?

On 23 Jul 2014, at 16:56, TobiasWrigstad notifications@github.com wrote:

Abstraction first, then performance, then safety. Otherwise, why not just use C.

Performance first, then abstract!
—
Reply to this email directly or view it on GitHub.

Dave.Clarke@cs.kuleuven.be
Dept. of Computer Science
Celestijnenlaan 200A
B-3001 Heverlee
BELGIUM
Tel: +32 16 327866

Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm