[rust-dev] Syntax sugar: Vec Rc RefCell Box Foo -> Vec<Rc<RefCell<Box<Foo>>>>

Nawfel BGH b.gh.n.93 at gmail.com
Sun Jun 29 07:36:33 PDT 2014

I like it.

Lets go all the way down and make `T P` an abbreviation to `T<P>` and `f x`
an abbreviation to `f(x)`

People will then start to write `f a b` instead of `f(a,b)` since unboxed
closures make this possible. They will also write a macro `defun` to ease
the definitions of such functions and request that feature to be integrated
in the language

Unfortunately `T P1 P2` will not come soon because we don't support type

Every thing after "i like it." was a joke. but i'm really sad to see rust
adopting the current syntax for types

2014-06-28 23:48 GMT+01:00 Benjamin Herr <ben at 0x539.de>:

> So, I've been vaguely concerned that types in a less sigil-heavy Rust
> inevitably devolve into what some call "spikey lisp", and tried to come
> up with some more lightweight syntax. Of course, just removing syntax is
> the easiest way to make it weigh less, and it seems like the following
> doesn't actually break the grammar dramatically (only some macros!):
> In parsing a path, if a path segment is immediately followed by an
> identifier, start parsing another type right away and use it as the only
> element of the type parameter list for the current path segment.
> This is fairly limited:
> * It won't work for absolute paths as type parameters
>   (since they'll look like just another path segment)
> * It also doesn't work for non-path types in type parameter lists
> * It doesn't simplify multiple type parameters
> I think that's okay, since it's a simplification that applies well to a
> lot of simple cases, and might still reduce the total depth of `<`, `>`
> nesting in more complicated cases.
> So, for example, the following desugarings would apply:
>        Vec String
>     => Vec<String>
>        Arc RWLock Vec f64
>     => Arc<RWLock<Vec<f64>>>
>        Arc Exclusive Vec Box Buffer T
>     => Arc<Exclusive<Vec<Box<Buffer<T>>>>>         // from libsync
>        RefCell DefIdMap Rc Vec Rc TraitRef
>     => RefCell<DefIdMap<Rc<Vec<Rc<TraitRef>>>>>    // from librustc
>        HashMap<Vec String, Vec Rc Cell int>
>     => HashMap<Vec<String>, Vec<Rc<Cell<int>>>>
>        Add<Complex T, Complex T>
>     => Add<Complex<T>, Complex<T>>
>        std::mem::size_of RefCell String()          // maybe a bit much?
>     => std::mem::size_of::<RefCell<String>>())
> I've patched that into libsyntax and `make check` passes...
> ... after changing some macros, since it basically means that adjacent
> identifiers parse as a single type (or expression, if we omit `::<>`
> too) and some macros try to match `($x:ty fake_keyword_ident ...)`, or
> have a case for `($x:expr)` and another for `(fake_keyword $x:expr)`, or
> just `($t:ty)*`. Seems like just chomping down on all adjacent
> identifiers makes the parser pretty aggressive...
> Yeah, okay, I don't know if this is really a good idea, and it's
> probably not RFC-worthy at this point, but imo it does make the syntax a
> bit easier on the eyes, and I think that's something we ought to look at
> at some point.
> _______________________________________________
> Rust-dev mailing list
> Rust-dev at mozilla.org
> https://mail.mozilla.org/listinfo/rust-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/rust-dev/attachments/20140629/0bbeca00/attachment.html>

More information about the Rust-dev mailing list