[WIP] TRef initial commit

[cpfiffer]

This contains the initial code for the TRef object, which currently stores arbitrary indexable objects. I had a whole bunch of weird stuff in here earlier and decided it would be better to just adapt the TArray code.

Here are a couple things I'd like comments on:

• Currently TRef stores things in a Ref object, because I was having trouble getting it to consistently store updates to references. Does anyone have a feel about whether this is a good choice?
• Are there any features we can include that work across any/all data types that are missing?
• What's the use case for this kind of thing? I wasn't sure how people might use this, so it's kind of poorly optimized at the moment.

Anyways, take a look when you've got a chance and let me know what's working and what's not.

[yebai]

Thanks, @cpfiffer.

Currently TRef stores things in a Ref object, because I was having trouble getting it to consistently store updates to references. Does anyone have a feel about whether this is a good choice?

This should be fine if Ref can hold any Julia objects. @mohamed82008 Could you comment whether this is true?

Are there any features we can include that work across any/all data types that are missing?

The most important feature is already implemented, i.e. perform self-duplication when the owner task is copied.

What's the use case for this kind of thing? I wasn't sure how people might use this, so it's kind of poorly optimized at the moment.

In Turing, task copying is used to implement the resampling step (roughly correspond to forking) of particle filters and particle Gibbs. There is also a minimal example in the README.md file. The following paper might be helpful:

Paige, Brooks, and Frank Wood. "A compilation target for probabilistic programming languages." arXiv preprint arXiv:1403.0504 (2014).
http://proceedings.mlr.press/v32/paige14.pdf

[mohdibntarek]

This should be fine if Ref can hold any Julia objects. @mohamed82008 Could you comment whether this is true?

Ref can hold any Julia object yes, but using it as a field in a mutable struct and to wrap another mutable struct is redundant and actually worse for performance. There are 4 use cases for Ref that I am aware of:

1. Mutating a field in an immutable struct.
2. Sharing an immutable object and modifying it across function calls.
3. Working around the closure bug.
4. Using it with @cfunction.

I haven't read this PR so I don't know what @cpfiffer is trying to do, but somewhere at the back of my mind, I feel this whole Libtask business can be simplified further once I understand how it is used in Turing. I will take a look at this PR this weekend.

[cpfiffer]

@yebai Dictionaries are currently not well supported -- they seem to be getting hung up in the task copying process. I'm currently poking around to see what's up, but I don't think I'll have anything ready to go within the next couple days.

Commit 1b42a63 (just added) allows indexing by non-integer values. This is mostly likely not super useful at the moment until dictionaries are supported fully.

[cpfiffer]

See #16.