Mantis Bug Tracker

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0005658OCamlOCaml internal build/install (Makefiles, configure)public2012-06-19 21:572013-12-05 15:54
Reporterhongboz 
Assigned To 
PrioritynormalSeverityfeatureReproducibilityalways
StatusacknowledgedResolutionopen 
PlatformOSOS Version
Product Version 
Target VersionFixed in Version 
Summary0005658: ocaml compiler lib asttypes
Descriptionwhen I derive code mechanically code for ocaml compiler itself.
I have found that asttypes.mli only have interface file without implementation.
It's fine when compiling. but I get an linking error.

Is there any technical difficulties that just rename asttypes.mli to asttypes.ml?
Many thanks
Tagspatch
Attached Filesdiff file icon asttypes.diff [^] (1,113 bytes) 2012-06-19 23:42 [Show Content]

- Relationships

-  Notes
(0007580)
hongboz (developer)
2012-06-19 23:41

I attached the patch. and copied asttypes.ml from asttypes.mli. Maybe you can find one way to keep only one copy.
Many thanks
(0007581)
frisch (developer)
2012-06-20 10:54

Why do you want to link Asttypes? If it doesn't contain any implementation, you should not need to link it.
(0007584)
glondu (reporter)
2012-06-20 12:06

For example, compiling:

> module Foo = struct
> include Asttypes
> end

results in the following error:

> File "toto.ml", line 1, characters 0-1:
> Error: Error while linking toto.cmo:
> Reference to undefined global `Asttypes'
(0007586)
garrigue (manager)
2012-06-20 12:15

module rec Foo : module type of Asttypes = Foo
(0007588)
glondu (reporter)
2012-06-20 12:59

module Bar1 (A : module type of Asttypes) = struct
  type t = A.constant
  let f (x : t) = x
end

module Bar2 = Bar1(Foo)
let bar2 = Bar2.f (Asttypes.Const_int 5)

module Bar3 = Bar1(Asttypes)
let bar3 = Bar3.f (Asttypes.Const_int 5)
(0007591)
hongboz (developer)
2012-06-20 16:53

Thanks for the work around. But is there any bad effect that renaming asttypes.mli into asttypes.ml?
(0007592)
hongboz (developer)
2012-06-20 23:27

my workaround(it's really ugly!!)
module rec Foo: module type of Parsetree with
type core_type = Parsetree.core_type and
type core_type_desc = Parsetree.core_type_desc and
type package_type = Parsetree.package_type and
type core_field_type = Parsetree.core_field_type and
type row_field = Parsetree.row_field and
type 'a class_infos = 'a Parsetree.class_infos and
type pattern = Parsetree.pattern and
type pattern_desc = Parsetree.pattern_desc and
type expression = Parsetree.expression and
type expression_desc = Parsetree.expression_desc and
type value_description = Parsetree.value_description and
type type_declaration = Parsetree.type_declaration and
type type_kind = Parsetree.type_kind and
type exception_declaration = Parsetree.exception_declaration and
type class_type = Parsetree.class_type and
type class_type_desc = Parsetree.class_type_desc and
type class_signature = Parsetree.class_signature and
type class_type_field = Parsetree.class_type_field and
type class_type_field_desc = Parsetree.class_type_field_desc and
type class_description = Parsetree.class_description and
type class_type_declaration = Parsetree.class_type_declaration and
type class_expr = Parsetree.class_expr and
type class_expr_desc = Parsetree.class_expr_desc and
type class_structure = Parsetree.class_structure and
type class_field = Parsetree.class_field and
type class_field_desc = Parsetree.class_field_desc and
type class_declaration = Parsetree.class_declaration and
type module_type = Parsetree.module_type and
type module_type_desc = Parsetree.module_type_desc and
(* type signature = Parsetree.signature and *)
type signature_item = Parsetree.signature_item and
type signature_item_desc = Parsetree.signature_item_desc and
type modtype_declaration = Parsetree.modtype_declaration and
type with_constraint = Parsetree.with_constraint and
type module_expr = Parsetree.module_expr and
type module_expr_desc = Parsetree.module_expr_desc and
(* type structure = Parsetree.structure and *)
type structure_item = Parsetree.structure_item and
type structure_item_desc = Parsetree.structure_item_desc and
type toplevel_phrase = Parsetree.directive_argument
  = Foo
(0007593)
hongboz (developer)
2012-06-20 23:31

I don't see any harm that renaming parsetree.mli and asttypes.mli to .ml. It's really helpful to make the change.
Many thanks
(0007595)
frisch (developer)
2012-06-21 10:39
edited on: 2012-06-21 10:40

When a module contains only static components (types), there is indeed a choice between:
  1. having only an .mli file
  2. having only an .ml file
  3. having both the .ml and the .mli files (identical)

3. is not very nice (at least, the build system should be responsible for copying one file to the other, but then there is always the risk to edit the wrong one and loose the change when recompiling).

I believe that 1. is considered superior to 2., because generally speaking, it is a good idea to have .mli files (and I think this is better for using ocamldoc to generate documentation).

Now, there is one technical problem in that using 1. prevents from rebinding the module (module X = Y). I'm still not sure why you want to do that, but this could be solved quite easily in the compiler, by not creating a reference to an external module when only static components are imported. Here is the patch:

===================================================================
--- bytecomp/translmod.ml	(revision 12623)
+++ bytecomp/translmod.ml	(working copy)
@@ -234,7 +234,9 @@
 
 let rec transl_module cc rootpath mexp =
   match mexp.mod_desc with
-    Tmod_ident (path,_) ->
+  | Tmod_ident _ when Mtype.no_code_needed mexp.mod_env mexp.mod_type ->
+      Lconst (Const_pointer 0)
+  | Tmod_ident (path,_) ->
       apply_coercion cc (transl_path path)
   | Tmod_structure str ->
       transl_struct [] cc rootpath str


Do you think it would solve your problem?

(Note that this patch might change the semantics when compiling without -linkall if the referenced module has side effects.)

(0007598)
hongboz (developer)
2012-06-21 17:18

Thanks. It's pretty cool. plz apply the patch.
Why I need to extend the module is
when the code generator scan the directory for all .cmi files, it generate a new module M which extends module M with some utility functions, for example,pretty printer. Suppose the type definitions in N.cmi contains some type (M.t), the code generator will call M.pp_print_t, so the code generator should be applied to M.cmi which should extend module M.
With this patch, I don't need to have control for the directory parsing/ typing/
(0007605)
frisch (developer)
2012-06-21 19:29

I'm checking with other OCaml developers if they are fine with this solution.
(0007616)
hongboz (developer)
2012-06-27 15:43

is it possible to make the change? I found it's a common idiom to just write mli files for the type definitions among some caml programmers. When I derive the code for dypgen, it's also the same case, they only write parse_tree.mli.
Please apply the patch if possible, many thanks.
(0007723)
frisch (developer)
2012-07-12 05:57

> is it possible to make the change?

Unfortunately, there is no consensus between OCaml developers that the change of semantics is harmless. (Namely, with the patch, a simple reference "module M = X" to a module X with an empty signature does not force X to be linked anymore, if X is part of a library. This can change the semantics if X has side effects.)
(0007732)
hongboz (developer)
2012-07-12 15:10
edited on: 2012-07-12 15:10

thanks, it makes sense. maybe in the long term it would be nice to add some meta-data to highlight functors which have side effect. It's possible to rename all the .mli files which include only type definitions in the directory typing and parsing to .ml files?

I was designing a quotation expander for parsetree and typedtree, it's fine for me to write those equalities by hand, but I may need to sync up when compiler changes which is not interesting.
Sorry for my poor English.
Another question: given -ppx flag is merged into trunk, is it possible that the compile can accept typedtree? I have heard that after -bin-anot merged, it's possible to recover the source information by typedtree, so it also makes sense to do meta-programming in the typedtree level.

(0007733)
frisch (developer)
2012-07-12 16:21

> It's possible to rename all the .mli files which include only type definitions in the directory typing and parsing to .ml files?

I'll let other developers decide on this point, I've no opinion.

> it also makes sense to do meta-programming in the typedtree level.

This is really different from rewriting parsetrees, because people writing the "extension" need to understand very well the data structures manipulated with the type-checker, its invariants, and the APIs. It's easy to break type soundness. An intermediate proposal is OCamlTemplates by Fabrice Le Fessant. IIRC, this is about allowing "quotations" in the parsetree, to be rewritten by dynlinked plugins during type-checking into parse tree fragments. This means the "extension" can use type information, but generated fragments will be type-checked by the regular type-checker. This is a little bit fragile because the extension can still break internal data structures of the type-checker, but still much more robust than allowing it to generate directly (potentially wrong) typed trees.

Anyway, this is rather out of scope for this ticket. Let's discuss that somewhere else!
(0009774)
doligez (administrator)
2013-07-12 17:48

FTR, I don't think it's a good idea to have a .ml without a .mli, and I'd like to avoid this in the compiler sources. I'd rather have both files with identical contents.
(0009776)
lpw25 (developer)
2013-07-14 10:39
edited on: 2013-07-14 10:40

Couldn't we just add the equivalent of:

  ocamlc -c -impl asttypes.mli

to the build instructions?

That seems to work fine on some toy examples.


- Issue History
Date Modified Username Field Change
2012-06-19 21:57 hongboz New Issue
2012-06-19 23:41 hongboz Note Added: 0007580
2012-06-19 23:42 hongboz File Added: asttypes.diff
2012-06-20 10:54 frisch Note Added: 0007581
2012-06-20 12:06 glondu Note Added: 0007584
2012-06-20 12:15 garrigue Note Added: 0007586
2012-06-20 12:59 glondu Note Added: 0007588
2012-06-20 16:53 hongboz Note Added: 0007591
2012-06-20 23:27 hongboz Note Added: 0007592
2012-06-20 23:31 hongboz Note Added: 0007593
2012-06-21 10:39 frisch Note Added: 0007595
2012-06-21 10:39 frisch Note Edited: 0007595 View Revisions
2012-06-21 10:39 frisch Note Edited: 0007595 View Revisions
2012-06-21 10:40 frisch Note Edited: 0007595 View Revisions
2012-06-21 10:40 frisch Note Edited: 0007595 View Revisions
2012-06-21 17:18 hongboz Note Added: 0007598
2012-06-21 19:29 frisch Assigned To => frisch
2012-06-21 19:29 frisch Status new => assigned
2012-06-21 19:29 frisch Note Added: 0007605
2012-06-27 15:43 hongboz Note Added: 0007616
2012-07-12 05:57 frisch Note Added: 0007723
2012-07-12 05:57 frisch Assigned To frisch =>
2012-07-12 05:57 frisch Target Version => 4.01.0+dev
2012-07-12 15:10 hongboz Note Added: 0007732
2012-07-12 15:10 hongboz Note Edited: 0007732 View Revisions
2012-07-12 16:21 frisch Note Added: 0007733
2012-07-31 13:36 doligez Target Version 4.01.0+dev => 4.00.1+dev
2012-09-06 19:32 frisch Target Version 4.00.1+dev => 4.00.2+dev
2013-07-12 17:48 doligez Note Added: 0009774
2013-07-12 17:48 doligez Status assigned => acknowledged
2013-07-12 17:48 doligez Target Version 4.00.2+dev =>
2013-07-14 10:39 lpw25 Note Added: 0009776
2013-07-14 10:40 lpw25 Note Edited: 0009776 View Revisions
2013-12-05 15:54 doligez Tag Attached: patch


Copyright © 2000 - 2011 MantisBT Group
Powered by Mantis Bugtracker