I realize that, but simplifying
Arc<Exclusive<Vec<Box<Buffer<T>>>>>
into
Arc (Exclusive (Vec (Box (Buffer T))))
wouldn't really buy us that much.
On Sun, 2014-06-29 at 09:50 -0700, Cameron Zwarich wrote:
> This is pretty confusing to me because it’s associative in the opposite
> direction that function application is associative in functional languages
> with automatic currying.
>
> Cameron
>
> On Jun 28, 2014, at 3:48 PM, Benjamin Herr <[email protected]> wrote:
>
> > 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
> > [email protected]
> > https://mail.mozilla.org/listinfo/rust-dev
>
_______________________________________________
Rust-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/rust-dev
