FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

Separating DMD and Phobos

 
Post new topic   Reply to topic     Forum Index -> Ares
View previous topic :: View next topic  
Author Message
sean



Joined: 24 Jun 2004
Posts: 609
Location: Bay Area, CA

PostPosted: Wed Oct 06, 2004 2:30 pm    Post subject: Separating DMD and Phobos Reply with quote

I finally decided to take a closer look at the overlap between DMD and Phobos and so far I've found a few files that will have to be looked at: asserterror.d, intrinsic.d, gc.d, outofmemory.d, and moduleinit.d. DMD definately relies on all of these, and I think it may be correct to have them in "std" where they are now. So that raises some questions:

Does this stuff belong in "std?"

Assuming it does, should object.d be put there as well?

Should we attempt to extract Phobos into its own namespace within Ares, and if so, where do these files belong?
Back to top
View user's profile Send private message
kris



Joined: 27 Mar 2004
Posts: 1494
Location: South Pacific

PostPosted: Wed Oct 06, 2004 3:13 pm    Post subject: Re: Separating DMD and Phobos Reply with quote

sean wrote:
I finally decided to take a closer look at the overlap between DMD and Phobos and so far I've found a few files that will have to be looked at: asserterror.d, intrinsic.d, gc.d, outofmemory.d, and moduleinit.d. DMD definately relies on all of these, and I think it may be correct to have them in "std" where they are now. So that raises some questions:

Does this stuff belong in "std?"

Assuming it does, should object.d be put there as well?

Should we attempt to extract Phobos into its own namespace within Ares, and if so, where do these files belong?

I'd be tempted to suggest that those files actually belong with the other compiler dependencies within the 'internal' subdirectory. They are presumably necessary components, that the compiler cannot build an operational executable without. That is, one does not import moduleinit.d to get a working program (much like object.d). One might think of these as "compiler helpers", even though Walter didn't place them in the "internal" location (although one can explicitly import from either location, if one wishes).

Regardless, I tend to feel that such functionality belongs to the implicit runtime support, whereas the "libraries" might be viewed as explicit runtime support (because one has to explicitly import them). As such, they might live in a completely seperate namespace (or even a seperate library, for that matter). That is, perhaps these modules (along with typeinfo.* and all the various internal\ modules) should live in a compiler.* or runtime.* namespace. Or perhaps they should all be in a secondary library outside of Phobos as it currently stands today (one which belongs to Walter, or some other D implementer). After all, don't all of those belong to the compiler proper?

One question might be: which of these modules (including all the internal\.* and typeinfo modules) are needed for compilation purposes, and which ones are present in Phobos purely for linker resolution only?

Another might be: which of these modules belong to the compiler-writer, or might be changed due to an implementation-specific idiom? Presumeably, such modules should be isolated away from our efforts?
Back to top
View user's profile Send private message
sean



Joined: 24 Jun 2004
Posts: 609
Location: Bay Area, CA

PostPosted: Wed Oct 06, 2004 3:22 pm    Post subject: Reply with quote

I agree, but the exceptions got me wondering. So move this stuff (plus typeinfo) into /internal and make it accessible at the global level, much like object.d is now. I'll give this a try and see how it goes.
Back to top
View user's profile Send private message
kris



Joined: 27 Mar 2004
Posts: 1494
Location: South Pacific

PostPosted: Wed Oct 06, 2004 6:21 pm    Post subject: Reply with quote

sean wrote:
I agree, but the exceptions got me wondering. So move this stuff (plus typeinfo) into /internal and make it accessible at the global level, much like object.d is now. I'll give this a try and see how it goes.


Walter has noted that only the location of Object.d is explicit within the compiler, and everything else is just linked via Phobos. This means that

1) those compiler-related modules can all live within /internal, if appropriate, after making the appropriate namespace changes.

2) all of /internal could be placed within a seperate lib, such that they are made the explicit property of the compiler developer only. That is, one might place all the /internal stuff into an internal.lib for now, and everything else into an ares.lib (or whatever it's called). Worth a try?

3) Object.d can probably stay where it is (as part of /internal), since it has no namespace prefix anyway. Perhaps it should become a 'skeleton' class, in the manner that's suggested for hidden implementation? That way, the source for Object.d can be part of the standard package, but the implementation is actually hidden within Object.obj (via internal.lib, or wherever it ultimately resides).

Note that the printf() reference should probably be removed from Object.d, and the opCmp() referencing std.string may have to be 'scrutinized' carefully. It may be fine to just duplicate the string comparison for the time being, until we decide whether the opCmp() should be abandoned within Object.d (per the enthusiastic NG discussions).

Just thoughts ...
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic   Reply to topic     Forum Index -> Ares All times are GMT - 6 Hours
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2005 phpBB Group