caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
* Bug in the module system of version 3.12.0+beta1
@ 2010-07-21 13:38 Dumitru Potop-Butucaru
  2010-07-21 14:13 ` [Caml-list] " Jeremy Yallop
  0 siblings, 1 reply; 11+ messages in thread
From: Dumitru Potop-Butucaru @ 2010-07-21 13:38 UTC (permalink / raw)
  To: caml-list

[-- Attachment #1: Type: text/plain, Size: 1745 bytes --]


Hello,

I started several days ago to use version 3.12.0+beta1
(at the suggestion of a colleague to whom I explained
what I need).

I have one main problem, which I see as a bug.
The code I want to write is the following:

module IntList = Set.Make(struct type t=int let compare x y = x-y end) ;;

module type Simple =
    sig
      type t
    end  
;;

module type Abc =
    functor (M:Simple) ->
    sig
       val x : M.t
    end
;;

module MyModule :
    sig
       include Abc(module type of IntSet)
       val y : int
    end
=
    struct
       let x = IntSet.empty
       let y = 0
    end
;;

The code gives a syntax error on the include line of the
signature of MyModule. I also tried several variants of the code,
including:
  include Abc(IntSet) instead of the rejected include
or
  module type TTT = Abc(IntSet) ;;
  ...
  include TTT

In the manual, it appears that these syntaxes are indeed not
permitted, which I think is a bug, given that converting all
module types to full module makes everything work smoothly:

module IntList =
  struct
    include Set.Make(struct
      type t = int
      let compare x y = x - y
    end)
    let zero = empty
  end
;;

module type Simple =
  sig
    type t
    val zero : t
  end
;;

module Abc (M:Simple) :
  sig
    val x : M.t
  end
=
  struct
    let x = M.zero
  end
;;

module MyModule :
    sig
      include module type of Abc(IntList)
      val y : int
    end
    =
  struct
    let x = IntList.empty
    let y = 10
  end
;;

Of course, transforming module types into modules
just for the purpose of writing "module type of "
defeats the very purpose of interfaces (this is why I
think this is a bug, not a feature). Can someone help me
(e.g., with a bugfix)?

Yours,
Dumitru



[-- Attachment #2: dumitru_potop_butucaru.vcf --]
[-- Type: text/x-vcard, Size: 301 bytes --]

begin:vcard
fn:Dumitru Potop-Butucaru
n:Potop-Butucaru;Dumitru
org:INRIA Rocquencourt;Project AOSTE
adr:;;Domaine de Voluceau, BP 105;Le Chesnay;;F-78153;France
email;internet:dumitru.potop@inria.fr
tel;work:+33-139.63.55.80
x-mozilla-html:FALSE
url:http://www.DumitruPotop.net
version:2.1
end:vcard


^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [Caml-list] Bug in the module system of version 3.12.0+beta1
  2010-07-21 13:38 Bug in the module system of version 3.12.0+beta1 Dumitru Potop-Butucaru
@ 2010-07-21 14:13 ` Jeremy Yallop
  2010-07-21 15:49   ` rossberg
  2010-07-21 18:41   ` Dumitru Potop-Butucaru
  0 siblings, 2 replies; 11+ messages in thread
From: Jeremy Yallop @ 2010-07-21 14:13 UTC (permalink / raw)
  To: dumitru.potop; +Cc: caml-list

On 21 July 2010 14:38, Dumitru Potop-Butucaru
<dumitru.potop_butucaru@inria.fr> wrote:
> module type Abc =
>   functor (M:Simple) ->
>   sig
>      val x : M.t
>   end

You're trying to treat Abc as a functor from signatures to signatures
(i.e. as a parameterised signature).  In fact, it's something quite
different: it's the *type* of a functor from structures to structures.

You can emulate a parameterised signature using a signature with some
opaque components, which are later specified using substitution.
Here's the "parametrised signature":

  module type ABC =
  sig
    module M : Simple
    val x : M.t
  end

Here's how to supply a value for M:

  module MyModule :
  sig
     include ABC with module M = IntList
     val y : int
  end
= ...

In OCaml 3.12 you can use destructive substitution instead, ensuring
that M doesn't appear in the output signature.  Note the ':=' in the
line that includes ABC:

  module MyModule :
    sig
       include ABC with module M := IntList
       val y : int
    end
  = ...


^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [Caml-list] Bug in the module system of version 3.12.0+beta1
  2010-07-21 14:13 ` [Caml-list] " Jeremy Yallop
@ 2010-07-21 15:49   ` rossberg
  2010-07-21 18:41   ` Dumitru Potop-Butucaru
  1 sibling, 0 replies; 11+ messages in thread
From: rossberg @ 2010-07-21 15:49 UTC (permalink / raw)
  To: caml-list; +Cc: dumitru.potop

"Jeremy Yallop" <yallop@gmail.com> wrote:
> On 21 July 2010 14:38, Dumitru Potop-Butucaru
> <dumitru.potop_butucaru@inria.fr> wrote:
>> module type Abc =
>>   functor (M:Simple) ->
>>   sig
>>      val x : M.t
>>   end
>
> You're trying to treat Abc as a functor from signatures to signatures
> (i.e. as a parameterised signature).  In fact, it's something quite
> different: it's the *type* of a functor from structures to structures.
>
> You can emulate a parameterised signature using a signature with some
> opaque components, which are later specified using substitution.

Or just write a functor that returns a structure containing the desired
signature. This requires no new features:

  module Abc (M:Simple) =
    struct
      module type S =
        sig
          val x : M.t
        end
    end

Use it as follows:

  module MyModule :
    sig
      include Abc(IntSet).S
      val y : int
    end = ...

/Andreas


^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [Caml-list] Bug in the module system of version 3.12.0+beta1
  2010-07-21 14:13 ` [Caml-list] " Jeremy Yallop
  2010-07-21 15:49   ` rossberg
@ 2010-07-21 18:41   ` Dumitru Potop-Butucaru
  2010-07-22  2:29     ` Alain Frisch
  2010-07-22  6:18     ` Jacques Garrigue
  1 sibling, 2 replies; 11+ messages in thread
From: Dumitru Potop-Butucaru @ 2010-07-21 18:41 UTC (permalink / raw)
  To: caml-list

[-- Attachment #1: Type: text/plain, Size: 732 bytes --]


Hello everybody,

Thanks for your help.
I now have 2 solutions that should work
(it will take a couple of days to change my **real**
project to see if it works).

However, I still did not understand this statement of
Jeremy Yallop:
>> module type Abc =
>>    functor (M:Simple) ->
>>    sig
>>       val x : M.t
>>    end
>>      
> You're trying to treat Abc as a functor from signatures to signatures
> (i.e. as a parameterised signature). In fact, it's something quite
> different: it's the *type* of a functor from structures to structures.
>    
If I understand well, what I try to do is impossible for
some deep theoretical reason. Can someone explain this
to me, or point me to a relevant paper explaining it?

Yours,
Jacky

[-- Attachment #2: dumitru_potop_butucaru.vcf --]
[-- Type: text/x-vcard, Size: 335 bytes --]

begin:vcard
fn:Dumitru Potop-Butucaru
n:Potop-Butucaru;Dumitru
org:INRIA Rocquencourt;Project AOSTE
adr:;;Domaine de Voluceau, BP 105;Le Chesnay;;F-78153;France
email;internet:dumitru.potop_butucaru@inria.fr
tel;work:+33-139.63.55.80
tel;fax:+33-139.63.51.93
x-mozilla-html:FALSE
url:http://www.DumitruPotop.net
version:2.1
end:vcard


^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [Caml-list] Bug in the module system of version 3.12.0+beta1
  2010-07-21 18:41   ` Dumitru Potop-Butucaru
@ 2010-07-22  2:29     ` Alain Frisch
  2010-07-22  6:36       ` Dumitru Potop-Butucaru
  2010-07-22  6:18     ` Jacques Garrigue
  1 sibling, 1 reply; 11+ messages in thread
From: Alain Frisch @ 2010-07-22  2:29 UTC (permalink / raw)
  To: Dumitru Potop-Butucaru; +Cc: caml-list

On 7/21/2010 8:41 PM, Dumitru Potop-Butucaru wrote:
> If I understand well, what I try to do is impossible for
> some deep theoretical reason. Can someone explain this
> to me, or point me to a relevant paper explaining it?

Turning a module type into a module is not possible in general: if the 
module type defines runtime components like values, what module would 
you produce?

Then there is a sub-category of module types that can be turned into 
module in a natural way (module type with only type, class types, module 
types, exceptions, and recursive or non-recursive modules with the same 
constraints on their components). By pure coincidence, I played a few 
months ago with the idea of adding a construction to the language that 
would turn such a module type into a module expression (I had no 
concrete motivation to do that). This is available in the 
module_of_module_type branch of the OCaml svn repository.

Alain


^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [Caml-list] Bug in the module system of version 3.12.0+beta1
  2010-07-21 18:41   ` Dumitru Potop-Butucaru
  2010-07-22  2:29     ` Alain Frisch
@ 2010-07-22  6:18     ` Jacques Garrigue
       [not found]       ` <4C47E768.4080507@inria.fr>
  2010-07-22  9:37       ` rossberg
  1 sibling, 2 replies; 11+ messages in thread
From: Jacques Garrigue @ 2010-07-22  6:18 UTC (permalink / raw)
  To: dumitru.potop_butucaru; +Cc: caml-list

From: Dumitru Potop-Butucaru <dumitru.potop_butucaru@inria.fr>
> However, I still did not understand this statement of
> Jeremy Yallop:
>>> module type Abc =
>>>    functor (M:Simple) ->
>>>    sig
>>>       val x : M.t
>>>    end
>>>      
>> You're trying to treat Abc as a functor from signatures to signatures
>> (i.e. as a parameterised signature). In fact, it's something quite
>> different: it's the *type* of a functor from structures to structures.
>>    
> If I understand well, what I try to do is impossible for
> some deep theoretical reason. Can someone explain this
> to me, or point me to a relevant paper explaining it?

I think this is not a question of impossibility, rather of
misunderstanding of the relation between modules and signatures.
A module type describes modules, it does not replace them.
In particular, in another mail you asked for the construct:

  module type MyModuleType(Param:ParamType) = sig ... end

But this just doesn't make sense. The type of a functor is not a
functor between module types. Just like the type "t1 * t2" describes
pairs of values of type t1 and t2, but it is not itself a pair of
types, but rather a product.

Note of course that one might want to play on the conceptual
similarity to write the two in the same way. Haskell does that a lot,
writing (t1,t2) for the product of the types t1 and t2. But if
you look at languages like Coq, where types are also values, this
kind of overloading seems dangerous.

Another similar misunderstanding is when you write
      include Abc(module type of IntSet)
This statement is doubly wrong: first you cannot apply a module type,
but even if Abc were a functor, it could only be applied to a module,
not a module type.
Others have explained how you can do what you intended, in two
different ways. 
The classical way is to use a real functor, returning a signature
enclosed in a module, since there is no way to return a signature
alone. There is nothing against applying functors inside signatures.
The new solution in 3.12 is to use a variant of the "with"
construct, which does exactly what you want, i.e. it turns a
signature into a "function" returning a signature.

Hope this helps,

Jacques Garrigue


^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [Caml-list] Bug in the module system of version 3.12.0+beta1
  2010-07-22  2:29     ` Alain Frisch
@ 2010-07-22  6:36       ` Dumitru Potop-Butucaru
  0 siblings, 0 replies; 11+ messages in thread
From: Dumitru Potop-Butucaru @ 2010-07-22  6:36 UTC (permalink / raw)
  To: caml-list

[-- Attachment #1: Type: text/plain, Size: 834 bytes --]

On 22/07/2010 04:29, Alain Frisch wrote:
> On 7/21/2010 8:41 PM, Dumitru Potop-Butucaru wrote:
>> If I understand well, what I try to do is impossible for
>> some deep theoretical reason. Can someone explain this
>> to me, or point me to a relevant paper explaining it?
>
> Turning a module type into a module is not possible in general: if the 
> module type defines runtime components like values, what module would 
> you produce?

I do not understand why you talk about transforming a module type
in a module. What I wanted to do is to use a functor signature as a
transformer of module types in module types (just as a functor
transforms a module into another module). Following the
definitions of the reference manual of 3.12.0+beta1, section 2.4,
doing this seems very natural, even if it is currently impossible.

Jacky Potop

[-- Attachment #2: dumitru_potop_butucaru.vcf --]
[-- Type: text/x-vcard, Size: 335 bytes --]

begin:vcard
fn:Dumitru Potop-Butucaru
n:Potop-Butucaru;Dumitru
org:INRIA Rocquencourt;Project AOSTE
adr:;;Domaine de Voluceau, BP 105;Le Chesnay;;F-78153;France
email;internet:dumitru.potop_butucaru@inria.fr
tel;work:+33-139.63.55.80
tel;fax:+33-139.63.51.93
x-mozilla-html:FALSE
url:http://www.DumitruPotop.net
version:2.1
end:vcard


^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [Caml-list] Bug in the module system of version 3.12.0+beta1
       [not found]         ` <9454F06C-C286-4A1F-8A9F-CA3B27F8E3BB@gmail.com>
@ 2010-07-22  7:07           ` Dumitru Potop-Butucaru
  0 siblings, 0 replies; 11+ messages in thread
From: Dumitru Potop-Butucaru @ 2010-07-22  7:07 UTC (permalink / raw)
  To: caml-list

[-- Attachment #1: Type: text/plain, Size: 3373 bytes --]


Ok, I got it.

Thank you all for the help,
Jacky

On 22/07/2010 08:47, Jacques Garrigue wrote:
> No, I'm saying that this kind of syntax overloading occurs in Haskell.
> However, since Haskell has no functors, you cannot do that either.
>
> Again, what you ask for is possible in ocaml, and in a particularly clean
> way in 3.12.  Namely, Jeremy Yallop's second example does exactly what you want.
> The only difference is the syntax: you write "ABC with module M := IntList"
> rather than "ABC(IntList)". Different concepts get different syntax.
>
> Jacques
>
> On 2010/07/22, at 15:38, Dumitru Potop-Butucaru wrote:
>
>    
>> So, what you say is that this way of manipulating
>> module types can be done in Haskell?
>>
>> Yours,
>> Jacky
>>
>>
>> On 22/07/2010 08:18, Jacques Garrigue wrote:
>>      
>>> From: Dumitru Potop-Butucaru<dumitru.potop_butucaru@inria.fr>
>>>
>>>        
>>>> However, I still did not understand this statement of
>>>> Jeremy Yallop:
>>>>
>>>>          
>>>>>> module type Abc =
>>>>>>     functor (M:Simple) ->
>>>>>>     sig
>>>>>>        val x : M.t
>>>>>>     end
>>>>>>
>>>>>>
>>>>>>              
>>>>> You're trying to treat Abc as a functor from signatures to signatures
>>>>> (i.e. as a parameterised signature). In fact, it's something quite
>>>>> different: it's the *type* of a functor from structures to structures.
>>>>>
>>>>>
>>>>>            
>>>> If I understand well, what I try to do is impossible for
>>>> some deep theoretical reason. Can someone explain this
>>>> to me, or point me to a relevant paper explaining it?
>>>>
>>>>          
>>> I think this is not a question of impossibility, rather of
>>> misunderstanding of the relation between modules and signatures.
>>> A module type describes modules, it does not replace them.
>>> In particular, in another mail you asked for the construct:
>>>
>>>    module type MyModuleType(Param:ParamType) = sig ... end
>>>
>>> But this just doesn't make sense. The type of a functor is not a
>>> functor between module types. Just like the type "t1 * t2" describes
>>> pairs of values of type t1 and t2, but it is not itself a pair of
>>> types, but rather a product.
>>>
>>> Note of course that one might want to play on the conceptual
>>> similarity to write the two in the same way. Haskell does that a lot,
>>> writing (t1,t2) for the product of the types t1 and t2. But if
>>> you look at languages like Coq, where types are also values, this
>>> kind of overloading seems dangerous.
>>>
>>> Another similar misunderstanding is when you write
>>>        include Abc(module type of IntSet)
>>> This statement is doubly wrong: first you cannot apply a module type,
>>> but even if Abc were a functor, it could only be applied to a module,
>>> not a module type.
>>> Others have explained how you can do what you intended, in two
>>> different ways.
>>> The classical way is to use a real functor, returning a signature
>>> enclosed in a module, since there is no way to return a signature
>>> alone. There is nothing against applying functors inside signatures.
>>> The new solution in 3.12 is to use a variant of the "with"
>>> construct, which does exactly what you want, i.e. it turns a
>>> signature into a "function" returning a signature.
>>>
>>> Hope this helps,
>>>
>>> Jacques Garrigue
>>>
>>>
>>>
>>>        
>> <dumitru_potop_butucaru.vcf>
>>      
>
>
>    


[-- Attachment #2: dumitru_potop_butucaru.vcf --]
[-- Type: text/x-vcard, Size: 335 bytes --]

begin:vcard
fn:Dumitru Potop-Butucaru
n:Potop-Butucaru;Dumitru
org:INRIA Rocquencourt;Project AOSTE
adr:;;Domaine de Voluceau, BP 105;Le Chesnay;;F-78153;France
email;internet:dumitru.potop_butucaru@inria.fr
tel;work:+33-139.63.55.80
tel;fax:+33-139.63.51.93
x-mozilla-html:FALSE
url:http://www.DumitruPotop.net
version:2.1
end:vcard


^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [Caml-list] Bug in the module system of version 3.12.0+beta1
  2010-07-22  6:18     ` Jacques Garrigue
       [not found]       ` <4C47E768.4080507@inria.fr>
@ 2010-07-22  9:37       ` rossberg
  2010-07-22 10:44         ` Jacques Garrigue
  1 sibling, 1 reply; 11+ messages in thread
From: rossberg @ 2010-07-22  9:37 UTC (permalink / raw)
  To: Jacques Garrigue; +Cc: caml-list

"Jacques Garrigue" <garrigue@math.nagoya-u.ac.jp> wrote:
>
>   module type MyModuleType(Param:ParamType) = sig ... end
>
> But this just doesn't make sense.

Hm, I would disagree. It makes perfect sense, it just wouldn't desugar in
the way Dumitru thought it should.

/Andreas


^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [Caml-list] Bug in the module system of version 3.12.0+beta1
  2010-07-22  9:37       ` rossberg
@ 2010-07-22 10:44         ` Jacques Garrigue
  2010-07-22 12:28           ` Dumitru Potop-Butucaru
  0 siblings, 1 reply; 11+ messages in thread
From: Jacques Garrigue @ 2010-07-22 10:44 UTC (permalink / raw)
  To: rossberg; +Cc: caml-list

On 2010/07/22, at 18:37, rossberg@mpi-sws.org wrote:
> "Jacques Garrigue" <garrigue@math.nagoya-u.ac.jp> wrote:
>> 
>>  module type MyModuleType(Param:ParamType) = sig ... end
>> 
>> But this just doesn't make sense.
> 
> Hm, I would disagree. It makes perfect sense, it just wouldn't desugar in
> the way Dumitru thought it should.
> 
> /Andreas

I actually agree with you, since at some point I thought of adding this
kind of syntactic sugar for functors returning a signature.
But, seeing Dumitru's reasonning, this might well be confusing.
Anyway, I think that destructive substitution provides the same expressive
power in a more uniform way (using intra-signature dependencies).

Jacques



^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [Caml-list] Bug in the module system of version 3.12.0+beta1
  2010-07-22 10:44         ` Jacques Garrigue
@ 2010-07-22 12:28           ` Dumitru Potop-Butucaru
  0 siblings, 0 replies; 11+ messages in thread
From: Dumitru Potop-Butucaru @ 2010-07-22 12:28 UTC (permalink / raw)
  To: garrigue, caml-list

[-- Attachment #1: Type: text/plain, Size: 1274 bytes --]



I'm interested, can you give more details?
(I try to understand the language, as obviously
there are parts that are not very intuitive)

Dumitru, alias Jacky


On 22/07/2010 12:44, Jacques Garrigue wrote:
> On 2010/07/22, at 18:37, rossberg@mpi-sws.org wrote:
>    
>> "Jacques Garrigue"<garrigue@math.nagoya-u.ac.jp>  wrote:
>>      
>>>   module type MyModuleType(Param:ParamType) = sig ... end
>>>
>>> But this just doesn't make sense.
>>>        
>> Hm, I would disagree. It makes perfect sense, it just wouldn't desugar in
>> the way Dumitru thought it should.
>>
>> /Andreas
>>      
> I actually agree with you, since at some point I thought of adding this
> kind of syntactic sugar for functors returning a signature.
> But, seeing Dumitru's reasonning, this might well be confusing.
> Anyway, I think that destructive substitution provides the same expressive
> power in a more uniform way (using intra-signature dependencies).
>
> Jacques
>
>
> _______________________________________________
> Caml-list mailing list. Subscription management:
> http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list
> Archives: http://caml.inria.fr
> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
> Bug reports: http://caml.inria.fr/bin/caml-bugs
>
>
>    


[-- Attachment #2: dumitru_potop_butucaru.vcf --]
[-- Type: text/x-vcard, Size: 335 bytes --]

begin:vcard
fn:Dumitru Potop-Butucaru
n:Potop-Butucaru;Dumitru
org:INRIA Rocquencourt;Project AOSTE
adr:;;Domaine de Voluceau, BP 105;Le Chesnay;;F-78153;France
email;internet:dumitru.potop_butucaru@inria.fr
tel;work:+33-139.63.55.80
tel;fax:+33-139.63.51.93
x-mozilla-html:FALSE
url:http://www.DumitruPotop.net
version:2.1
end:vcard


^ permalink raw reply	[flat|nested] 11+ messages in thread

end of thread, other threads:[~2010-07-22 12:28 UTC | newest]

Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2010-07-21 13:38 Bug in the module system of version 3.12.0+beta1 Dumitru Potop-Butucaru
2010-07-21 14:13 ` [Caml-list] " Jeremy Yallop
2010-07-21 15:49   ` rossberg
2010-07-21 18:41   ` Dumitru Potop-Butucaru
2010-07-22  2:29     ` Alain Frisch
2010-07-22  6:36       ` Dumitru Potop-Butucaru
2010-07-22  6:18     ` Jacques Garrigue
     [not found]       ` <4C47E768.4080507@inria.fr>
     [not found]         ` <9454F06C-C286-4A1F-8A9F-CA3B27F8E3BB@gmail.com>
2010-07-22  7:07           ` Dumitru Potop-Butucaru
2010-07-22  9:37       ` rossberg
2010-07-22 10:44         ` Jacques Garrigue
2010-07-22 12:28           ` Dumitru Potop-Butucaru

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).