February 08, 2007
Andrei Alexandrescu (See Website For Email) wrote:
> Walter Bright wrote:
>> Andrei has been mostly hard at work on the const/inout/scope problem. The current way D does it is hackish, and Andrei feels (and I agree) that bringing rigor to it will make D a considerably stronger language.
> 
> There's good progress on that!

Yup, I think the end result will be something we can all be proud of.
February 08, 2007
Walter Bright wrote:
> 
> Yes, in the end, I think that's a more maintainable solution. You'll find your core modules will become much more portable, and you shouldn't need to edit (or even understand) them at all when porting to a new platform.
> 
> If your job is to port the gc to a new XYZ platform, would you find it easier to edit the long and complicated gcx.d, or just copy gclinux.d to gcXYZ.d and restrict your work to just figuring out how to port a few lines of code with (hopefully) well-defined behavior?
> 

And there in lies the primary issue I have with this approach. Say I do the above and then a bug is found in the system independent parts of the module, now I have to extract the fix from a fixed version and reapply it to my version.

I am a strong proponent of the theory that you should never have two peaces of /Identical/ code (as in does the exact same thing). It's kinda sorta the Extreme Programming model[*] but that's not where I'm coming from.

An example, I am working on a D lexer, it needs to work on 6 type of files ASCII and UTF-8/16BE/16LE/32BE/32LE. also to make things easier downstream, I have it convert all EOLs to \n. Well rather than write 6 scanners, I wrote one that was templated on two types (I think) results in correct conversions. It is about 30 lines long and the sum total difference between the functions is the types on about about 3 lines. Now if at some point I find a bug, I fix it in one place and I'm done.

The same sort of thing can apply to other cases.


* I think that is the model but I could be remembering the wrong name
February 08, 2007
Walter Bright wrote:
> 
> 
> I think you view version as a scalpel, while I see it as more like an axe.

Not the analogy I would have used but I think we are thinking of different uses.
February 08, 2007
Derek Parnell wrote:
> On Wed, 07 Feb 2007 11:50:50 -0800, BCS wrote:
> 
> So in your example above ...
> 
>   version(build) pragma(export_version, Foo, Bar);
> 

Cool, but I think that would be

 version(Foo) pragma(export_version, Bar);
February 08, 2007
Andrei Alexandrescu (See Website For Email) wrote:
> Kyle Furlong wrote:
>>
>> I agree with the point that metaprogramming needs more control structures.
>>
>> static for, static foreach, static while, static do, static switch case, etc.
> 

static loops at any scope static if is allowed

> 
> Static loops are not very useful without compile-time mutation.
> 
> Andrei

Maybe some sort of const loop would work

static for(const i = 0; i< 10; i++) // i const outside of ()
{
}

If the the last two clauses were scoped as being at the end of the loop then it might even be able to access const values computed during the last pass.

const s = 356;
char[s] buf;
char[] buf2;

static for(const i = 1; cont; i<<=1)
{
	static if(i < buf.length)
		const bool cont = true
	else
	{
		const bool cont = false
		buf2.length = i;
	}		
}

Yeah, it's contrived )and brings up a pile of issues with regards to scoping) but, it illustrates the point.
February 08, 2007
Walter Bright wrote:
> Andrei Alexandrescu (See Website For Email) wrote:
>> Walter Bright wrote:
>>> Andrei has been mostly hard at work on the const/inout/scope problem. The current way D does it is hackish, and Andrei feels (and I agree) that bringing rigor to it will make D a considerably stronger language.
>>
>> There's good progress on that!
> 
> Yup, I think the end result will be something we can all be proud of.

This is great news!
February 08, 2007
BCS wrote:
> Walter Bright wrote:
>>
>> Yes, in the end, I think that's a more maintainable solution. You'll find your core modules will become much more portable, and you shouldn't need to edit (or even understand) them at all when porting to a new platform.
>>
>> If your job is to port the gc to a new XYZ platform, would you find it easier to edit the long and complicated gcx.d, or just copy gclinux.d to gcXYZ.d and restrict your work to just figuring out how to port a few lines of code with (hopefully) well-defined behavior?
>>
> 
> And there in lies the primary issue I have with this approach. Say I do the above and then a bug is found in the system independent parts of the module, now I have to extract the fix from a fixed version and reapply it to my version.
> 
> I am a strong proponent of the theory that you should never have two peaces of /Identical/ code (as in does the exact same thing). It's kinda sorta the Extreme Programming model[*] but that's not where I'm coming from.

If there's a lot of identical code in this approach, then perhaps the abstraction layer is drawn in the wrong place. There isn't much in the gc version api implementations.

> An example, I am working on a D lexer, it needs to work on 6 type of files ASCII and UTF-8/16BE/16LE/32BE/32LE. also to make things easier downstream, I have it convert all EOLs to \n. Well rather than write 6 scanners, I wrote one that was templated on two types (I think) results in correct conversions. It is about 30 lines long and the sum total difference between the functions is the types on about about 3 lines. Now if at some point I find a bug, I fix it in one place and I'm done.
> 
> The same sort of thing can apply to other cases.

Using templates is a great way to write generic code, but it's a different approach than using versions.
February 08, 2007
Sean Kelly wrote:
> BCS wrote:
> 
>> Walter Bright wrote:
>>
>>>
>>> No, versions defined in an import do NOT affect the importer.
>>
>>
>> What?? then how do you implement non trivial vertion logic?
> 
> 
> Do it in a makefile or use constants and static if :-p
> 
> 
> Sean

If that's the case, then this is the point where I start to do "evil" things with D, like versioning with constants/static if/mixin(import()).  I really dislike makefiles and such external languages that tell my program how to compile.

I like to have all the information needed to compile a program be contained within the source itself.  It makes compiling so much simpler.
February 08, 2007
> The main difficulty is if the DSL needs to access symbols in the rest of the D code.

I agree.
But how do you think do such things in the current approach?

-- 
Regards,
Yauheni Akhotnikau
February 08, 2007
> I agree with the point that metaprogramming needs more control structures.
>
> static for, static foreach, static while, static do, static switch case, etc.

I think it is not a good way. Because this leads to two different languages in one: compile-time D (constructs from ordinal D but with prefix 'static') and run-time (ordinal D).

If it is necessary to use compile-time D then the following difficalties arose:
* it is imposible to use externals tools, such as compiler-compiler generators, which produces ordinal D code;
* it is hard to debug compile-time code -- how to launch debugger at compile time?
* it is necessary to construct compile-time unit tests;
* it is impossible to use existing D libraries for DSL transformations.

I'm use Ruby a lot and much metaprogramming things done via creating strings with Ruby code and evaluating it by various 'eval' methods. It is very simple method -- easy in writting, debugging and testing. And there isn't two different Ruby -- only one language.

Yet another example -- Nemerle (http://www.nemerle.org). But Nemerle use different technique -- code of macros have access to syntax tree at compilation stage.

-- 
Regards,
Yauheni Akhotnikau