Re: [Caml-list] Private types

2008-10-30 Thread Daniel Bünzli
Le 30 oct. 08 à 21:18, David Allsopp a écrit : Shouldn't I now be able to say: string_of_int x;; I don't think so. According to the manual [1] the only thing you can do on private types is pattern match or project their fields. I doesn't mean your type can be substituted by int. Daniel

Re: [Caml-list] Private types

2008-10-30 Thread Jérémie Dimino
"David Allsopp" <[EMAIL PROTECTED]> writes: > I thought that the point of private types was that you could > deconstruct them... so values of type M.t are valid wherever an int > is used but not the converse. It should probably be ok for immutable data but not for mutable ones. One example is usi

RE: [Caml-list] Private types

2008-10-30 Thread David Allsopp
Daniel Bünzli wrote: > Le 30 oct. 08 à 21:18, David Allsopp a écrit : > > > Shouldn't I now be able to say: > > > > string_of_int x;; > > I don't think so. According to the manual [1] the only thing you can > do on private types is pattern match or project their fields. I > doesn't mean your ty

Re: [Caml-list] Private types

2008-10-30 Thread Jacques Garrigue
From: "David Allsopp" <[EMAIL PROTECTED]> > Thanks for this - although it's a link to an OCaml 3.10 manual so not > applicable here it did point me to the correct chapter in the OCaml 3.11 > manual (I'd been looking in Part I of the manual and given up). What I > should have written is > > string

Re: [Caml-list] Private types

2008-10-31 Thread Dario Teixeira
Hi, > Your intuition is correct that it would theoretically be possible to > try subtyping in place of unification in some cases. The trouble is > that thoses cases are not easy to specify (so that it would be hard > for the programmer to known when he can remove a coercion), and that > subtyping

Re: [Caml-list] Private types

2008-10-31 Thread Edgar Friendly
Jacques Garrigue wrote: > Your intuition is correct that it would theoretically be possible to > try subtyping in place of unification in some cases. The trouble is > that thoses cases are not easy to specify (so that it would be hard > for the programmer to known when he can remove a coercion),

RE: [Caml-list] Private types

2008-11-01 Thread David Allsopp
Edgar Friendly wrote: > Jacques Garrigue wrote: > > > Your intuition is correct that it would theoretically be possible to > > try subtyping in place of unification in some cases. The trouble is > > that thoses cases are not easy to specify (so that it would be hard > > for the programmer to known

Re: [Caml-list] Private types

2008-11-01 Thread Jacques Garrigue
Dear Dario, Since you use a private abbreviation, extraction from the private type must be explicit before you can do anything on its representation. So the solution is simple enough: module Mymod = struct let is_foo2 x = match (x : _ Foobar.t :> [> ]) with `A -> true | `B -> false

Re: [Caml-list] Private types

2008-11-01 Thread Jacques Garrigue
From: Edgar Friendly <[EMAIL PROTECTED]> > > So the current approach is to completely separate subtyping and type > > inference, and require coercions everywhere subtyping is needed. > > > Would it be particularly difficult to, in the cases where type [x] is > found but type [y] is expected, to t

Re: [Caml-list] Private types

2008-11-01 Thread Edgar Friendly
David Allsopp wrote: > Without the full coercion for x you'll get a type error because the type > checker infers that the type of the [if] expression is [t] from the [then] > branch and then fails to unify [> `B of int ] with [t] unless the type of > [x] is first coerced to [> t ]. If the compiler

Re: [Caml-list] Private types

2008-11-01 Thread Edgar Friendly
Jacques Garrigue wrote: > If we limit ourselves to the case where both [x] and [y] contrain no > type variables, this si not particularly difficult. However whether > they will contain type variables or not depends heavily on how the > type inference algorithm proceeds. > > If they contain type va

RE: [Caml-list] Private types

2008-11-01 Thread David Allsopp
Edgar Friendly wrote: > David Allsopp wrote: > > > Without the full coercion for x you'll get a type error because the type > > checker infers that the type of the [if] expression is [t] from the > > [then] branch and then fails to unify [> `B of int ] with [t] unless the > > type of [x] is first c

Re: [Caml-list] Private types

2008-11-02 Thread Edgar Friendly
David Allsopp wrote: > I agree that the error will still show up somewhere if there is an error - > but remember that a closed polymorphic variant type required an annotation > in the first place (in this case, the type [t] and the explicit type > annotation to use it)... so having made the explici

Re: [Caml-list] Private types in 3.11, again

2009-01-19 Thread Dario Teixeira
Hi, > So my question is how can I make the Foobar code behave as if it were > defined inside Node. Based on a previous thread [1], I'm guessing there > is a solution, but I've been unable to hit on its exact formulation. There have been no replies yet to my question, but I'm still stuck with thi

Re: [Caml-list] Private types in 3.11, again

2009-01-20 Thread Dario Teixeira
Hi again, I ditched the regular variants in favour of polymorphic variants, hoping the coercion trick described by Jacques Garrigue would help [1]. I've also simplified the formulation as much as possible. Anyway, I'm still stuck with the same problem: while function 'sprint' works alright insid

Re: [Caml-list] Private types in 3.11, again

2009-01-20 Thread Jacques Carette
Hmmm, a variant of your code may be exhibiting a bug in ocaml 3.11.0. In your signature, change the +'a t signature to type +'a t = private [< elem_t ] and remove all annotations from the definition of sprint2. Then, as defined, one gets the error message File "bug2.ml", line 26, character

Re: [Caml-list] Private types in 3.11, again

2009-01-20 Thread Dario Teixeira
Hi, > Hmmm, a variant of your code may be exhibiting a bug in ocaml 3.11.0. Thanks for the reply. I'm kind of hoping it is indeed a bug, because those are fixable and it would mean what I intend to do is feasible... Best regards, Dario Teixeira

Re: [Caml-list] Private types in 3.11, again

2009-01-21 Thread Jacques Garrigue
Hi Jacques, From: Jacques Carette > Hmmm, a variant of your code may be exhibiting a bug in ocaml 3.11.0. > > In your signature, change the +'a t signature to > type +'a t = private [< elem_t ] > and remove all annotations from the definition of sprint2. Then, as > defined, one gets the er

Re: [Caml-list] Private types in 3.11, again

2009-01-21 Thread Jacques Garrigue
From: Dario Teixeira > I ditched the regular variants in favour of polymorphic variants, hoping > the coercion trick described by Jacques Garrigue would help [1]. I've also > simplified the formulation as much as possible. Anyway, I'm still stuck > with the same problem: while function 'sprint'

Re: [Caml-list] Private types in 3.11, again

2009-01-21 Thread Jacques Garrigue
From: Dario Teixeira > > So my question is how can I make the Foobar code behave as if it were > > defined inside Node. Based on a previous thread [1], I'm guessing there > > is a solution, but I've been unable to hit on its exact formulation. > > There have been no replies yet to my question, b

Re: [Caml-list] Private types in 3.11, again

2009-01-21 Thread Dario Teixeira
Hi, Thank you very much for your help, Jacques! It's always enlightening to see an Ocaml ninja in action, though I'm still digesting the finer points of your message. Anyway, I have implemented all three solutions you suggested: a) Using a private row and PV b) Using a private abbreviation and

Re: [Caml-list] Private types in 3.11, again

2009-01-21 Thread Gabriel Kerneis
Hi, On Wed, Jan 21, 2009 at 11:11:14AM -0800, Dario Teixeira wrote: > So my question is whether it > is at all possible to emulate GADTs using only PV + phantom types, or if on > the > contrary one needs to use the object system in these cases, as exemplified by > solution c). In other words, is

Re: [Caml-list] Private types in 3.11, again

2009-01-21 Thread Jacques Garrigue
From: Dario Teixeira > Thank you very much for your help, Jacques! It's always enlightening to > see an Ocaml ninja in action, though I'm still digesting the finer points > of your message. Anyway, I have implemented all three solutions you > suggested: > > a) Using a private row and PV > b)

Re: [Caml-list] Private types in 3.11, again

2009-01-26 Thread Dario Teixeira
Hi, And once more, thanks for your very informative reply. I spent the last few days exploring these issues (there's quite some info on the Haskell wiki) and weighting in the pros/cons of each solution. I've decided for an approach similar to that taken by the Ocsigen guys. That is, acknowledge