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

[Nawfel BGH]

I like it.

Lets go all the way down and make `T P` an abbreviation to `T` 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
constructors

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 :

> 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
>
>Arc RWLock Vec f64
> => Arc>>
>
>Arc Exclusive Vec Box Buffer T
> => Arc // from libsync
>
>RefCell DefIdMap Rc Vec Rc TraitRef
> => RefCell// from librustc
>
>HashMap
> => HashMap, Vec>>>
>
>Add
> => Add, Complex>
>
>std::mem::size_of RefCell String()  // maybe a bit much?
> => std::mem::size_of::>())
>
> 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@mozilla.org
> https://mail.mozilla.org/listinfo/rust-dev
>
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

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

[Cameron Zwarich]

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  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
> 
>   Arc RWLock Vec f64
>=> Arc>>
> 
>   Arc Exclusive Vec Box Buffer T
>=> Arc // from libsync
> 
>   RefCell DefIdMap Rc Vec Rc TraitRef
>=> RefCell// from librustc
> 
>   HashMap
>=> HashMap, Vec>>>
> 
>   Add
>=> Add, Complex>
> 
>   std::mem::size_of RefCell String()  // maybe a bit much?
>=> std::mem::size_of::>())
> 
> 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@mozilla.org
> https://mail.mozilla.org/listinfo/rust-dev

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

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

[Benjamin Herr]

I realize that, but simplifying

Arc

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  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
> > 
> >   Arc RWLock Vec f64
> >=> Arc>>
> > 
> >   Arc Exclusive Vec Box Buffer T
> >=> Arc // from libsync
> > 
> >   RefCell DefIdMap Rc Vec Rc TraitRef
> >=> RefCell// from librustc
> > 
> >   HashMap
> >=> HashMap, Vec>>>
> > 
> >   Add
> >=> Add, Complex>
> > 
> >   std::mem::size_of RefCell String()  // maybe a bit much?
> >=> std::mem::size_of::>())
> > 
> > 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@mozilla.org
> > https://mail.mozilla.org/listinfo/rust-dev
> 


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

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

[François-Xavier Bourlet]

Isn't:

   type my_convonluted_type = Arc;

The most common way to avoid retyping long definition? one could also
pretty indent the type definition for readability, since it will be
defined once.

On Sun, Jun 29, 2014 at 9:56 AM, Benjamin Herr  wrote:
> I realize that, but simplifying
>
> Arc
>
> 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  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
>> >
>> >   Arc RWLock Vec f64
>> >=> Arc>>
>> >
>> >   Arc Exclusive Vec Box Buffer T
>> >=> Arc // from libsync
>> >
>> >   RefCell DefIdMap Rc Vec Rc TraitRef
>> >=> RefCell// from librustc
>> >
>> >   HashMap
>> >=> HashMap, Vec>>>
>> >
>> >   Add
>> >=> Add, Complex>
>> >
>> >   std::mem::size_of RefCell String()  // maybe a bit much?
>> >=> std::mem::size_of::>())
>> >
>> > 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@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] Support for Literate Rust

[Nathan Typanski]

Literate Rust (.lrs)


I'm wondering if anyone else here has had the thought of supporting
literate programming in Rust. For those who don't know what this is
about, a language with good support for the concept is Haskell [1],
which normally uses bird-style (>) for code blocks. I would propose a
file extension (.lrs, most likely) that's dedicated to literate
usage.

If there's some decent feedback for this, and people seem to enjoy it,
then I will do more research and write a RFC.

[1]: 

## Who would benefit from this

### Schools teaching Rust

Universities teaching Rust would be one of my first bets as a user for
Literate Rust. While literate programming is sometimes too far a
stretch from reality for production code (which is both a good and bad
thing), pedagogical gains for literate programming are huge - you can
run the same code that's teaching you about the language or the
concept. Essays and writings that feature the code are
indistinguishable from valid Rust code.

### Documentation/books/etc.

Another use is general documentation, books about Rust, etc. where
there are real benefits to having valid code all the way through them.
When walking through a sample project, the sample project is also the
code that produced it. This makes documentation easier, since you're
more able to ensure that your examples compile properly and actually
run when the compiler updates, etc.

There's also a mental shift when doing literate programming, versus
just ///'ing within code and whatnot: your primary thought process
becomes thinking and communicating with the reader, rather than
working on the code. You focus more on the text and ensuring that it
makes sense.

## How this could work with Rustdoc for APIs

API documentation in a literate program would be included as before,
in rustdoc comments in the output. The internal comments should be the
default for text, not external API.

As an example, here's some code taken from 
src/libstd/collections/hashmap.rs, and interpreted in a literate style:

> /// Does not initialize the buckets. The caller should ensure they,
> /// at the very least, set every hash to EMPTY_BUCKET.
> unsafe fn new_uninitialized(capacity: uint) -> RawTable {
> let hashes_size = capacity.checked_mul(&size_of::())
>   .expect("capacity overflow");
> let keys_size = capacity.checked_mul(&size_of::< K >())
> .expect("capacity overflow");
> let vals_size = capacity.checked_mul(&size_of::< V >())
> .expect("capacity overflow");
>

Allocating hashmaps is a little tricky. We need to allocate three
arrays, but since we know their sizes and alignments up front,
we just allocate a single array, and then have the subarrays
point into it.

This is great in theory, but in practice getting the alignment
right is a little subtle. Therefore, calculating offsets has been
factored out into a different function.

> let (malloc_alignment, hash_offset, keys_offset, vals_offset, size) =
> calculate_offsets(
> hashes_size, min_align_of::(),
> keys_size,   min_align_of::< K >(),
> vals_size,   min_align_of::< V >());

The non-bird text (without the >) is what would normally go in the
comments for the code. In this case, since it's an API, the thing you
actually want in your regular documentation is still the rustdoc api
comments (///), but with the option of generating a literate
presentation of the code (perhaps by autoconversion to pandoc?) where
you read the internal comments instead of the API docs as the main
source of writing.

In other words, literate files can serve as a guide to *developers* of
the code, not necessarily just to users. Though for non-API material,
it's useful for both.

## Editor updates

- Emacs and Vim plugins would have to be updated to understand the new
  extension, and actually behave properly when editing one of these
  files. Probably we should have conditional syntax highlighting
  depending on the block type that we're working on.

## Rustc

Rustc would need to be able to interpret and understand literate Rust
code just as well as it can regular code, so that they can link to one
another without an additional step - otherwise this isn't useful. I
should be able to run Literate Rust just like it's any other Rust
code.

### Conversion

There are relatively easy ways to do "literate -> code" conversion
without actually interfering with anything. Haskell has a sed
implementation [2] on their wiki. Re-implementing this in Rust would
not be a significant effort.

I think a reasonable way to manage the conversion would be to have a
hidden step that moves the converted code to /tmp or something
similar, then compiles that code and removes the converted bit.

There would be s

Re: [rust-dev] Support for Literate Rust

[Evan G]

I'm not sure if this is exactly what you're looking for, but rust already
has support for running code examples in documentation. If I remember
correctly, all of the code examples in the guide are currently run and
tested as part of make test, so this is at least part way towards what you
want.


On Sun, Jun 29, 2014 at 2:30 PM, Nathan Typanski 
wrote:

> Literate Rust (.lrs)
> 
>
> I'm wondering if anyone else here has had the thought of supporting
> literate programming in Rust. For those who don't know what this is
> about, a language with good support for the concept is Haskell [1],
> which normally uses bird-style (>) for code blocks. I would propose a
> file extension (.lrs, most likely) that's dedicated to literate
> usage.
>
> If there's some decent feedback for this, and people seem to enjoy it,
> then I will do more research and write a RFC.
>
> [1]: 
>
> ## Who would benefit from this
>
> ### Schools teaching Rust
>
> Universities teaching Rust would be one of my first bets as a user for
> Literate Rust. While literate programming is sometimes too far a
> stretch from reality for production code (which is both a good and bad
> thing), pedagogical gains for literate programming are huge - you can
> run the same code that's teaching you about the language or the
> concept. Essays and writings that feature the code are
> indistinguishable from valid Rust code.
>
> ### Documentation/books/etc.
>
> Another use is general documentation, books about Rust, etc. where
> there are real benefits to having valid code all the way through them.
> When walking through a sample project, the sample project is also the
> code that produced it. This makes documentation easier, since you're
> more able to ensure that your examples compile properly and actually
> run when the compiler updates, etc.
>
> There's also a mental shift when doing literate programming, versus
> just ///'ing within code and whatnot: your primary thought process
> becomes thinking and communicating with the reader, rather than
> working on the code. You focus more on the text and ensuring that it
> makes sense.
>
> ## How this could work with Rustdoc for APIs
>
> API documentation in a literate program would be included as before,
> in rustdoc comments in the output. The internal comments should be the
> default for text, not external API.
>
> As an example, here's some code taken from
> src/libstd/collections/hashmap.rs, and interpreted in a literate style:
>
> > /// Does not initialize the buckets. The caller should ensure they,
> > /// at the very least, set every hash to EMPTY_BUCKET.
> > unsafe fn new_uninitialized(capacity: uint) -> RawTable {
> > let hashes_size = capacity.checked_mul(&size_of::())
> >   .expect("capacity overflow");
> > let keys_size = capacity.checked_mul(&size_of::< K >())
> > .expect("capacity overflow");
> > let vals_size = capacity.checked_mul(&size_of::< V >())
> > .expect("capacity overflow");
> >
>
> Allocating hashmaps is a little tricky. We need to allocate three
> arrays, but since we know their sizes and alignments up front,
> we just allocate a single array, and then have the subarrays
> point into it.
>
> This is great in theory, but in practice getting the alignment
> right is a little subtle. Therefore, calculating offsets has been
> factored out into a different function.
>
> > let (malloc_alignment, hash_offset, keys_offset, vals_offset,
> size) =
> > calculate_offsets(
> > hashes_size, min_align_of::(),
> > keys_size,   min_align_of::< K >(),
> > vals_size,   min_align_of::< V >());
>
> The non-bird text (without the >) is what would normally go in the
> comments for the code. In this case, since it's an API, the thing you
> actually want in your regular documentation is still the rustdoc api
> comments (///), but with the option of generating a literate
> presentation of the code (perhaps by autoconversion to pandoc?) where
> you read the internal comments instead of the API docs as the main
> source of writing.
>
> In other words, literate files can serve as a guide to *developers* of
> the code, not necessarily just to users. Though for non-API material,
> it's useful for both.
>
> ## Editor updates
>
> - Emacs and Vim plugins would have to be updated to understand the new
>   extension, and actually behave properly when editing one of these
>   files. Probably we should have conditional syntax highlighting
>   depending on the block type that we're working on.
>
> ## Rustc
>
> Rustc would need to be able to interpret and understand literate Rust
> code just as well as it can regular code, so that they can link to one
> another without an additional step - otherwise this isn't useful. I
> sho

Re: [rust-dev] Support for Literate Rust

[Brian Anderson]

It does seem like rustdoc could be extended to do something 
approximating literate programming without much hassle. I'd like to see 
this project built out-of-tree using the rustdoc and rustc API's.


On 06/29/2014 12:38 PM, Evan G wrote:
I'm not sure if this is exactly what you're looking for, but rust 
already has support for running code examples in documentation. If I 
remember correctly, all of the code examples in the guide are 
currently run and tested as part of make test, so this is at least 
part way towards what you want.



On Sun, Jun 29, 2014 at 2:30 PM, Nathan Typanski > wrote:


Literate Rust (.lrs)


I'm wondering if anyone else here has had the thought of supporting
literate programming in Rust. For those who don't know what this is
about, a language with good support for the concept is Haskell [1],
which normally uses bird-style (>) for code blocks. I would propose a
file extension (.lrs, most likely) that's dedicated to literate
usage.

If there's some decent feedback for this, and people seem to enjoy it,
then I will do more research and write a RFC.

[1]: 

## Who would benefit from this

### Schools teaching Rust

Universities teaching Rust would be one of my first bets as a user for
Literate Rust. While literate programming is sometimes too far a
stretch from reality for production code (which is both a good and bad
thing), pedagogical gains for literate programming are huge - you can
run the same code that's teaching you about the language or the
concept. Essays and writings that feature the code are
indistinguishable from valid Rust code.

### Documentation/books/etc.

Another use is general documentation, books about Rust, etc. where
there are real benefits to having valid code all the way through them.
When walking through a sample project, the sample project is also the
code that produced it. This makes documentation easier, since you're
more able to ensure that your examples compile properly and actually
run when the compiler updates, etc.

There's also a mental shift when doing literate programming, versus
just ///'ing within code and whatnot: your primary thought process
becomes thinking and communicating with the reader, rather than
working on the code. You focus more on the text and ensuring that it
makes sense.

## How this could work with Rustdoc for APIs

API documentation in a literate program would be included as before,
in rustdoc comments in the output. The internal comments should be the
default for text, not external API.

As an example, here's some code taken from
src/libstd/collections/hashmap.rs , and
interpreted in a literate style:

> /// Does not initialize the buckets. The caller should
ensure they,
> /// at the very least, set every hash to EMPTY_BUCKET.
> unsafe fn new_uninitialized(capacity: uint) -> RawTable {
> let hashes_size = capacity.checked_mul(&size_of::())
>   .expect("capacity overflow");
> let keys_size = capacity.checked_mul(&size_of::< K >())
> .expect("capacity overflow");
> let vals_size = capacity.checked_mul(&size_of::< V >())
> .expect("capacity overflow");
>

Allocating hashmaps is a little tricky. We need to allocate three
arrays, but since we know their sizes and alignments up front,
we just allocate a single array, and then have the subarrays
point into it.

This is great in theory, but in practice getting the alignment
right is a little subtle. Therefore, calculating offsets has been
factored out into a different function.

> let (malloc_alignment, hash_offset, keys_offset,
vals_offset, size) =
> calculate_offsets(
> hashes_size, min_align_of::(),
> keys_size,   min_align_of::< K >(),
> vals_size,   min_align_of::< V >());

The non-bird text (without the >) is what would normally go in the
comments for the code. In this case, since it's an API, the thing you
actually want in your regular documentation is still the rustdoc api
comments (///), but with the option of generating a literate
presentation of the code (perhaps by autoconversion to pandoc?) where
you read the internal comments instead of the API docs as the main
source of writing.

In other words, literate files can serve as a guide to *developers* of
the code, not necessarily just to users. Though for non-API material,
it's useful for both.

## Editor updates

- Emacs and Vim plugins would have to be updated to understand the ne

Re: [rust-dev] Integer overflow, round -2147483648

[Gábor Lehel]

Thanks to everyone for the excellent feedback. I've submitted an RFC
incorporating many of the ideas from the discussion:

https://github.com/rust-lang/rfcs/pull/146


On Fri, Jun 27, 2014 at 5:58 PM, Patrick Walton 
wrote:

> On 6/27/14 1:31 AM, Igor Bukanov wrote:
>
>> This bug would be harmless in safe code in Rust as exploiting it
>> requires array access without bound checking.
>>
>
> Correct. This is a prime example of what I was talking about in my earlier
> message: weaponizing integer overflows is much more difficult in a
> memory-safe language.
>
> Patrick
>
>
> ___
> 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

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

[Benjamin Striegel]

If the vast majority of types take only a single type parameter, then it
could potentially be worth considering using a unary sigil. (I think D does
something like this.)

Choosing the tilde as the arbitrary symbol here, your example would look
like Arc~Exclusive~Vec~Box~Buffer~T. If you have multiple type parameters,
you would need to wrap them in parens like ~(T, U). Just something to
consider.

Whether or not we want something like this, I'd be fascinated if someone
managed to gather stats on how many types take only a single type parameter.


On Sun, Jun 29, 2014 at 3:06 PM, François-Xavier Bourlet 
wrote:

> Isn't:
>
>type my_convonluted_type = Arc;
>
> The most common way to avoid retyping long definition? one could also
> pretty indent the type definition for readability, since it will be
> defined once.
>
> On Sun, Jun 29, 2014 at 9:56 AM, Benjamin Herr  wrote:
> > I realize that, but simplifying
> >
> > Arc
> >
> > 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  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
> >> >
> >> >   Arc RWLock Vec f64
> >> >=> Arc>>
> >> >
> >> >   Arc Exclusive Vec Box Buffer T
> >> >=> Arc // from libsync
> >> >
> >> >   RefCell DefIdMap Rc Vec Rc TraitRef
> >> >=> RefCell// from librustc
> >> >
> >> >   HashMap
> >> >=> HashMap, Vec>>>
> >> >
> >> >   Add
> >> >=> Add, Complex>
> >> >
> >> >   std::mem::size_of RefCell String()  // maybe a bit much?
> >> >=> std::mem::size_of::>())
> >> >
> >> > 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@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