On Mon, Apr 29, 2013 at 9:30 PM, Erik S sw...@earthling.net wrote:
On 4/29/2013 2:00 PM, Graydon Hoare wrote:
Yes. Formalizing and completing the definition of the constant
expression subgrammar would be extremely valuable. It's one of the
major high-risk areas remaining the the design space.
I know this will be an unpopular opinion, but pure functions would be a
massive win for Rust, especially if the eventual goal is high performance,
highly parallelizable (browser rendering engines..) development.
The typestate system did seme very complex but isn't there a middle ground
via
On Tue, Apr 30, 2013 at 10:08 AM, Max Cantor i...@cantor.mx wrote:
I know this will be an unpopular opinion, but pure functions would be a
massive win for Rust, especially if the eventual goal is high performance,
highly parallelizable (browser rendering engines..) development.
Being able to
In Haskell they're spectacularly useful. For example, implementing STM in
about a weekend as opposed to never:
http://blog.enfranchisedmind.com/2009/01/the-problem-with-stm-your-languages-still-suck/
I know STM doesn't necessarily play with the Rust memory model, just an
example of an unexpected
On Tue, Apr 30, 2013 at 6:57 PM, Tim Chevalier catamorph...@gmail.comwrote:
On Mon, Apr 29, 2013 at 9:30 PM, Erik S sw...@earthling.net wrote:
On 4/29/2013 2:00 PM, Graydon Hoare wrote:
Yes. Formalizing and completing the definition of the constant
expression subgrammar would be extremely
If so, I had no idea. However, if it doesn't come in before 1.0 then I
fear that ecosystem will develop around not having one and then by 2.0 it
will be too late
On Tue, Apr 30, 2013 at 10:49 AM, Gábor Lehel illiss...@gmail.com wrote:
On Tue, Apr 30, 2013 at 6:57 PM, Tim Chevalier
I just realized that what I proposed earlier is pretty much exactly what
predicate functions were in the days of typestate (sorry, I'm a bit new
here). I completely understand and agree with the decision to remove
typestate which does seem quite complex, however, predicate functions have
a lot of
On Sun, Apr 28, 2013 at 8:14 PM, Patrick Walton pwal...@mozilla.com wrote:
Is
there some way to make it just work, no matter what kind of strings
you're comparing? Perhaps foo == (*x) would work, for example?
That doesn't work, because it makes the dynamically sized `str` a type,
On 4/30/13 11:26 AM, Gábor Lehel wrote:
Couldn't this be relaxed? In other words allow dynamically sized `str`
as a type (and perhaps similarly for other dynamically sized types), but
prohibit those things specifically which would be problematic, i.e.
using it in ways that would require knowing
On 30/04/2013 10:08 AM, Max Cantor wrote:
I know this will be an unpopular opinion, but pure functions would be a
massive win for Rust, especially if the eventual goal is high
performance, highly parallelizable (browser rendering engines..)
development.
Careful. It's important to understand
On 30/04/2013 11:00 AM, Max Cantor wrote:
I just realized that what I proposed earlier is pretty much exactly what
predicate functions were in the days of typestate (sorry, I'm a bit new
here). I completely understand and agree with the decision to remove
typestate which does seem quite
Just want to say that I really appreciate the thoughtful, comprehensive
reply to my beating a dead horse. Pure functions or not, I think its
awesome what you, Mozilla, and the community is doing and look forward to
experimenting with Rust and working on it.
Thanks,
Max
On Tue, Apr 30, 2013 at
Keep in mind that Rust's type system offers very strong guarantees
about aliasing which I think will be very helpful for this sort of
optimization. For example:
- `T` data is *immutable* (not const)
- all `mut` are disjoint (i.e., ANSI C's `restrict`, but checked and
by default)
- when an
On Tue, Apr 30, 2013 at 8:27 PM, Patrick Walton pwal...@mozilla.com wrote:
On 4/30/13 11:26 AM, Gábor Lehel wrote:
Couldn't this be relaxed? In other words allow dynamically sized `str`
as a type (and perhaps similarly for other dynamically sized types), but
prohibit those things
On 29/04/2013 20:40, Graydon Hoare wrote:
On 13-04-28 12:05 PM, james wrote:
Well, the issue is whether the program logic that will deal with data
calls (say) read and iterates over the response, or whether something
gets data and invokes a callback, in which case the code that deals with
the
When the last copy of an `@mut` value is overwritten or goes out of scope,
the runtime is free to deallocate the value it points to. When you take an
`'r mut` to a value in an `@mut`, the compiler has to ensure that at least
one copy of the `@mut` exists for the lifetime 'r, since the `'r mut`
On 30/04/2013 11:26 AM, Gábor Lehel wrote:
Couldn't this be relaxed? In other words allow dynamically sized `str`
as a type (and perhaps similarly for other dynamically sized types), but
prohibit those things specifically which would be problematic, i.e.
using it in ways that would require
On 30/04/2013 12:17 PM, james wrote:
This is what I call blocking synchronous read, a 'pull' model. Its
hardly different
from a threaded rogram with a userspace switch and sync to async call
translation,
whether N:1 or N:M. Granted that the compiler support for task switch
points and
segmented
On Tue, Apr 30, 2013 at 12:22:15PM -0700, Graydon Hoare wrote:
So about the only wiggle room away from where we are now is that we
might be able to make ~[] represented by (ptr,len) pairs too, like
slices are, rather than 1 ptr that points to a [len,data...] buffer.
But it's not clear if that
Hi Graydon,
How does Rust currently represent its' pointers to vectors? Based on what
I've seen in the library, it seems that ~[T] and @[T] are plain pointers
(with size stored in the pointee), but [T] is a fat pointer, i.e. a
(ptr,len) pair. Is this correct?
On Tue, Apr 30, 2013 at 12:22 PM,
On 30/04/2013 2:03 PM, Vadim wrote:
Hi Graydon,
How does Rust currently represent its' pointers to vectors? Based on
what I've seen in the library, it seems that ~[T] and @[T] are plain
pointers (with size stored in the pointee), but [T] is a fat pointer,
i.e. a (ptr,len) pair. Is this
Niko,
- Does immutable mean that the referenced object cannot change forever,
even after current function has returned?
Is it possible in Rust to create a hash that stores its' keys by borrowed
reference (assuming that the hash does not outlive contained keys) and be
assured that the keys will not
On 04/26/2013 04:40 PM, Vadim wrote:
I share your concern. It's likely that Rust tasks will never scale
as well as Erlang and I suspect that we will ultimately want an
async API that does not impose the expense of 1 task per I/O
stream. I hope though that the current approach
On 04/27/2013 03:07 AM, Jordi Boggiano wrote:
Take my input with a grain of salt since I'm so new to the language, but
here goes nothing:
I am particularly interested in making sure that common operations are
convenient and don't require a lot of boilerplate. To that end I've been
collecting
I see, thank you for clarification.
Can't help but note, though, that the dynamic loading case could be worked
around by having a wrapper similar to the one Rust generates around calls
to foreign functions, that would ensure bigger stack segment for the
dynamic linker to use (only the first time
What makes an API a second class citizen? If we expose both, and 99%
of users ...
Which users count? 99% of programmers do half of the
programming work (*). The rest do the other half (**). To
inconvenience 99 out 100 programmers would be a grave error,
To inconvenience the 1% who do the
Let's drop this thread, as per the code of conduct at
https://github.com/mozilla/rust/wiki/Note-development-policy :
Please keep unstructured critique to a minimum. If you have solid
ideas you want to experiment with, make a fork and see how it works.
Cheers,
Tim
--
Tim Chevalier *
27 matches
Mail list logo
