Re: Native rules proposal

From: David Abrahams (dave_at_[hidden])
Date: 2003-12-15 12:18:13

Vladimir Prus <ghost_at_[hidden]> writes:

> David Abrahams wrote:
>
>> >> The problem with builtins is that they are declared and executed in
>> >> global module. This means that if rule accesses module variables, or if
>> >> rule is a class method, we're in trouble, since those variables can't be
>> >> accessed, at least cleanly.
>> >
>> > Isn't that what the "localize" parameter to IMPORT is for?
>>
>> Volodya, I don't mean to press you, but I'm afraid that large and
>> unneccessary changes could get made if you don't consider this
>> question.
>
> Sure. I did asked about the proposal precisely to make sure this is not a 
> mistake. I was not able to reply on Friday because we had yet another holiday 
> here in Russia.
>
> Now about 'localize' -- I did not consider it at the moment. IIUC, with 
> 'localize', the whole thing will work like:
>
> 1. You declare builtin called 'set.difference'. 

You could call it anything.

> 2. Insides the 'set' module, you put
>
> IMPORT : set.difference : $(_name) : difference : localize ;
> EXPORT set : difference ;
>
> 3. After 'set.jam' is read, the 'difference' rule is exported into global 
> scope, and now 'set.difference' behaves as rule declared in 'set', but is in 
> fact implemented in 'C'

Yep.

> The good thing about the proposal is that it does not require a new
> builtin. 

You mean _my_ proposal?

> The only thing I don't like is cluttering the global namespace. 
> After all, the implementation -- the .c files declaring new rules -- is better 
> live in separate files in 'modules' directory, as builtins.c is large enough 
> already. It's nicer if namespaces follow that layout, though it's not 
> critical.

It should be very easy to get builtin rule declarations to go into a
specific module. You could even do it by searching for "." in the
name.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com