Steven T. Hatton wrote:
> This modules proposal seems attractive to me in its general outlines.
> Clearly the existing document doesn't represent a formal design, and the
> author seems to be seeking opinions and feedback.
>
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1778.pdf
>
> I have one question to begin with:  why not introduce a new keyword
> `module', rather than piggyback on `namespace'?
>
> My speculation is that it's due to the potential for braking existing code
> that already uses 'module' as an an identifier.

Avoiding using a relatively likely identifier is certainly an issue.

However, another important goal is to reinforce the notion that
modules _are_ namespaces.  They have some important properties
(being "closed" is the most important one) that make them slightly
different from the standard ("open") namespaces, but from a client
perspective they are mostly "just namespaces".

This is IMO a critical element of the proposal because:
  - it allows for libraries to be transitioned with no change
     in binary interface (e.g., no new mangling system is
     needed).
  - it allows in almost all cases for third party library
     transitioning without client source changes (the
     exception occurs when the client source explicitly
     defines a namespace extension, but library specs
     typically outlaw that anyway -- the standard library
     does too).
  - very little new teaching is required for client programmers.
  - relatively little new concepts must be handled by library
     coders.

It might be worthwhile to examine your other ideas withing that
perspective too.

I hope that helps,

      Daveed

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Steven T. Hatton escreveu:
> This modules proposal seems attractive to me in its general outlines.
> Clearly the existing document doesn't represent a formal design, and the
> author seems to be seeking opinions and feedback.
>
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1778.pdf
>
(...)
>
> I believe many people will find the use of '<<' objectionable.  Without
> adding a new keyword (or three) to the language, I see no superior
> alternative to overloading '<<'.

I had thought about suggesting "new namespace" to define modules, but
"using new namespace" doesn't work very well :-)

This pattern makes me dizzy:
namespace >> Lib {
  namespace << std;
  ...
}

But, since I don't have a better syntax to suggest, just ignore my
dizziness :-)

Additionally, I would like to suggest two small things:

- If modules will have "void main()", then void should be allowed as
the return type of "traditional-style" main() too... I don't want more
confusion (and flames) about "void main()" :-(
Alternatively, use "int main" in modules too.

- The attribute list syntax and the namespace partition syntax are too
similar (just the position of the square brackets). I think it will be
too easy for novices to try to write an attribute list and end up with
a module partition.
Using double square brackets for attributes could be better for this
reason. It will be easier to remember the double-bracket [["thingies"]]
and the single-bracket ["thingies"]. And the compiler could issue
better error messages too.

/* I think i used the word "too" too many times in this message, too! */

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

This modules proposal seems attractive to me in its general outlines.
Clearly the existing document doesn't represent a formal design, and the
author seems to be seeking opinions and feedback.

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1778.pdf

I have one question to begin with:  why not introduce a new keyword
`module', rather than piggyback on `namespace'?

My speculation is that it's due to the potential for braking existing code
that already uses 'module' as an an identifier.  If that is the case, would
it be reasonable to propose scoped keywords?  (Perhaps not available for
users).  std::module? Perhaps it would be possible to have a default
`using' declaration which would place the std::module keyword in the global
namespace, but could be disabled if needed.

I believe many people will find the use of '<<' objectionable.  Without
adding a new keyword (or three) to the language, I see no superior
alternative to overloading '<<'.

As an alternative approach to Daveed's, I will offer for means of comparison
the suggestion I made some months back.  That is, to extend the concept of
namespace to include the notions of private, protected and public,
currently used in classtype objects.  I'm almost tempted to suggest
something like a singleton class with no user accessible non-static
members.  The advantage to my suggestion is that it would leverage the
current notions of public, private, and protected we find in classes.  It
might also make use of the existing syntax and semantics of class
inheritance. Like classes, these class-like modules would be closed. In
contrast to namespaces.  We may also be able to leverage existing notions
of `using' directives and `using' declarations, as in `using module
moduleName;', and `using module moduleName::exportedIdentifier;'.

I'm not trying to steel the thunder from Daveed.  He's done a whole lot more
thinking, and good work toward this end than I have.  I'm simply trying to
form a basis for discussion.  The two approaches are not mutually
exclusive.

Why modules is a good path for C++:

#include can be (partially) deprecated.

More natural support for dynamically loadable program substructures. DLL's,
SO's, etc.

Formalization of interfaces between program substructures.

Better compile times.

Better support for distributed systems.

#MACRO exclusion

Better ODR conformance.

Improved, uh..., modularization of programs.



Could modules be templatized to support conditional builds? E.g.,

namespace std {
   template<typename Hardware=Heathkit>
   module hardware_abstraction {
     //hardware specific specializations go here
  }

}
--
STH
http://www.kdevelop.org
http://www.suse.com
http://www.mozilla.org

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Steven T. Hatton wrote:

A few clarifications and additional thoughts:

[..]
> My speculation is that it's due to the potential for braking existing code
> that already uses 'module' as an an identifier.  If that is the case,
> would
> it be reasonable to propose scoped keywords?  (Perhaps not available for
> users).

I meant the ability to define new keywords, not use them.  Of course I want
users to use them.  I just don't want #define replaced with something far
more hiddeus.
[...]

> That is, to extend the concept of
> namespace to include the notions of private, protected and public,
> currently used in classtype objects.  I'm almost tempted to suggest
> something like a singleton class with no user accessible non-static
> members.

Scratch that part about "no user-accessible", I don't know what I was
thinking when I wrote that.

> The advantage to my suggestion is that it would leverage the
> current notions of public, private, and protected we find in classes.  It
> might also make use of the existing syntax and semantics of class
> inheritance. Like classes, these class-like modules would be closed. In
> contrast to namespaces.  We may also be able to leverage existing notions
> of `using' directives and `using' declarations, as in `using module
> moduleName;', and `using module moduleName::exportedIdentifier;'.

Typo:
using module moduleName::exportedIdentifer;

should be:

using moduleName::exportedIdentifer;

Another thing I failed to mention.  RAII could be used in place of Daveed's
main() and ~main();

So, how would this differ from a singleton class?  For one, I would follow
Daveed's wisdom and have it automatically included where needed.  It would
be strongly suggested that there be a one-to-one mapping between dynamic
library and module.  It would conceptually communicate a different meaning
(which is the greatest value namespaces offer - IMO).  Modules could be
treated in ways similar to namespaces regarding using declaration and
directives.  They would also have the ability to contain such declarations
and directives at module-local scope (as opposed to classes).

They could probably offer virtually identical functionality to what Daveed
suggested, but with a somewhat different syntax.  This could be both a boon
and a bane.  My suggestions has the potential to be too close to a class,
and therefore confusing in terms of (apparently) subtle differences.  OTOH,
they probably wouldn't have as steep a learning curve, nor as much
potential to complicate code as would adding a fundamentally new syntax.

I believe C++ could benefit significantly from some concept of modules.  I
really don't care if it's my idea or Daveed's, or someone else's.  I only
care that what ever gets approved (if anything) is the _best_ idea.
--
STH
http://www.kdevelop.org
http://www.suse.com
http://www.mozilla.org

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]