Newbie initial comments on D language - scope

[Michel Fortin]

On 2008-02-03 08:20:32 -0500, Edward Diener 
<eddielee_no_spam_here at tropicsoft.com> said:

> I am fully cognizant of a dynamically typed language since I program in 
> Python also. I agree there is no fixed dividing line. But the 
> difference between static typing and dynamic typing is well defined in 
> a statically typed language like D. My argument was that for 'scope' to 
> be really effective it needs to consider the dynamic type at run-time 
> and not just the static type as it exist at compile time.

Considering the dynamic type at runtime means you need to check if 
you're dealing with a reference-counted object each time you copy a 
reference to that object to see if it the reference count needs 
adjusting. This is significant overhead over the "just copy the 
pointer" thing you can do in a GC. Basically, just checking this will 
increase by two or three times the time it take to copy an object 
reference... I can see why Walter doesn't want that.

Beside, the overhead of actually checking the type of the class will be 
approximativly the same as doing the reference counting. Given this, 
it's much better to always just do the reference counting than checking 
dynamically if it's needed.


> class C { ... }
> scope class D : C { ... }
> 
> [...]
> 
> This may make things much easier for the compiler, but it requires the 
> end user knowledge of 'scope', which has been specified at the class 
> level, to be applied at the syntax level. Intuitively I feel the 
> compiler can figure this out, and that 'scope' should largely be 
> totally transparent to the end user above at the syntax level.

Well, if the compiler is to be able to distinguish scope at compile 
time, then it needs a scope flag (either explicit or implicit) on each 
variable. This is exactly what Walter has proposed to do. He prefers 
the explicit route because going implicit isn't going to work in too 
many cases. For instance, let's have a function that returns a C:

	C makeOne() {
		if (/* random stuff here */)
			return new C;
		else
			return new D;
	}

Now let's call the function:

	C c = makeOne();

How can you know at compile time if the returned object of that 
function call is scoped or not? You can't, and therfore the compiler 
would need to add code to check if the returned object is scope or not, 
with a significant overhead, each time you assign a C.

If however you make scope known at compile time:

	scope C makeOne() {
		if (/* random stuff here */)
			return new C;
		else
			return new D;
	}

	scope C c = makeOne();

Now the compiler knows it must generate reference counting code for the 
following assignment, and any subsequent assignment of this type, and 
it won't have to generate code to dynamically everywhere you use a C 
check the "scopeness".

If makeOne returns a C, it'll simply be scope too, which is more 
overhead than having a garbage-collected C, but, as I said earlier, not 
necessarly less than checking dynamically if it should be reference 
counted.

Perhaps Walter can confirm that the above code makes sense given what 
he intends to do, but I believe it does.

-- 
Michel Fortin
michel.fortin at michelf.com
http://michelf.com/