Module name compile time constant?

[Yigal Chripun]

Bill Baxter wrote:
> 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
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