Re: [rust-dev] rusti - the - repl renovation
On Thu, Sep 19, 2013 at 11:51 AM, Alex Crichton a...@crichton.co wrote: Basically, I'm OK with leaving out tasks/spawned tasks from rusti, but I think that it should be important to be able to fail! and have the repl state intact afterwards. Agreed. I'm convinced that fail! should result in an almost-magical lets pretend that never happened jump back in time. I'm still trying to figure out how to do this efficiently. For code that has alot of state, serializing and deserializing everything will be too slow. Perhaps the best thing is just to fork(2), so we get a new (OS level) process that has copy-on-write (virtual) memory, and if the compilation + run succeeds in the child, then have the child take over. Otherwise the child dies with an fail! + location message, and we return to the parent exactly before the child was spawned. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] rusti - the - repl renovation
Perhaps the best thing is just to fork(2), so we get a new (OS level) process that has copy-on-write (virtual) memory, and if the compilation + run succeeds in the child, then have the child take over. Otherwise the child dies with an fail! + location message, and we return to the parent exactly before the child was spawned. Do you intend for rusti to work on windows? Because I'm not sure you could do something like that efficiently there. On Fri, Sep 20, 2013 at 8:40 AM, Jason E. Aten j.e.a...@gmail.com wrote: On Thu, Sep 19, 2013 at 11:51 AM, Alex Crichton a...@crichton.co wrote: Basically, I'm OK with leaving out tasks/spawned tasks from rusti, but I think that it should be important to be able to fail! and have the repl state intact afterwards. Agreed. I'm convinced that fail! should result in an almost-magical lets pretend that never happened jump back in time. I'm still trying to figure out how to do this efficiently. For code that has alot of state, serializing and deserializing everything will be too slow. Perhaps the best thing is just to fork(2), so we get a new (OS level) process that has copy-on-write (virtual) memory, and if the compilation + run succeeds in the child, then have the child take over. Otherwise the child dies with an fail! + location message, and we return to the parent exactly before the child was spawned. ___ 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] RFC: Syntax for raw string literals
The way that Lua does raw strings is also fairly nifty. Check out
http://www.lua.org/manual/5.2/manual.html, section 3.1, or, in short:
- Strings can be delimited by [===[, with any number of equals signs.
The corresponding closing delimiter must match the original number of
equals signs.
- No escaping is done.
- Any kind of end-of-line sequence (i.e. \r and \n in any order) is
converted to just a newline.
- It can run for multiple lines.
--Andrew D
On Thu, Sep 19, 2013 at 10:28 PM, Kevin Cantu m...@kevincantu.org wrote:
I think designing good traits to support all these text implementations is
far more important than whatever hungarian notation is preferred for
literals.
Kevin
On Thu, Sep 19, 2013 at 2:50 PM, Martin DeMello
martindeme...@gmail.comwrote:
Ah, good point. You could fix it by having a very small whitelist of
acceptable delimiters, but that probably takes it into overcomplex
territory.
martin
On Thu, Sep 19, 2013 at 2:46 PM, Kevin Ballard ke...@sb.org wrote:
As I just responded to Masklinn, this is ambiguous. How do you lex `do
R{foo()}`?
-Kevin
On Sep 19, 2013, at 2:41 PM, Martin DeMello martindeme...@gmail.com
wrote:
Yes, I figured R followed by a non-alphabetical character could serve
the same purpose as ruby's %char.
martin
On Thu, Sep 19, 2013 at 2:37 PM, Kevin Ballard ke...@sb.org wrote:
I didn't look at Ruby's syntax, but what you just described sounds a
little too free-form to me. I believe Ruby at least requires a % as part of
the syntax, e.g. %q{test}. But I don't think %R{test} is a good idea for
rust, as it would conflict with the % operator. I don't think other
punctuation would work well either.
-Kevin
On Sep 19, 2013, at 2:10 PM, Martin DeMello martindeme...@gmail.com
wrote:
How complicated would it be to use R but with arbitrary paired
delimiters (the way, for instance, ruby does it)? It's very handy to
pick a delimiter you know does not appear in the string, e.g. if you
had a string containing ')' you could use R{this is a string with a )
in it} or R|this is a string with a ) in it|.
martin
On Thu, Sep 19, 2013 at 1:36 PM, Kevin Ballard ke...@sb.org wrote:
One feature common to many programming languages that Rust lacks is
raw string literals. Specifically, these are string literals that don't
interpret backslash-escapes. There are three obvious applications at the
moment: regular expressions, windows file paths, and format!() strings that
want to embed { and } chars. I'm sure there are more as well, such as large
string literals that contain things like HTML text.
I took a look at 3 programming languages to see what solutions they
had: D, C++11, and Python. I've reproduced their syntax below, plus one
more custom syntax, along with pros cons. I'm hoping we can come up with
a syntax that makes sense for Rust.
## Python syntax:
Python supports an r or R prefix on any string literal (both
short strings, delimited with a single quote, or long strings,
delimited with 3 quotes). The r or R prefix denotes a raw string, and
has the effect of disabling backslash-escapes within the string. For the
most part. It actually gets a bit weird: if a sequence of backslashes of an
odd length occurs prior to a quote (of the appropriate quote type for the
string), then the quote is considered to be escaped, but the backslashes
are left in the string. This means rfoo\ evaluates to the string
`foo\`, and similarly rfoo\\\ is `foo\\\`, but rfoo\\ is merely the
string `foo\\`.
Pros:
* Simple syntax
* Allows for embedding the closing quote character in the raw string
Cons:
* Handling of backslashes is very bizarre, and the closing quote
character can only be embedded if you want to have a backslash before it.
## C++11 syntax:
C++11 allows for raw strings using a sequence of the form Rseq(raw
text)seq. In this construct, `seq` is any sequence of (zero or more)
characters except for: space, (, ), \, \t, \v, \n, \r. The simplest form
looks like R(raw text), which allows for anything in the raw text except
for the sequence `)`. The addition of the delimiter sequence allows for
constructing a raw string containing any sequence at all (as the delimiter
sequence can be adjusted based on the represented text).
Pros:
* Allows for embedding any character at all (representable in the
source file encoding), including the closing quote.
* Reasonably straightforward
Cons:
* Syntax is slightly complicated
## D syntax:
D supports three different forms of raw strings. The first two are
similar, being rraw text and `raw text`. Besides the choice of
delimiters, they behave identically, in that the raw text may contain
anything except for the appropriate quote character. The third syntax is a
slightly more complicated form of C++11's syntax, and is called a delimited
string. It takes two forms.
The first looks like q(raw text) where the ( may
Re: [rust-dev] RFC: Syntax for raw string literals
On 2013-09-19, at 23:45 , Kevin Ballard wrote: Yes I know, but in my (rather limited) experience with Python, triple-quoted strings are typically used for docstrings. It was just an example anyway. They're also commonly used for multiline strings as single-quoted strings don't require it. * The quote-escaping oddness is less of an issue in Python as you can also use single-quotes for delimiting, or use triple-quoted strings (if you need to embed both single and double quotes in rawstrings). If I need to embed both ''' and in a string, I'm out of luck. The chance of that is as remote as can be. I've never seen or heard of it happen. And mind, the issue must happen *in a rawstring* which is even more unlikely. Also, windows file paths windows paths can also use forward slashes so that's not a very interesting justification. Not always. UNC paths must start with \\ (in my testing, //foo/bar/baz is not interpreted as a UNC path by the Windows File Explorer, but \\foo/bar/baz is). True. Do you expect writing literal UNC paths in Rust to be a common occurrence? There's also paths that start with the verbatim prefix \\?\, which disables interpretation of forward-slashes (among other things). That's not really relevant to a rawstrings proposal, why would a developer embed such a path literally? As I am actively engaged in writing a replacement for the path module, and am currently expanding the test suite for Windows paths, raw strings would be extremely useful to me. I'd have thought it a better idea to use path builders (maybe macros) and avoid embedding literal path separators in order to avoid portability issues. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] RFC: Syntax for raw string literals
On Sep 20, 2013, at 1:13 AM, Masklinn maskl...@masklinn.net wrote: Also, windows file paths windows paths can also use forward slashes so that's not a very interesting justification. Not always. UNC paths must start with \\ (in my testing, //foo/bar/baz is not interpreted as a UNC path by the Windows File Explorer, but \\foo/bar/baz is). True. Do you expect writing literal UNC paths in Rust to be a common occurrence? Maybe not for most people, but I've been writing them a _lot_ lately (I'm rewriting the path module). Regular expressions is really the most common application here. There's also paths that start with the verbatim prefix \\?\, which disables interpretation of forward-slashes (among other things). That's not really relevant to a rawstrings proposal, why would a developer embed such a path literally? Perhaps they want to hard-code a path that refers to something that requires the \\?\ prefix (such as a path that contains / as part of a path component, or is longer than 255 characters). But just in general, \ is the canonical Windows path separator. I don't think use / is particularly great advice. What if this string is intended for displaying? As I am actively engaged in writing a replacement for the path module, and am currently expanding the test suite for Windows paths, raw strings would be extremely useful to me. I'd have thought it a better idea to use path builders (maybe macros) and avoid embedding literal path separators in order to avoid portability issues. People still use literal path separators in strings all the time in languages that support path-building methods. -Kevin ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] RFC: Syntax for raw string literals
If I need to embed both ''' and in a string, I'm out of luck. The chance of that is as remote as can be. I've never seen or heard of it happen. And mind, the issue must happen *in a rawstring* which is even more unlikely. You should note that, as soon as you include something in the language itself, that creates meaningful strings (programs in the language) that include the token, which are not likely, at some point, to need to be written as a multiline string in the language itself. (As a related example, as someone writing JavaScript-analyzing code in JavaScript, I've had several bugs caused by the fact that the nonsense, no-one-is-ever-going-to-use-this word __proto__ has a very hard to suppress special meaning, and you *are* going to use it when analyzing the elements in another JavaScript program.) ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] RFC: Syntax for raw string literals
On 2013-09-20, at 10:26 , Marijn Haverbeke wrote: If I need to embed both ''' and in a string, I'm out of luck. The chance of that is as remote as can be. I've never seen or heard of it happen. And mind, the issue must happen *in a rawstring* which is even more unlikely. You should note that, as soon as you include something in the language itself, that creates meaningful strings (programs in the language) that include the token, which are not likely, at some point, to need to be written as a multiline string in the language itself. It's already noted, my objections are very much that this is highly unlikely to be an issue as it only comes to a head when needing *triple-quoted rawstrings* to include *their own* delimiters (meaning a triple-quoted rawstring which needs to include both triple-quoted delimiters at the same time). Even unlikelier given python will concatenate string literals during parsing. On 2013-09-20, at 10:25 , Kevin Ballard wrote: Regular expressions is really the most common application here. Right, which was just about all I was saying in the original message. People still use literal path separators in strings all the time in languages that support path-building methods. Something I don't believe should be encouraged. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] RFC: Syntax for raw string literals
Out of all the mentioned syntaxes, Python's seems simple and easy (and the corner cases appear to be fairly unlikely for the actual use cases for raw strings), Ruby's seems very powerful and if a couple of restrictions are added could probably fit well, and Lua's seem very well designed by allowing delimiters of arbitrary length. As a user of higher-level languages, all of these seem appealing to me. I don't really feel that rawstring should be complicated to use, and I don't really think the limitations are bad so long as they areexplicitly documented (which is how it should be). On Fri, Sep 20, 2013 at 5:38 AM, Masklinn maskl...@masklinn.net wrote: On 2013-09-20, at 10:26 , Marijn Haverbeke wrote: If I need to embed both ''' and in a string, I'm out of luck. The chance of that is as remote as can be. I've never seen or heard of it happen. And mind, the issue must happen *in a rawstring* which is even more unlikely. You should note that, as soon as you include something in the language itself, that creates meaningful strings (programs in the language) that include the token, which are not likely, at some point, to need to be written as a multiline string in the language itself. It's already noted, my objections are very much that this is highly unlikely to be an issue as it only comes to a head when needing *triple-quoted rawstrings* to include *their own* delimiters (meaning a triple-quoted rawstring which needs to include both triple-quoted delimiters at the same time). Even unlikelier given python will concatenate string literals during parsing. On 2013-09-20, at 10:25 , Kevin Ballard wrote: Regular expressions is really the most common application here. Right, which was just about all I was saying in the original message. People still use literal path separators in strings all the time in languages that support path-building methods. Something I don't believe should be encouraged. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev -- Andrés Osinski http://www.andresosinski.com.ar/ ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] RFC: Syntax for raw string literals
Python's has really stupid handling of backslashes, and I really don't like how it cannot represent all valid strings. I'd really prefer not to make that same mistake. Ruby's syntax cannot be used because % lexes as an operator. Of the 3, Lua's is probably the best, although it's a bit esoteric (with using [[ and nary a quote in sight). It seems roughly equivalent to C++11's syntax though, both in ease of use and flexibility. -Kevin On Sep 20, 2013, at 1:41 AM, Andres Osinski andres.osin...@gmail.com wrote: Out of all the mentioned syntaxes, Python's seems simple and easy (and the corner cases appear to be fairly unlikely for the actual use cases for raw strings), Ruby's seems very powerful and if a couple of restrictions are added could probably fit well, and Lua's seem very well designed by allowing delimiters of arbitrary length. As a user of higher-level languages, all of these seem appealing to me. I don't really feel that rawstring should be complicated to use, and I don't really think the limitations are bad so long as they areexplicitly documented (which is how it should be). On Fri, Sep 20, 2013 at 5:38 AM, Masklinn maskl...@masklinn.net wrote: On 2013-09-20, at 10:26 , Marijn Haverbeke wrote: If I need to embed both ''' and in a string, I'm out of luck. The chance of that is as remote as can be. I've never seen or heard of it happen. And mind, the issue must happen *in a rawstring* which is even more unlikely. You should note that, as soon as you include something in the language itself, that creates meaningful strings (programs in the language) that include the token, which are not likely, at some point, to need to be written as a multiline string in the language itself. It's already noted, my objections are very much that this is highly unlikely to be an issue as it only comes to a head when needing *triple-quoted rawstrings* to include *their own* delimiters (meaning a triple-quoted rawstring which needs to include both triple-quoted delimiters at the same time). Even unlikelier given python will concatenate string literals during parsing. On 2013-09-20, at 10:25 , Kevin Ballard wrote: Regular expressions is really the most common application here. Right, which was just about all I was saying in the original message. People still use literal path separators in strings all the time in languages that support path-building methods. Something I don't believe should be encouraged. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev -- Andrés Osinski http://www.andresosinski.com.ar/ ___ 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] Proposed API for character encodings
I really like the API you are proposing. In particular, the error handling is
close to what I was expecting from such an API.
I have some remarks, though.
Is there a reason for encoders and decoders to not be reusable ? I think it
would be reasonable to specify that they get back to their initial state once
the 'flush' method is called, or when a 'DecodeError' is returned.
Is a condition raised when the order of method calls is not respected ? E.g.
if one calls 'flush' multiple times, of calls 'feed' and then 'decode' ?
It is not clear what is given as a parameter to the 'decoding_error'
condition. I guess it's the exact subset of byte sequence that cannot be
decoded, possibly spanning multiple 'feed' calls. Is that correct ? Is it
sufficient for variable-length encodings ?
I am doubtful that the encoder is just a decoder with [u8] and str swapped. A
decoder must deal with a possibly invalid sequence of bytes, while an encoder
deals with str, which is guaranteed to be a valid utf8 sequence. An encoder
must handle unmappable characters, whereas a decoder doesn't (actually, it
depends whether we consider unicode to be universal or not...).
I think it would be a good idea to make a difference between an invalid
sequence and an unmappable character. I think there should be both an
'invalid_sequence' and an 'unmappable_char' condition.
Also, the 'fatal' handler is a bit scary, based on the name I'd expect it to
result in a 'fail!'.
I propose this set of conditions and handlers :
// Decoder conditions
condition! {
/// The byte sequence is not a valid input
pub invalid_sequence : ~[u8] - Option~str;
/// The byte sequence cannot be represented in Unicode (rarely used)
pub unmappable_bytes : ~[u8] - Option~str;
}
// Encoder condition
condition! {
/// The Unicode string cannot be represented in the target encoding
/// (essential for single byte encodings)
pub unmappable_str : ~str - Option~[u8];
}
/// Functions to be used with invalid_sequence::cond.trap
/// or unmappable_bytes::cond.trap
mod decoding_error_handlers {
fn decoder_error(_: ~[u8]) - Option~str { None }
fn replacement(_: ~[u8]) - Option~str { Some(~\uFFFD) }
fn ascii_substitute(_: ~[u8]) - Option~str { Some(~\u001A) }
fn ignore(_: ~[u8]) - Option~str { Some(~) }
}
/// Functions to be used with unmappable_str::cond.trap
mod encoding_error_handlers {
fn decoder_error(_: ~str) - Option~[u8] { None }
fn ascii_substitute(_: ~str) - Option~[u8] { Some(~[0x1A]) }
fn ignore(_: ~str) - Option~[u8] { Some(~[]) }
}
Not sure about this substitute/replacement duality. Maybe we can have only one
function name 'default', that would be FFFD for unicode and 1A for ascii.
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Proposed API for character encodings
Le 20/09/2013 10:18, Olivier Renaud a écrit :
I really like the API you are proposing. In particular, the error handling is
close to what I was expecting from such an API.
I have some remarks, though.
Is there a reason for encoders and decoders to not be reusable ? I think it
would be reasonable to specify that they get back to their initial state once
the 'flush' method is called, or when a 'DecodeError' is returned.
I don’t have a strong opinion on that. There could be a reset or
similar method, but I don’t see how this is better than just throwing
the decoder away and making a new one.
With static dispatch and the encoding known at compile-time, you can
probably have decoders on the stack so making a new one is cheap.
If the encoding is determined at run-time and you use trait objects
(dynamic dispatch) for decoders, the next input might have a different
encoding so reusing decoders might not be useful either.
Is a condition raised when the order of method calls is not respected ? E.g.
if one calls 'flush' multiple times, of calls 'feed' and then 'decode' ?
Decoder::decode is a static method / associated function. It’s
independent from everything else.
Other than that, I don’t know. rust-encoding doesn’t do that. AFAIU it
leaves this behavior undefined, which I think is fine. Do you think it
should be explicitly checked for?
It is not clear what is given as a parameter to the 'decoding_error'
condition. I guess it's the exact subset of byte sequence that cannot be
decoded, possibly spanning multiple 'feed' calls. Is that correct ? Is it
sufficient for variable-length encodings ?
Correct, and I think yes. It is called once every time the spec says to
run the error algorithm:
http://encoding.spec.whatwg.org/#error
I am doubtful that the encoder is just a decoder with [u8] and str swapped. A
decoder must deal with a possibly invalid sequence of bytes, while an encoder
deals with str, which is guaranteed to be a valid utf8 sequence. An encoder
must handle unmappable characters, whereas a decoder doesn't
You’re right, I cut some corners. In particular, the encoding_error
condition can take a single (unsupported) 'char'. Other than that, the
*API* is (very close to?) the same with [u8] and str swapped.
(actually, it
depends whether we consider unicode to be universal or not...).
I suggest we consider it is. (For the purpose of the WHATWG spec it is.)
If Unicode is missing things, the right solution is to add things to
Unicode.
I think it would be a good idea to make a difference between an invalid
sequence and an unmappable character. I think there should be both an
'invalid_sequence' and an 'unmappable_char' condition.
That’s the distinction between decoding_error and encoding_error, which
already exists.
Also, the 'fatal' handler is a bit scary, based on the name I'd expect it to
result in a 'fail!'.
I’m open to other names. Maybe abort? The idea is that you reject the
entirety of this input (including previous successful calls to .feed())
I propose this set of conditions and handlers :
// Decoder conditions
condition! {
/// The byte sequence is not a valid input
pub invalid_sequence : ~[u8] - Option~str;
/// The byte sequence cannot be represented in Unicode (rarely used)
pub unmappable_bytes : ~[u8] - Option~str;
}
// Encoder condition
condition! {
/// The Unicode string cannot be represented in the target encoding
/// (essential for single byte encodings)
pub unmappable_str : ~str - Option~[u8];
}
I think that unmappable_bytes is not needed, and the other two should
just be decoding_error and encoding_error. (See above.)
/// Functions to be used with invalid_sequence::cond.trap
/// or unmappable_bytes::cond.trap
mod decoding_error_handlers {
fn decoder_error(_: ~[u8]) - Option~str { None }
fn replacement(_: ~[u8]) - Option~str { Some(~\uFFFD) }
fn ascii_substitute(_: ~[u8]) - Option~str { Some(~\u001A) }
fn ignore(_: ~[u8]) - Option~str { Some(~) }
}
/// Functions to be used with unmappable_str::cond.trap
mod encoding_error_handlers {
fn decoder_error(_: ~str) - Option~[u8] { None }
fn ascii_substitute(_: ~str) - Option~[u8] { Some(~[0x1A]) }
fn ignore(_: ~str) - Option~[u8] { Some(~[]) }
}
Not sure about this substitute/replacement duality. Maybe we can have only one
function name 'default', that would be FFFD for unicode and 1A for ascii.
I think we should only provide two handlers for each of decoding and
encoding: fail/abort/error, and replace. The latter is U+FFFD
(replacement character) for decoding and 0x3F (ASCII question mark) for
encoding as in the WHATWG spec, per web-compatibility constraints.
In particular, ignore is terrible and should not be encouraged.
(Depending on what you’re doing with it, it could lead to security
issues.) If you do want ignore or ASCII substitute, writing a custom
condition handler is easy
[rust-dev] Struct members in trait definitions
Hi all, I have a question which I'm sure must have already been discussed and dealt with, but I wanted to understand the design rationale: A lot of trait-level functionality would be enhanced if a trait could specify members to be included in the struct which implements the trait. This can be solved in practice by wrapping member access in accessor methods, but I fail to see why that would be preferable. The reason I'm asking is because I'm trying to design data structures which contain a couple of arrays, and I wanted to define the trait by not only a set of supported operations but by the existence of both arrays so that a default method could deal with any struct which implements the trait, instead of having to define for every struct an accessor method for each structure and then have to call the accessors in the trait to do anything. Thanks -- Andrés Osinski http://www.andresosinski.com.ar/ ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Struct members in trait definitions
Andres (cc'ing rust-dev)-
An initial question, since I'm not clear on one thing:
What is your goal in proposing this change?
That is, is your primary concern that you dislike writing either method
invocations or method definitions? Or are you concerned about the
ability of the compiler to optimize the generated code if one uses
methods instead of struct fields?
Justifications for why traits should be expressed in terms of associated
methods, not associated fields (and thus why Rust does things this way):
1.) Method definitions are strictly more general than fields, in terms
of allowing other implementations to dynamically compute the value, read
it from a database, from an input stream, etc). I assume you already
are aware of this, and just want to know why we don't provide special
handling for Trait designers willing to rule out such generality up-front.
2.) Associated struct-fields would either disallow mixing traits whose
names collide, or would require extending the `impl` item syntax with a
struct-field renaming feature.
Elaboration of point 2:
Traits are designed to be mixed together; the language should discourage
patterns that make mixing traits on a single type difficult.
The fields of a struct are written down with the `struct` definition.
The associated methods for an implementation are written down with the
`impl` item.
If two traits require the same kind of associated state, right now you
would give them identical method names, and the one struct could
implement both traits (i.e. mixing them) with no ambiguity.
If traits were to define struct names, to get the same amount of
generality we would need to provide some way to map the field name of
the struct to the name expected by the trait within `impl` items. But
why do that? A method definition is a perfectly reasonable way to
express this.
Concrete illustration of point 2 above: How would you express the below
in your proposal, assuming that *both* T1 and T2 are revised to require
`state` to be a member field rather than a method?
```rust
trait T1 { fn state(self) - int; }
trait T2 { fn state(self) - int; }
struct one_int { state: int }
struct two_ints { state: int, state2: int }
impl T1 for one_int { fn state(self) - int { self.state } }
impl T2 for one_int { fn state(self) - int { self.state } }
impl T1 for two_ints { fn state(self) - int { self.state } }
impl T2 for two_ints { fn state(self) - int { self.state2 } }
```
Again, to be clear: I'm not saying its impossible to express the example
above via hypothetical Traits with fields. But I think it would add
unnecessary complexity (e.g. extensions to `impl` item syntax). So
that's why I wanted to know what the driving motivation here is.
If the motivation is concern over syntactic overhead: method invocations
vs field deference seems trivial. The method definitions are more
annoying boilerplate code, but I imagine that one could write an easy
macro_rules! for the common case where the Trait method name is the same
as the struct field name.
If the motivation is concern over the quality of the generated code: I
assume that LLVM does a good job inlining these things. (If I'm wrong
about that, I'd like to know.)
Cheers,
-Felix
On 20/09/2013 13:02, Andres Osinski wrote:
Hi all, I have a question which I'm sure must have already been
discussed and dealt with, but I wanted to understand the design
rationale:
A lot of trait-level functionality would be enhanced if a trait could
specify members to be included in the struct which implements the
trait. This can be solved in practice by wrapping member access in
accessor methods, but I fail to see why that would be preferable.
The reason I'm asking is because I'm trying to design data structures
which contain a couple of arrays, and I wanted to define the trait by
not only a set of supported operations but by the existence of both
arrays so that a default method could deal with any struct which
implements the trait, instead of having to define for every struct an
accessor method for each structure and then have to call the accessors
in the trait to do anything.
Thanks
--
Andrés Osinski
http://www.andresosinski.com.ar/
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
--
irc: pnkfelix on irc.mozilla.org
email: {fklock, pnkfelix}@mozilla.com
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] rusti - the - repl renovation
Would running test-to-destruction cases that are expected to fail count as running in a sandbox? Currently I spawn them to a separate task and catch its failure, which is probably better practice - but it would be nice if I were able to access the message given to fail and compare it with the expected one. If the unsafe catch would allow for that, it may be worthwhile to switch to it... On Fri, Sep 20, 2013 at 4:54 PM, Patrick Walton pwal...@mozilla.com wrote: On 9/19/13 11:40 PM, Jason E. Aten wrote: Agreed. I'm convinced that fail! should result in an almost-magical lets pretend that never happened jump back in time. I'm personally fine with adding an unsafe catch function or form that will stop unwinding if you absolutely have to use it, incidentally. In general fail! is not supposed to be used as an exception mechanism, because monadic use of Result does that better. But if you're doing special things like trying to sandbox Rust code, it seems relatively harmless to me. We already have all the low-level infrastructure (DWARF unwinding based C++ exceptions) necessary to make it work... Patrick __**_ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/**listinfo/rust-devhttps://mail.mozilla.org/listinfo/rust-dev ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Proposed API for character encodings
Le 20/09/2013 13:40, Henri Sivonen a écrit : On Tue, Sep 10, 2013 at 6:47 PM, Simon Sapinsimon.sa...@exyr.org wrote: /// Call this to indicate the end of the input. /// The Decoder instance should be discarded afterwards. /// Some encodings may append some final output at this point. /// May raise the decoding_error condition. fn flush(output: mut ~str) - OptionDecodeError; Please call this finish instead of calling it flush. In other APIs, for example JDK APIs, flush really just means flushing the current buffers instead of ending the stream, so calling the method that does end-of-stream processing flush would be confusing. flush is the name that rust-encoding uses, but I argee that finish is better for what it does. -- Simon Sapin ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Proposed API for character encodings
Le 10/09/2013 16:47, Simon Sapin a écrit : TR;DR: the actual proposal is at the end of this email. I moved this to the wiki, to better deal with updates: https://github.com/mozilla/rust/wiki/Proposal-for-character-encoding-API -- Simon Sapin ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Struct members in trait definitions
Hi Andres, I'm thinking about your question from a structural typing point of view, so let me see if an analogy from Scala (which has its own take on traits) helps. Scala is more of an OO language than Rust is, and Scala traits can extend classes (abstract or not), which is how it's possible for a trait to incorporate members (what Niko just described as struct inheritance) -- but the trait itself cannot name a new member, only methods, as with Rust. So in that regard, traits are also an awful lot like Go's interfaces, in that they describe the interface that a value must be able to satisfy at compile time. All three languages are structurally typed, but Go has the fewest bells and whistles in the type system, Scala the most, and Rust somewhere in the middle (thanks to generics and type bounds). There are efficiency reasons for that; it's relevant that Scala is a JVM language. This isn't a particularly concrete answer, but I hope it helps. Cheers, --mlp On Fri, Sep 20, 2013 at 2:18 PM, andres.osin...@gmail.com wrote: It would be audacious to propose this as a change; I'm merely trying to understand the philosophy behind certain design decisions, My personal motivation comes from an interest in seeing how expressive Rust can be as a language to model business objects; I think the intersection between high-level logic and type classes with low-level access, extreme efficiency, and deterministic memory access, is a very interesting domain which, thus far, no language manages to handle well, and Rust shows immense promise in that. Something I really dislike and consider a huge antipattern is the question of logical indirection and boilerplate; anything that hinders the understanding of the code through unnecessary invocations or synax is a big no-no for me (a great example being Java's requirement for type declarations everywhere and the disgusting use of accessor methods everywhere even when they make no sense). Rust is a very lean language and seems to be extremely concise for what it's capable of. And the thing is, if a trait has a data dependency rather than a behavior (method existence) dependency, then why are we working around the data through methods when it just happens to be that what we really want is to fetch the data in a struct with no logical intermediaries, regardless of whether the compiler turns that into a straight memory access? The first use case that came to mind was when I was attempting to create a business object library that could be used a starting point for forms, data persistency, serialization, validation, and the like. I wanted to define, for a model, a series of validators that would depend on the struct definition; something easy to do with Enums and macros. However when it came to validation, i wanted to store certain conditions in a data structure, such that all models have a validate() method that would query the data needed to perform validation. The current trait implementation would require me to needlessly define a getter/setter for the validation data structure in order to have a trait. In reality, i just want to define the trait as a the existence of a certain struct member data definition (a corresponding validators data structure), with no limits in how I may want to access of modify such data. The beauty of this would be that i would only need to define said member and trait in order to get all the features i could ever want out of a validation library, and default methods would take care of the rest, whereas as it's now, i would have to define the accessors, or use a macro so that any model definition would come with an automatic accessor definition. This is not ideal if I have a system with several hundred models, which may be trivial in their definition but require a useless method definition for each of them. And while I think it's great that a macro is capable of that, it seems to me that as a language feature it would be substantially more useful. Like I said before, I'm just toying around; I have little frame of reference as to whether there are hidden downsides to such a feature. I just wanted to know what the community thinks about this. Thanks Enviado desde mi BlackBerry de Movistar (http://www.movistar.com.ar) -- *From: * Felix S. Klock II pnkfe...@mozilla.com *Date: *Fri, 20 Sep 2013 13:41:02 +0200 *To: *Andres Osinskiandres.osin...@gmail.com *Cc: *rust-dev@mozilla.orgrust-dev@mozilla.org *Subject: *Re: [rust-dev] Struct members in trait definitions Andres (cc'ing rust-dev)- An initial question, since I'm not clear on one thing: What is your goal in proposing this change? That is, is your primary concern that you dislike writing either method invocations or method definitions? Or are you concerned about the ability of the compiler to optimize the generated code if one uses methods instead of struct fields? Justifications for why traits
Re: [rust-dev] Struct members in trait definitions
Adding struct members in traits would be… weird. Where would those members be stored when passing things around by value? This sounds like something for properties. But as Nikko says it is not a planned feature at the moment – there is enough on the table for 1.0 as it is. I'm sure they would be a controversial proposal too (although I think they would be nice). ~Brendan On 20/09/2013, at 9:02 PM, Andres Osinski andres.osin...@gmail.com wrote: Hi all, I have a question which I'm sure must have already been discussed and dealt with, but I wanted to understand the design rationale: A lot of trait-level functionality would be enhanced if a trait could specify members to be included in the struct which implements the trait. This can be solved in practice by wrapping member access in accessor methods, but I fail to see why that would be preferable. The reason I'm asking is because I'm trying to design data structures which contain a couple of arrays, and I wanted to define the trait by not only a set of supported operations but by the existence of both arrays so that a default method could deal with any struct which implements the trait, instead of having to define for every struct an accessor method for each structure and then have to call the accessors in the trait to do anything. Thanks -- Andrés Osinski http://www.andresosinski.com.ar/ ___ 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] rusti - the - repl renovation
On Sep 20, 2013, at 9:48 AM, Alex Crichton a...@crichton.co wrote: It this not possible to do with tasks? I don't see how we can catch and rollback any memory modification that a call into already compiled code might make, not without reimplementing in software the memory protection that the MMU hardware already gives us for free. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Struct members in trait definitions
How about allowing anonymous fields, like go does? It seems to provide most of the benefits at very little language complexity cost. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Proposed API for character encodings
Le vendredi 20 septembre 2013 11:47:04 Simon Sapin a écrit : Le 20/09/2013 10:18, Olivier Renaud a écrit : I really like the API you are proposing. In particular, the error handling is close to what I was expecting from such an API. I have some remarks, though. Is there a reason for encoders and decoders to not be reusable ? I think it would be reasonable to specify that they get back to their initial state once the 'flush' method is called, or when a 'DecodeError' is returned. I don’t have a strong opinion on that. There could be a reset or similar method, but I don’t see how this is better than just throwing the decoder away and making a new one. I don't see the need for a 'reset' method. A decoder could return to its initial state after a call to 'finish'. With static dispatch and the encoding known at compile-time, you can probably have decoders on the stack so making a new one is cheap. If the encoding is determined at run-time and you use trait objects (dynamic dispatch) for decoders, the next input might have a different encoding so reusing decoders might not be useful either. My typical usage of a charset decoder is to read many files on disk, all of them using the same charset. Is a condition raised when the order of method calls is not respected ? E.g. if one calls 'flush' multiple times, of calls 'feed' and then 'decode' ? Decoder::decode is a static method / associated function. It’s independent from everything else. Oh yes of course, my bad. Other than that, I don’t know. rust-encoding doesn’t do that. AFAIU it leaves this behavior undefined, which I think is fine. Do you think it should be explicitly checked for? Well, in my opinion it is not a good idea for an API to have undefined behavior. Being explicit about what is disallowed also helps the user to understand how the API is supposed to be used. Also, I think it's preferable to fail fast, when the state of an object becomes invalid. There are a handful of reasonable behavior, for the decoder : * If reusing a decoder is legal, then calling 'feed' after 'finish' is legal (we start decoding a new stream), no need to introduce a special case. A second call to 'finish' can be a noop (we decode an empty stream) * If reusing a decoder is illegal: -- Calling 'feed' after 'finish' should be an error. The API must report that it is being misused by the programmer. I don't know what is the recommended way to do that in Rust. I think it's ok to fail!, or to have an assert. In Java, I'd throw an (unchecked) IllegalStateException, which serves exactly this purpose. -- Calling 'finish' a second time can also be a noop, but it would be better to be consistent with the 'feed' after 'finish' behavior and to fail. Another totally different solution would be to use phantom types, to indicate the state of the decoder, but that would be overkill. Or typestates :) Simpler is better, so I think having a reusable decoder with no special invalid state is the least problematic solution. It is not clear what is given as a parameter to the 'decoding_error' condition. I guess it's the exact subset of byte sequence that cannot be decoded, possibly spanning multiple 'feed' calls. Is that correct ? Is it sufficient for variable-length encodings ? Correct, and I think yes. It is called once every time the spec says to run the error algorithm: http://encoding.spec.whatwg.org/#error I am doubtful that the encoder is just a decoder with [u8] and str swapped. A decoder must deal with a possibly invalid sequence of bytes, while an encoder deals with str, which is guaranteed to be a valid utf8 sequence. An encoder must handle unmappable characters, whereas a decoder doesn't You’re right, I cut some corners. In particular, the encoding_error condition can take a single (unsupported) 'char'. Other than that, the *API* is (very close to?) the same with [u8] and str swapped. (actually, it depends whether we consider unicode to be universal or not...). I suggest we consider it is. (For the purpose of the WHATWG spec it is.) If Unicode is missing things, the right solution is to add things to Unicode. It simplifies many things, indeed. [...] ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] RFC: Syntax for raw string literals
Does it HAVE to be a single typed char seen on the English 101 keyboard ? History Lesson: The industry in the very early, early days of printing, storing, and processing characters, both English and non-English, came up with a solution around the use of Control Characters. ASCI Char 1 is known as Start Of Header, or abbreviated SOH. ASCII Char 2 is known as Start of Text, or abbreviated STX. ASCII Char 3 is known as End of Text, or abbreviated ETX. It got me thinking of how various industries to this day still use Start of Text and End of Text... what we are discussing as enclosing a String verbatim. Many data operations that I perform with conversion of string fields are actually done by first wrapping with Control Chars [1] to enclose the String LITERALLY. Apple's Enterprise Partner Feed is an example that uses such basic Control Chars to separate fields and interestingly uses multibyte EOL Control Chars to retain even unicode contents (Foreign Language strings, that use quotes of a different nature at times [2] and that sometimes appear in its fields and that need to be retained inside a database field as well.) I am wondering if doing something similar to that the industry does with using Control Chars to represent a STX or ETX would not be even wiser to subplant String Literal ? i.e. do not reinvent the fast spinning wheel that also has built-in never go flat technology. :) [1] http://www.theasciicode.com.ar/ascii-control-characters/start-of-text-ascii-code-2.html [2] http://en.wikipedia.org/wiki/Non-English_usage_of_quotation_marks Thoughts ? -- -Thad Thad on Freebase.com http://www.freebase.com/view/en/thad_guidry Thad on LinkedIn http://www.linkedin.com/in/thadguidry/ ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Proposed API for character encodings
Le vendredi 20 septembre 2013 11:52:14 Simon Sapin a écrit :
Le 13/09/2013 23:03, Simon Sapin a écrit :
/// Takes the invalid byte sequence.
/// Return a replacement string, or None to abort with a DecodeError.
condition! {
pub decoding_error : ~[u8] - Option~str;
}
/// Functions to be used with decoding_error::cond.trap
mod decoding_error_handlers {
fn fatal(_: ~[u8]) - Option~str { None }
fn replacement(_: ~[u8]) - Option~str { Some(~\uFFFD) }
}
Allocating ~\uFFFD repeatedly is, let’s say, unfortunate. This could
be avoided by having the return value be:
enum DecodingErrorResult {
AbortDecoding,
ReplacementString(~str),
ReplacementChar(char),
}
Similarly, for encoding:
enum EncodingErrorResult {
AbortDecoding,
ReplacamentByteSequence(~[u8]),
ReplacementByte(u8),
}
That's a nice addition, it's even better this way !
I have one more question regarding the error handling : in DecodeError, what
does 'input_byte_offset' mean ? Is it relative to the 'invalid_byte_sequence'
or to the beginning of the decoded stream ?
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Struct members in trait definitions
When I mention struct members I'm saying that in order for a struct to satisfy trait properties (explicitly conforming to the interface, not implicitly like Go), the struct must have implemented the functions for the trait and also contain the required members. Looking at a few more examples, I think what I'm looking for here is a mixin for composition ( inheritance would not be too relevant here) a la Scala's, or a purpose-made Python asbtract class that defines class members and methods pertaining only to those members. On Fri, Sep 20, 2013 at 2:55 PM, Oren Ben-Kiki o...@ben-kiki.org wrote: How about allowing anonymous fields, like go does? It seems to provide most of the benefits at very little language complexity cost. -- Andrés Osinski http://www.andresosinski.com.ar/ ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Struct members in trait definitions
Andres Osinski andres.osin...@gmail.com wrote: Hi all, I have a question which I'm sure must have already been discussed and dealt with, but I wanted to understand the design rationale: A lot of trait-level functionality would be enhanced if a trait could specify members to be included in the struct which implements the trait. This can be solved in practice by wrapping member access in accessor methods, but I fail to see why that would be preferable. IMO this would completely defeat the advantage of traits over inheritance based interfaces. The beauty of traits is, that the trait and the type are separated, only connected by the implementation: - You can add an implementation for your custom trait to any existing type. - You can add an implementation for any existing trait to your custom type. Now if you add a fields specification to the trait, the former isn't true anymore. The type has now a dependency on the trait since it must at least contain a field of a given type, if not even with a given name. If you the concrete type is under your control, this is obviously not a problem, as it is the case with inheritance based interfaces. But you cannot simply assume that for every use case. Tobi ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] RFC: Syntax for raw string literals
As usual, I'm highly resistant to use of the backtick because Markdown uses
it pervasively. Not only would this make it very annoying to embed Markdown
in strings, it can make it impossible to embed inline Rust code in Markdown
editors. Let's leave the backtick as a metasyntactic symbol.
On Fri, Sep 20, 2013 at 3:45 PM, Kevin Ballard ke...@sb.org wrote:
I considered backtick as well. If that approach is used, I would suggest
that a doubled-up backtick represent a single backtick in the string, i.e.
`error: path ``{}' failed`. This is pretty much equivalent to just using
r as the syntax, although backtick may be a slightly nicer syntax for it.
-Kevin
On Sep 20, 2013, at 9:27 AM, Alex Crichton a...@crichton.co wrote:
Of the 3, Lua's is probably the best, although it's a bit esoteric (with
using [[ and nary a quote in sight).
I think an important thing to keep in mind is that the main reason
behind creating a new form of literal is for things like:
* Escapes in format! strings
* Possible regular expression syntax (this also may be a syntax
extension)
* Type literal windows paths (escaping \ is hard)
* Otherwise long literals which may contain quotes (like html text)
With those in mind, although Lua's syntax is sufficient, is it nice to
use? If the first thing I saw as an introduction to Rust was:
fn main() {
println!([[Hello, {}!]], world);
}
I would be a little confused. Now the [[/]] aren't really necessary in
this case, but I'm personally unsure of how usable [[/]] would be
throughout the language. Raw literals in languages like C++ and Lua I
think aren't intended to be used that often. Instead they should be
used only when necessary, and you frequently don't see them in code.
For rust, the use cases which are the cause of this discussion are
actually fairly common, and I'm not sure that we'd want to see [[/]]
all over the place, although of course that's just my opinion :)
Skimming back, I haven't seen a suggestion of the backtick character
as a delimiter. Go takes this approach, and I don't believe that in Go
you can have a backtick anywhere in a backtick literal, and otherwise
what you see is what you get. It's at least something to consider,
though.
___
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] Proposed API for character encodings
On Tue, Sep 10, 2013 at 6:47 PM, Simon Sapin simon.sa...@exyr.org wrote: /// Call this to indicate the end of the input. /// The Decoder instance should be discarded afterwards. /// Some encodings may append some final output at this point. /// May raise the decoding_error condition. fn flush(output: mut ~str) - OptionDecodeError; Please call this finish instead of calling it flush. In other APIs, for example JDK APIs, flush really just means flushing the current buffers instead of ending the stream, so calling the method that does end-of-stream processing flush would be confusing. -- Henri Sivonen hsivo...@hsivonen.fi http://hsivonen.iki.fi/ ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] rusti - the - repl renovation
Could it be possible for rusti to spawn a task that runs the expression, and then if that results in a fail! it would become a simple child-task failure cleanup, which in this case means printing the appropriate error message? Of course, if there is a lot of state, this might not be feasible, but if the compile was completed in the main task and the child task only handled the actual run, it might work. Depending of course on how compilation is done for rusti. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
[rust-dev] [RFC] Migrating to a composable API in std::option
The current `std::option` API defines 3 versions of most methods, in order to handle by-value, by-reference and by-mutable-reference. As the module grows, it will continue to pick up sets of 3 nearly identical methods rather than one implementation of each. We could replace the current design with a single by-value implementation of the methods, and composable `as_mut`/`as_imm` methods to convert `OptionT` to `OptionT` or `Optionmut T`. This is the same pattern used by iterators, as they keep the element type separate from the algorithms/adaptors. https://github.com/mozilla/rust/issues/9355 https://github.com/mozilla/rust/pull/9359 ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] rusti - the - repl renovation
On Fri, Sep 20, 2013 at 4:24 PM, Alex Crichton a...@crichton.co wrote: Q: Is there a way to *really* just get one thread in the rust runtime? Best case, I'm hoping the two threads observed is just a bug that can be fixed. Right now the runtime will always spawn at least one thread, so without turning off the runtime you'll have at least two threads. That's arguably a bug in the runtime though... Ok. Filed as https://github.com/mozilla/rust/issues/9373 ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] rusti - the - repl renovation
On 09/19/2013 11:24 AM, Jason E. Aten wrote: Minh Do and I are looking into how to improve rusti -the- repl, so that is fast, efficient, and stable. Minh is undertaking this as a final year project in his CS undergraduate program, and I am mentoring that project and plan to work on it my spare time. We had a first conference call this week. I'm very excited about this! I've spoken with Alex Crichton and started a few conversations on IRC #rust to discuss how rusti might ideally work. I'm posting to rust-dev to solicit additional feedback, guidance, and input. Goals (and an important non-goal) for an improved rusti experience: As an application developer in rust, I want to evaluate the effect of a small Rust statement or expression, so that I can quickly learn the impact of that statement and immediately verify or correct its syntax based on instant feedback. As a developer, I want to be able to change one variable or function definition without a full recompile, so that I can quickly and immediately see the result of, and evaluate the impact of, the change. [I'm impatient! I don't want to wait for a full recompile of everything.] Yes. One of the major flaws in the current rusti is that it maintains no state, instead just accumulating a bunch of statements and recompiling the entire history every time the user presses enter. The important example that is present in my mind, from discussions on the #rust channel, is that it appears that tasks/coroutines may be difficult or needlessly complex for a repl (if written in rust itself, which lacks exceptions) to handle. In other words, it may be very arduous (given current encodable/decodable constraints) to implement in a rusti repl that supports task and fail! semantics. While we are open to clever suggestions about how to make that happen if it is indeed possible, this may still be undesirable and out-of-scope for a resource-constrained project. The classic tradeoff of 80% of the benefit for 20% of the effort should be observed. I don't know why tasks and failure are special in the context of rusti. It seems like they should just work as long as the JIT works. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] rusti - the - repl renovation
On 09/19/2013 11:40 PM, Jason E. Aten wrote: On Thu, Sep 19, 2013 at 11:51 AM, Alex Crichton a...@crichton.co mailto:a...@crichton.co wrote: Basically, I'm OK with leaving out tasks/spawned tasks from rusti, but I think that it should be important to be able to fail! and have the repl state intact afterwards. Agreed. I'm convinced that fail! should result in an almost-magical lets pretend that never happened jump back in time. I'm still trying to figure out how to do this efficiently. For code that has alot of state, serializing and deserializing everything will be too slow. Perhaps the best thing is just to fork(2), so we get a new (OS level) process that has copy-on-write (virtual) memory, and if the compilation + run succeeds in the child, then have the child take over. Otherwise the child dies with an fail! + location message, and we return to the parent exactly before the child was spawned. It seems a shame to be relying on process isolation instead of tasks. If I were to just imagine the architecture of a repl that used task isolation for crash recovery it might have one task for accepting input and another as a sandbox that maintains the repl state and executes commands in a loop. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Struct members in trait definitions
AFAIK the go solution walks a thin line here. An anonymous field means one can directly access any subfield, and also that the container has all the included struct traits - as implemented by the included struct. It is also possible to override the implementation. This is different from what was asked which was the opposite - the go way is the struct implies the trait, what was asked was that the trait implies the struct. I think the go approach makes a lot of sense - I found it to need very useful and simple (e.g. ambiguities are not allowed). The go docs have a better description - give it a look... On Sep 20, 2013 11:30 PM, Tobias Müller trop...@bluewin.ch wrote: Andres Osinski andres.osin...@gmail.com wrote: Hi all, I have a question which I'm sure must have already been discussed and dealt with, but I wanted to understand the design rationale: A lot of trait-level functionality would be enhanced if a trait could specify members to be included in the struct which implements the trait. This can be solved in practice by wrapping member access in accessor methods, but I fail to see why that would be preferable. IMO this would completely defeat the advantage of traits over inheritance based interfaces. The beauty of traits is, that the trait and the type are separated, only connected by the implementation: - You can add an implementation for your custom trait to any existing type. - You can add an implementation for any existing trait to your custom type. Now if you add a fields specification to the trait, the former isn't true anymore. The type has now a dependency on the trait since it must at least contain a field of a given type, if not even with a given name. If you the concrete type is under your control, this is obviously not a problem, as it is the case with inheritance based interfaces. But you cannot simply assume that for every use case. Tobi ___ 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] rusti - the - repl renovation
In this talk https://www.youtube.com/watch?v=f9Xfh8pv3Fs cling devs say that they did implement transactions. However the best you could hope for is to restore internal process state. You can't do much about external resources such as file handles, sockets, etc, etc, so I wonder if it's even worth trying. On Fri, Sep 20, 2013 at 10:25 AM, Jason E. Aten j.e.a...@gmail.com wrote: On Sep 20, 2013, at 9:48 AM, Alex Crichton a...@crichton.co wrote: It this not possible to do with tasks? I don't see how we can catch and rollback any memory modification that a call into already compiled code might make, not without reimplementing in software the memory protection that the MMU hardware already gives us for free. ___ 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
