[rust-dev] Compile-time function evaluation in Rust

SiegeLord slabode at aim.com
Wed Jan 29 09:00:47 PST 2014


On 01/29/2014 11:44 AM, Niko Matsakis wrote:
> On Tue, Jan 28, 2014 at 07:01:44PM -0500, comex wrote:
>> Actually, Rust already has procedural macros as of recently.  I was
>> wondering whether that could be combined with the proposed new system.
>
> I haven't looked in detail at the procedural macro support that was
> recently added, but off hand I think I favor that approach. That is,
> I'd rather compile a Rust module, link it dynamically, and run it as
> normal, versus defining some subset of Rust that the compiler can
> execute. The latter seems like it'll be difficult to define,
> implement, and understand. Our experience with effect systems and
> purity has not been particularly good, and I think staged compilation
> is easier to explain and free from the twin hazards of "this library
> function is pure but not marked pure" (when using explicit
> declaration) or "this library function is accidentally pure" (when
> using inference).
>

I was under the impression from some time ago that this was going to be 
the way CTFE is implemented in Rust. Having tried CTFE in D, I was not 
impressed by the nebulous definition of the constant language used 
there, it was never clear ahead of time what will work and what won't 
(although maybe the problem won't be as big in Rust, as Rust is a 
smaller language). Additionally, it was just plain slow (you are 
essentially creating a very slow scripting language without JIT).

It seems to me (judging at the size of the loadable procedural macro 
commit size) that using staged compilation approach will be easier to 
implement and be more powerful at the cost of, perhaps, less convenient 
usage.

-SL



More information about the Rust-dev mailing list