Compiler as dll

[grauzone]

Yigal Chripun wrote:
> grauzone wrote:
>> Yigal Chripun wrote:
>>> Static languages can have Variant/box types that'll give most of the
>>> same functionality of dynamic languages. so, instead of instantiating
>>> list!(int), list!(string), etc, you can get one list!(Variant)..
>>> C# provide such a feature with a keyword instead of rellying on
>>> templates.
>>
>> It would be nice if D would be extended to provide all these things. I
>> guess the only reason this hasn't been done is the space overhead of
>> full RTTI information. (And dynamic method invocation might require a
>> lot of hackery to manually copy the method arguments on the stack.)
>>
>>> The real difference is that static languages have mostly read-only
>>> RTTI. (Java provides a very limited capability to reload classes, IIRC)
>>> a scripting language allows you to manipulate Types and instances at
>>> run-time, for example you can add/remove/alter methods in a class and
>>> affect all instances of that class, or alter a specific instance of a
>>> class. This cannot be done in a static language.
>>
>> Some static languages allow it to statically add your own methods or
>> variables to a foreign class. An example would be AspectJ, which, among
>> other things, adds this feature to Java.
> 
> from what little I know about AOP - it's done at link time, not runtime. 
> Java does however provide very limited support for this - for example, 
> while debugging your code, you can change an implementation of a method 
> and reload the containing class so instances of that class *that where 
> created after the change* will call the new implementation. this allows 
> to make small changes while debugging without the need to re-run the 
> program each time. But you can't do things like:
> 
> Class a = new Class;
> class b = new Class;
> a.getClass.addMethod(foo);
> b.foo();
> 
> note that this is done at run-time, not link time.

Yes. But when do you need to be fully dynamic? I claim that this is 
unneeded in most cases. Most time, you probably only want to extend a 
class by your own methods and members.

To me, it looks like the biggest fundamental advantage of dynamic 
languages is only to be able to omit type signatures.

>>
>> This is still not as dynamic as in dynamic type systems, but I wonder if
>> you really need more?
>>
>> There's something similar in current static languages: you can extend
>> the global data segment with global variables. Global variables don't
>> have to be all in a single source file. Instead, the linker takes care
>> of collecting global variables from object files and allocating space
>> for them in the data segment. A dynamic linker can do this even while a
>> program is running!
>>
>> Thread local storage (with global __thread variables) does the same
>> thing per thread. Threads can be created and destroyed at runtime.
>> Dynamic linking is still supported, I think.
> 
> Can you explain more? I don't see how globals and threads can allow me 
> to do the above code snippet.

First, this was only meant as some kind of analogy between dynamic 
languages and the AOP techniques mentioned above. Like you can 
dynamically add global variables to your program by loading a dynamic 
shared object (.so/.dll), although there aren't functions like 
addGlobalVariable(char[] name, size_t size). A thread is almost like an 
object, and declaring __thread variables is like adding fields to this 
object.

Second, concerning actual implementations, you maybe could turn every 
class into a separate data section. Then it would only require a new 
linker symbol to extend a class by a field. The linker would take care 
of doing the actual class layout by assigning each linker symbol an 
address. This address is used as field offset. But I don't know enough 
about linkers to tell if this would actually work. And there are still 
some problems, like the question what happens with dynamic linking.