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

Here's the pull request for loadable syntax extensions: https://github.com/mozilla/rust/pull/11151 If you look through the tests, there are a few more examples of them, like this: https://github.com/mozilla/rust/blob/master/src/test/auxiliary/macro_crate_test.rs Once this pull requests lands, i

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

On 01/29/2014 06:00 PM, SiegeLord wrote: 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 loo

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

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 supp

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

Hi, I didn't read through the whole post, but I think maybe we could even let user add one more hint about max iteration time, since lib user should be aware of it? 于 2014/1/29 18:44, Pierre Talbot 写道: Well yes, due to the halting problem, we can't detect if a function will diverge or not. It

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

The rough idea that pcwalton, acrichto and I were talking about when I was working on the procedural macro stuff was to split compilation into two phases. The first phase would produce a library that the compiler would load for the second phase. The procedural macro PR added the `phase` attribute w

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

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 t

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

Well yes, due to the halting problem, we can't detect if a function will diverge or not. It's on the behalf of the library user. However, we could limit the number of iteration or recursion to an arbitrary number. On 01/29/2014 11:39 AM, Gábor Lehel wrote: Ah, so `fail!()` is not okay, but `lo

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

Ah, so `fail!()` is not okay, but `loop { }` is okay. On Wed, Jan 29, 2014 at 11:26 AM, Pierre Talbot wrote: > It's a diverging function in the sense of the manual: > http://static.rust-lang.org/doc/master/rust.html#diverging-functions > > On 01/29/2014 11:21 AM, Gábor Lehel wrote: > >> On Wed,

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

It's a diverging function in the sense of the manual: http://static.rust-lang.org/doc/master/rust.html#diverging-functions On 01/29/2014 11:21 AM, Gábor Lehel wrote: On Wed, Jan 29, 2014 at 10:19 AM, Pierre Talbot > wrote: I add: a pure function can call extern code

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

On Wed, Jan 29, 2014 at 10:19 AM, Pierre Talbot wrote: > I add: a pure function can call extern code and diverges, so the pure > requirements are a subset of the CTFE requirements. > How do you plan to enforce that a function won't diverge? Are there any systems which allow calling functions an

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

On 01/29/2014 01:39 AM, Brendan Zabarauskas wrote: On 29 Jan 2014, at 9:15 am, Pierre Talbot wrote: I propose some requirements on function eligible for CTFE (see the proposal for references to the Rust manual): 1. Its parameters are evaluable at compile-time. 2. It isn’t a diverging functio

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

CTFE would indeed be a very interesting thing to see an experiment on in Rust. However, practically, what is the problem that CTFE solves that cannot be solved by a hygienic macro system (or alternatively, a syntax extension that has access to the AST)? My experience with D's CTFE has been largel

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

On Jan 28, 2014, at 4:01 PM, Pierre Talbot wrote: > On 01/29/2014 12:45 AM, Kevin Ballard wrote: >> Yes, I was using #[ctfe] to mean something slightly different than you were. >> In my case, it meant "mark this function as eligible for CTFE, and impose >> all the CTFE restrictions". And it doe

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

On 01/29/2014 12:45 AM, Kevin Ballard wrote: On Jan 28, 2014, at 3:16 PM, Pierre Talbot wrote: On 01/28/2014 11:24 PM, Kevin Ballard wrote: It sounds like you're proposing that arbitrary functions may be eligible for CTFE if they happen to meet all the requirements, without any special anno

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

On Tue, Jan 28, 2014 at 6:56 PM, Pierre Talbot wrote: > With support of the compiler, the macros could be implemented in Rust, but > this is a work that can only be done after CTFE is implemented. So we have > all the time to invent new syntax and deliberate on the semantic. Actually, Rust alread

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

If we drop macro, I can come up with a "simple" solution inspired by the Lisp quote: // Return a Rust construction string. #[ctfe(always)] fn make_rust_construct() -> ~str { return ~"5 + 5"; } #[ctfe(always)] fn eval(s: ~str) -> ??; fn main() { eval(make_rust_construct()); } We'd rely on

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

On 29/01/14 10:45, Kevin Ballard wrote: On Jan 28, 2014, at 3:16 PM, Pierre Talbot wrote: On 01/28/2014 11:24 PM, Kevin Ballard wrote: It sounds like you're proposing that arbitrary functions may be eligible for CTFE if they happen to meet all the requirements, without any special annotatio

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

On Jan 28, 2014, at 3:16 PM, Pierre Talbot wrote: > On 01/28/2014 11:24 PM, Kevin Ballard wrote: >> It sounds like you're proposing that arbitrary functions may be eligible for >> CTFE if they happen to meet all the requirements, without any special >> annotations. This seems like a bad idea to

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

The way it is implemented in Rust is by using the libc, but the requirement #6 says we can't call external function, so implicitly the problem is solved. I'm agree that it isn't formal, but I can't come up with a better solution for now. You made me think of another requirements (so basic that

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

That's what I figured. Forbidding unsafe is definitely a good way to keep things simple starting out. Compile time evaluation can always be extended later on. On Tue, Jan 28, 2014 at 3:21 PM, Pierre Talbot wrote: > On 01/28/2014 11:26 PM, Eric Reed wrote: > >> Looks pretty reasonable to me at f

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

Devil's advocate: CTFE and procedural macros would both allow arbitrary Rust code to be evaluated at compile time. Is there any sane way to combine them rather than making them separate islands? Personally, I want a way to run arbitrary code at compile time that can introspect on and possibly gen

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

On 01/28/2014 11:26 PM, Eric Reed wrote: Looks pretty reasonable to me at first glance. Out of curiosity, what's the rationale behind forbidding unsafe functions/blocks? In the reference manual we can read things such as: "Mutating an immutable value/reference, if it is not marked as non-free

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

On 01/28/2014 11:24 PM, Kevin Ballard wrote: It sounds like you're proposing that arbitrary functions may be eligible for CTFE if they happen to meet all the requirements, without any special annotations. This seems like a bad idea to me. I understand why it's attractive, but it means that see

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

Out of that list of requirements, #5 (doesn't perform I/O actions) is the one that strikes me as least well-defined. Could you elaborate on how you would enforce it? Cheers, Josh On 28 January 2014 14:15, Pierre Talbot wrote: > Hi, > > The Mozilla foundation proposes research internships [1] a

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

Looks pretty reasonable to me at first glance. Out of curiosity, what's the rationale behind forbidding unsafe functions/blocks? On Tue, Jan 28, 2014 at 2:15 PM, Pierre Talbot wrote: > Hi, > > The Mozilla foundation proposes research internships [1] and the CTFE > optimization in the Rust compi

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

It sounds like you're proposing that arbitrary functions may be eligible for CTFE if they happen to meet all the requirements, without any special annotations. This seems like a bad idea to me. I understand why it's attractive, but it means that seemingly harmless changes to a function's implem

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

Hi, The Mozilla foundation proposes research internships [1] and the CTFE optimization in the Rust compiler seems to be a really exciting project. I wrote a proposal [2] that I'll send with my application and so I'd like to share it with you and discuss about bringing CTFE inside Rust. Here