RE: [Caml-list] recursive modules redux, & interface files

RE: [Caml-list] recursive modules redux, & interface files

[Dave Berry]

Pardon me if this is a dumb question, but what is the difference between
"include" and "open"?

-----Original Message-----
From: Markus Mottl [mailto:mottl@miss.wu-wien.ac.at]
Sent: Thursday, March 22, 2001 11:41
To: John Max Skaller
Cc: Chris Hecker; caml-list@inria.fr
Subject: Re: [Caml-list] recursive modules redux, & interface files

If you want even more hardcore moduling, you might be interested in
trying
out the new "include"-keyword for structures (my favourite new language
extension! Thanks!) with the tricks above. You can do tremendous things
with it, like overriding specific functions of modules at runtime, etc.,
with hardly any effort.

-------------------
To unsubscribe, mail caml-list-request@inria.fr.  Archives: http://caml.inria.fr

Re: [Caml-list] recursive modules redux, & interface files

[Markus Mottl]

On Thu, 22 Mar 2001, Dave Berry wrote:
> Pardon me if this is a dumb question, but what is the difference between
> "include" and "open"?

"include" reexports the definitions of the included module, whereas
"open" only makes them visible within the current module.

Regards,
Markus Mottl

-- 
Markus Mottl, mottl@miss.wu-wien.ac.at, http://miss.wu-wien.ac.at/~mottl
-------------------
To unsubscribe, mail caml-list-request@inria.fr.  Archives: http://caml.inria.fr

Re: [Caml-list] recursive modules redux, & interface files

[John Max Skaller]

Dave Berry wrote:
> 
> Pardon me if this is a dumb question, but what is the difference between
> "include" and "open"?

	Open simply changes the way lookup is done: the 'environment;
in which definitions in a module are defined. It doesn't change the
interface of the module, or define anything in the module.

	Include adds the definitions of one module as definitions
of another module, more or less saving a lot of typing.

	(* o.ml *)
	open List
	let f = map
	(* this module contains one symbol, 'f' *)

	(* i.ml *)
	include List
	let f = map
	(* this module contains 'map', as well as 'f',
 	indeed, everything in 'List' *)

	(* client.ml *)
	let _ = O.f .... (* OK *)
	let _ = O.map .. (* error *)
	let _ = I.f ... (* OK *)
	let _ = I.map .. (* OK, synonym for List.map *)

In other words, O is a client of List, whereas I is an extension
of List.

BTW: include was already available for signatures, but not open.
Is this right? Can 'open' be made available for signatures?
[This would shorten .mli files a lot, make them more readable]

-- 
John (Max) Skaller, mailto:skaller@maxtal.com.au
10/1 Toxteth Rd Glebe NSW 2037 Australia voice: 61-2-9660-0850
checkout Vyper http://Vyper.sourceforge.net
download Interscript http://Interscript.sourceforge.net
-------------------
To unsubscribe, mail caml-list-request@inria.fr.  Archives: http://caml.inria.fr

RE: [Caml-list] recursive modules redux, & interface files

[Manuel Fahndrich]

To add more fuel to this interesting conversation, I've recently come
across a nice analogy between recursive modules and the assume-guarantee
rules known from model checking. The assume-guarantee rule in model
checking allows models to be checked relatively independently. In
general, the AG rule takes on the form

	AI | B <= BI
	A | BI <= AI
    ------------------- [some side conditions]
	A | B <= AI | BI

where A and B are two processes, and we want to check that the parallel
composition A | B conforms to some interface AI | BI. In general, it is
not the case that A <= AI and B <= BI, which would lead to the result.
Instead, some amount of information about the interactions between A and
B are needed. This is expressed in the preconditions AI | B <= BI, i.e.,
we check that B composed with the interface specification of A (AI)
conforms to BI, and similarly for A. 

The side conditions depend on the particular domain being modeled. If
the models are synchronous and asynchronous logic circuits, then the
side conditions express that there cannot be any logical circularities
between module A and B, ie. mutually recursive definitions of wires that
do not involve at least one latch.

Now what does this have to do with recursive modules? May be by now this
is obvious, but let me say it anyway. In the context of recursive
modules, composition is linking, and conformance is interface checking.
If we have two modules A and B that are mutually recursive and we want
to ascribe interfaces AI and BI to these, it may be the case that we
cannot do that independently, that is we can only ascribe these
interfaces, given that we know we will link A with something conforming
to BI and link B with something conforming to AI, ie., we can use the
assume guarantee rule.
The notation AI | B <= BI then simply states that in order to verify
that B has interface BI, we also need to know the interfaces AI of
module A that will be linked with B.

What about the side conditions? It turns out that the side conditions of
an assume guarantee rule for modules is very similar to that of logical
circuits, namely, we cannot have any circular definitions of values that
do not involve a function abstraction (a delay).

	module A = struct let (x:int) = B.y end
      module B = struct let (y:int) = A.x end

contains such a circular definition, whereas 

	module A = struct let fx () = B.fy () end
      module B = struct let fy () = A.fx () end

Thus the side conditions are concerned with correct initialization. This
is of course not new, Crary and Harper have given sufficient conditions
on recursive module definitions for these properties to be true, and I
suppose Claudio Russo has similar conditions, although I haven't read
his thesis yet.

Regards,

-Manuel Fahndrich
 

-----Original Message-----
From: Xavier Leroy [mailto:Xavier.Leroy@inria.fr] 
Sent: Tuesday, March 27, 2001 1:01 AM
To: Don Syme
Cc: caml-list@inria.fr
Subject: Re: [Caml-list] recursive modules redux, & interface files

> Isn't it feasible to annotate elements of signatures with something
that
> indicates that an identifier really is bound to a value, rather than a
> module??  i.e.

You probably meant "rather than a result of an arbitrary computation".
Yes, it can be done this way, and I believe such annotations in
signatures are necessary for a full treatment of recursion between
modules (the Holy Grail :-).  However, they also pollute signatures
with "implementation details".

For more modest forms of recursion, e.g. cross-recursion between
compilation units, I was hoping this information could be propagated
behind the scene, without cluttering signatures, or just re-inferred and
checked at link-time.  This is just a vague idea.

Cheers,

- Xavier Leroy
-------------------
To unsubscribe, mail caml-list-request@inria.fr.  Archives:
http://caml.inria.fr
-------------------
To unsubscribe, mail caml-list-request@inria.fr.  Archives: http://caml.inria.fr

RE: [Caml-list] recursive modules redux, & interface files

[Don Syme]

> > Isn't it feasible to annotate elements of signatures with 
> something that
> > indicates that an identifier really is bound to a value, 
> rather than a
> > module??  i.e.
> 
> You probably meant "rather than a result of an arbitrary computation".

Yes, sorry.

> Yes, it can be done this way, and I believe such annotations in
> signatures are necessary for a full treatment of recursion between
> modules (the Holy Grail :-).  However, they also pollute signatures
> with "implementation details".

I'm not sure this "pollution" is really at that bad, is it?  Users
always have the option of _not_ revealing the extra detail, though with
the result
that they can't do cross-module recursion (or at least they don't get a
guarantee
that all the runtime dynamic checks that verify that data is initialized
before use 
succeed).  And OCaml already have "external" in interfaces, which only
gives
added performance, not extra expressive power.  Phase distinction
annotations seem
as least as useful in practice, and a whole lot simpler than the other
techniques
mentioned....  It seems a whole lot better than having users roll their
own "unsafe"
phase distinctions by hacking in "ref" indirections....  And if a
different, better
solution was found later, then, to use my suggested notation, you could
just revert 
"value" to mean the same as "expr".

Cheers,
Don
-------------------
To unsubscribe, mail caml-list-request@inria.fr.  Archives: http://caml.inria.fr

RE: [Caml-list] recursive modules redux, & interface files

[Don Syme]

> A possible approach for Caml would be to have a link-time analysis
> that detects cross-module value recursions that involve only function
> definitions, and allow these (because they are safe -- like in C!).
> Fabrice Le Fessant posted a patch to OCaml a while ago that does
> pretty much this.  I'm still hoping more general, principled solutions
> exist, but they sure are hard to design!


Isn't it feasible to annotate elements of signatures with something that
indicates that an identifier really is bound to a value, rather than a
module??  i.e.

foo.mli:

    value f : int -> int  (* must be bound to a lambda expression or an
identifier in foo.ml *)
    value x : int list (* must be bound to a cons-cell or an identifier
in foo.ml *)
    expr g : int -> int (* may be a computation *)

(The current "val" would be interpreted as "expr". "value" could also be
replaced by "const" or "val rec" or "rec" or whatever)  

I know this is revealing part of how foo.mli is implemented, but that is
really the point: allow the programmer to reveal more when necessary to
prove that things are safe.  I guess you'd have to generalize this to
functors, etc., (the subsumption relation between signatures would allow
"values" to be used as "expressions", but not vice-versa).   

Hasn't there been some work done one such "phase distinction" rules?
Was that by Harper et al.? 

However, this would not solve the problem:

    A.mli    val x : int                B.mli    val y : int
    A.ml     let x = B.y                B.ml     let y = A.x

Perhaps disallowing identifiers on the r.h.s. (as in "let rec") is the
right thing to do, even if a bit of pain when just rebinding function
values.

Cheers,
Don
-------------------
To unsubscribe, mail caml-list-request@inria.fr.  Archives: http://caml.inria.fr

Re: [Caml-list] recursive modules redux, & interface files

[Xavier Leroy]

> Isn't it feasible to annotate elements of signatures with something that
> indicates that an identifier really is bound to a value, rather than a
> module??  i.e.

You probably meant "rather than a result of an arbitrary computation".
Yes, it can be done this way, and I believe such annotations in
signatures are necessary for a full treatment of recursion between
modules (the Holy Grail :-).  However, they also pollute signatures
with "implementation details".

For more modest forms of recursion, e.g. cross-recursion between
compilation units, I was hoping this information could be propagated
behind the scene, without cluttering signatures, or just re-inferred and
checked at link-time.  This is just a vague idea.

Cheers,

- Xavier Leroy
-------------------
To unsubscribe, mail caml-list-request@inria.fr.  Archives: http://caml.inria.fr

RE: [Caml-list] recursive modules redux, & interface files

[Dave Berry]

I'd say that the module Ten would have to include a declaration of the
sub-module PLAYER.

To be honest, I don't know whether there are counter-examples to the
suggestion.  It may be unsound or impractical.  I was just following a
single line of thought; I'm sure the idea would require lots more work
before it could be adopted, or it might not work at all. 


-----Original Message-----
From: Tom Hirschowitz [mailto:Tom.Hirschowitz@inria.fr]
Sent: Friday, March 23, 2001 7:55
To: Dave Berry; caml-list@inria.fr
Subject: Re: [Caml-list] recursive modules redux, & interface files

Just curious, but how would you treat this?

module type TEN = 
  sig 
    module PLAYER : sig type t = Andre | Pete | Ivan | Cedric val name :
t -> string end
    exception Not_Ex_No1 of PLAYER.t
    type u = PLAYER.t -> PLAYER.t
  end

module Ten = 
  struct 
    includesig TEN
    ...
  end

Reject?

Friendly, 

Tom

Dave Berry a écrit :
> 
> To be more general, perhaps specifications could be interleaved with
> declarations in modules.  In addition to including entire structures,
> this would let you specify the type of a function separately from it's
> implementation:
> 
> val map: ('a -> 'b) -> 'a list -> 'b list
> let rec map f l =
>   match ...
> 
> This is one aspect I like about Haskell's syntax.  I find it clearer
> than the current:
> 
> let rec map (f: 'a -> 'b) (l: 'a list) =
>   match ...
> 
> 
> type coleur = Rouge | Vert | Bleu
> (both type and implementation exported)
> 
> type animal
> type animal = Chien | Chat | Oiseau
> (only the type is visible outside the module)
> 
> I've no idea how easy or hard it would be to incorporate this into
> either the semantics or the implementation of the language.  But from
a
> pragmatic point of view, it seems a relatively clean change.
> 
> Dave.
> 
> -----Original Message-----
> From: Hendrik Tews [mailto:tews@tcs.inf.tu-dresden.de]
> Sent: Thursday, March 22, 2001 12:03
> To: caml-list@inria.fr
> Subject: Re: [Caml-list] recursive modules redux, & interface files
> 
> What about changing
> include, such that including a signature into a structure
> includes all types and all exceptions?
> 
> -------------------
> To unsubscribe, mail caml-list-request@inria.fr.  Archives:
http://caml.inria.fr
-------------------
To unsubscribe, mail caml-list-request@inria.fr.  Archives: http://caml.inria.fr

RE: [Caml-list] recursive modules redux, & interface files

[Dave Berry]

To be more general, perhaps specifications could be interleaved with
declarations in modules.  In addition to including entire structures,
this would let you specify the type of a function separately from it's
implementation:

val map: ('a -> 'b) -> 'a list -> 'b list
let rec map f l = 
  match ...

This is one aspect I like about Haskell's syntax.  I find it clearer
than the current:

let rec map (f: 'a -> 'b) (l: 'a list) =
  match ...

I prefer Hendrik's suggestion of explicitly including a signature to the
earlier suggestion of automatically including types from a signature
constraint.  If you automatically include types from a signature
constraint, the signature stops being a constraint, and you might match
signatures that you never intended to.

I assume Hendrik is considering the case where an interface already
exists, and you're writing the implementation.  Another case is where
you're writing a module without an explicit interface, but you want to
constrain just some of the external view.  Using specifications in the
module itself might help here too:

type coleur = Rouge | Vert | Bleu
(both type and implementation exported)

type animal
type animal = Chien | Chat | Oiseau
(only the type is visible outside the module)

I've no idea how easy or hard it would be to incorporate this into
either the semantics or the implementation of the language.  But from a
pragmatic point of view, it seems a relatively clean change.

Dave.


-----Original Message-----
From: Hendrik Tews [mailto:tews@tcs.inf.tu-dresden.de]
Sent: Thursday, March 22, 2001 12:03
To: caml-list@inria.fr
Subject: Re: [Caml-list] recursive modules redux, & interface files

What about changing
include, such that including a signature into a structure
includes all types and all exceptions?

-------------------
To unsubscribe, mail caml-list-request@inria.fr.  Archives: http://caml.inria.fr

Re: [Caml-list] recursive modules redux, & interface files

[Tom Hirschowitz]

> I prefer Hendrik's suggestion of explicitly including a signature to the
> earlier suggestion of automatically including types from a signature
> constraint.  If you automatically include types from a signature
> constraint, the signature stops being a constraint, and you might match
> signatures that you never intended to.

> I assume Hendrik is considering the case where an interface already
> exists, and you're writing the implementation.  

Just curious, but how would you treat this?

module type TEN = 
  sig 
    module PLAYER : sig type t = Andre | Pete | Ivan | Cedric val name :
t -> string end
    exception Not_Ex_No1 of PLAYER.t
    type u = PLAYER.t -> PLAYER.t
  end

module Ten = 
  struct 
    includesig TEN
    ...
  end

Reject?

Friendly, 

Tom

Dave Berry a écrit :
> 
> To be more general, perhaps specifications could be interleaved with
> declarations in modules.  In addition to including entire structures,
> this would let you specify the type of a function separately from it's
> implementation:
> 
> val map: ('a -> 'b) -> 'a list -> 'b list
> let rec map f l =
>   match ...
> 
> This is one aspect I like about Haskell's syntax.  I find it clearer
> than the current:
> 
> let rec map (f: 'a -> 'b) (l: 'a list) =
>   match ...
> 
> 
> type coleur = Rouge | Vert | Bleu
> (both type and implementation exported)
> 
> type animal
> type animal = Chien | Chat | Oiseau
> (only the type is visible outside the module)
> 
> I've no idea how easy or hard it would be to incorporate this into
> either the semantics or the implementation of the language.  But from a
> pragmatic point of view, it seems a relatively clean change.
> 
> Dave.
> 
> -----Original Message-----
> From: Hendrik Tews [mailto:tews@tcs.inf.tu-dresden.de]
> Sent: Thursday, March 22, 2001 12:03
> To: caml-list@inria.fr
> Subject: Re: [Caml-list] recursive modules redux, & interface files
> 
> What about changing
> include, such that including a signature into a structure
> includes all types and all exceptions?
> 
> -------------------
> To unsubscribe, mail caml-list-request@inria.fr.  Archives: http://caml.inria.fr
-------------------
To unsubscribe, mail caml-list-request@inria.fr.  Archives: http://caml.inria.fr

Re: [Caml-list] recursive modules redux, & interface files

[Fabrice Le Fessant]

Why don't you use classes ? You can define classes with "virtual"
methods for the functions you will not define immediatly, and then
define them in another module. Later, you can create a class which
inherit from both classes, thus binding correctly all variables.

Isn't "late binding" the only interest of objects ? :) 

Of course, this only works for functions. For types, you should use
a separate module. Some time ago, I wrote a patch to ocaml to allow
C-like linking under some conditions. I can update it to 3.01 if you
are interested.

- Fabrice

-------------------
To unsubscribe, mail caml-list-request@inria.fr.  Archives: http://caml.inria.fr

Re: [Caml-list] recursive modules redux, & interface files

[Hendrik Tews]

Hi,

Tom Hirschowitz writes:
   Date: Fri, 23 Mar 2001 08:54:43 +0100
   Subject: Re: [Caml-list] recursive modules redux, & interface files
   
   Just curious, but how would you treat this?
   
   module type TEN = 
     sig 
       module PLAYER : sig 
                type t = Andre | Pete | Ivan | Cedric 
                val name : t -> string 
       end
       exception Not_Ex_No1 of PLAYER.t
       type u = PLAYER.t -> PLAYER.t
     end
   
   module Ten = 
     struct 
       includesig TEN
       ...
     end
   
   Reject?
   
Probably. I think we need a solution for the case where a big
variant type is defined in an .ml file and is exported in the
associated .mli file. 

The module language of ocaml is great. But I know only a few
people that are acquainted with it. If you can built expressions
like the above, then you surely find a way with several functor
applications that avoids any duplications. 

Bye,

Hendrik
-------------------
To unsubscribe, mail caml-list-request@inria.fr.  Archives: http://caml.inria.fr

[Caml-list] recursive modules redux, & interface files

[Chris Hecker]

Two questions/problems:

1.  So, I understand that doing recursive types across modules is hard (but I'd say very important for decoupling large software), but is it true that I can't even call across modules recursively?  Even with mli files to resolve the types?  I find that incredibly hard to believe, but I can't get it to work and it seems the docs say it's impossible as well (so why am I posting about it, you ask?  Disbelief that it's not possible, I guess. :).

What is the point of separate mli files if they can't be used to declare a callable interface separate from the implementation?  Is this just a small feature that needs to be added to the linker (defer binding unseen modules until all the object files have been seen), or is there something really subtle going on?  Since everything compiles and type checks fine, and the subtleties that I don't understand in ocaml usually have to do with the type checker, I'm having trouble seeing how this could be that hard.  Example below.  Am I missing something?

2. Also, on a related note, why do the interface file and the implementation file (or equivalently, I believe, the signature and structure) both have to have all the concrete types duplicated?  I can see the value of having interfaces that hide some implementation stuff and abstract types, but if I've got a big fully-specified variant type in a .mli file, it's annoying and error prone (yes, I know the compiler will catch it) to have to retype the whole thing into the ml file (which I have to do if I want to hide anything else in the ml file, meaning I can't just have an ml without an mli).  Is this something the "include" keyword takes care of?  Heck, "#include<foo.mli>" would be an improvement over duplicating all the types. :)  One of the things I hate about C++ and is having to type function declarations/definitions multiple times.

Thanks,
Chris

---------
Example for Question 1:

--- t1.mli ---
val foo: int -> int
--- t1.ml ---
let foo x = if x = 1 then T2.bar x else x
--- t2.mli ---
val bar: int -> int
--- t2.ml ---
let bar x = if x = 2 then T1.foo (x-1) else x
--- main.ml ---
let _ = print_int (T2.bar 2)

-------------------
To unsubscribe, mail caml-list-request@inria.fr.  Archives: http://caml.inria.fr

Re: [Caml-list] recursive modules redux, & interface files

[Brian Rogoff]

On Sun, 18 Mar 2001, Chris Hecker wrote:
> Two questions/problems:

Just one answer/solution I'm afraid, but I also give a grotesque
workaround...

> 2. Also, on a related note, why do the interface file and the
> implementation file (or equivalently, I believe, the signature and
> structure) both have to have all the concrete types duplicated?  I can
> see the value of having interfaces that hide some implementation stuff
> and abstract types, but if I've got a big fully-specified variant type
> in a .mli file, it's annoying and error prone (yes, I know the compiler
> will  catch it) to have to retype the whole thing into the ml file
> (which I have to do if I want to hide anything else in the ml file, meaning I
> can't just have an ml without an mli).  Is this something the
> "include" keyword takes care of?  

No, but if you are finding this really onerous then you can use "open" by 
creating a "pure" mli file with your gignatic variant type and opening it 
in the mli and ml file where it is needed. Does that help?

-- Brian

PS : There are some ways to get around the fact that the linker requires
     ordering, either by putting the mutually recursive functions in the 
     same module (I assume you know this) or by breaking the cycle with 
     an indirection (first rule of programming: any problem can be solved
     with another level of indirection :-). In this case, the indirection
     can be provided by passing in functions to foo and bar. Yeah, it's 
     ugly and all that but it is a workaround.

(* t1.mli *)
val foo : (int -> int) -> int -> int
(* t2.mli *)
val bar: (int -> int) -> int -> int
(* t1.ml *)
let foo f x = if x = 1 then f x else x
(* t2.ml *)
let bar f x = if x = 2 then f (x-1) else x
(* main.ml *)
let rec foo_aux x = T2.bar bar_aux x 
and bar_aux x = T1.foo foo_aux x

let _ = print_int (T2.bar bar_aux 2)


-------------------
To unsubscribe, mail caml-list-request@inria.fr.  Archives: http://caml.inria.fr

Re: [Caml-list] recursive modules redux, & interface files

[John Max Skaller]

Chris Hecker wrote:
> 
> Two questions/problems:
> 
> 1.  So, I understand that doing recursive types across modules is hard (but I'd say very important for decoupling large software), but is it true that I can't even call across modules recursively? 

	Yes. More precisely, you cannot forward reference any symbol,
however you _can_ call forward by passing a function backward as an
argument.
[This sucks though]

> 2. Also, on a related note, why do the interface file and the implementation file (or equivalently, I believe, the signature and structure) both have to have all the concrete types duplicated? 

	Because types in a given implementation may or may not be present
in the interface.

	IF you have a file containing ONLY types, then there is no need
to have an .ml file for it. If you have even one val (function, class),
you need the .ml file.


-- 
John (Max) Skaller, mailto:skaller@maxtal.com.au
10/1 Toxteth Rd Glebe NSW 2037 Australia voice: 61-2-9660-0850
checkout Vyper http://Vyper.sourceforge.net
download Interscript http://Interscript.sourceforge.net
-------------------
To unsubscribe, mail caml-list-request@inria.fr.  Archives: http://caml.inria.fr

Re: [Caml-list] recursive modules redux, & interface files

[Chris Hecker]

>        Because types in a given implementation may or may not be present
>in the interface.

Right, that's fine, but I only want to have them once, whereever they are.  So, if it's a private type, it's in the ml file, and if it's public it's in the mli file (assuming I want one, if I don't then everything's public).  How does having them duplicated buy me anything but trouble?

Chris

-------------------
To unsubscribe, mail caml-list-request@inria.fr.  Archives: http://caml.inria.fr

Re: [Caml-list] recursive modules redux, & interface files

[John Max Skaller]

Chris Hecker wrote:
> 
> >        Because types in a given implementation may or may not be present
> >in the interface.
> 
> Right, that's fine, but I only want to have them once, whereever they are.  So, if it's a private type, it's in the ml file, and if it's public it's in the mli file (assuming I want one, if I don't then everything's public).  How does having them duplicated buy me anything but trouble?
> 
> Chris

In C++, a function is either extern or static. 
There are only two options. [And non-local classes are _always_ extern]
This is not so in Ocaml: you may wish to provide access to a component
such as a function with a type more constrained than the actual
implementation.
For example:

	(* twoint.mli *)
	val twoint: int -> int * int

	(* twoint.ml *)
	let twoint x = (x,x)

Here, the implementation is actually polymorphic, it will work
for more than ints, but clients of the module 'twoint' cannot
use this function to make a pair of floats.

Here is another example:

	(* abstr.mli *)
	type t
	val get: t -> int
	val make: int -> t

	(* abstr.ml *)
	type t = int * int
	let get x = fst x
	let make x = (x,x+1)	


Here, the type t is implemented as a pair of ints.
But the implementation is hidden from the client of the module.
Note that the type 't' itself is not hidden.

-- 
John (Max) Skaller, mailto:skaller@maxtal.com.au
10/1 Toxteth Rd Glebe NSW 2037 Australia voice: 61-2-9660-0850
checkout Vyper http://Vyper.sourceforge.net
download Interscript http://Interscript.sourceforge.net
-------------------
To unsubscribe, mail caml-list-request@inria.fr.  Archives: http://caml.inria.fr

Re: [Caml-list] recursive modules redux, & interface files

[Chris Hecker]

> There are only two options. [And non-local classes are _always_ extern]
> This is not so in Ocaml: you may wish to provide access to a component
> such as a function with a type more constrained than the actual
> implementation.

Yes yes yes, I know this.  I'm saying I understand why I need to type
stuff if there's a difference betwen the .ml and .mli versions (hiding
stuff, restricting stuff, abstracting stuff), and that's fine.  I'm
asking why I need to retype stuff if it's identical.  Check out some
of the source code in the compiler, or any ocaml project I've seen
(the ICFP winners, whatever).  There are tons of really huge variants
that are just duplicated in mli and ml.  That seems bad, for the same
reason that typing a C++ function declaration 2 times is bad.

Chris


-------------------
To unsubscribe, mail caml-list-request@inria.fr.  Archives: http://caml.inria.fr

Re: [Caml-list] recursive modules redux, & interface files

[Patrick M Doane]

I agree that checking interface/implementation of modules could be
improved.

For projects that I've worked on that have huge variant types, I have
typically placed the variants in a module by themselves with no .mli file. 
This technique hasn't worked too well for me in practice and is still
annoying for the smaller variants. 

A reasonable modification to the language would allow a module expression
to not include type definitions when they are defined in the module type
and include their type information. 

This would mean that

  module X : sig type t = int end = struct end

would be accepted, but

  module X : sig type t end = struct end

would be rejected because the abstract field 't' is required but missing.


Would this proposal address all the issues you had in mind?

Patrick Doane

On Tue, 20 Mar 2001, Chris Hecker wrote:

> 
> > There are only two options. [And non-local classes are _always_ extern]
> > This is not so in Ocaml: you may wish to provide access to a component
> > such as a function with a type more constrained than the actual
> > implementation.
> 
> Yes yes yes, I know this.  I'm saying I understand why I need to type
> stuff if there's a difference betwen the .ml and .mli versions (hiding
> stuff, restricting stuff, abstracting stuff), and that's fine.  I'm
> asking why I need to retype stuff if it's identical.  Check out some
> of the source code in the compiler, or any ocaml project I've seen
> (the ICFP winners, whatever).  There are tons of really huge variants
> that are just duplicated in mli and ml.  That seems bad, for the same
> reason that typing a C++ function declaration 2 times is bad.
> 
> Chris
> 
> 
> -------------------
> To unsubscribe, mail caml-list-request@inria.fr.  Archives: http://caml.inria.fr
> 

-------------------
To unsubscribe, mail caml-list-request@inria.fr.  Archives: http://caml.inria.fr

Re: [Caml-list] recursive modules redux, & interface files

[Chris Hecker]

> This would mean that
>   module X : sig type t = int end = struct end
> would be accepted, but
>   module X : sig type t end = struct end
> would be rejected because the abstract field 't' is required but missing.
> Would this proposal address all the issues you had in mind?

Yep, that's what I had in mind!

Chris

-------------------
To unsubscribe, mail caml-list-request@inria.fr.  Archives: http://caml.inria.fr

Re: [Caml-list] recursive modules redux, & interface files

[John Max Skaller]

Patrick M Doane wrote:
 
> For projects that I've worked on that have huge variant types, I have
> typically placed the variants in a module by themselves with no .mli file.
> This technique hasn't worked too well for me in practice and is still
> annoying for the smaller variants.

	Try placing them in a .mli file instead (no ml file).

-- 
John (Max) Skaller, mailto:skaller@maxtal.com.au
10/1 Toxteth Rd Glebe NSW 2037 Australia voice: 61-2-9660-0850
checkout Vyper http://Vyper.sourceforge.net
download Interscript http://Interscript.sourceforge.net
-------------------
To unsubscribe, mail caml-list-request@inria.fr.  Archives: http://caml.inria.fr

Re: [Caml-list] recursive modules redux, & interface files

[Patrick M Doane]

I don't see that it makes much of a difference. Besides, the reason it
hasn't worked well for me is that inevitably I want to add some
functions to the module that has the variant type. For example, pretty
printers. The next compromise is to continue the path without a .mli file
until I don't want some of these utilities to be exported.  In the end,
I'm back to the source of the problem, having to duplicate a large variant
type.

On Thu, 22 Mar 2001, John Max Skaller wrote:

> Patrick M Doane wrote:
>  
> > For projects that I've worked on that have huge variant types, I have
> > typically placed the variants in a module by themselves with no .mli file.
> > This technique hasn't worked too well for me in practice and is still
> > annoying for the smaller variants.
> 
> 	Try placing them in a .mli file instead (no ml file).
> 
> -- 
> John (Max) Skaller, mailto:skaller@maxtal.com.au
> 10/1 Toxteth Rd Glebe NSW 2037 Australia voice: 61-2-9660-0850
> checkout Vyper http://Vyper.sourceforge.net
> download Interscript http://Interscript.sourceforge.net
> 

-------------------
To unsubscribe, mail caml-list-request@inria.fr.  Archives: http://caml.inria.fr

Re: [Caml-list] recursive modules redux, & interface files

[Brian Rogoff]

On Wed, 21 Mar 2001, Patrick M Doane wrote:
> I don't see that it makes much of a difference. Besides, the reason it
> hasn't worked well for me is that inevitably I want to add some
> functions to the module that has the variant type. For example, pretty
> printers. The next compromise is to continue the path without a .mli file
> until I don't want some of these utilities to be exported.  In the end,
> I'm back to the source of the problem, having to duplicate a large variant
> type.

What's the problem with the hack I suggested earlier: put the huge variant 
(and other duplicated types) in a "pure" .mli file (I hate using .ml for
that) and "open"ing it where you need it, once in the .mli file and once in the 
.ml file? This way you reduce the duplication to two lines.

I know some people are open-phobes, but I find this use of open to be 
acceptable.

-- Brian

> 
> On Thu, 22 Mar 2001, John Max Skaller wrote:
> 
> > Patrick M Doane wrote:
> >  
> > > For projects that I've worked on that have huge variant types, I have
> > > typically placed the variants in a module by themselves with no .mli file.
> > > This technique hasn't worked too well for me in practice and is still
> > > annoying for the smaller variants.
> > 
> > 	Try placing them in a .mli file instead (no ml file).
> > 
> > -- 
> > John (Max) Skaller, mailto:skaller@maxtal.com.au
> > 10/1 Toxteth Rd Glebe NSW 2037 Australia voice: 61-2-9660-0850
> > checkout Vyper http://Vyper.sourceforge.net
> > download Interscript http://Interscript.sourceforge.net
> > 
> 
> -------------------
> To unsubscribe, mail caml-list-request@inria.fr.  Archives: http://caml.inria.fr
> 

-------------------
To unsubscribe, mail caml-list-request@inria.fr.  Archives: http://caml.inria.fr

Re: [Caml-list] recursive modules redux, & interface files

[Francois Pottier]

On Wed, Mar 21, 2001 at 07:03:55PM -0500, Patrick M Doane wrote:
>
> I'm back to the source of the problem, having to duplicate a large variant
> type.

I think you have missed the point of John's (or was it Brian's?) suggestion,
which is to place large type (or module type) definitions in a separate .mli
(or .ml) file, then refer to it from your .mli *and* your .ml file. This has
the unfortunate consequence of breaking every module into three files (shared
definitions, interface, and implementations), making the program structure
somewhat more cryptic. But it usually works well.

Regarding your suggestion,

>  For every module definition M that has a signature S
>    For every type definition t in S that contains optional
>               type-information and is not defined in M
>      Add the type definition of t to M (preserving the order from S)
                                          ^^^^^^^^^^^^^^^^^^^^

I think the problematic part is in the ordering. The order in which bindings
appear may be different in M and S, to start with. So, where do we insert the
definition, and (assuming we know where) what do we do if some names referred
to by the definition aren't yet defined in M at that point?

-- 
François Pottier
Francois.Pottier@inria.fr
http://pauillac.inria.fr/~fpottier/
-------------------
To unsubscribe, mail caml-list-request@inria.fr.  Archives: http://caml.inria.fr

Re: [Caml-list] recursive modules redux, & interface files

[John Prevost]

>>>>> "pd" == Patrick M Doane <patrick@watson.org> writes:

    pd> This would mean that

    pd>   module X : sig type t = int end = struct end

    pd> would be accepted, but

    pd>   module X : sig type t end = struct end

    pd> would be rejected because the abstract field 't' is required
    pd> but missing.

What about "module X : sig type t end = struct type t end", where
values of the type can't actually be constructed?  (Except possibly by
C code.)

John.
-------------------
To unsubscribe, mail caml-list-request@inria.fr.  Archives: http://caml.inria.fr

Re: [Caml-list] recursive modules redux, & interface files

[Patrick M Doane]

Hi John,

It seems to me that this would be perfectly legal. It is accepted by the
current Ocaml language, and by the extension I proposed unless there is
something I'm missing.  Is this the behavior you're expecting?

Patrick

On 21 Mar 2001, John Prevost wrote:

> >>>>> "pd" == Patrick M Doane <patrick@watson.org> writes:
> 
>     pd> This would mean that
> 
>     pd>   module X : sig type t = int end = struct end
> 
>     pd> would be accepted, but
> 
>     pd>   module X : sig type t end = struct end
> 
>     pd> would be rejected because the abstract field 't' is required
>     pd> but missing.
> 
> What about "module X : sig type t end = struct type t end", where
> values of the type can't actually be constructed?  (Except possibly by
> C code.)
> 
> John.
> 

-------------------
To unsubscribe, mail caml-list-request@inria.fr.  Archives: http://caml.inria.fr

Re: [Caml-list] recursive modules redux, & interface files

[John Max Skaller]

Chris Hecker wrote:
> 
> > There are only two options. [And non-local classes are _always_ extern]
> > This is not so in Ocaml: you may wish to provide access to a component
> > such as a function with a type more constrained than the actual
> > implementation.
> 
> Yes yes yes, I know this.  I'm saying I understand why I need to type
> stuff if there's a difference betwen the .ml and .mli versions (hiding
> stuff, restricting stuff, abstracting stuff), and that's fine.  I'm
> asking why I need to retype stuff if it's identical. 

	You don't. There is a tool:

	ocamlc -i fred.ml > fred.mli

which will generate the mli file for you. (Use the -i option on the
compiler).

-- 
John (Max) Skaller, mailto:skaller@maxtal.com.au
10/1 Toxteth Rd Glebe NSW 2037 Australia voice: 61-2-9660-0850
checkout Vyper http://Vyper.sourceforge.net
download Interscript http://Interscript.sourceforge.net
-------------------
To unsubscribe, mail caml-list-request@inria.fr.  Archives: http://caml.inria.fr

Re: [Caml-list] recursive modules redux, & interface files

[John Max Skaller]

Chris Hecker wrote:
> 
> > There are only two options. [And non-local classes are _always_ extern]
> > This is not so in Ocaml: you may wish to provide access to a component
> > such as a function with a type more constrained than the actual
> > implementation.
> 
> Yes yes yes, I know this.  I'm saying I understand why I need to type
> stuff if there's a difference betwen the .ml and .mli versions (hiding
> stuff, restricting stuff, abstracting stuff), and that's fine.  I'm
> asking why I need to retype stuff if it's identical. 

	BTW: you DON'T actually need an .mli file. Try it.
It is only needed when there IS a constraint on 'everything public'.

-- 
John (Max) Skaller, mailto:skaller@maxtal.com.au
10/1 Toxteth Rd Glebe NSW 2037 Australia voice: 61-2-9660-0850
checkout Vyper http://Vyper.sourceforge.net
download Interscript http://Interscript.sourceforge.net
-------------------
To unsubscribe, mail caml-list-request@inria.fr.  Archives: http://caml.inria.fr

Re: [Caml-list] recursive modules redux, & interface files

[Markus Mottl]

On Mon, 19 Mar 2001, John Max Skaller wrote:
> 	Yes. More precisely, you cannot forward reference any symbol,
> however you _can_ call forward by passing a function backward as an
> argument.
> [This sucks though]

Note that you can always use local modules + functors so as not having
to pass around functions backwards, e.g.:

  module MakeM (Spec : sig val f : int -> int end) = struct
    open Spec

    let foo x = f x
    let bar x y = f x + f y
  end

  let bla g =
    let module Spec = struct let f = g end in
    let module M = MakeM (Spec) in
    print_int (M.foo 42 + M.bar 1 2)

  let _ = bla succ

Put the functions that should be "backwards parameterized" into functor
"MakeM". Then generate its specifcation "Spec" at runtime in some function
"bla" (here: "f" should be some function "g" passed at runtime) and apply
the functor "MakeM" to the specification "Spec". Now you can access the
"backwards parameterized" functions using the qualified module path "M."

If you feel annoyed by the fully qualified path, just write another
local module, in which you can "open" module "M" and provide some "start"
function in this new module to continue execution.

If you want even more hardcore moduling, you might be interested in trying
out the new "include"-keyword for structures (my favourite new language
extension! Thanks!) with the tricks above. You can do tremendous things
with it, like overriding specific functions of modules at runtime, etc.,
with hardly any effort.

The only remaining question here is: how efficiently can OCaml handle
local modules and local functor applications? I haven't measured it,
but I guess that this could be expensive.

Regards,
Markus Mottl

-- 
Markus Mottl, mottl@miss.wu-wien.ac.at, http://miss.wu-wien.ac.at/~mottl
-------------------
To unsubscribe, mail caml-list-request@inria.fr.  Archives: http://caml.inria.fr

Re: [Caml-list] recursive modules redux, & interface files

[Xavier Leroy]

> 1.  So, I understand that doing recursive types across modules is
> hard (but I'd say very important for decoupling large software), but
> is it true that I can't even call across modules recursively?  Even
> with mli files to resolve the types?  I find that incredibly hard to
> believe, but I can't get it to work and it seems the docs say it's
> impossible as well (so why am I posting about it, you ask?
> Disbelief that it's not possible, I guess. :).

You're right that cross-module recursion even between functions is not
supported, and you're right that this is not because of typing
difficulties -- the type-checking of such recursions is easy.

This is because value components of modules can be the result of
arbitrary computations, and the only way to ensure that these
computations succeed is by making sure they occur sequentially.
Consider for instance:

    A.mli    val x : int                B.mli    val y : int
    A.ml     let x = B.y + 1            B.ml     let y = A.x * 3

We don't know how to evaluate these definitions correctly -- indeed,
there is no integer solution to this recursive definition.

Other languages avoid this problem in one of two ways.  C and C-like
languages only allow global identifiers to be defined as functions or
compile-time constants, but not results of arbitrary computations.
Haskell and other lazy languages rely on lazy evaluation to perform
on-demand initialization (i.e. compute the definition the first time
it's needed), and aborting computation if a dynamic dependency cycle
is detected (as in the example above).

Java goes pretty much the Haskell way, relying on dynamic class
loading to lazily evaluate static field definitions; originally, it
raised an exception on discovering a dynamic dependency cycle;
nowadays, I think it just pre-initializes static fields to 0 or null,
then compute the initial values based on this (so that in the example
above you'd get x = 1 and y = 3 if the program refers to B.y first,
and y = 0 and x = 1 if the program refers to A.x first :-).

The Haskell solution is semantically cleanest, but lazy evaluation
of module components entails a performance penalty and some increase
in code size (the compiler must emit "am I initialized already?" tests
on every module value access).  (The semantics of Java class
initialization entail similar penalties, although they partially hide
them by relying on JIT compilation -- blech.)

A possible approach for Caml would be to have a link-time analysis
that detects cross-module value recursions that involve only function
definitions, and allow these (because they are safe -- like in C!).
Fabrice Le Fessant posted a patch to OCaml a while ago that does
pretty much this.  I'm still hoping more general, principled solutions
exist, but they sure are hard to design!

> 2. Also, on a related note, why do the interface file and the
> implementation file (or equivalently, I believe, the signature and
> structure) both have to have all the concrete types duplicated?  I can
> see the value of having interfaces that hide some implementation stuff
> and abstract types, but if I've got a big fully-specified variant type
> in a .mli file, it's annoying and error prone (yes, I know the
> compiler will catch it) to have to retype the whole thing into the ml
> file (which I have to do if I want to hide anything else in the ml
> file, meaning I can't just have an ml without an mli).

Yes, it's annoying, and it's more or less a consequence of the
ideology behind the ML module system: that structures define things,
and that signatures can later be ascribed to these structures to hide
or abstract some of these things.  With this ideology, every type that
is declared in a signature -- even if it's a concrete declaration that
includes as much information as a type definition! -- must be matched
by a type definition in the corresponding structure. It's just very
principled and logical -- just a bit inconvenient at times :-)

Another way to think about it is that every structure (or
implementation file) must "stand on its own" and make sense without
the signature (or interface file) that will be ascribed to it later
on.  It makes sense when the signature is not known when the structure
is defined, e.g.

        module M = struct type t = A | B ... end
        (* 5000 lines later: *)
        module M' = (M : sig type t = A | B ... end)

It becomes practically inconvenient when the signature is known at the
time of the structure definition:

        module M : sig type t = A | B ... end =
          struct type t = A | B ... end

Which is the case with interface and implementation files.

In this case, one could envision an automatic completion of the
structure / implementation file so that concrete type specifications
from the signature do not need to be implemented in the structure.
Doing this right is not obvious, though.  First, it's not enough to
say that a concrete type spec does not need to be matched in the
structure.  This would type-check

        module M : sig type t = A | B end = struct end

but not

    module M : sig type t = A | B  val v : t end = struct let v = A end

In other terms, the unmatched concrete type specs in the signature
need to be somehow reintroduced in the structure definition, so that
other parts of the structure may refer to them.  While I think it can
be done in most practical cases, it's a bit of a kludge and I'm not
sure how to do this in all cases.

Is the practical value of this kludge enough to forget that it's a
kludge?  Can't we live with the current duplication of concrete type
definitions in the name of systematic, principled module systems?  
I really don't know.

Best,

- Xavier Leroy
-------------------
To unsubscribe, mail caml-list-request@inria.fr.  Archives: http://caml.inria.fr

Re: [Caml-list] recursive modules redux, & interface files

[Patrick M Doane]

Hi Xavier,

Your example demonstrates that a proposal for such an extension
should be more explicit about how it should work.  I had a particular
implementation in mind from my post yesterday:

  For every module definition M that has a signature S
    For every type definition t in S that contains optional
               type-information and is not defined in M
      Add the type definition of t to M (preserving the order from S)

  Proceed with the usual algorithms for type checking, matching
      structures,  etc.

I think this should work properly. Anything I might have missed? You seem
to elude to special cases that are not immediately obvious.

I agree that it becomes kludgy to remove the separation that currently
exists between structures and signatures.  However, as a programmer
maintaining the duplicate types also seems kludgy . After all, the
compiler has the information available, why doesn't it use it?

This seems to be a case where a compromise between theory and practice
should be explored.

Patrick


On Wed, 21 Mar 2001, Xavier Leroy wrote:

> It becomes practically inconvenient when the signature is known at the
> time of the structure definition:
> 
>         module M : sig type t = A | B ... end =
>           struct type t = A | B ... end
> 
> Which is the case with interface and implementation files.
> 
> In this case, one could envision an automatic completion of the
> structure / implementation file so that concrete type specifications
> from the signature do not need to be implemented in the structure.
> Doing this right is not obvious, though.  First, it's not enough to
> say that a concrete type spec does not need to be matched in the
> structure.  This would type-check
> 
>         module M : sig type t = A | B end = struct end
> 
> but not
> 
>     module M : sig type t = A | B  val v : t end = struct let v = A end
> 
> In other terms, the unmatched concrete type specs in the signature
> need to be somehow reintroduced in the structure definition, so that
> other parts of the structure may refer to them.  While I think it can
> be done in most practical cases, it's a bit of a kludge and I'm not
> sure how to do this in all cases.
> 
> Is the practical value of this kludge enough to forget that it's a
> kludge?  Can't we live with the current duplication of concrete type
> definitions in the name of systematic, principled module systems?  
> I really don't know.

-------------------
To unsubscribe, mail caml-list-request@inria.fr.  Archives: http://caml.inria.fr

Re: [Caml-list] recursive modules redux, & interface files

[Hendrik Tews]

Hi,

I would like to vote for solutions that work for the common case
when writing large programs, even if they are hacks, considered
from a theoretical point of view.

Xavier Leroy writes:

     [cross module recursion]
   
       A.mli    val x : int                B.mli    val y : int
       A.ml     let x = B.y + 1            B.ml     let y = A.x * 3
   
   We don't know how to evaluate these definitions correctly -- indeed,
   there is no integer solution to this recursive definition.
   
I think that in this case the theoretical cleaness is overrated.
Cross module recursion of functions is soo useful, that it
should be made to work --- even if the solution seems stupid with
respect to the example above.

   [duplications in signatures and structures]

   Is the practical value of this kludge enough to forget that it's a
   kludge?  

Sure.

   Can't we live with the current duplication of concrete type
   definitions in the name of systematic, principled module systems?  

No, at least I cannot. Also here I would suggest to have a
solution that works for the common case. What about changing
include, such that including a signature into a structure
includes all types and all exceptions?


Bye,

Hendrik
-------------------
To unsubscribe, mail caml-list-request@inria.fr.  Archives: http://caml.inria.fr

Re: [Caml-list] recursive modules redux, & interface files

[Markus Mottl]

Hendrik Tews schrieb am Thursday, den 22. March 2001:
> I would like to vote for solutions that work for the common case
> when writing large programs, even if they are hacks, considered
> from a theoretical point of view.

I am not so fond of sacrificing theoretical beauty: it usually seems
to be the case that there are working solutions that are also elegant -
it's only a matter of thinking about them long enough. You might speed
up development a bit by allowing hacks if you cannot immediately find
a sound solution, but IMHO it is hardly ever a good idea in the long run.

> I think that in this case the theoretical cleaness is overrated.

In general? Probably not. If there is a problem with expressiveness or
else, it seems to be better to first try harder to find a solution with
the existing system before crying for a hacky extension. And if this
doesn't work, let's try to find a more expressive theory rather than
abandoning theory completely.

> Cross module recursion of functions is soo useful, that it
> should be made to work --- even if the solution seems stupid with
> respect to the example above.

Nearly everytime I had thought "now I need recursive modules", I found
other, even elegant ways to do it. If we really want them, please
let's don't put aside theory but take existing clean solutions (e.g.
see Claudio Russo's thesis).

>    [duplications in signatures and structures]
> 
>    Is the practical value of this kludge enough to forget that it's a
>    kludge?  
> 
> Sure.

The solution to put the whole signature into a separate .ml-file requires
hardly any work and solves this problem neatly. Why introduce a kludge
if there are reasonable ways to do it?

> No, at least I cannot.

Do you have examples where the current system is just too awkward to use?

> Also here I would suggest to have a
> solution that works for the common case. What about changing
> include, such that including a signature into a structure
> includes all types and all exceptions?

But you can do this (and I do it regularly) by putting the signature stuff
into a separate module (or .ml-file): then you can "include" things in
your structures to your hearts delight (thanks to the new way of using
"include" with structures).

Regards,
Markus Mottl

-- 
Markus Mottl, mottl@miss.wu-wien.ac.at, http://miss.wu-wien.ac.at/~mottl
-------------------
To unsubscribe, mail caml-list-request@inria.fr.  Archives: http://caml.inria.fr

Re: [Caml-list] recursive modules redux, & interface files

[Brian Rogoff]

On Thu, 22 Mar 2001, Markus Mottl wrote:
> Hendrik Tews schrieb am Thursday, den 22. March 2001:
> > I would like to vote for solutions that work for the common case
> > when writing large programs, even if they are hacks, considered
> > from a theoretical point of view.
> 
> I am not so fond of sacrificing theoretical beauty: it usually seems
> to be the case that there are working solutions that are also elegant -
> it's only a matter of thinking about them long enough. You might speed
> up development a bit by allowing hacks if you cannot immediately find
> a sound solution, but IMHO it is hardly ever a good idea in the long run.

I agree with this general principle, and to be honest, I haven't found in
my own programming a compelling case where module spanning mutually
recursive function definitions were an issue. Is it possible to produce a 
reasonably sized example, Hendrik (or Chris)? I'm annoyed by the inability
to have a mutually recursive *type* definition and functor instantiation,
and that problem can be solved with recursive modules (Claudio Russo says 
it works in a development version of Mosml), but I haven't had this
problem with functions yet. 

As an aside, Claudio mentioned that it would be easy to extend OCaml to 
support this feature: are there any plans to do so? If not, maybe I'll 
push for it when the Consortium is set up. 

> > Cross module recursion of functions is soo useful, that it
> > should be made to work --- even if the solution seems stupid with
> > respect to the example above.

I agree that the workaround is a tiny bit ugly, but I'm not convinced that
the problem is so great that it justifies any kind of new kludge. Convince 
me! My mind is open (or include'ed :) 

> Nearly everytime I had thought "now I need recursive modules", I found
> other, even elegant ways to do it. 

How about the case I mention above? I think that there are a few cases
where some extensions are necessary, however...

> If we really want them, please let's don't put aside theory but take
> existing clean solutions (e.g. see Claudio Russo's thesis).

Yes. Let's have the extensions be clean, well founded ones. Even some
people in industry realize that this is the right way to go. :-)

I've snipped the module inclusion stuff because I think that while the 
need for a workaround is unfortunate, I think that there are bigger fish
to fry.

-- Brian


-------------------
To unsubscribe, mail caml-list-request@inria.fr.  Archives: http://caml.inria.fr

Re: [Caml-list] recursive modules redux, & interface files

[Daniel de Rauglaudre]

Hi everybody,

My usual hack for mutually recursive functions in different modules:

File foo.ml:
   let g_ref = ref (fun _ -> failwith "Bar.g not yet defined")
   let g x = !g_ref x
   let f ... = .... g ...

File bar.ml:
   let g .... = .... Foo.f ...
   Foo.g_ref := g

By extending the language using Camlp4, by the constructions "forward" and
"define_forward" doing the right thing, you could have:

File foo.ml:
   forward g
   let f ... = .... g ...

File bar.ml:
   let g .... = .... Foo.f ...
   define_forward g

-- 
Daniel de RAUGLAUDRE
daniel.de_rauglaudre@inria.fr
http://cristal.inria.fr/~ddr/
-------------------
To unsubscribe, mail caml-list-request@inria.fr.  Archives: http://caml.inria.fr

Re: [Caml-list] recursive modules redux, & interface files

[Fergus Henderson]

On 22-Mar-2001, Brian Rogoff <bpr@best.com> wrote:
> 
> I haven't found in
> my own programming a compelling case where module spanning mutually
> recursive function definitions were an issue. Is it possible to produce a 
> reasonably sized example, Hendrik (or Chris)?

In the Mercury compiler, we have made significant use of module spanning
mutually recursive procedures.  For example, the code generator
is split among several modules, roughly for each language construct
(e.g. ite_gen handles code generation for if-then-elses,
switch_gen handles code generation for switches, etc.),
and since if-then-elses can contain switches (and vice versa),
the procedures in these modules are mutually recursive.

-- 
Fergus Henderson <fjh@cs.mu.oz.au>  |  "I have always known that the pursuit
                                    |  of excellence is a lethal habit"
WWW: <http://www.cs.mu.oz.au/~fjh>  |     -- the last words of T. S. Garp.
-------------------
To unsubscribe, mail caml-list-request@inria.fr.  Archives: http://caml.inria.fr

Re: [Caml-list] recursive modules redux, & interface files

[Brian Rogoff]

On Sat, 24 Mar 2001, Fergus Henderson wrote:
> On 22-Mar-2001, Brian Rogoff <bpr@best.com> wrote:
> > I haven't found in
> > my own programming a compelling case where module spanning mutually
> > recursive function definitions were an issue. Is it possible to produce a 
> > reasonably sized example, Hendrik (or Chris)?
> 
> In the Mercury compiler, we have made significant use of module spanning
> mutually recursive procedures.  For example, the code generator
> is split among several modules, roughly for each language construct
> (e.g. ite_gen handles code generation for if-then-elses,
> switch_gen handles code generation for switches, etc.),
> and since if-then-elses can contain switches (and vice versa),
> the procedures in these modules are mutually recursive.

Interesting. A similar example occurred in a discussion in comp.lang.ml 
between Matthias Blume and Greg Morrissett (concerning datatypes not
functions) where MB argued as an SML/NJ maintainer that such recurrences
were best placed in the same module and GM thought it best that they be
split even though recursive. Clearly I lean towards MB's view on this 
though I take it that there are other schools of thought. 

What is your criteria for splitting the functions into different modules?

-- Brian


-------------------
To unsubscribe, mail caml-list-request@inria.fr.  Archives: http://caml.inria.fr

Re: [Caml-list] recursive modules redux, & interface files

[Fergus Henderson]

On 23-Mar-2001, Brian Rogoff <bpr@best.com> wrote:
> On Sat, 24 Mar 2001, Fergus Henderson wrote:
> > 
> > In the Mercury compiler, we have made significant use of module spanning
> > mutually recursive procedures.  For example, the code generator
> > is split among several modules, roughly for each language construct
> > (e.g. ite_gen handles code generation for if-then-elses,
> > switch_gen handles code generation for switches, etc.),
> > and since if-then-elses can contain switches (and vice versa),
> > the procedures in these modules are mutually recursive.
> 
> Interesting. A similar example occurred in a discussion in comp.lang.ml 
> between Matthias Blume and Greg Morrissett (concerning datatypes not
> functions) where MB argued as an SML/NJ maintainer that such recurrences
> were best placed in the same module and GM thought it best that they be
> split even though recursive. Clearly I lean towards MB's view on this 
> though I take it that there are other schools of thought. 
> 
> What is your criteria for splitting the functions into different modules?

Our criteria are pretty informal: each module should consist of closely
related code, preferably with a single purpose that can be summed up
in a concise title, e.g. "code generation for if-then-elses".

In this case, I think the code was originally in a single module,
but was split into sub-modules when it became too large.
Here's the line counts of the relevant modules:

       768 call_gen.m
      1296 code_gen.m
        67 commit_gen.m
       324 disj_gen.m
       360 ite_gen.m
       283 par_conj_gen.m
      1254 pragma_c_gen.m
       313 switch_gen.m
       897 unify_gen.m
       245 dense_switch.m
       549 lookup_switch.m
       246 string_switch.m
      1100 tag_switch.m
       584 middle_rec.m
      ----
      8286

Generally we prefer to make modules in the range of about 200-2000
lines of code each.  If a module gets much larger than that, then
it tends to get a bit unwieldy, and recompilation times start to become
inconvenient, so we prefer to split up modules that get larger than that.
8000 lines is definitely way too big.

-- 
Fergus Henderson <fjh@cs.mu.oz.au>  |  "I have always known that the pursuit
                                    |  of excellence is a lethal habit"
WWW: <http://www.cs.mu.oz.au/~fjh>  |     -- the last words of T. S. Garp.
-------------------
To unsubscribe, mail caml-list-request@inria.fr.  Archives: http://caml.inria.fr

Re: [Caml-list] recursive modules redux, & interface files

[John Max Skaller]

Brian Rogoff wrote:

> I agree with this general principle, and to be honest, I haven't found in
> my own programming a compelling case where module spanning mutually
> recursive function definitions were an issue. Is it possible to produce a
> reasonably sized example, Hendrik (or Chris)? 

	I have such an example. In the Vyper interpreter, there is a
very large module which handles execution of ASTs, which contains
almost all the interpretive code. It was not possible to break this
module into further pieces because of the mutual recursion.
[I actually _did_ do this, then undid it, because of the excessive
number of extra arguments that had to be passed to make it work]

	Vyper is an extension of Python, which does things like:

	1. The expression x + y is addition of numbers if x and y are
	  numbers, otherwise, if x or y are objects of class type,
	  method calls.

	2. The expression eval(string) evaluates string in the current context

which require mutual recursion across widely separates levels of 
otherwise fairly logical layers. I used indirection for most of these
recursions (via a class object), but the lower level core execution
was best handled by putting all the routines in one module.

-- 
John (Max) Skaller, mailto:skaller@maxtal.com.au
10/1 Toxteth Rd Glebe NSW 2037 Australia voice: 61-2-9660-0850
checkout Vyper http://Vyper.sourceforge.net
download Interscript http://Interscript.sourceforge.net
-------------------
To unsubscribe, mail caml-list-request@inria.fr.  Archives: http://caml.inria.fr

Re: [Caml-list] recursive modules redux, & interface files

[Brian Rogoff]

On Wed, 28 Mar 2001, John Max Skaller wrote:
> Brian Rogoff wrote:
> > I agree with this general principle, and to be honest, I haven't found in
> > my own programming a compelling case where module spanning mutually
> > recursive function definitions were an issue. Is it possible to produce a
> > reasonably sized example, Hendrik (or Chris)? 
> 
> 	I have such an example. In the Vyper interpreter, there is a
> very large module which handles execution of ASTs, which contains
> almost all the interpretive code. It was not possible to break this
> module into further pieces because of the mutual recursion.

This seems simialr to Fergus Henderson's example in the Mercury compiler. 
I thought his rationale was convincing (the file just got too big) and 
I assume he and you considered various refactorings to keep from splitting 
the module and decided against them. So even though there's practically no
better example of functions that belong in the same module as mutually
recursive ones, pragmatics suggests that you split them. None of the
compiler like programs I've worked on have become that big yet. 

> [I actually _did_ do this, then undid it, because of the excessive 
> number of extra arguments that had to be passed to make it work]

Yes, that can be a problem with the trick/hack of passing extra arguments. 
Did you consider the trick Daniel showed using function references which
get initialized in the right order during the calls? I don't like
introducing references unnecessarily but it might be useful until there is 
a cleaner solution. 

-- Brian


-------------------
To unsubscribe, mail caml-list-request@inria.fr.  Archives: http://caml.inria.fr

Re: [Caml-list] recursive modules redux, & interface files

[John Max Skaller]

Brian Rogoff wrote:

> Did you consider the trick Daniel showed using function references which
> get initialized in the right order during the calls?

	Yes, but it's also just too messy. Many of the workarounds are
probably OK for a few uses, but they don't really scale. 
With a 'fat' module, we get the simplest, cleanest, code, even if the
module is rather large: interfaces are only useful if they help reduce
complexity.

	The most scalable solution I found was to use classes to
'clump' related functions together, allowing a set of functions to
be passed as a single argument (a class object). This also allowed
some state to be put in the object instead of using a functional
closure.

-- 
John (Max) Skaller, mailto:skaller@maxtal.com.au
10/1 Toxteth Rd Glebe NSW 2037 Australia voice: 61-2-9660-0850
checkout Vyper http://Vyper.sourceforge.net
download Interscript http://Interscript.sourceforge.net
-------------------
To unsubscribe, mail caml-list-request@inria.fr.  Archives: http://caml.inria.fr

Re: [Caml-list] recursive modules redux, & interface files

[Hendrik Tews]

Hi,

Markus Mottl writes:
   From: Markus Mottl <mottl@miss.wu-wien.ac.at>
   Date: Thu, 22 Mar 2001 14:01:57 +0100
   Subject: Re: [Caml-list] recursive modules redux, & interface files
   
   Hendrik Tews schrieb am Thursday, den 22. March 2001:
   > I would like to vote for solutions that work for the common case
   > when writing large programs, even if they are hacks, considered
   > from a theoretical point of view.
   
   I am not so fond of sacrificing theoretical beauty: it usually seems
   to be the case that there are working solutions that are also elegant -
   it's only a matter of thinking about them long enough. You might speed
   up development a bit by allowing hacks if you cannot immediately find
   a sound solution, but IMHO it is hardly ever a good idea in the long run.
   
[As an aside: In principle I do not agree that usually there
 exist elegant solutions. This would imply that for most problems
 there are elegant solutions, whereas the attribute elegant can
 only apply to a small subset of all solutions (unless everything
 is elegant).
]

But for the main problem of mutual recursion: I would also
appreciate a theoretically nice solution. But ocaml and its
predecessors have been around now for long time, so it seems that
it is not that easy to find a good solution for mutal recursion
between modules. So instead of waiting another three years I
would prefer a solution now, even if it is intermediate and not
so clean.

   If there is a problem with expressiveness or
   else, it seems to be better to first try harder to find a solution with
   the existing system before crying for a hacky extension. And if this
   doesn't work, let's try to find a more expressive theory rather than
   abandoning theory completely.
   
I agree, don't let's abandoning theory. But let's make a few
compromises, where a good solution is not available in the near
future. 

   Nearly everytime I had thought "now I need recursive modules", I found
   other, even elegant ways to do it. 

I know, with some effort you can put every system in a linear
structure and avoid module spanning recursion. But I do not want
to restructure the whole project, only because I need some
recursive functions. The more important point is that in a
project with several people the overall complexity of the system
structure must stay below a certain limit. If you create a system
structure that is above this limit, then the project will fail.

   
   >    [duplications in signatures and structures]
   
   The solution to put the whole signature into a separate .ml-file requires
   hardly any work and solves this problem neatly. Why introduce a kludge
   if there are reasonable ways to do it?
   
I have the same argument here. Keeping three files instead of two
is more complex. As a programmer you have to pay for this
complexity and it doesn't buy you anything. The result is that
people do not write interfaces because they do not like the
additional effort it requires. 


Bye,

Hendrik
-------------------
To unsubscribe, mail caml-list-request@inria.fr.  Archives: http://caml.inria.fr