From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail4-relais-sop.national.inria.fr (mail4-relais-sop.national.inria.fr [192.134.164.105]) by walapai.inria.fr (8.13.6/8.13.6) with ESMTP id q45HCYXT010558 for ; Sat, 5 May 2012 19:12:34 +0200 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AskBAH9epU/RVda2imdsb2JhbABFoHeRdQgiAQEBCgkNGQYjggwBAQEEEgITGQEbEgsBAwwGBQsNDSEiAREBBQEKEgYTEhCFcIFtAQMLC5tmCQOMJIJzhDcKGScDChVCiHYBBQuKdAGGHwSVfoERjVE9hA6BXA X-IronPort-AV: E=Sophos;i="4.75,536,1330902000"; d="scan'208";a="142692071" Received: from mail-ob0-f182.google.com ([209.85.214.182]) by mail4-smtp-sop.national.inria.fr with ESMTP/TLS/RC4-SHA; 05 May 2012 19:12:28 +0200 Received: by obcni5 with SMTP id ni5so9758159obc.27 for ; Sat, 05 May 2012 10:12:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=wehpZmD1QfcUGRBuUrIzNMlHMkHqAgLgItd3mhBaRSI=; b=tY1/fXBA4I53PvDVJ46FCGJ2RMWJMjQ2wVryoOIOykE7lE7G+23UiRDHnVXRUokXlc HZnHLW78mNVVWy1VW3ttVPH740N8oUG+4Hk62W4DBImAJliuRQJ5Hu97jPAg5TVRMFCk 1Cj2fkVeB7jfDEZrOTKx2KN0sOqwTjumfD/q0CVAFcx7gB4w2C2ZtOy2+Y18sSL7w9wo sfd/LKeBdDmghsBGjireEmf/5g1ilnUvkM9M9rVkFT0ilfZm2nU5f8INiHfhG/BZsn1g cJZdbLKJrr/wM29+qRsAxIsi0k83JRLt2w41IfJMRXqy8n38YIX/1cLpWWNU53UirsV2 Zl9Q== Received: by 10.50.185.161 with SMTP id fd1mr5210588igc.70.1336237946839; Sat, 05 May 2012 10:12:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.50.140.100 with HTTP; Sat, 5 May 2012 10:11:46 -0700 (PDT) In-Reply-To: <87havu4mxu.fsf@frosties.localnet> References: <87r4uykb09.fsf@frosties.localnet> <8A61AE0A-950A-4AE0-912F-2B7A233C7E8A@mpi-sws.org> <87havu4mxu.fsf@frosties.localnet> From: Gabriel Scherer Date: Sat, 5 May 2012 19:11:46 +0200 Message-ID: To: Goswin von Brederlow Cc: Andreas Rossberg , caml-list@inria.fr Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by walapai.inria.fr id q45HCYXT010558 Subject: Re: [Caml-list] A shallow option type 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. 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? On Sat, May 5, 2012 at 6:22 PM, Goswin von Brederlow wrote: > Andreas Rossberg 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 != " 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 >