> In article <CzovvJ.I28@borland.com> Pete Becker <pete@borland.com> writes:
> >> In article <CzJ8CG.IsC@ucc.su.OZ.AU> maxtal@physics.su.OZ.AU (John Max Skaller) writes:
> >>
> >> >  Is it worth it? I think so, but most other members of the
> >> > committee do not. Too bad.
> >>
> > I suspect that trying to add a module system would delay the
> >standard by several years, and might well not succeed. The first
> >problem is that there is no clearcut agreement in the discussions I
> >have seen on just what the term "module system" means. The second is
> >that I, for one, could not vote for such a major restructuring of the
> >way programs are built without trying it out.
>
>  Its circular isn't it? No one will implement it if it
> is not in the Standard and it will not be in the Standard unless
> it has been implemented. (***)

 As was indicated in the part of the message that was omitted
here, I was responding to the assertion that adding modules would
only delay the standard by four months.
 -- Pete

I just wanted to indicate my whole-hearted agreement with Mr. Skallers
comments.  If software engineering is to ever become a real discipline, the
development process must become more unified.  The current patch work tool
chain created 25 years ago will not provide such capabilities.  The concept
of modules begs for a unified repository.  Such a repository is analogous to
repositories in hardware and mechanical engineering tools.  The software
industry has long ago decided that such repositories are the answer for
the hardware and mechanical industry, but for itself it has choosen to stay
with the arcane tools of 25 years ago.  This, I can not understand!

The destiny lies down the module/repository path, let's stop hedging and
get on with it.

Stephen Cipolli
These opinions are mine alone.

In article <3avrjpINNkpu@marble.summit.novell.com> jls@summit.novell.com (-mlc-+Schilling J.) writes:
>
>Agreed.  There's enough new and untested (in the large) features in the
>standard already.  The four months figure seems wildly optimistic.  The
>language needs to stabilize!
>
>If someone wants a module system bad enough, they can use a language
>that has one; there are a number of good such languages around.

 If someone wants a stable, Standardised language bad enough,
they can use a language that is stable and Standardised, like
ISO C, ISO Modula, ISO Fortran, ISO COBOL ...

--
        JOHN (MAX) SKALLER,         INTERNET:maxtal@suphys.physics.su.oz.au
 Maxtal Pty Ltd,
        81A Glebe Point Rd, GLEBE   Mem: SA IT/9/22,SC22/WG21
        NSW 2037, AUSTRALIA     Phone: 61-2-566-2189

In article <CzqM7p.H82@ucc.su.OZ.AU>,
maxtal@physics.su.OZ.AU (John Max Skaller) wrote:

>       Its circular isn't it? No one will implement it if it
> is not in the Standard and it will not be in the Standard unless
> it has been implemented. (***)

>       Is a module system hard? Perhaps. But a minimal
> support facility -- like the one I have suggested -- at least
> _permits_ emulation without breaking any existing programs.
> Perhaps with that kind of facility, we will be ready to Standardise
> a real module system next time round.

I like your idea very much.  Produce the interface out of the compilation
of a source unit without the introduction of a lot of new keywords and
syntax is really a simple idea with lots of merit.  The object code of the
compile is already not portable (due to no standard name mangling) so why
do we have to support archaic linkers.  The interface can be produced in
two forms human readable as documentation and machine readable encapsulated
with the compiled code. The introduction of an "include" or "uses" could
then be used to tie up the code.

But then it seems like the people who want units or modules are in the
minority.

Vince
=====

In article <Czv52I.M6H@ucc.su.OZ.AU> maxtal@physics.su.OZ.AU (John Max Skaller) writes:
>In article <3avrjpINNkpu@marble.summit.novell.com> jls@summit.novell.com (-mlc-+Schilling J.) writes:
>>If someone wants a module system bad enough, they can use a language
>>that has one; there are a number of good such languages around.
>
> If someone wants a stable, Standardised language bad enough,
>they can use a language that is stable and Standardised, like
>ISO C, ISO Modula, ISO Fortran, ISO COBOL ...

That's my point.  People will vote with their feet.  There _are_ people who
will not use C++ because it is not standardized and every compiler implements
a different language.  How many people are there who will not use C++ because
of its lack of a module system?  Not many I think.  The same lack sure doesn't
seem to have hurt the popularity of C.

Please note that this is not an indication of personal preference.  The
header file model is probably the thing I dislike most about C and C++.
For people with Ada or other module-based language backgrounds, issues
like the One Definition Rule are an excursion into the bizarre.

Your point about C++ being a difficult mixture of the very high level and
the very low level is well taken, but this characteristic pervades the
language and just putting in a module system won't change it.  At some
point you just have to let a language be itself.

--
Jonathan Schilling
Novell, UNIX Systems Group
jls@summit.novell.com

In article <CzovvJ.I28@borland.com> Pete Becker <pete@borland.com> writes:
:> In article <CzJ8CG.IsC@ucc.su.OZ.AU> maxtal@physics.su.OZ.AU (John Max Skaller) writes:
 [concerning adding a module system to C++]
:> >
:> >  However, adding one, while not that demanding, will
:> > take some time and effort and probably delay Standardisation
:> > for 4 months.
:
: I suspect that trying to add a module system would delay the
:standard by several years, and might well not succeed.

Agreed.  There's enough new and untested (in the large) features in the
standard already.  The four months figure seems wildly optimistic.  The
language needs to stabilize!

If someone wants a module system bad enough, they can use a language
that has one; there are a number of good such languages around.

--
Jonathan Schilling
Novell, UNIX Systems Group
jls@summit.novell.com

In article <CzovvJ.I28@borland.com> Pete Becker <pete@borland.com> writes:
>> In article <CzJ8CG.IsC@ucc.su.OZ.AU> maxtal@physics.su.OZ.AU (John Max Skaller) writes:
>>
>> >  Is it worth it? I think so, but most other members of the
>> > committee do not. Too bad.
>>
> I suspect that trying to add a module system would delay the
>standard by several years, and might well not succeed. The first
>problem is that there is no clearcut agreement in the discussions I
>have seen on just what the term "module system" means. The second is
>that I, for one, could not vote for such a major restructuring of the
>way programs are built without trying it out.

 Its circular isn't it? No one will implement it if it
is not in the Standard and it will not be in the Standard unless
it has been implemented. (***)

 Unless the _notion_ is given strong support -- without
adopting a particular model -- then no one will even WORK
on a design or trial implementation. Of course there is no
agreement on what "module system" means if no one will take
discussion of it seriously.

 I agree people need to try out ideas -- although
really we voted in features of exception handling, templates
and namespaces, without first trying them out.

 In the end, in Australia, the piece of paper
"ISO C++ Standard" is less important than consistent
implementation of a high quality computer programming language
for general use in construction of both portable and system
specific software. In my opinion. And the committee -- by its
very existence and efforts, really is achieving that, already,
Standard or no.

 USA seems to me to have different needs -- the document
is more important in itself, no matter what it describes,
as far as I can tell.

 And the purpose of an ISO forum is to obtain some
balance between these needs -- which does not mean adopting
the position best for one nation or another, but finding something
we can all live with.

 If we don't delay now for a module system, we may
never get one -- in 5-7 years or whatever it may be too late,
C++ may be dead, perhaps because it had no module system,
and perhaps because something better came along -- or perhaps
it will be in such heavy use and expected to be stable and
unchanging that it is impossible to add a module system --
locking programmers into deficient engineering methods
for unknown time to come. Then again, the wrong module system
might have that effect too.

 We'll never know if we dont take the time to study the
problem -- Pete Becker is quite right that even considering
the issue may well delay the Standard. And it may improve it.

 I guess everyone has to do their own cost/benefit
analysis -- but in the end it is NOT the compiler vendors
who I at least am serving but the programmers and users of
software -- the whole of my nation.

 Over here, we have had a few major projects
crash disasterously at huge expense. Part of the reason is
that software engineering is HARD and the tools we have available
are inadequate. What use iostreams in a multi-threaded GUI
based application?  Why are we Standardising yesterdays technology?
We -- over here -- need Standards for _tomorrow_, not yesterday.
Yesterday is gone.

 C++ embodies -- in some of its parts -- some very
advanced and modern ideas. The class/encapsulation system
is second to none. But it is _very_ weak in other areas,
where it is even more deficient that C because it has
extended some C notions and failed to adjust others to account
for that. And it has failed to incorporate _other_ advances
made long before OO but after C. For example, C is not
block structured -- the natural thing to do is take advantage of
two decades of knowledge and make it so (add nested functions).

 We all know structured programming is not enough,
and why it does not work as a complete methodology,
but OO does not replace functional decomposition, it just
provides another technique to be used with it -- as appropriate.
NO one I know suggests bottom up analysis replace top down
design completely -- most OO writings suggest simply you
need to do BOTH and iterate.

 So what we end up with is a strong assembler (C),
and a strong class system, and programmer are forced to bend
their designs to using inappropriate structures --
inheritance is greatly overused for all the wrong things.

 What should we do? I think we should Standardise what
we have now plus what we can add easily. Nested functions
are easy, we should do them. Discriminated unions are hard,
we should not do them (but provide support for people to
emulate them). GC and multi-threading is hard, we should not
do them -- but provide minimal support for those wanting to
do that stuff. (Dag's coroutine classes would be very useful)

 Is a module system hard? Perhaps. But a minimal
support facility -- like the one I have suggested -- at least
_permits_ emulation without breaking any existing programs.
Perhaps with that kind of facility, we will be ready to Standardise
a real module system next time round.

 Smalltalk is becoming popular -- because C++ is just too
hard to engineer.  One of our top C++ shops is switching
to TCL wherever possible for just this reason.

 It just takes far too long to implement classes and get
them running. (Good environments like Borland's _really_ help
a lot though: I use BC3.1/BC4.0 as a text editor even when
I'm using another compiler :-)

(***) Actually, thats not quite true. Borland implemented
new style casts before they were actually voted in:
BC4 hit the streets a few _days_ after the decision.
I commend Borland on its willingness to take risks like this.
--
        JOHN (MAX) SKALLER,         INTERNET:maxtal@suphys.physics.su.oz.au
 Maxtal Pty Ltd,
        81A Glebe Point Rd, GLEBE   Mem: SA IT/9/22,SC22/WG21
        NSW 2037, AUSTRALIA     Phone: 61-2-566-2189

> In article <CzJ8CG.IsC@ucc.su.OZ.AU> maxtal@physics.su.OZ.AU (John Max Skaller) writes:
>
> >  However, adding one, while not that demanding, will
> > take some time and effort and probably delay Standardisation
> > for 4 months.
> >
> >  Is it worth it? I think so, but most other members of the
> > committee do not. Too bad.
>
> I think it's worth it too.  It's really bizarre that C++ doesn't have
> any notion of a module with an interface/implementation split.  Sure,
> you can use the mechanism of textual inclusion to simulate a module
> system (which is what pretty much everyone does), but the whole notion
> of a header file is simply an extralinguistic programming convention.
>
>
> --
>
>                                --matt

 I suspect that trying to add a module system would delay the
standard by several years, and might well not succeed. The first
problem is that there is no clearcut agreement in the discussions I
have seen on just what the term "module system" means. The second is
that I, for one, could not vote for such a major restructuring of the
way programs are built without trying it out.