"Sean Kelly" <sean@f4.ca> wrote in message news:duqh7n$1l6c$1@digitaldaemon.com...
> There's been a recent push to adopt a module import scheme for C++, but I think the huge mass of legacy code like the above will make the scheme very difficult to use.

I've seen that scheme. It strikes me as excessively complicated. Furthermore, there are no implementations of it, so nobody knows if it is implementable (see "export"), or if it is actually usable (see "namespace").

Walter Bright wrote:
> D doesn't allow overloading of ordinary functions with template functions. C++ does, but I don't see a compelling reason for it, and it is the source of some complicated corner cases. 

Yup, and I agree that this is a good thing.  My example used normal functions because template overloading is incomplete.


Sean

"Sean Kelly" <sean@f4.ca> wrote in message news:dur5fn$2g79$1@digitaldaemon.com...
> My example used normal functions because template overloading is incomplete.

That'll get fixed.

"Sean Kelly" <sean@f4.ca> wrote in message news:duq8gt$1cav$1@digitaldaemon.com...

> By the way, the more complex C++ examples don't work in D anyway, because D is module-based.  For example, it's more likely func would be defined in a third module like so:
>
> Module C:
>
>     module c;
>     import b; // let's say b is the default implementation
>
>     template func( T )
>     {
>         void func( inout T t1, inout T t2 )
>         {
>             swap( t1, t2 );
>         }
>     }
>
> Main:
>
>     import a;
>     import c;
>
>     void main()
>     {
>         int i = 1, j = 2;
>         func( s, t );
>     }
>
> However, this doesn't work in D even without overloading.


I doubt that this would work in any programming language   ;-)

In article <dur2g6$29us$1@digitaldaemon.com>, Walter Bright says...
>
>"Sean Kelly" <sean@f4.ca> wrote in message news:duqh7n$1l6c$1@digitaldaemon.com...
>> There's been a recent push to adopt a module import scheme for C++, but I think the huge mass of legacy code like the above will make the scheme very difficult to use.

The proposal is actually pretty good about backward compatibility. The transition would be messy, yes, but transitions always are.

>I've seen that scheme. It strikes me as excessively complicated. Furthermore, there are no implementations of it, so nobody knows if it is implementable (see "export"), or if it is actually usable (see "namespace").

In fairness, the proposal is by Daveed Vandevoorde of EDG, who AFAIK are the only people on the planet who *have* implemented "export". I don't think he's chucking this stuff out of the window of some ivory tower.

My main concern about the proposal as it currently stands is that I can't see how build tools like "make" can possibly work with it. The model is no longer "compile a bunch of separate objects and throw them at the linker". To compile a source file you need to have compiled all source files it depends on, and all source files *they* depend on, and so on. I'm increasing worried that the whole module concept may not be workable in a language that doesn't allow references to undeclared symbols at compile time.

cheers
Mike

Mike Capp wrote:
> 
> My main concern about the proposal as it currently stands is that I can't see
> how build tools like "make" can possibly work with it. The model is no longer
> "compile a bunch of separate objects and throw them at the linker". To compile a
> source file you need to have compiled all source files it depends on, and all
> source files *they* depend on, and so on. I'm increasing worried that the whole
> module concept may not be workable in a language that doesn't allow references
> to undeclared symbols at compile time.

This is my concern as well.  Just how far will they truly be able to abstract themselves from the include model?  However, I haven't yet read the proposal so perhaps I should do so before speculating further.


Sean

"Mike Capp" <mike.capp@gmail.com> wrote in message news:durud0$109b$1@digitaldaemon.com...
> In article <dur2g6$29us$1@digitaldaemon.com>, Walter Bright says...
>>I've seen that scheme. It strikes me as excessively complicated. Furthermore, there are no implementations of it, so nobody knows if it is implementable (see "export"), or if it is actually usable (see "namespace").
> In fairness, the proposal is by Daveed Vandevoorde of EDG, who AFAIK are
> the
> only people on the planet who *have* implemented "export". I don't think
> he's
> chucking this stuff out of the window of some ivory tower.

I have the greatest admiration and respect for Daveed. But nobody is smart enough to reliably predict how useful such a complex addition will be in practice, or what all the corner cases will be, or how difficult it is to implement on any compiler other than his own, etc., all based on a paper proposal.

Bottom line: the committee's track record on invention of complex new features is poor when they got standardized with no existing implementation experience (see namespace and export). The committee's record on standardizing functionality that *has* been extensively tried out is reasonably good (see STL).

> My main concern about the proposal as it currently stands is that I can't
> see
> how build tools like "make" can possibly work with it. The model is no
> longer
> "compile a bunch of separate objects and throw them at the linker". To
> compile a
> source file you need to have compiled all source files it depends on, and
> all
> source files *they* depend on, and so on. I'm increasing worried that the
> whole
> module concept may not be workable in a language that doesn't allow
> references
> to undeclared symbols at compile time.

I.e., it's a design for something that is complicated and quite unique among programming languages. It will *fundamentally* change the way C++ programs are built, probably in unanticipated ways. There's no implementation experience to see how it will work in a real project.

The risk is that if it gets standardized without being tried, and then people find out that it is either unworkable, unusable, or has little benefit in the real world, then it cannot be taken out again (like export).

In article <dusk1e$24pt$1@digitaldaemon.com>, Walter Bright says...

[various good points with with I fully agree]

>I.e., it's a design for something that is complicated and quite unique among programming languages. It will *fundamentally* change the way C++ programs are built, probably in unanticipated ways. There's no implementation experience to see how it will work in a real project.

I think that statement is a little extreme. Daveed is arguably just trying to standardize and generalize the concept of precompiled headers, of which there's quite a lot of implementation experience. (Most of it bad, from where I've been standing.)

Modules are a very different beast, granted, but not an entirely new one.

cheers
Mike

Walter Bright wrote:
> "Mike Capp" <mike.capp@gmail.com> wrote in message news:durud0$109b$1@digitaldaemon.com...
>> In article <dur2g6$29us$1@digitaldaemon.com>, Walter Bright says...
>>> I've seen that scheme. It strikes me as excessively complicated.
>>> Furthermore, there are no implementations of it, so nobody knows if it is
>>> implementable (see "export"), or if it is actually usable (see "namespace").
>> In fairness, the proposal is by Daveed Vandevoorde of EDG, who AFAIK are the
>> only people on the planet who *have* implemented "export". I don't think he's
>> chucking this stuff out of the window of some ivory tower.
> 
> I have the greatest admiration and respect for Daveed. But nobody is smart enough to reliably predict how useful such a complex addition will be in practice, or what all the corner cases will be, or how difficult it is to implement on any compiler other than his own, etc., all based on a paper proposal.
> 
> Bottom line: the committee's track record on invention of complex new features is poor when they got standardized with no existing implementation experience (see namespace and export). The committee's record on standardizing functionality that *has* been extensively tried out is reasonably good (see STL).
> 
>> My main concern about the proposal as it currently stands is that I can't see
>> how build tools like "make" can possibly work with it. The model is no longer
>> "compile a bunch of separate objects and throw them at the linker". To compile a
>> source file you need to have compiled all source files it depends on, and all
>> source files *they* depend on, and so on. I'm increasing worried that the whole
>> module concept may not be workable in a language that doesn't allow references
>> to undeclared symbols at compile time.
> 
> I.e., it's a design for something that is complicated and quite unique among programming languages. It will *fundamentally* change the way C++ programs are built, probably in unanticipated ways. There's no implementation experience to see how it will work in a real project.
> 
> The risk is that if it gets standardized without being tried, and then people find out that it is either unworkable, unusable, or has little benefit in the real world, then it cannot be taken out again (like export). 
> 
> 
Responding to both what Walter and Mike said:
Isn't this a design that Java, C#, and even D (to a slighty lesser degree) do? To compile a .d source file, the compiler must parse all other .d files that the original one references (in the form of modules), so isn't it the same? What's the whole new different paradigm?

-- 
Bruno Medeiros - CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D