View mode: basic / threaded / horizontal-split · Log in · Help
February 08, 2007
Re: DMD 1.005 release
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
Re: DMD 1.005 release
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
Re: DMD 1.005 release
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
Re: DMD 1.005 release
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
Re: DMD 1.005 release
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
Re: DMD 1.005 release
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
Re: DMD 1.005 release
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
Re: DMD 1.005 release
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
Re: DMD 1.005 release
> 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
Re: DMD 1.005 release
> 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
9 10 11 12 13 14 15 16 17
Top | Discussion index | About this forum | D home