RE: [Caml-list] Namespace proposal

RE: [Caml-list] Namespace proposal

[Gurr, David (MED, self)]

> -----Original Message-----
> From: Vitaly Lugovsky [mailto:vsl@ontil.ihep.su]
> Sent: Thursday, August 15, 2002 10:00 AM
> To: Gurr, David (MED, self)
> Cc: Yurii A. Rashkovskii; caml-list@inria.fr
> Subject: RE: [Caml-list] Namespace proposal
> 
> 
> On Thu, 15 Aug 2002, Gurr, David (MED, self) wrote:
> 
> > My two cents worth: Please dont copy package ideas from 
> > languages that lack functors.  And Java's package ==
> > directory idea is far from beloved by all.  -D
> 
>  For me package is not a modules collection, but just
> a way of multi-word module naming. It's not so easy to
> give short and still adequate names to the modules, but
> something like Db.Core.Storage looks much better then
> Dbstorage, and Storage can still be accessed just as
> "Storage" from modules of the same "package". Just a naming
> way, nothing more.

And what happens when you need to abstract over a module/sub-package? -D
-------------------
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] Namespace proposal

[Vitaly Lugovsky]

On Thu, 15 Aug 2002, Gurr, David (MED, self) wrote:

> > > My two cents worth: Please dont copy package ideas from 
> > > languages that lack functors.  And Java's package ==
> > > directory idea is far from beloved by all.  -D
> > 
> >  For me package is not a modules collection, but just
> > a way of multi-word module naming. It's not so easy to
> > give short and still adequate names to the modules, but
> > something like Db.Core.Storage looks much better then
> > Dbstorage, and Storage can still be accessed just as
> > "Storage" from modules of the same "package". Just a naming
> > way, nothing more.
> 
> And what happens when you need to abstract over a module/sub-package? -D

 No subpackages. Dots in the name does not mean any hierarchy - but just
a "name search path" hints. Just the same modules as we have now, but with
a slightly more intelligent way of name resolving.




-------------------
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] Namespace proposal

[Yurii A. Rashkovskii]

Hi Vitaly!

On Thu, 15 Aug 2002, Vitaly Lugovsky wrote:

>  No subpackages. Dots in the name does not mean any hierarchy - but just
> a "name search path" hints. Just the same modules as we have now, but with
> a slightly more intelligent way of name resolving.

I agree with directory packaging

-- 
Regards,
Yurii.
-------------------
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] Namespace proposal

[M E Leypold @ labnet]

Vitaly Lugovsky writes:


 > 
 >  No subpackages. Dots in the name does not mean any hierarchy - but just
 > a "name search path" hints. Just the same modules as we have now, but with
 > a slightly more intelligent way of name resolving.


'name resolving' and 'path search' should be part of the surrounding
build system, not the language. I do not want to see any (build time)
paths in my *.ml source files.

Regards -- Markus

-------------------
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] Namespace proposal

[Vitaly Lugovsky]

On Fri, 16 Aug 2002, M E Leypold @ labnet wrote:

>  >  No subpackages. Dots in the name does not mean any hierarchy - but just
>  > a "name search path" hints. Just the same modules as we have now, but with
>  > a slightly more intelligent way of name resolving.
> 
> 
> 'name resolving' and 'path search' should be part of the surrounding
> build system, not the language. I do not want to see any (build time)
> paths in my *.ml source files.

 Modules are reffered from the *.ml files - so, they may (not "must") have
some hints about the search order. And if we'll have some syntax for this
hints, that will be enough to avoid all the current problems with module 
naming.



-------------------
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] Namespace proposal

[Yurii A. Rashkovskii]

Hi Vitaly!

On Fri, 16 Aug 2002, Vitaly Lugovsky wrote:

>  Modules are reffered from the *.ml files - so, they may (not "must") have
> some hints about the search order. And if we'll have some syntax for this
> hints, that will be enough to avoid all the current problems with module 
> naming.

Can you provide us with an example of such syntax (approx.)?

-- 
Regards,
Yurii.
-------------------
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] Namespace proposal

[Fernando Alegre]

On Thu, Aug 15, 2002 at 12:13:47PM -0500, Gurr, David (MED, self) wrote:
> 
> >  For me package is not a modules collection, but just
> > a way of multi-word module naming. It's not so easy to
> > give short and still adequate names to the modules, but
> > something like Db.Core.Storage looks much better then
> > Dbstorage, and Storage can still be accessed just as
> > "Storage" from modules of the same "package". Just a naming
> > way, nothing more.
> 
> And what happens when you need to abstract over a module/sub-package? -D

I think a naming convention like this is definitely needed, but in order
not to be confused with sub-modules, a different character should be used.
For example:

Db/Core/Storage could be a legal module name (in Db/Core/storage.ml), and
Db.Core.Storage could be a module hierarchy defined in Db.ml, and
Db/Core/Storage.Medium could be a submodule defined in Db/Core/storage.ml,...

An added advantage of this syntax is that it is consistent with the overall
esthetics of the OCaml language (i.e., ugly). :-)

Fernando


-------------------
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] Namespace proposal

[Gurr, David (MED, self)]

>  No subpackages. Dots in the name does not mean any hierarchy 
> - but just
> a "name search path" hints. Just the same modules as we have 
> now, but with
> a slightly more intelligent way of name resolving.

Isnt that the equiv of the universally acclaimed all singing 
acme of perfection Java package == directory system?
-------------------
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] Namespace proposal

[Vitaly Lugovsky]

On Thu, 15 Aug 2002, Gurr, David (MED, self) wrote:

> >  No subpackages. Dots in the name does not mean any hierarchy 
> > - but just
> > a "name search path" hints. Just the same modules as we have 
> > now, but with
> > a slightly more intelligent way of name resolving.
> 
> Isnt that the equiv of the universally acclaimed all singing 
> acme of perfection Java package == directory system?

 No. Please note - I said "hints", not "constraints".



-------------------
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] Namespace proposal

[Gurr, David (MED, self)]

> -----Original Message-----
> From: Fernando Alegre [mailto:fernando@cc.gatech.edu]
> Sent: Thursday, August 15, 2002 10:46 AM
> To: caml-list@inria.fr
> Subject: Re: [Caml-list] Namespace proposal
> 
> 
> On Thu, Aug 15, 2002 at 12:13:47PM -0500, Gurr, David (MED, 
> self) wrote:
> > 
> > >  For me package is not a modules collection, but just
> > > a way of multi-word module naming. It's not so easy to
> > > give short and still adequate names to the modules, but
> > > something like Db.Core.Storage looks much better then
> > > Dbstorage, and Storage can still be accessed just as
> > > "Storage" from modules of the same "package". Just a naming
> > > way, nothing more.
> > 
> > And what happens when you need to abstract over a 
> module/sub-package? -D
> 
> I think a naming convention like this is definitely needed, 
> but in order
> not to be confused with sub-modules, a different character 
> should be used.
> For example:
> 
> Db/Core/Storage could be a legal module name (in 
> Db/Core/storage.ml), and
> Db.Core.Storage could be a module hierarchy defined in Db.ml, and
> Db/Core/Storage.Medium could be a submodule defined in 
> Db/Core/storage.ml,...
> 
> An added advantage of this syntax is that it is consistent 
> with the overall
> esthetics of the OCaml language (i.e., ugly). :-)
> 
> Fernando
> 

I agree with the ugly part.  But it is consistent with
C not OCaml, IMHO. The difference between structures 
(ie first order modules) and packages as far as I can 
see is that you can abstract over modules and you can 
individually type check modules. If you have a language
where abstraction and type checking are non-existent
then packages might be a fine thing.  Separate compilation
for nested modules and a name mangling scheme for their
file names might be useful for OCaml.  -D
 

-------------------
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] Namespace proposal

[Gurr, David (MED, self)]

My two cents worth: Please dont copy package ideas from 
languages that lack functors.  And Java's package ==
directory idea is far from beloved by all.  -D

> -----Original Message-----
> From: Vitaly Lugovsky [mailto:vsl@ontil.ihep.su]
> Sent: Thursday, August 15, 2002 8:53 AM
> To: Yurii A. Rashkovskii
> Cc: caml-list@inria.fr
> Subject: Re: [Caml-list] Namespace proposal
> 
> 
> On Thu, 15 Aug 2002, Yurii A. Rashkovskii wrote:
> 
> > Hi Vitaly!
> > 
> > >  I think that the best and the most natural solution is something
> > > like Java or Python packages...
> > 
> > Well, as it was proposed in original mail :)
> 
>  I mean slightly different approach: no need in any syntax sugar, but
> only using the directory structure. It's much better then cifering 
> package contents and names inside Makefiles, and it does not need any
> significiant modifications to the existing OCaml code.
> 
> 
> 
> -------------------
> 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
-------------------
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] Namespace proposal

[Vitaly Lugovsky]

On Thu, 15 Aug 2002, Gurr, David (MED, self) wrote:

> My two cents worth: Please dont copy package ideas from 
> languages that lack functors.  And Java's package ==
> directory idea is far from beloved by all.  -D

 For me package is not a modules collection, but just
a way of multi-word module naming. It's not so easy to
give short and still adequate names to the modules, but
something like Db.Core.Storage looks much better then
Dbstorage, and Storage can still be accessed just as
"Storage" from modules of the same "package". Just a naming
way, nothing more.




-------------------
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] Namespace proposal

[John Max Skaller]

Gurr, David (MED, self) wrote:

> My two cents worth: Please dont copy package ideas from 
> languages that lack functors.  And Java's package ==
> directory idea is far from beloved by all.  -D

While I agree that 'package == directory' has problems,
languages that do not properly allow installation
of third party packages in such a way as to avoid
name clashes in supporting components, have even
more problems.

Ocaml is in this position. It can't be easily
use in large projects which incorporate many third
party libraries.

Separable installation
is possible but clumbsy (use OCAMLPATH),
but there is no associated mechanism for nameclash avoidance.

In theory, one could use nested modules to avoid nameclashes.
In practice that is out of the question because
it requires all the modules be in one file.

C had exactly the same problem, which is why
C++ added namespaces (independently of
file locations). Python had this problem,
which is why it added packages (dependent on
directory structure).

I personally favour the Eiffel approach because
it is the most flexible -- the dependence of
top level component names on files/directories
is defined by a secondary configuration language.
However, it is a somewhat heavy approach.

One thing is for sure though. The ability to install
third party packages in directories, and the ability
to avoid name clashes in supporting components,
are both required for programming in the large.

Ocaml is so close to a solution: both separable
installation and name clash avoidance are possible,
but the mechanisms cannot be easily integrated.

-- 
John Max Skaller, mailto:skaller@ozemail.com.au
snail:10/1 Toxteth Rd, Glebe, NSW 2037, Australia.
voice:61-2-9660-0850


-------------------
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] Namespace proposal

[Ohad Rodeh]

I liked the "ocaml forever" bit :-).

My personal experience has been that all the <reasonable> modifications
I've requested from the Caml folk were carried out. On the other hand, I
can
easily think of some <non-reasonable> language modifications. As long
as the core developers are willing to listen to the community, I don't
think
there is a big problem.

By the way, I do think we need some kind of package/namespace approach.
My personal contribution was the "emrg" mini-tool, adapted from the
Ensemble
distribution. Also, the Caml team was convinced enough that namespaces were
an issue to add the "-pack" option to v3.05.

Just my two cents,
      Ohad.

-----------------------------------------------------------------------------------

Ohad Rodeh
tel: +972-3-6401641
IBM Haifa, storage research


                                                                                                                                            
                      Michael Vanier                                                                                                        
                      <mvanier@cs.caltech.ed        To:       yrashk@openeas.org                                                            
                      u>                            cc:       caml-list@inria.fr                                                            
                      Sent by:                      Subject:  Re: [Caml-list] Namespace proposal                                            
                      owner-caml-list@pauill                                                                                                
                      ac.inria.fr                                                                                                           
                                                                                                                                            
                                                                                                                                            
                      12/08/2002 20:31                                                                                                      
                                                                                                                                            
                                                                                                                                            




The namespace proposal brings up a related issue.  Is there any interest in
having a more formal process for making requests for enhancements to the
ocaml language analogous to (e.g.) the Python Enhancement Proposals (PEPs)
for python (http://www.python.org/peps) or similar processes for perl,
ruby, and java?  I can see advantages and disadvantages to this approach.
The advantage is that there is an organized record of proposals, commentary
on proposals, etc.  The disadvantage is that I suspect that a lot of
feature requests might be unimplementable or require a huge amount of
research to see if they're implementable (e.g. generically overloaded
operators), as opposed to PEPs, which are generally fairly trivial.  What
do people think?

Ocaml forever,

Mike
-------------------
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




-------------------
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] Namespace proposal

[Vitaly Lugovsky]

On Thu, 15 Aug 2002, Ohad Rodeh wrote:

> Also, the Caml team was convinced enough that namespaces were
> an issue to add the "-pack" option to v3.05.

 I knew it!!! I'm already using this feature to manage modules
in one not so big project (about 50 modules). Before -pack was introduced
I had a very bad headache with modules naming... But even this is not
a complete solution: some namespace info is defined completely in the
Makefiles, not in the source code. And, Makefiles becomes more and more
complex.

 I think that the best and the most natural solution is something
like Java or Python packages...



-------------------
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] Namespace proposal

[Yurii A. Rashkovskii]

Hi Vitaly!

On Thu, 15 Aug 2002, Vitaly Lugovsky wrote:

>  I think that the best and the most natural solution is something
> like Java or Python packages...

Well, as it was proposed in original mail :)


--
Regards,
Yurii.
-------------------
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] Namespace proposal

[Vitaly Lugovsky]

On Thu, 15 Aug 2002, Yurii A. Rashkovskii wrote:

> Hi Vitaly!
> 
> >  I think that the best and the most natural solution is something
> > like Java or Python packages...
> 
> Well, as it was proposed in original mail :)

 I mean slightly different approach: no need in any syntax sugar, but
only using the directory structure. It's much better then cifering 
package contents and names inside Makefiles, and it does not need any
significiant modifications to the existing OCaml code.



-------------------
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] Namespace proposal

[Yurii A. Rashkovskii]

Michael,

Generally I'd like to have organized proposal system for OCaml (I was Python 
fan and l remember advantages of the proposal system :-)

I think that if the proposal system will have argued voting system (so any 
OCaml users could submit their  *argued* votes for or against proposal) it 
will add serious advantage to OCaml. Most of work on judging on proposals 
will be done by volunteers and OCaml maintainers will have enough argues to 
decide whether to accept proposal or not. I think that this will help OCaml 
in spreading it among developers. More, theoretically, volunteers that are 
familiar with OCaml source code could propose ways to implement particular 
feature in order to help OCaml team.

And,  of course, it will be very interesting to hear OCaml maintainers' 
opinion.

-- 
Regards,
Yurii
-------------------
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] Namespace proposal

[Yurii A. Rashkovskii]

Hi,

I'd like to submit a proposal for OCaml namespaces. Any questions, reports 
about my mistakes and so on are welcome :)



OCaml Namespace Proposal
========================

Version: 0.1 (DRAFT)

1. What Is a Namespace?
=======================

Namespace is an approach to assemble all components used for development
in way that will prevent name coincidence.

2. Syntax
=========

Namespace support will add new reserved keyword 'namespace' that will be
used in way indentical to 'module', except that namespaces could not be
parametrized (no polymorphism allowed). Namespace will not be module
replacement.

Example:

namespace Org = struct

   namespace Openeas = struct

      namespace Core = struct
 
        ...

      end

   end

end


The above example creates Org, Org.Openeas and Org.Openeas.Core namespaces.


4. How It Works?
================

To solve the positing problem (preventing name coincidence) namespaces
are subject to be "glued". This means that in case of coincidence of names
namespaces' signatures and structures are glued in two new single one 
signature and structure.

Example:

namespace Org = struct

   namespace Openeas = struct

      namespace Core = struct

         let f x = x

      end

   end

end


namespace Org = struct

   namespace Openeas = struct

      namespace Misc = struct

         let j x = x

      end

   end

end


The above example will define namespaces Org.Openeas.Core and Org.Openeas.Misc
with some functions inside. There we'll get the first benefit - we could 
define
namespaces absolutely independing with coincident names and this will make no
harm for the development.

The next benefit is that we could add functions and objects to existing 
namespace 
wherever.

Since OCaml is a language that pretends to be fully adopted for the "real 
world"
programming, namespaces will add the possibility to construct applications in 
a
more clean way.


5. Some Considerations
======================

In order to make namespaces' implementation easier it is proposed to "glue" 
namespace
structures and signatures only on opening modules that contain namespace(s).

So, for instance, we have module HTTP_Library that contains Org.W3.HTTP 
namespace defined and module FTP_Library that contains 
Net.Sourceforge.CamlFtp namespace defined.

(* Here is no Org.W3.HTTP namespace *)

open HTTP_Library;;

(* Here Org.W3.HTTP namespace is available *)
(* but no Net.Sourceforge.CamlFtp *)

open FTP_Library;;

(* And here Net.Sourceforge.CamlFtp is available *)

-- 
Regards,
Yurii
-------------------
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] Namespace proposal

[Michael Vanier]

The namespace proposal brings up a related issue.  Is there any interest in
having a more formal process for making requests for enhancements to the
ocaml language analogous to (e.g.) the Python Enhancement Proposals (PEPs)
for python (http://www.python.org/peps) or similar processes for perl,
ruby, and java?  I can see advantages and disadvantages to this approach.
The advantage is that there is an organized record of proposals, commentary
on proposals, etc.  The disadvantage is that I suspect that a lot of
feature requests might be unimplementable or require a huge amount of
research to see if they're implementable (e.g. generically overloaded
operators), as opposed to PEPs, which are generally fairly trivial.  What
do people think?

Ocaml forever,

Mike
-------------------
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