Goswin von Brederlow wrote:
Which would also need
module A1 = new module A
module A2 = new module A
A1.incr_x ()
A1.get_x;;
- : int = 124
A2.get_x ();;
- : int = 123
So you see A does not have global variables but only instance
variables. What you describe are ocaml objects. Not
Ashish Agarwal wrote:
The module type exists, it's just that it doesn't have a name.
Right, thanks for the clarification.
let x = (123, abc)
does not define type x = int * string either.
True, but I think the expectations are different for module types. A
file a.ml http://a.ml
Jon Harrop j...@ffconsultancy.com writes:
On Sunday 19 April 2009 22:36:12 Ashish Agarwal wrote:
Having the compiler introduce module type names automatically from mli
files would be very helpful, and I don't see any disadvantages.
Some people contest the idea that files should automatically
Martin Jambon martin.jam...@ens-lyon.org writes:
OK, but I think the real issue is inheritance. In order to truly extend an
existing module, one needs to access the private items of the inherited module
implementation. In order to avoid messing up with the original module's
global
Hi...
I have a quick question. I want to extend the List module with various
functions that I want that aren't present in the standard library,
much as the Batteries ExtList library does.
I might write the following code in mylibrary.ml:
module MyList = struct
include List
let foo x = ...
Peter Hawkins hawki...@cs.stanford.edu writes:
Hi...
I have a quick question. I want to extend the List module with various
functions that I want that aren't present in the standard library,
much as the Batteries ExtList library does.
I might write the following code in mylibrary.ml:
This is a commonly requested feature. One issue is that a file a.ml creates
a module A. However, a file a.mli does not create a module type A. I'm not
sure why this is the case. Does anyone know if there is a specific reason?
On Fri, Apr 17, 2009 at 4:51 PM, Peter Hawkins
