Mutable state using evidence

[serkm]

Here is an alternative implementation for mutable state in the LLVM backend that should work with #244. It doesn't refer to regions by name and instead uses evidence for allocation and access.

This comes with the cost of not having direct pointers as references anymore. On the other hand it makes memory management a lot simpler.

[serkm]

@marzipankaiser I encountered an issue with boxed types while implementing this.

var x = 0
x = 1

The generated core tree for above statements looks like this:

List(Let(tmp124_139, Literal(0, Data(Int_98, Nil)))),
State(
  x_116,
  ValueVar(tmp124_139, Data(Int_98, Nil)),
  this_127,
  App(
    Member(
      BlockVar(
        x_116,
        Interface(Ref_118, List(Data(BoxedInt_82, Nil))),
        Set(this)
      ),
      put_140,
      Function(
        Nil,
        Nil,
        List(Data(Int_98, Nil)),
        Nil,
        Data(Unit_119, Nil)
      )
    ),
    Nil,
    List(Literal(1, Data(Int_98, Nil))),
    Nil
  )
)

The var declaration uses Int_98 and the access uses BoxedInt_82. This lead to usage of the wrong arena, because Ints and Objects are allocated in separate arenas.
As a workaround I hardcoded the boxed types for now (see 9bb9c1a)

[marzipankaiser]

@marzipankaiser I encountered an issue with boxed types while implementing this.

var x = 0
x = 1

The generated core tree for above statements looks like this:

List(Let(tmp124_139, Literal(0, Data(Int_98, Nil)))),
State(
  x_116,
  ValueVar(tmp124_139, Data(Int_98, Nil)),
  this_127,
  App(
    Member(
      BlockVar(
        x_116,
        Interface(Ref_118, List(Data(BoxedInt_82, Nil))),
        Set(this)
      ),
      put_140,
      Function(
        Nil,
        Nil,
        List(Data(Int_98, Nil)),
        Nil,
        Data(Unit_119, Nil)
      )
    ),
    Nil,
    List(Literal(1, Data(Int_98, Nil))),
    Nil
  )
)

The var declaration uses Int_98 and the access uses BoxedInt_82. This lead to usage of the wrong arena, because Ints and Objects are allocated in separate arenas. As a workaround I hardcoded the boxed types for now (see 9bb9c1a)

Ah, sorry, I completely forgot about answering here. In principle, it should be easy enough to fix this in PolymorphismBoxing, depending on what's the correct behavior, i.e.: should Ref[Int] be special-cased and allowed? Or should state always be boxed?

[serkm]

I special-cased references for now.
@phischu I also added support for nested handlers here.

[phischu]

Very good job!

[phischu]

I would have used keywords like alloc load store but this is fine.

[phischu]

I don't quite like this solution and would prefer storing a sharer and an eraser with each object. But ok.

[serkm]

This would become obsolete if we switch to monomorphic regions.

[phischu]

Later we could perhaps move this reallocation into its own function.

[phischu]

The %idx is for the 3 different kinds of values, right?

[serkm]

Yes, perhaps it should be renamed to %kind or something similar.

[phischu]

Nice! Higher-order functions in LLVM.

[phischu]

I forgot why the meta stack is cyclic...

[serkm]

The meta-stack isn't cyclic but first-class stacks are.
This representation saves us a few operations on PushStack/PopStack, because we only have to swap the heads of the meta-stack and the first-class stack.