Module name compile time constant?

[Bill Baxter]

Yigal Chripun wrote:
> Bill Baxter wrote:
>> Simen Kjaeraas wrote:
>>> On Tue, 15 Apr 2008 17:56:32 +0200, Spacen Jasset
>>> <spacenjasset at yahoo.co.uk> wrote:
>>>
>>>> davidl wrote:
>>>>> 在 Tue, 15 Apr 2008 15:12:13 +0800，Janice Caron
>>>>> <caron800 at googlemail.com> 写道:
>>>>>
>>>>>> On 15/04/2008, davidl <davidl at 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