The Thermopylae excerpt of TDPL available online

[Lars T. Kyllingstad]

Don wrote:
> Jason House wrote:
>> Don Wrote:
>>
>>> Leandro Lucarella wrote:
>>>> Justin Johansson, el 30 de octubre a las 08:42 me escribiste:
>>>>>> Actually, I think I like that better than 'traits'.
>>>>>>
>>>>>> -Lars
>>>>> I'm in agreement with whoever suggested 'meta' or just about 
>>>>> anything else except  'traits'.
>>>>> 'meta', whilst perhaps an overloaded keyword, is still much more 
>>>>> user-friendly.  Whenever
>>>>> I see 'traits' I get the feeling I need a Ph.D. to understand what 
>>>>> it's about.  For some reason,
>>>>> I don't know why, 'meta' has an aire of karma about it.
>>>> "compiler"? That could open the door to other types of access to 
>>>> compiler
>>>> internals, AST, etc.
>>> Yup. I think the 'magic namespace' approach is a simple, clean way to 
>>> incorporate reflection. It could be like Object and TypeInfo, 
>>> implicitly available in every module and tightly coupled to the 
>>> compiler, but can be viewed by the user as if it were just a module. 
>>> It'd be particularly interesting if some of the functions _were_  
>>> actually implemented in library code, when possible.
>>
>> What about going one step further? You could require an import 
>> statement to use traits. For example, import traits=std.traits could 
>> reproduce your earlier suggestion, but gives added flexibility to the 
>> programmer. It also eliminates a keyword.
> 
> It's too fundamental for that. You can't use template constraints 
> without it.
> BTW, 'scope' is another possible magic namespace.
> 
> scope.compiles(XXX) -- true if XXX compiles in the current scope.
> 
> More generally, scope.YYY()  would provide metaprogramming information 
> about the property YYY of the current scope.

Do you mean in addition to or instead of the already proposed 
traits/meta/compiler namespace?

If it's just about avoiding new keywords I think this feature is 
fundamental enough to deserve its own keyword, and all of the above are 
more descriptive than 'scope'.

Is this "magic namespace" proposal technically difficult to implement in 
the compiler?

-Lars