Re: [Caml-list] A shallow option type

[Goswin von Brederlow <goswin-v-b@web.de>]

Gabriel Scherer <gabriel.scherer@gmail.com> writes:

> Thanks for the clearer use-case example.
>
> I think Andreas's comment is at a general level of language design:
> no, we don't want to add something close to what you're asking for in
> a language. His argumentation is spot on. What we could have is a type
> system with strong update, but that's dreaming about another language,
> not OCaml.
>
> In your case, have you considered having a private option type, that
> would be allocated by a call to a C primitive (building a genuine
> OCaml option, but outside the heap) instead of (Some foo) on the OCaml
> side? That would be completely safe, and you could still safely match
> it on the OCaml side.

I have considered that shortly. Setting the option would be simple. A
call to a C primitive that mallocs a block, fills in the GC metadata,
tag and pointer to the unit.

But what about removing the unit, setting the option to None again? At
what point would it be save to free the old option? The other thread
might be using it right now. Any kind of dynamic memory allocation will
require some coordination between the threads to free the block.

Now that I think about it again (and with what I say below for units)
there can be at most one option per tile. So I could pre-allocate an
array of them and assign each tile one option block to be reused
whenever the tile needs one.

> That said, it's only pushing the problem one step further: now you
> still need to allocate your Unit.t value outside the OCaml heap,
> otherwise you still have this problem. Is it the case in your
> application?

Yes that is the plan. The world has a fixed number of tiles and there
can be at most one unit per tile so I can pre-allocate an array of units
outside the heap large enough to never run out.

MfG
        Goswin

> On Sat, May 5, 2012 at 6:22 PM, Goswin von Brederlow <goswin-v-b@web.de> wrote:
>> Andreas Rossberg <rossberg@mpi-sws.org> writes:
>>
>>> On May 5, 2012, at 15.33 h, Goswin von Brederlow wrote:
>>>> What I want is a
>>>>
>>>>    type 'a shallow = NULL | 'a  (constraint 'a != 'b shallow)
>>>
>>> This is a form of negation, which cannot be expressed in conventional
>>> type systems. Just consider what it should mean in the presence of
>>> type abstraction: if you have
>>>
>>>   M : sig
>>>     type t
>>>     ...
>>>   end
>>>
>>> would `M.t shallow` be a legal type? You couldn't decide that properly
>>> without requiring that _every_ abstract type in every signature is
>>> annotated with a constraint saying that it is "not shallow".
>>
>> True, so abstract types would have to be forbidden too becauseit can't
>> be decided wether they are save or not. Since 'a shallow is an abstract
>> type that would also forbid 'a shallow shallow.
>>
>> So "constraint 'a != <abstract>" would be the right thing.
>>
>>>> I have some ideas on how to implement this in a module as abstract
>>>> type
>>>> providing get/set/clear functions, which basically means I map None
>>>> to a
>>>> C NULL pointer and Some x to plain x. I know x can never be the NULL
>>>> pointer, except when someone creates a 'a shallow shallow and sets
>>>> Some
>>>> None. That would turn into simply None.
>>>
>>> And how do you know that nobody else implements a _different_ type,
>>> say shallow2, that does the same thing? And a third party then
>>> constructs a value of type `int shallow2 shallow`?
>>
>> I don't and I can't. But such a type would be abstract so wouldn't be
>> allowed by the above (reject abstract types).
>>
>>> It seems to me that what you want effectively is a special case of non-
>>> disjoint union. Unfortunately, those are known to come with all kinds
>>> of problems, such as not being compositional.
>>>
>>> /Andreas
>>
>> What I want is to have an array of
>>
>>    type t ={ ... }  (* Unit.t *)
>>
>> and a matrix of
>>
>>    type tile = { ... mutable unit : Unit.t option; }
>>
>> that I can safely access from a C thread in parallel with ocaml without
>> having to look the runtime system or individual tiles (the array and
>> matrix would both be created outside the ocaml heap).
>>
>> The problem I have is that
>>
>>    tile.unit <- Some unit
>>
>> will allocate an option block on the heap and accessing that from C
>> while the GC runs causes a race condition.
>>
>>
>> What I don't want to do is use
>>
>>    type tile = { ... mutable unit : Unit.t; }
>>    tile.unit <- Obj.magic 0
>>
>> since then trying things out in the toplevel causes segfaults when the
>> pretty printer prints the tile.unit and it would be easy to forget to
>> compare the tile.unit to Obj.magic 0 on every use. I know my shallow
>> type is basically nothing else but it adds a level of savety to it.
>>
>> Idealy I would even love to write
>>
>>    match tile.unit with
>>      | NULL -> ()
>>      | unit -> do_something unit
>>
>> I guess some camlp4 magic could be used to transform such a match into
>>
>>    match Shallow.as_option tile.unit with
>>      | None -> ()
>>      | Some unit -> do_something unit
>>
>> or similar constructs.
>>
>> MfG
>>        Goswin
>>
>> --
>> Caml-list mailing list.  Subscription management and archives:
>> https://sympa-roc.inria.fr/wws/info/caml-list
>> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
>> Bug reports: http://caml.inria.fr/bin/caml-bugs
>>