FYI:Modules in C++ Proposal

[Steven T. Hatton]

This looks very important, and potentially consequential. If it were added
to C++ it would certainly have a significant impact on the language. If
done right, it would be a boon. If done wrong it would be severely
detrimental.

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

"Introduction
Modules are a mechanism to package libraries and encapsulate their
implementations.
They differ from the C approach of translation units and header files
primarily in that all
entities are defined in just one place (even classes, templates, etc.). This
paper proposes a
module mechanism as an extension to namespaces with three primary goals:
? Significantly improve build times of large projects
? Enable a better separation between interface and implementation
? Provide a viable transition path for existing libraries
Before delving in the detailed benefits and issues of the proposal, this
paper offers some
examples illustrating general principles and common use cases. Along the way
some
nomenclature is introduced to enable concise discussion.
"

 

[Zorro]

Thank you for posting the proposal. I went through most of it.

The following (short and sweet) article provides a simple and intuitive
extension to C++ that accomplishes more. In fact, it has even been
implemented and thoroughly tested.

http://www.zhmicro.com/namespaces.htm

Regards,
Z.

 

[u.int.32.t]

This is mental. Too complicated for too little.

 

[Zorro]

Thank you for posting the proposal. I went through most of it.

The following (short and sweet) article provides a simple and intuitive
extension to C++ that accomplishes more. In fact, it has even been
implemented and thoroughly tested.

http://www.zhmicro.com/namespaces.htm

Regards,
Z.

 

[Alf P. Steinbach]

* Steven T. Hatton:

This looks very important, and potentially consequential.

Yes, it's been important and consequential for fifteen years.

If it were added
to C++ it would certainly have a significant impact on the language. If
done right, it would be a boon. If done wrong it would be severely
detrimental.

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

Summarizing:

* Bad: Really Awful Syntax (more reuse of existing operators, unreadable).

* Bad: Attempt at unification with namespaces instead of separation of
concerns, more confusion.

* Good: Envelopes (here called 'main'/'~main') & guaranteed initialization
order, explicit export & no header files, but then, those are sort of
minimum for module support, you couldn't very well call it a module
otherwise.

I.e. what's good stems from the general module concept as implemented in a
score of other languages, almost couldn't be avoided, and the particular
concept realization in the proposal seems complex & very ungood.

 

[Steven T. Hatton]

Thank you for posting the proposal. I went through most of it.

The following (short and sweet) article provides a simple and intuitive
extension to C++ that accomplishes more. In fact, it has even been
implemented and thoroughly tested.

http://www.zhmicro.com/namespaces.htm

Regards,
Z.

You aren't going to get much argument out of me over what you've done. I've
suggested just about the same thing in the past. I will observe, however
that the modules proposal does eliminate the need for the #include
directive. I haven't read it very carfully myself, but I do believe it
offers feature not described in your article. One possibly significant
feature I believe you may have which is lacking in the module proposal is
the `endusing' directive. I'm not sure how much difference there really is
between your product and the scoping rules and import/export features of
modules.

 

[Steven T. Hatton]

* Steven T. Hatton:

Yes, it's been important and consequential for fifteen years.


Summarizing:

* Bad: Really Awful Syntax (more reuse of existing operators,
unreadable).

He does offer something of an alternative. He's kind of stuck between a
rock and a hardplace. People don't want new keywords introduced because
they have the potential to break existing code. He is therefore obliged to
make use of what symbols are currently available. I agree the syntax is
potentially confusing. I am fairly comfortable with it because it is close
to what Mathematica uses for packages.

* Bad: Attempt at unification with namespaces instead of separation of
concerns, more confusion.

Keyword problem.

* Good: Envelopes (here called 'main'/'~main') & guaranteed
initialization
order, explicit export & no header files, but then, those are sort of
minimum for module support, you couldn't very well call it a module
otherwise.

I.e. what's good stems from the general module concept as implemented in a
score of other languages, almost couldn't be avoided, and the particular
concept realization in the proposal seems complex & very ungood.

I have to say he has not presented a definite design, but rather suggestions
for which he would like feedback. Or, at least that's my perception.

 

[Zorro]

You aren't going to get much argument out of me over what you've done. I've

suggested just about the same thing in the past. I will observe, however
that the modules proposal does eliminate the need for the #include
directive. I haven't read it very carfully myself, but I do believe it
offers feature not described in your article. One possibly significant
feature I believe you may have which is lacking in the module proposal is
the `endusing' directive. I'm not sure how much difference there really is
between your product and the scoping rules and import/export features of
modules.

Thank you for taking the time to read and comment on the article. I
failed to come up with brief reply on your profound comments. Instead,
I will confine my reply to "elimination of include directive", which is
more specific to C++.

As a language evolves some features will inevitably vanish.
Preprocessor directives should be avoided, except for the following two
(in my opinion).

1. Conditional compilation. This mechanism separates the concerns of
compiler from those of platfrom. There are times we need different
implementations in a small area of the code, depending on platform.

2. Include directive. This can be used orthogonal to conditional
compilation when platform differences are more than a few lines of
code. One can include different header files for different platforms.
It also helps separate definitions from their implementation. It works
well without causing confusion (novice abuse is not an issue here).
There is no need to replace it with a mechanism that involves compiler
action.

Your quote from BR should be read more than just some quote. It is the
framework for how to approach the design of a language.

Regards,
Z.

 

[Steven T. Hatton]

Thank you for taking the time to read and comment on the article. I
failed to come up with brief reply on your profound comments. Instead,
I will confine my reply to "elimination of include directive", which is
more specific to C++.

As a language evolves some features will inevitably vanish.
Preprocessor directives should be avoided, except for the following two
(in my opinion).

1. Conditional compilation. This mechanism separates the concerns of
compiler from those of platfrom. There are times we need different
implementations in a small area of the code, depending on platform.

I've made two suggestions along these lines. One is to have an in-language
`compile_if(const bool condition){/*...*/};'

(Perhaps that could be extended to a switch statement?)

The other is to templateize modules so particular specializations of member
templates could be instantiated based upon the parameters passed to the
module template.

2. Include directive. This can be used orthogonal to conditional
compilation when platform differences are more than a few lines of
code. One can include different header files for different platforms.
It also helps separate definitions from their implementation. It works
well without causing confusion (novice abuse is not an issue here).
There is no need to replace it with a mechanism that involves compiler
action.

I disagree. I have seen the best of'm get bit by Cpp goofs related to both
conditional compilation, and #inclusion. The correspondence between
declaration/definition location and program structure is ad-hoc, and
usually timeconsuming to resolve.

CPP #MACROS (including the #include directive) cripple the efforts to create
powerful development tools because the cut across the natural structure of
the language. This is one major reason why it is so much easier to create
development environments for languages such as C#, Java, and even C++/CLI.
Efforts to overcome the other obstacles such as lack of introspection, and
lack of clearly defined file naming requirements are likewise crippled by
the CPP.

Your quote from BR should be read more than just some quote. It is the
framework for how to approach the design of a language.

Regards,
Z.

I'm familiar with Russell's work. It is instructive regarding computer
science, but not entirely essential. Stroustrup has some things to say
regarding philosophy and "comprehensive 'systems'" in relation to his
pragmatism when designing C++.