April 16, 2008
Yigal Chripun wrote:
> Bill Baxter wrote:
>> Simen Kjaeraas wrote:
>>> On Tue, 15 Apr 2008 17:56:32 +0200, Spacen Jasset
>>> <spacenjasset@yahoo.co.uk> wrote:
>>>
>>>> davidl wrote:
>>>>> 在 Tue, 15 Apr 2008 15:12:13 +0800,Janice Caron
>>>>> <caron800@googlemail.com> 写道:
>>>>>
>>>>>> On 15/04/2008, davidl <davidl@126.com> wrote:
>>>>>>>  I want some magic of module.name to get the current module name
>>>>>>> in compile
>>>>>>> time string form.
>>>>>> Yeah, basically you want to add __MODULE__ to the list of "special
>>>>>> tokens" in
>>>>>> http://digitalmars.com/d/2.0/lex.html
>>>>>>
>>>>>> I think it would be easy for Walter to add, and I don't think it's
>>>>>> particularly controversial, so why not just go ahead and add an
>>>>>> enhancement request to Bugzilla.
>>>>>  I'm looking for a cleaner solution.
>>>>> __SPEC_TOKEN__ for me looks like a hack.
>>>>>  and it's not so well defined if my app doesn't have a module
>>>>> declaration section?
>>>>> should the compiler stop the compilation?
>>>>>
>>>> __MODULE__ seems reasonable to me. It's in line with __FILE__ and
>>>> __LINE__ and __FUNC__ (which seems absent, from dmd 1 anyway)
>>>>
>>>> If you have no module definition, then presumably it could be "" or
>>>> whatever module the compiler considers it is when that happens
>>>> according to the current rules.
>>>>
>>>> They look a bit like C preprocessor type macros, but really they
>>>> aren't so much, at any rate there is none of the problems you get
>>>> with C style macros and so they don't seem like a hack to me.
>>>>
>>>> What alternative did you have in mind?
>>>
>>> One could argue that a more D-style way to do it would be along the
>>> lines
>>> of preprocessor.line, preprocessor.file, and so on. It looks less like a
>>> hack and more like a real part of the language. One could possibly add
>>> other things to this preprocessor object as well, for instance a list of
>>> version statements, and I'm sure there are other ideas floating around.
>> +1
>>
>> Good point!  Maybe it should still have a preprocessor macro feel
>> though, with underscores, like
>>
>>   __ID(line) or __ID__(file), etc. (akin to __traits(...))
>>
>> I guess pretending it's an object and using . access would be ok too.
>>
>>   __ID.line or __ID__.file, etc.
>>
>>
>>
>> --bb
> 
> +2 for the idea, -infinity for the name. D does not have a preprocessor.
> IMO, the best way to implement it is to have a defined API for the
> compiler and use a Compiler object (just like you have a GC object)
> insead of adding various symbols to the language. This way, you can
> remove __traits(...) as well as all those __Line__, __File__, etc from
> the language as they would become regular methods.
> 
> --Yigal
> 
> PS - Isn't there something like a stringof property for symbols that
> returns a string representation?

That's a good one too.  So you would do something like

   import system : Compiler;

And the compiler would give you access to the Compiler object?
It might be nice to reserve some module names for compiler usage like that.  For providing 'intrinsic' modules.
Python does something like that with its __future__ pseudo-module.

But I think the suggestion may not work for __LINE__ and __FILE__ type constructs.  Those are replaced by the lexer which doesn't know anything about objects or modules or namespaces.  That's probably why there's not __FUNCTION__, too, because the lexer just doesn't know what's a function and what's not.  But it does know what line of what file it's reading.



--bb
April 16, 2008
Bill Baxter wrote:
> Yigal Chripun wrote:
>> Bill Baxter wrote:
>>> Simen Kjaeraas wrote:
>>>> On Tue, 15 Apr 2008 17:56:32 +0200, Spacen Jasset <spacenjasset@yahoo.co.uk> wrote:
>>>>
>>>>> davidl wrote:
>>>>>> 在 Tue, 15 Apr 2008 15:12:13 +0800,Janice Caron <caron800@googlemail.com> 写道:
>>>>>>
>>>>>>> On 15/04/2008, davidl <davidl@126.com> wrote:
>>>>>>>>  I want some magic of module.name to get the current module name
>>>>>>>> in compile
>>>>>>>> time string form.
>>>>>>> Yeah, basically you want to add __MODULE__ to the list of "special
>>>>>>> tokens" in
>>>>>>> http://digitalmars.com/d/2.0/lex.html
>>>>>>>
>>>>>>> I think it would be easy for Walter to add, and I don't think it's particularly controversial, so why not just go ahead and add an enhancement request to Bugzilla.
>>>>>>  I'm looking for a cleaner solution.
>>>>>> __SPEC_TOKEN__ for me looks like a hack.
>>>>>>  and it's not so well defined if my app doesn't have a module
>>>>>> declaration section?
>>>>>> should the compiler stop the compilation?
>>>>>>
>>>>> __MODULE__ seems reasonable to me. It's in line with __FILE__ and __LINE__ and __FUNC__ (which seems absent, from dmd 1 anyway)
>>>>>
>>>>> If you have no module definition, then presumably it could be "" or whatever module the compiler considers it is when that happens according to the current rules.
>>>>>
>>>>> They look a bit like C preprocessor type macros, but really they aren't so much, at any rate there is none of the problems you get with C style macros and so they don't seem like a hack to me.
>>>>>
>>>>> What alternative did you have in mind?
>>>>
>>>> One could argue that a more D-style way to do it would be along the
>>>> lines
>>>> of preprocessor.line, preprocessor.file, and so on. It looks less
>>>> like a
>>>> hack and more like a real part of the language. One could possibly add
>>>> other things to this preprocessor object as well, for instance a
>>>> list of
>>>> version statements, and I'm sure there are other ideas floating
>>>> around.
>>> +1
>>>
>>> Good point!  Maybe it should still have a preprocessor macro feel though, with underscores, like
>>>
>>>   __ID(line) or __ID__(file), etc. (akin to __traits(...))
>>>
>>> I guess pretending it's an object and using . access would be ok too.
>>>
>>>   __ID.line or __ID__.file, etc.
>>>
>>>
>>>
>>> --bb
>>
>> +2 for the idea, -infinity for the name. D does not have a preprocessor. IMO, the best way to implement it is to have a defined API for the compiler and use a Compiler object (just like you have a GC object) insead of adding various symbols to the language. This way, you can remove __traits(...) as well as all those __Line__, __File__, etc from the language as they would become regular methods.
>>
>> --Yigal
>>
>> PS - Isn't there something like a stringof property for symbols that returns a string representation?
>
> That's a good one too.  So you would do something like
>
>    import system : Compiler;
>
> And the compiler would give you access to the Compiler object?
> It might be nice to reserve some module names for compiler usage like
> that.  For providing 'intrinsic' modules.
> Python does something like that with its __future__ pseudo-module.
>
> But I think the suggestion may not work for __LINE__ and __FILE__ type constructs.  Those are replaced by the lexer which doesn't know anything about objects or modules or namespaces.  That's probably why there's not __FUNCTION__, too, because the lexer just doesn't know what's a function and what's not.  But it does know what line of what file it's reading.
>
>
>
> --bb
I think the __LINE__ can be replaced by a CTFE function. This way it
would be possible to provide two methods to solve the issue for mixins
(__LINE__ where the mixin defined vs. __LINE__ where the mixin in
instantiated).
Another befit of this would be a well defined API for D compilers (with
a mechanism for extensions for compiler vendors) which could be used for
other tools. For example, currently if you want a D aware IDE/editor you
either need a D parser or an implementation of the dmd frontend. rebuild
contains an embeded dmd frontend and Descent has a java port. Instead of
reinventing the wheel, such tools could just use that API, and new
features of dmd would be quickly available to IDEs.

Does this worth the extra work? what do you think?

-- Yigal

April 25, 2008
davidl wrote:
> 在 Tue, 15 Apr 2008 13:00:57 +0800,Bill Baxter <dnewsgroup@billbaxter.com> 写道:
> 
>> Walter Bright wrote:
>>> davidl wrote:
>>>>
>>>> module abc.super.long.pack.awesome.mod;
>>>>
>>>> what if i need the string of "abc.super.long.pack.awesome.mod" generally and don't want to copy paste differently in all my modules?
>>>  alias abc.super.long.pack.awesome.mod foo;
>>
>> I think he wants that full module name as a char[], though.
>>
>> Is that what you want, Davidl?
>>
>> Or do you just want to be able to say
>>
>>
>>     import short.awesome; // aka "import abc.super.long.pack.awesome.mod"
>>
>> If that's what you want you can create a module in short/awesome.d that contains just:
>>
>>    module short.awesome;
>>    public import abc.super.long.pack.awesome.mod;
>>
>> But somehow I'm thinking you actually want to automatically get that module name as a string.
>>
>> How about going the other way around?  Start with a string?
>>
>> string foo = "abc.super.long.pack.awesome.mod";
>> mixin(import_module(foo));
>>
>> where import_module  is
>>
>> string import_module(string name) {
>>     return "import " ~ name ";" ;
>> }
>>
>> If those don't answer your question you're gonna have to be more specific.
>>
>>
>> --bb
> 
> Yes, i want the string. But I don't want to modify the module part to manually defined strings
> I want some magic of module.name to get the current module name in compile time string form.
> 

I tried this to see if it would work:

---  ---
module foo.test;

void main()
{
	writefln(.stringof);
}


Almost worked! It prints "module test". It would do what you wanted if '.stringof' returned the fully qualified module (and didn't have the "module " prefix).



-- 
Bruno Medeiros - MSc in CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
April 26, 2008
Bruno Medeiros wrote:
> davidl wrote:
>> 在 Tue, 15 Apr 2008 13:00:57 +0800,Bill Baxter <dnewsgroup@billbaxter.com> 写道:
>>
>>> Walter Bright wrote:
>>>> davidl wrote:
>>>>>
>>>>> module abc.super.long.pack.awesome.mod;
>>>>>
>>>>> what if i need the string of "abc.super.long.pack.awesome.mod" generally and don't want to copy paste differently in all my modules?
>>>>  alias abc.super.long.pack.awesome.mod foo;
>>>
>>> I think he wants that full module name as a char[], though.
>>>
>>> Is that what you want, Davidl?
>>>
>>> Or do you just want to be able to say
>>>
>>>
>>>     import short.awesome; // aka "import abc.super.long.pack.awesome.mod"
>>>
>>> If that's what you want you can create a module in short/awesome.d that contains just:
>>>
>>>    module short.awesome;
>>>    public import abc.super.long.pack.awesome.mod;
>>>
>>> But somehow I'm thinking you actually want to automatically get that module name as a string.
>>>
>>> How about going the other way around?  Start with a string?
>>>
>>> string foo = "abc.super.long.pack.awesome.mod";
>>> mixin(import_module(foo));
>>>
>>> where import_module  is
>>>
>>> string import_module(string name) {
>>>     return "import " ~ name ";" ;
>>> }
>>>
>>> If those don't answer your question you're gonna have to be more specific.
>>>
>>>
>>> --bb
>>
>> Yes, i want the string. But I don't want to modify the module part to manually defined strings
>> I want some magic of module.name to get the current module name in compile time string form.
>>
> 
> I tried this to see if it would work:
> 
> ---  ---
> module foo.test;
> 
> void main()
> {
>     writefln(.stringof);
> }
> 
> 
> Almost worked! It prints "module test". It would do what you wanted if '.stringof' returned the fully qualified module (and didn't have the "module " prefix).

Maybe it's supposed to. The spec for .stringof is completely different to what's implemented.

But anyway...

Getting the fully qualified name is currently possible (since about D0.150) but it's a bit disgusting to do, and I can't really recommend it.  My old meta.nameof module did the job.
If you pass the module name as a template alias parameter, the fully qualified name appears in the mangled name. You just need to demangle it and extract the module name.
April 27, 2008
Don wrote:
> Bruno Medeiros wrote:
>> davidl wrote:
>>> 在 Tue, 15 Apr 2008 13:00:57 +0800,Bill Baxter <dnewsgroup@billbaxter.com> 写道:
>>>
>>>> Walter Bright wrote:
>>>>> davidl wrote:
>>>>>>
>>>>>> module abc.super.long.pack.awesome.mod;
>>>>>>
>>>>>> what if i need the string of "abc.super.long.pack.awesome.mod" generally and don't want to copy paste differently in all my modules?
>>>>>  alias abc.super.long.pack.awesome.mod foo;
>>>>
>>>> I think he wants that full module name as a char[], though.
>>>>
>>>> Is that what you want, Davidl?
>>>>
>>>> Or do you just want to be able to say
>>>>
>>>>
>>>>     import short.awesome; // aka "import abc.super.long.pack.awesome.mod"
>>>>
>>>> If that's what you want you can create a module in short/awesome.d that contains just:
>>>>
>>>>    module short.awesome;
>>>>    public import abc.super.long.pack.awesome.mod;
>>>>
>>>> But somehow I'm thinking you actually want to automatically get that module name as a string.
>>>>
>>>> How about going the other way around?  Start with a string?
>>>>
>>>> string foo = "abc.super.long.pack.awesome.mod";
>>>> mixin(import_module(foo));
>>>>
>>>> where import_module  is
>>>>
>>>> string import_module(string name) {
>>>>     return "import " ~ name ";" ;
>>>> }
>>>>
>>>> If those don't answer your question you're gonna have to be more specific.
>>>>
>>>>
>>>> --bb
>>>
>>> Yes, i want the string. But I don't want to modify the module part to manually defined strings
>>> I want some magic of module.name to get the current module name in compile time string form.
>>>
>>
>> I tried this to see if it would work:
>>
>> ---  ---
>> module foo.test;
>>
>> void main()
>> {
>>     writefln(.stringof);
>> }
>>
>>
>> Almost worked! It prints "module test". It would do what you wanted if '.stringof' returned the fully qualified module (and didn't have the "module " prefix).
> 
> Maybe it's supposed to. The spec for .stringof is completely different to what's implemented.
> 
> But anyway...
> 
> Getting the fully qualified name is currently possible (since about D0.150) but it's a bit disgusting to do, and I can't really recommend it.  My old meta.nameof module did the job.
> If you pass the module name as a template alias parameter, the fully qualified name appears in the mangled name. You just need to demangle it and extract the module name.

Yikes!  Devious.  I guess that's why they pay you the big bucks. ... Or should if they don't.

--bb
April 28, 2008
Bill Baxter wrote:
> Don wrote:
>> Bruno Medeiros wrote:
>>> davidl wrote:
>>>> 在 Tue, 15 Apr 2008 13:00:57 +0800,Bill Baxter <dnewsgroup@billbaxter.com> 写道:
>>>>
>>>>> Walter Bright wrote:
>>>>>> davidl wrote:
>>>>>>>
>>>>>>> module abc.super.long.pack.awesome.mod;
>>>>>>>
>>>>>>> what if i need the string of "abc.super.long.pack.awesome.mod" generally and don't want to copy paste differently in all my modules?
>>>>>>  alias abc.super.long.pack.awesome.mod foo;
>>>>>
>>>>> I think he wants that full module name as a char[], though.
>>>>>
>>>>> Is that what you want, Davidl?
>>>>>
>>>>> Or do you just want to be able to say
>>>>>
>>>>>
>>>>>     import short.awesome; // aka "import abc.super.long.pack.awesome.mod"
>>>>>
>>>>> If that's what you want you can create a module in short/awesome.d that contains just:
>>>>>
>>>>>    module short.awesome;
>>>>>    public import abc.super.long.pack.awesome.mod;
>>>>>
>>>>> But somehow I'm thinking you actually want to automatically get that module name as a string.
>>>>>
>>>>> How about going the other way around?  Start with a string?
>>>>>
>>>>> string foo = "abc.super.long.pack.awesome.mod";
>>>>> mixin(import_module(foo));
>>>>>
>>>>> where import_module  is
>>>>>
>>>>> string import_module(string name) {
>>>>>     return "import " ~ name ";" ;
>>>>> }
>>>>>
>>>>> If those don't answer your question you're gonna have to be more specific.
>>>>>
>>>>>
>>>>> --bb
>>>>
>>>> Yes, i want the string. But I don't want to modify the module part to manually defined strings
>>>> I want some magic of module.name to get the current module name in compile time string form.
>>>>
>>>
>>> I tried this to see if it would work:
>>>
>>> ---  ---
>>> module foo.test;
>>>
>>> void main()
>>> {
>>>     writefln(.stringof);
>>> }
>>>
>>>
>>> Almost worked! It prints "module test". It would do what you wanted if '.stringof' returned the fully qualified module (and didn't have the "module " prefix).
>>
>> Maybe it's supposed to. The spec for .stringof is completely different to what's implemented.
>>
>> But anyway...
>>
>> Getting the fully qualified name is currently possible (since about D0.150) but it's a bit disgusting to do, and I can't really recommend it.  My old meta.nameof module did the job.
>> If you pass the module name as a template alias parameter, the fully qualified name appears in the mangled name. You just need to demangle it and extract the module name.
> 
> Yikes!  Devious.  I guess that's why they pay you the big bucks. ... Or should if they don't.

They don't. <g>
Actually, I'm not employed as a programmer. In fact, programming doesn't even always appear on my performance review. :(
I'm strongly considering a career switch...
April 28, 2008
Don wrote:
>>
>> Yikes!  Devious.  I guess that's why they pay you the big bucks. ... Or should if they don't.
> 
> They don't. <g>
> Actually, I'm not employed as a programmer. In fact, programming doesn't even always appear on my performance review. :(
> I'm strongly considering a career switch...

Graphics is fun.  Use all that nifty math stuff to make pretty pictures!

Better than writing better baby killing algorithms for some military contractor, anyway.

--bb
1 2
Next ›   Last »