www.digitalmars.com         C & C++   DMDScript  

D - Simplify the compiler through modules

reply Russ Lewis <russ deming-os.org> writes:
Maybe we should take some of the syntax and algorithm sugar (like
associative arrays) and try to outsource the logic to a module.

Basically, the idea is that the compiler spec defines a certain class
that it needs in order to compile with a certain feature.  At compile
time, it recognizes the use of the feature and internal converts the
"pretty" syntax used in the code to old fashioned function calls.  This
simplifies the compiler's internal algorithms (making it easier to
confirm their accuracy).  It also means that somebody could tweak the
algorithms without having to recompile the compiler.

Example with associative arrays:

***Original Code***
int[char[]] b;
b["hello"] = 3;
func(b["hello"]);
delete b["hello"];

***Converted Code (user never sees this)***
StringAssociativeArrayOfInts b;
b.Get("hello") = 3;
func(b.Get("hello"));
b.Remove("hello");
Aug 21 2001
parent "Robert W. Cunningham" <rwc_2001 yahoo.com> writes:
Russ Lewis wrote:

 Maybe we should take some of the syntax and algorithm sugar (like
 associative arrays) and try to outsource the logic to a module.

 Basically, the idea is that the compiler spec defines a certain class
 that it needs in order to compile with a certain feature.  At compile
 time, it recognizes the use of the feature and internal converts the
 "pretty" syntax used in the code to old fashioned function calls.  This
 simplifies the compiler's internal algorithms (making it easier to
 confirm their accuracy).  It also means that somebody could tweak the
 algorithms without having to recompile the compiler.

I'd go further, and *force* several language features/properties to be expressed ONLY across module boundaries. That is, code in the same module would NOT have all the "power" and "capabilities" of external code. And the same would be true for external code: Some things could only be done in local code. This would allow "interfaces" to carry more weight (as contracts), and also allow things like multiple inheritance to be more easily approximated (in a manner that is limited, but useful). The notion of "type" can be extended and enhanced, as can notions of persistence (since an external module could come from *anywhere*). Why not allow external modules to contain instantiated objects? Then the module interface could also encapsulate and support some notions of RTTI and various forms of RPC. Could two different programs written in D share a set of active objects without the need for cumbersome overhead and complex interactions? Even if they are on different computer systems having different processors and architectures? Why not? If "modules" are defined sanely, then the notion of both static and dynamic attachment can be allowed, and accessed at a language level. I'm thinking here of ways to "squash" the link/DLL/CORBA hierarchy a bit, at least from a language perspective. And it all hinges on the "import" statement. Different kinds of importing will require different kinds of support, some at compile time, more at link time, and the rest at run time. Can the D language (and its object model / link model) be made symmetric (not agnostic) to the differences? Of course, some form of OS support would be required for the "juicier" import modes, though "basic" module features would be implemented directly by the D compiler/linker. Finally, this could provide massive inducement for programmers to modularize their code, generally a Very Good Thing. Yes, this is a fairly nebulous idea: I'm still working on it, but I wanted to get the general thought out sooner rather than later... -BobC
Aug 21 2001