• Russ Lewis (20/20) Aug 21 2001 Maybe we should take some of the syntax and algorithm sugar (like
• Robert W. Cunningham (33/42) Aug 21 2001 I'd go further, and *force* several language features/properties to be

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");

"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