Speaking of macros and overly nested functional style--I had some code with 
deeply nested "do" blocks and experimented with a multi_do macro that creates 
syntax reminiscent of haskell's "do" notation.  It's more syntactically noisy 
than would be preferable--I couldn't get it to parse unambiguously without the 
|| and the =>, which I really didn't want.  Having to put the final block 
inside the parentheses of the macro invocation made it not really worth it, 
because when using it, you're always nested two deep, so it'd only reduce 
indentation for three or more levels deep.  But in case anyone's interested:

macro_rules! multi_do {
    (|$args:pat| <- $e:expr; $(|$args_rest:pat| <- $e_rest:expr;)+
     => $blk:block) =>
        (do $e |$args| { multi_do!($(|$args_rest| <- $e_rest;)+ => $blk) });
    {|$args:pat| <- $e:expr; => $blk:block} => (do $e |$args| $blk);
}

it's used it like this:

multi_do!(
    |a| <- first_function(x);
    |b| <- second_function(y);
    |c| <- third_function();
    => {
        compute_stuff_with(a,b, c); 
    });

which expands to:

do first_function(x) |a| {
    do second_function(y) |b| {
        do third_function() |c| {
            compute_stuff_with(a, b, c);
        }
    }
}

On Sep 25, 2013, at 7:39 PM, Marvin Löbel wrote:

> Argh, I forgot about macros! Nevermind then. :P
> 
> On 09/25/2013 08:33 PM, Benjamin Striegel wrote:
>> Note that we reserve the dollar sign ($) for use in macros, so it wouldn't 
>> be able to appear in regular Rust code without some sort of escaping 
>> mechanism. I also don't see anything like this happening before Rust 2.0 at 
>> the earliest.
>> 
>> 
>> On Wed, Sep 25, 2013 at 2:40 PM, Marvin Löbel <loebel.mar...@gmail.com> 
>> wrote:
>> We don't use the symbol in our syntax, but are using functional paradigm 
>> that sometimes result in a bit hard to read nested calls.
>> 
>> I'd propose that it works similar to `do`, in that it allows to move the 
>> last expression of an function or method call after the parentheses, though 
>> they would still remain required for ambiguity reasons:
>> 
>> ~~~
>>    a(b(c(1,d(2,3,4,e()))))
>> == a() $ b() $ c(1) $ d(2,3,4) $ e()
>> 
>> let v: ~[uint] = from_iter() $ range(0, 100);
>> ~~~
>> 
>> In that sense, it wouldn't really be an operator but syntactic sugar for a 
>> function call.
>> It might even be possible to replace `do` with it, though the now required 
>> parentheses would make it longer:
>> 
>> ~~~
>> do task::spawn { ... }
>> task::spawn() $ || { ... }
>> ~~~
>> 
>> Downside is of course that it adds another symbol, which could alienate more 
>> potentiall users, and it could mean a shift-away-from or at least an 
>> inconsistency-with methods and method chaining in general.
>> 
>> Which would be ironic because I wanted it in some complicated Iterator 
>> chain. ;)
>> 
>> It could of course always be implemented as a syntax extension, and in any 
>> case I don't expect this to get any attention before Rust 2.0. :)
>> _______________________________________________
>> Rust-dev mailing list
>> Rust-dev@mozilla.org
>> https://mail.mozilla.org/listinfo/rust-dev
>> 
>> 
>> 
>> _______________________________________________
>> Rust-dev mailing list
>> Rust-dev@mozilla.org
>> https://mail.mozilla.org/listinfo/rust-dev
> 
> _______________________________________________
> Rust-dev mailing list
> Rust-dev@mozilla.org
> https://mail.mozilla.org/listinfo/rust-dev

_______________________________________________
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Reply via email to