[Caml-list] Meta module in findlib and the need for namespaces

[Caml-list] Meta module in findlib and the need for namespaces

[Alessandro Baretta]

There seems to be an incompatibility between dynlink.cma and 
findlib. The following text shows a sample toplevel session 
where you can see how linking to "dynlink.cma" is rendered 
impossible by the presence of the findlib module.

         Objective Caml version 3.06

# #use "topfind";;
Findlib has been successfully loaded. Additional directives:
   #require "package";;      to load a package
   #list;;                   to list the available packages
   #camlp4o;;                to load camlp4 (standard syntax)
   #camlp4r;;                to load camlp4 (revised syntax)
   Topfind.reset();;         to force that packages will be 
reloaded

- : unit = ()
# #require "afo";;
Loading /usr/lib/ocaml/site-lib/pcre/pcre.cma
Loading /usr/lib/ocaml/unix.cma
Loading /usr/lib/ocaml/site-lib/netstring/netstring.cma
Loading /usr/lib/ocaml/site-lib/netstring/netmappings_iso.cmo
Loading /usr/lib/ocaml/site-lib/netstring/netmappings_other.cmo
Loading /usr/lib/ocaml/site-lib/netstring/netstring_top.cmo
Loading /usr/lib/ocaml/site-lib/pxp-engine/pxp_engine.cma
Loading /usr/lib/ocaml/site-lib/pxp-engine/pxp_top.cmo
Loading 
/usr/lib/ocaml/site-lib/pxp-lex-iso88591/pxp_lex_iso88591.cma
Loading 
/usr/lib/ocaml/site-lib/pxp-lex-iso88591/pxp_lex_link_iso88591.cmo
Loading /usr/lib/ocaml/site-lib/pxp-lex-utf8/pxp_lex_utf8.cma
Loading 
/usr/lib/ocaml/site-lib/pxp-lex-utf8/pxp_lex_link_utf8.cmo
*Loading /usr/lib/ocaml/dynlink.cma*
Files /usr/lib/ocaml/dynlink.cma
and /usr/lib/ocaml/site-lib/findlib/findlib.cma
make inconsistent assumptions over interface Meta

This seems to imply that a Meta module is already defined in 
  dynlink.cma, and that such module is different from that 
referenced by findlib. I have no evidence to prove this 
point though, for I have not found in the Ocaml sources 
where a Meta module is defined.

***

This incompatibility between findlib and dynlink is the 
first example I have encountered of a nameclash bug in Ocaml 
software. Of course, Gerd could easily solve the problem by 
renaming his Meta to Findlib_meta, or something like that, 
but it would be a lot easier to have a namespace construct 
to allow Gerd to distinguish *his* Meta from the one in the 
standard library.

Cheers to everyone,
Alex

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Meta module in findlib and the need for namespaces

[Gerd Stolpmann]

Hi, 

Am 2002.09.17 16:47 schrieb(en) Alessandro Baretta:
> There seems to be an incompatibility between dynlink.cma and 
> findlib. The following text shows a sample toplevel session 
> where you can see how linking to "dynlink.cma" is rendered 
> impossible by the presence of the findlib module.
> 
>          Objective Caml version 3.06
> 
> # #use "topfind";;
> Findlib has been successfully loaded. Additional directives:
>    #require "package";;      to load a package
>    #list;;                   to list the available packages
>    #camlp4o;;                to load camlp4 (standard syntax)
>    #camlp4r;;                to load camlp4 (revised syntax)
>    Topfind.reset();;         to force that packages will be 
> reloaded
> 
> - : unit = ()
> # #require "afo";;
> Loading /usr/lib/ocaml/site-lib/pcre/pcre.cma
> Loading /usr/lib/ocaml/unix.cma
> Loading /usr/lib/ocaml/site-lib/netstring/netstring.cma
> Loading /usr/lib/ocaml/site-lib/netstring/netmappings_iso.cmo
> Loading /usr/lib/ocaml/site-lib/netstring/netmappings_other.cmo
> Loading /usr/lib/ocaml/site-lib/netstring/netstring_top.cmo
> Loading /usr/lib/ocaml/site-lib/pxp-engine/pxp_engine.cma
> Loading /usr/lib/ocaml/site-lib/pxp-engine/pxp_top.cmo
> Loading 
> /usr/lib/ocaml/site-lib/pxp-lex-iso88591/pxp_lex_iso88591.cma
> Loading 
> /usr/lib/ocaml/site-lib/pxp-lex-iso88591/pxp_lex_link_iso88591.cmo
> Loading /usr/lib/ocaml/site-lib/pxp-lex-utf8/pxp_lex_utf8.cma
> Loading 
> /usr/lib/ocaml/site-lib/pxp-lex-utf8/pxp_lex_link_utf8.cmo
> *Loading /usr/lib/ocaml/dynlink.cma*
> Files /usr/lib/ocaml/dynlink.cma
> and /usr/lib/ocaml/site-lib/findlib/findlib.cma
> make inconsistent assumptions over interface Meta
> 
> This seems to imply that a Meta module is already defined in 
>   dynlink.cma, and that such module is different from that 
> referenced by findlib. I have no evidence to prove this 
> point though, for I have not found in the Ocaml sources 
> where a Meta module is defined.

There is a module "Meta" in the byte compiler, and it is member of
dynlink.cma. So your observation is right.

> ***
> 
> This incompatibility between findlib and dynlink is the 
> first example I have encountered of a nameclash bug in Ocaml 
> software. Of course, Gerd could easily solve the problem by 
> renaming his Meta to Findlib_meta, or something like that, 
> but it would be a lot easier to have a namespace construct 
> to allow Gerd to distinguish *his* Meta from the one in the 
> standard library.

I think there are two problems:

(1) The name clash as such
(2) The fact that dynlink.cma contains a hidden module (no cmi is
    installed for it), making the name clash surprising and hard
    to debug.

Note that dynlink.cma not only contains Meta, but also other modules
with plain names: Misc, Config, Ident, Path, Types, i.e. names for
which name clashes are much more likely than for cryptic names.

Maybe problem (2) can be fixed by using "include" to link the needed
compiler modules to Dynlink, i.e. something like

module Meta = struct include Meta end

so Meta would not occur in dynlink.cma anymore.

Gerd

------------------------------------------------------------
Gerd Stolpmann * Viktoriastr. 45 * 64293 Darmstadt * Germany 
gerd@gerd-stolpmann.de          http://www.gerd-stolpmann.de
------------------------------------------------------------
-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

We should start using -pack by default when building libraries, (was : Re: [Caml-list] Meta module in findlib and the need for namespaces)

[Sven LUTHER]

On Sun, Sep 22, 2002 at 11:29:20PM +0200, Gerd Stolpmann wrote:
> Hi, 
> > This incompatibility between findlib and dynlink is the 
> > first example I have encountered of a nameclash bug in Ocaml 
> > software. Of course, Gerd could easily solve the problem by 
> > renaming his Meta to Findlib_meta, or something like that, 
> > but it would be a lot easier to have a namespace construct 
> > to allow Gerd to distinguish *his* Meta from the one in the 
> > standard library.
> 
> I think there are two problems:
> 
> (1) The name clash as such
> (2) The fact that dynlink.cma contains a hidden module (no cmi is
>     installed for it), making the name clash surprising and hard
>     to debug.
> 
> Note that dynlink.cma not only contains Meta, but also other modules
> with plain names: Misc, Config, Ident, Path, Types, i.e. names for
> which name clashes are much more likely than for cryptic names.

Well, is it not for exactly this kind of problems that the -pack option
was implemented ? Would it not solve all this kind of problem if it
would be a standard that all libraries should be using the -pack option
for including their modules, thus having a Dynlink.Meta, Dynlink.Misc,
Dynlink.Config, ... (and also i guess findlib would then have a
Findlib.Meta or something such ?).

Sure this would cause a bit of backward compatibility, but nothing that
could not be solved by a simple open at the begining of the sources, and
it would also most probably help solving much of the 'namespace'
discution that happens here from time to time.

What do you all think about this, is this a valuable solution, or are
there profound reason for not going that way ? 

Friendly,

Sven Luther
-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: We should start using -pack by default when building libraries, (was : Re: [Caml-list] Meta module in findlib and the need for namespaces)

[Xavier Leroy]

> > Note that dynlink.cma not only contains Meta, but also other modules
> > with plain names: Misc, Config, Ident, Path, Types, i.e. names for
> > which name clashes are much more likely than for cryptic names.
> 
> Well, is it not for exactly this kind of problems that the -pack option
> was implemented ?

Yes, exactly.

> Would it not solve all this kind of problem if it
> would be a standard that all libraries should be using the -pack option
> for including their modules, thus having a Dynlink.Meta, Dynlink.Misc,
> Dynlink.Config, ... (and also i guess findlib would then have a
> Findlib.Meta or something such ?).
> Sure this would cause a bit of backward compatibility, but nothing that
> could not be solved by a simple open at the begining of the sources, and
> it would also most probably help solving much of the 'namespace'
> discution that happens here from time to time.

In the case of Dynlink, it's even better than this: the Misc, Meta,
etc, compiler modules that it imports are used purely internally and
need not be re-exported to the user, so we can keep the old API by
having just two modules, Dynlink (the user-visible API) and
Dynlink_internal_impossibly_long_name (a "pack" of the compiler
modules that Dynlink needs).

For other existing libraries, backward compatibility can deter using
-pack, but I'd encourage authors of new libraries to use it in order
to export only one compilation unit.

- Xavier Leroy
-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: We should start using -pack by default when building libraries, (was : Re: [Caml-list] Meta module in findlib and the need for namespaces)

[Sven LUTHER]

On Mon, Sep 23, 2002 at 04:36:19PM +0200, Xavier Leroy wrote:
> > > Note that dynlink.cma not only contains Meta, but also other modules
> > > with plain names: Misc, Config, Ident, Path, Types, i.e. names for
> > > which name clashes are much more likely than for cryptic names.
> > 
> > Well, is it not for exactly this kind of problems that the -pack option
> > was implemented ?
> 
> Yes, exactly.

:)))

> For other existing libraries, backward compatibility can deter using
> -pack, but I'd encourage authors of new libraries to use it in order
> to export only one compilation unit.

Could we consider making using -pack the standard for a future version of
ocaml (3.07) and add a -nopack version for those that don't want to use
it, especially when building .cmas ?

This would need a bit of discussion first, but mostly, i don't think
anyone would object to this, at least not very strongly.

That said ...

John Carr <jfc@MIT.EDU> Wrote :

| OCaml 3.06 does not support -pack when using native code on a system
| without the GNU linker.  If you release software that depends on -pack,
| I will not be able to use it.

Well, this would cause a problem, which need to be solved before -pack
is supported as standard. What are exactly the cases were it causes
problem, (AIX when not using the GNU linker, i guess, but also maybe
windows ?) and is there any chance this can be solved soonly ?

Alternatively, this could be a feature that could be enabled/disabled at
build time ?

Friendly,

Sven Luther

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

[Caml-list] Re: We should start using -pack by default when building libraries, (was : Re: Meta module in findlib and the need for namespaces)

[Michaël Grünewald]

Sven LUTHER <luther@dpt-info.u-strasbg.fr> writes:

> On Mon, Sep 23, 2002 at 04:36:19PM +0200, Xavier Leroy wrote:
> > > > Note that dynlink.cma not only contains Meta, but also other modules
> > > > with plain names: Misc, Config, Ident, Path, Types, i.e. names for
> > > > which name clashes are much more likely than for cryptic names.
> > > 
> > > Well, is it not for exactly this kind of problems that the -pack option
> > > was implemented ?
> > 
> > Yes, exactly.
> 
> :)))
> 
> > For other existing libraries, backward compatibility can deter using
> > -pack, but I'd encourage authors of new libraries to use it in order
> > to export only one compilation unit.
> 
> Could we consider making using -pack the standard for a future version of
> ocaml (3.07) and add a -nopack version for those that don't want to use
> it, especially when building .cmas ?

> This would need a bit of discussion first, but mostly, i don't think
> anyone would object to this, at least not very strongly.

So every unmaintained code and Makefiles becomes all suddenly obsoletes ?
This is a really bad thing to do things like this, and it is so easy to
write wrappers scripts over the compiler, so it has defaults suitable for
your needs ... There is no need to modify standards for that.

> That said ...
> 
> John Carr <jfc@MIT.EDU> Wrote :
> 
> | OCaml 3.06 does not support -pack when using native code on a system
> | without the GNU linker.  If you release software that depends on -pack,
> | I will not be able to use it.
> 
> Well, this would cause a problem, which need to be solved before -pack
> is supported as standard. What are exactly the cases were it causes
> problem, (AIX when not using the GNU linker, i guess, but also maybe
> windows ?) and is there any chance this can be solved soonly ?
> 
> Alternatively, this could be a feature that could be enabled/disabled at
> build time ?

E.g. with the `-pack' option ? :)
-- 
Michaël Grünewald <michael-grunewald@wanadoo.fr>  - RSA PGP Key ID: 0x20D90C12
-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Re: We should start using -pack by default when building libraries, (was : Re: Meta module in findlib and the need for namespaces)

[Sven LUTHER]

On Wed, Sep 25, 2002 at 06:48:19AM +0200, Michaël Grünewald wrote:
> Sven LUTHER <luther@dpt-info.u-strasbg.fr> writes:
> 
> > On Mon, Sep 23, 2002 at 04:36:19PM +0200, Xavier Leroy wrote:
> > > > > Note that dynlink.cma not only contains Meta, but also other modules
> > > > > with plain names: Misc, Config, Ident, Path, Types, i.e. names for
> > > > > which name clashes are much more likely than for cryptic names.
> > > > 
> > > > Well, is it not for exactly this kind of problems that the -pack option
> > > > was implemented ?
> > > 
> > > Yes, exactly.
> > 
> > :)))
> > 
> > > For other existing libraries, backward compatibility can deter using
> > > -pack, but I'd encourage authors of new libraries to use it in order
> > > to export only one compilation unit.
> > 
> > Could we consider making using -pack the standard for a future version of
> > ocaml (3.07) and add a -nopack version for those that don't want to use
> > it, especially when building .cmas ?
> 
> > This would need a bit of discussion first, but mostly, i don't think
> > anyone would object to this, at least not very strongly.
> 
> So every unmaintained code and Makefiles becomes all suddenly obsoletes ?

unmaintained code is not good to have around anyway, it will most
probably break some in the future anyway (when there is a ocaml 4.0 for
example ?).

> This is a really bad thing to do things like this, and it is so easy to
> write wrappers scripts over the compiler, so it has defaults suitable for
> your needs ... There is no need to modify standards for that.

But the change is only adding the appropriate open at the top of the
files, i guess it could even be done with automatic translation or
something such.

Also, i guess the Pervasive library will be opened by default, and maybe
also the standard library.

This namespace problem is one that ocaml was having since a long time,
and which will become only worse as time passes and more library will be
written. So are you saying that we should stay with something that will
cause more and more problem as time passes, just because some obsolete
and unmaintained code will break in this case ? 

Anyway, this can be done in a painless incremental way.

We decide that starting now, all libraries should use the -pack option
when it is possible, and slowly migrate to using that for the existing
code, but still keep the default behavior as usual. Later, when we are
satisfied that it works well and most libraries are ported to using
-pack (and the acompanying code using it also), we can modify the
behavior to use -pack by default for libraries.

And btw, it is more natural to write, for example Gdk.Event.Button than
GdkEvent.Button, as we do now, don't you think ?

> > That said ...
> > 
> > John Carr <jfc@MIT.EDU> Wrote :
> > 
> > | OCaml 3.06 does not support -pack when using native code on a system
> > | without the GNU linker.  If you release software that depends on -pack,
> > | I will not be able to use it.
> > 
> > Well, this would cause a problem, which need to be solved before -pack
> > is supported as standard. What are exactly the cases were it causes
> > problem, (AIX when not using the GNU linker, i guess, but also maybe
> > windows ?) and is there any chance this can be solved soonly ?
> > 
> > Alternatively, this could be a feature that could be enabled/disabled at
> > build time ?
> 
> E.g. with the `-pack' option ? :)

At build time of the ocaml compiler suite, with a configure option, so
that you could build an ocaml suite to either use -pack by default or
not, and a ocamlc option to return the default used pack option, so you
could use it to write the libraries accordyingly (well, maybe this is
not easily).

Friendly,

Sven Luther
-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

[Caml-list] Re: We should start using -pack by default when building libraries, (was : Re: Meta module in findlib and the need for namespaces)

[Michaël Grünewald]

Sven LUTHER <luther@dpt-info.u-strasbg.fr> writes:

> > So every unmaintained code and Makefiles becomes all suddenly obsoletes ?
> 
> unmaintained code is not good to have around anyway, it will most
> probably break some in the future anyway (when there is a ocaml 4.0 for
> example ?).

Oc :)

> > 
> > This is a really bad thing to do things like this, and it is so easy to
> > write wrappers scripts over the compiler, so it has defaults suitable for
> > your needs ... There is no need to modify standards for that.
> 
> But the change is only adding the appropriate open at the top of the
> files, i guess it could even be done with automatic translation or
> something such.
> 
> Also, i guess the Pervasive library will be opened by default, and maybe
> also the standard library.
> 
> This namespace problem is one that ocaml was having since a long time,
> and which will become only worse as time passes and more library will be
> written. So are you saying that we should stay with something that will
> cause more and more problem as time passes, just because some obsolete
> and unmaintained code will break in this case ? 
> 
> Anyway, this can be done in a painless incremental way.
> 
> We decide that starting now, all libraries should use the -pack option
> when it is possible, and slowly migrate to using that for the existing
> code, but still keep the default behavior as usual. Later, when we are
> satisfied that it works well and most libraries are ported to using
> -pack (and the acompanying code using it also), we can modify the
> behavior to use -pack by default for libraries.

But what if you compile only one module ? If you compile a.ml 
ocamlc -c -o unnom.cmo a.cmo
will act like
ocamlc -pack -o unnom.cmo -c a.cmo and 
i will have to access the A module through Unnom.A which is very disturbing,
isn't it ?

I cannot understand why you wish a so strange behaviour, and

- think that it is disturbing for beginners that use a compiler for the
  first time, and ask them to read more doc on something that is not clearly
  needed, so it makes more magic

- wonder why you do not want use something like a makefile, and change your
  compiler with $(OCAMLC) and having `OCAMLC=ocamlc -pack' if you really
  find it useful. 

- am leaded to think you try to set something that will coerce the users to
  use a special type of organisation in their developpement (such as
  namespace), in the ways of passivity, so that default behaviour is oc, and
  since it is easier to do nothing than to do something, default will be
  followed. This way has a lot of horrible names i do not want to write
  here. It is better to convince every one this design is a good and shioul
  be used, because people must do things they want (keywords are they and
  want).

> And btw, it is more natural to write, for example Gdk.Event.Button than
> GdkEvent.Button, as we do now, don't you think ?

I do think so. But what has it to do with the `pack option enabled by
default' ?

> > > That said ...
> > > 
> > > John Carr <jfc@MIT.EDU> Wrote :
> > > 
> > > | OCaml 3.06 does not support -pack when using native code on a system
> > > | without the GNU linker.  If you release software that depends on -pack,
> > > | I will not be able to use it.
> > > 
> > > Well, this would cause a problem, which need to be solved before -pack
> > > is supported as standard. What are exactly the cases were it causes
> > > problem, (AIX when not using the GNU linker, i guess, but also maybe
> > > windows ?) and is there any chance this can be solved soonly ?
> > > 
> > > Alternatively, this could be a feature that could be enabled/disabled at
> > > build time ?
> > 
> > E.g. with the `-pack' option ? :)
> 
> At build time of the ocaml compiler suite, with a configure option, so
> that you could build an ocaml suite to either use -pack by default or
> not, and a ocamlc option to return the default used pack option, so you
> could use it to write the libraries accordyingly (well, maybe this is
> not easily).

This sounds hairy (i mean: i am frightened !) ! 

How can you write Makefile that can compile an application on any
installation, when the change you eask about is applied (if i understand
it). 

you determine if the default behaviour is to pack or not to
you set a variable OCAMLC according to what you expect the compiler to do.
you use the OCAMLC variable in the place of `ocamlc' program

When it is not, and you want the apck option being ysed:
you set a variable OCAMLC=ocamlc -pack
you use the OCAMLC variable in the place of `ocamlc' program

What is the simplest ? 

As you may noticed, i REALLY do not understand WHY you want the pack option
enabled by default (and it sounds really stupid to me, as i tried to
demonstrate it. I am not professional developper, so my point of view on
these problems might be more `naive' than yours, so be patient ... :) )

Friendly,
-- 
Michaël Grünewald <michael-grunewald@wanadoo.fr>  - RSA PGP Key ID: 0x20D90C12
-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Re: We should start using -pack by default when building libraries, (was : Re: Meta module in findlib and the need for namespaces)

[Sven]

On Wed, Sep 25, 2002 at 09:33:32PM +0200, Micha?l Gr?newald wrote:
> Sven LUTHER <luther@dpt-info.u-strasbg.fr> writes:
> 
> > > So every unmaintained code and Makefiles becomes all suddenly obsoletes ?
> > 
> > unmaintained code is not good to have around anyway, it will most
> > probably break some in the future anyway (when there is a ocaml 4.0 for
> > example ?).
> 
> Oc :)
> 
> > > 
> > > This is a really bad thing to do things like this, and it is so easy to
> > > write wrappers scripts over the compiler, so it has defaults suitable for
> > > your needs ... There is no need to modify standards for that.
> > 
> > But the change is only adding the appropriate open at the top of the
> > files, i guess it could even be done with automatic translation or
> > something such.
> > 
> > Also, i guess the Pervasive library will be opened by default, and maybe
> > also the standard library.
> > 
> > This namespace problem is one that ocaml was having since a long time,
> > and which will become only worse as time passes and more library will be
> > written. So are you saying that we should stay with something that will
> > cause more and more problem as time passes, just because some obsolete
> > and unmaintained code will break in this case ? 
> > 
> > Anyway, this can be done in a painless incremental way.
> > 
> > We decide that starting now, all libraries should use the -pack option
> > when it is possible, and slowly migrate to using that for the existing
> > code, but still keep the default behavior as usual. Later, when we are
> > satisfied that it works well and most libraries are ported to using
> > -pack (and the acompanying code using it also), we can modify the
> > behavior to use -pack by default for libraries.
> 
> But what if you compile only one module ? If you compile a.ml 
> ocamlc -c -o unnom.cmo a.cmo
> will act like
> ocamlc -pack -o unnom.cmo -c a.cmo and 
> i will have to access the A module through Unnom.A which is very disturbing,
> isn't it ?

Well, no, it would be used by default only when building libraries (.cma
and such).

So suppose you have a library calle Lib, which is composed of modules A, B
and C.

you would build A, B and C normally, and then do :

ocamlmklib -pack -o lib.cma a.cmo b.cmo c.cmo, 

And then use the modules as :

Lib.A, Lib.B, Lib.C, or even just do an open Lib at the begining of the
source, and continue to use A, B and C normally.

This would enable the libraries to have a private namespace, and thus
you would have no problem with reusing names already used in other
libraries (like the Meta we were discusing here).

This will in no way affect the build of standalone .cmo.

> I cannot understand why you wish a so strange behaviour, and

Does it makes more sense if limited to libraries ?

> - think that it is disturbing for beginners that use a compiler for the
>   first time, and ask them to read more doc on something that is not clearly
>   needed, so it makes more magic

Well, It seems natural enough to me, that if you have a library called
Gtk for example, containing a module Main, then you would use it as
Gtk.Main.

Also, beginners don't usually build libraries, so they will not be
affected at all.

> - wonder why you do not want use something like a makefile, and change your
>   compiler with $(OCAMLC) and having `OCAMLC=ocamlc -pack' if you really
>   find it useful. 

No, the problem is that we want each library to use its own namespace,
so that there is no namespace polution, this has nothing whatsoever to
do with makefiles. 

Alternatively, we could keep the compiler as is, and decide that the
standard for libraries would be to use the -pack option. This would not
need any change to the way the compiler works, but would need for
libraries authors to do more advanced makefile stuff to build the
libraries, and not everyone will maybe bother to do it.

> - am leaded to think you try to set something that will coerce the users to
>   use a special type of organisation in their developpement (such as
>   namespace), in the ways of passivity, so that default behaviour is oc, and
>   since it is easier to do nothing than to do something, default will be
>   followed. This way has a lot of horrible names i do not want to write
>   here. It is better to convince every one this design is a good and shioul
>   be used, because people must do things they want (keywords are they and
>   want).
> 
> > And btw, it is more natural to write, for example Gdk.Event.Button than
> > GdkEvent.Button, as we do now, don't you think ?
> 
> I do think so. But what has it to do with the `pack option enabled by
> default' ?

Like i said before, because the enabling by default is only for building
.cmas. Sorry about the confussion.

> > > > That said ...
> > > > 
> > > > John Carr <jfc@MIT.EDU> Wrote :
> > > > 
> > > > | OCaml 3.06 does not support -pack when using native code on a system
> > > > | without the GNU linker.  If you release software that depends on -pack,
> > > > | I will not be able to use it.
> > > > 
> > > > Well, this would cause a problem, which need to be solved before -pack
> > > > is supported as standard. What are exactly the cases were it causes
> > > > problem, (AIX when not using the GNU linker, i guess, but also maybe
> > > > windows ?) and is there any chance this can be solved soonly ?
> > > > 
> > > > Alternatively, this could be a feature that could be enabled/disabled at
> > > > build time ?
> > > 
> > > E.g. with the `-pack' option ? :)
> > 
> > At build time of the ocaml compiler suite, with a configure option, so
> > that you could build an ocaml suite to either use -pack by default or
> > not, and a ocamlc option to return the default used pack option, so you
> > could use it to write the libraries accordyingly (well, maybe this is
> > not easily).
> 
> This sounds hairy (i mean: i am frightened !) ! 

Yes, sure, better to have it all work for all plateforms ...

> How can you write Makefile that can compile an application on any
> installation, when the change you eask about is applied (if i understand
> it). 

With conditional rules depending on the result of ocamlc -pack-default
or something such ?

> you determine if the default behaviour is to pack or not to
> you set a variable OCAMLC according to what you expect the compiler to do.
> you use the OCAMLC variable in the place of `ocamlc' program

Or like that also, but the definition of OCAMLC could be conditional.
And anyway, it would be ocamlmklib which we redefine.

> When it is not, and you want the apck option being ysed:
> you set a variable OCAMLC=ocamlc -pack
> you use the OCAMLC variable in the place of `ocamlc' program
> 
> What is the simplest ? 
> 
> As you may noticed, i REALLY do not understand WHY you want the pack option
> enabled by default (and it sounds really stupid to me, as i tried to
> demonstrate it. I am not professional developper, so my point of view on
> these problems might be more `naive' than yours, so be patient ... :) )

Ok, i hope this mail will lift the misunderstanding now.

Friendly,

Sven Luther
-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

[Caml-list] Re: We should start using -pack by default when building libraries, (was : Re: Meta module in findlib and the need for namespaces)

[Michaël Grünewald]

Sven <luther@dpt-info.u-strasbg.fr> writes:

[...]

> > But what if you compile only one module ? If you compile a.ml ocamlc -c
> > -o unnom.cmo a.cmo will act like ocamlc -pack -o unnom.cmo -c a.cmo and
> > i will have to access the A module through Unnom.A which is very
> > disturbing, isn't it ?
> 
> Well, no, it would be used by default only when building libraries (.cma
> and such).

This makes more sense when limiting this behaviour to libraries

[...]

> > I cannot understand why you wish a so strange behaviour, and
> 
> Does it makes more sense if limited to libraries ?

Yes it does !


[...]

> Like i said before, because the enabling by default is only for building
> .cmas. Sorry about the confussion.

Confussion has been wiped out :)

[...]

> > This sounds hairy (i mean: i am frightened !) ! 
> 
> Yes, sure, better to have it all work for all plateforms ...
> 
> > How can you write Makefile that can compile an application on any
> > installation, when the change you eask about is applied (if i understand
> > it). 
> 
> With conditional rules depending on the result of ocamlc -pack-default
> or something such ?

This will lead users to write more advanced makefile stuff, they will not
necessarily bother.

> > you determine if the default behaviour is to pack or not to
> > you set a variable OCAMLC according to what you expect the compiler to do.
> > you use the OCAMLC variable in the place of `ocamlc' program
> 
> Or like that also, but the definition of OCAMLC could be conditional.
> And anyway, it would be ocamlmklib which we redefine.

Oc.


[...]

> Ok, i hope this mail will lift the misunderstanding now.

It did !
> 
> Friendly,

Bye !
-- 
Michaël Grünewald <michael-grunewald@wanadoo.fr>  - RSA PGP Key ID: 0x20D90C12
-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

[Caml-list] Re: We should start using -pack by default when building libraries

[John Carr]

> What do you all think about this, is this a valuable solution, or are
> there profound reason for not going that way ? 


OCaml 3.06 does not support -pack when using native code on a system
without the GNU linker.  If you release software that depends on -pack,
I will not be able to use it.


A few thoughts on this topic:

1. The AIX linker can rename symbols, so AIX could be supported.

2. I may write a tool to rename symbols in an ELF object.

3. There are alternate implementations of the -pack concept that
do not require symbol renaming.  In particular, the container
module could be specified as an option to ocamlopt -c.

4. There is a conjecture that any computer science problem can be
solved by adding an additional level of indirection.

5. From experience, I can tell you that it takes significant effort to
make a linker-dependent feature work with many different linkers, even
when they all have the necessary functions.  (I was controlling symbol
visibility and early vs. late binding in shared libraries -- even the
linkers derived from SVR4 had evolved different syntax and control file
formats.)


-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners