February 08, 2007 Re: DMD 1.005 release | ||||
---|---|---|---|---|
| ||||
Posted in reply to Andrei Alexandrescu (See Website For Email) | 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 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter Bright | 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 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter Bright | 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 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Derek Parnell | 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 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Andrei Alexandrescu (See Website For Email) | 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 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter Bright | 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 | ||||
---|---|---|---|---|
| ||||
Posted in reply to BCS | 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 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Sean Kelly | 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 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter Bright | > 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 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Kyle Furlong | > 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 |
Copyright © 1999-2021 by the D Language Foundation