On Thu, Apr 25, 2013 at 1:25 AM, Patrick Walton pwal...@mozilla.com wrote:
I have an untested grammar for Rust here,
with the token regexes not yet filled in:
https://gist.github.com/anonymous/5457664
yapps2 reports that this grammar is LL(1).
Note that the refactorings I made resulted in
On 25 April 2013 06:25, Patrick Walton pwal...@mozilla.com wrote:
Note that the refactorings I made resulted in a grammar which isn't that
great for tooling or parsing in many places. In particular the contortions
needed to make `self_ty_and_maybenamed_args` result in an AST that combines
the
There is an issue on Servo #282, which talks about having a uniform string
internment strategy across Rust, Spidermonkey and NetsurfCSS.
Is there any existing string internment library in Rust?
If not, any plans to provide one?
___
Rust-dev mailing list
On 04/24/2013 03:38 PM, Brian Anderson wrote:
## String encoding
I have not yet put much thought about how to deal with string encoding
and decoding. The existing `io` module simply has Reader and Writer
extension traits that add a number of methods like `read_str`, etc. I
think this is the
On 13-04-24 11:39 PM, Lindsey Kuper wrote:
On Thu, Apr 25, 2013 at 1:25 AM, Patrick Walton pwal...@mozilla.com wrote:
I have an untested grammar for Rust here,
with the token regexes not yet filled in:
https://gist.github.com/anonymous/5457664
yapps2 reports that this grammar is LL(1).
Note
On Thu, Apr 25, 2013 at 8:25 AM, Nathan Myers n...@cantrip.org wrote:
On 04/24/2013 03:38 PM, Brian Anderson wrote:
## String encoding
I have not yet put much thought about how to deal with string encoding and
decoding. The existing `io` module simply has Reader and Writer extension
traits
You write:
So what actually happens if `new` encounters an error? To understand
that it's important to know that what `new` returns is not a `File`
but an `OptionFile`. If the file does not open, and the condition
is handled, then `new` will simply return `None`. Because there is an
My opinion (that nobody will follow, but I still give it) is that integers
should not have the / operator at all. This was one of the bad choices of
C (or maybe of a previous language).
Hmm, maybe, though I can imagine plenty of people being surprised at that.
What really gets me though is
On Apr 25, 2013, at 1:39 AM, Abhijeet Gaiha wrote:
There is an issue on Servo #282, which talks about having a uniform string
internment strategy across Rust, Spidermonkey and NetsurfCSS.
Is there any existing string internment library in Rust?
If not, any plans to provide one?
The
What about
match bar {
0 .. (end - 1) = ...
}
Shouldn't it include an expression?
On 25 April 2013 16:30, John Clements cleme...@brinckerhoff.org wrote:
On Apr 24, 2013, at 8:59 PM, Benjamin Striegel wrote:
would it be reasonable to restrict the left- and right-hand-sides to
simply
On Apr 25, 2013, at 7:04 AM, Graydon Hoare wrote:
On 13-04-24 11:39 PM, Lindsey Kuper wrote:
On Thu, Apr 25, 2013 at 1:25 AM, Patrick Walton pwal...@mozilla.com wrote:
I have an untested grammar for Rust here,
with the token regexes not yet filled in:
On Apr 25, 2013, at 8:34 AM, Lucian Branescu wrote:
What about
match bar {
0 .. (end - 1) = ...
}
Shouldn't it include an expression?
Well, that's the question. Currently the grammar (and compiler) allow this. I'd
like to define a grammar here that nails down what's allowed a
On 4/25/13 12:08 AM, Alex Bradbury wrote:
On 25 April 2013 06:25, Patrick Walton pwal...@mozilla.com wrote:
Note that the refactorings I made resulted in a grammar which isn't that
great for tooling or parsing in many places. In particular the contortions
needed to make
On 13-04-25 08:37 AM, John Clements wrote:
FWIW, I'm (mildly) concerned too. In particular, I'm disappointed to discover
that in its present form (and using my present caveman-like invocation style),
ANTLR parses source files so slowly that it's impossible to use directly as a
validation
Hello,
FWIW, I'm (mildly) concerned too. In particular, I'm disappointed to discover
that in its present form (and using my present caveman-like invocation style),
ANTLR parses source files so slowly that it's impossible to use directly as a
validation tool; I would very much like to
On 4/25/13 9:12 AM, Graydon Hoare wrote:
Longer term, I would like whatever grammar we wind up denoting as
canonical / documented / spec'ed to be as (re)target-able as possible.
I've been relatively insistent on LL(1) since it is a nice
intersection-of-inputs, practically guaranteed to parse
On 13-04-25 08:33 AM, Paul Stansifer wrote:
(For example: suppose that some statements and some expressions shared a
common prefix that had to be merged in order to make the grammar LL(1);
instead of having `stmt` and `expr` nonterminals in macros, we'd need to
split them into `most_stmt`
On 25/04/2013 18:12, Graydon Hoare wrote:
I've been relatively insistent on LL(1) since it is a nice
intersection-of-inputs, practically guaranteed to parse under any
framework we retarget it to.
I'm a fan of this choice too, if only because the simplest efficient
parser-generators and/or
On 13-04-25 07:52 AM, Diggory Hardy wrote:
My opinion (that nobody will follow, but I still give it) is that integers
should not have the / operator at all. This was one of the bad choices of
C (or maybe of a previous language).
Hmm, maybe, though I can imagine plenty of people being surprised
On 13-04-25 09:23 AM, Felix S. Klock II wrote:
Are we allowing for the possibility of choosing the semi-middle ground
of: There *exists* an LL(1) grammar for Rust that is derivable from the
non-LL(1)-but-official grammar for Rust. ? Or do we want to go all the
way to ensuring that our own
On Thu, Apr 25, 2013 at 10:04 AM, Graydon Hoare gray...@mozilla.com wrote:
On 13-04-24 11:39 PM, Lindsey Kuper wrote:
This is really cool, but I'm sort of confused about the apparent
multiple ongoing efforts toward having a precise and machine-readable
Rust grammar. Should we consider one of
On 4/25/13 9:23 AM, Felix S. Klock II wrote:
On 25/04/2013 18:12, Graydon Hoare wrote:
I've been relatively insistent on LL(1) since it is a nice
intersection-of-inputs, practically guaranteed to parse under any
framework we retarget it to.
I'm a fan of this choice too, if only because the
I was thinking about the mapping of / and % and indeed maybe the simplest
option is not to map them.
Of course, having an infix syntax would make things easier: 5 % 3 vs 5 rem
3 vs 5.rem(3), in increasing order of typed keys (and visual noise for the
latter ?).
On the other hand, if there is no
On Thu, Apr 25, 2013 at 6:53 PM, Patrick Walton pwal...@mozilla.com wrote:
On 4/25/13 9:23 AM, Felix S. Klock II wrote:
On 25/04/2013 18:12, Graydon Hoare wrote:
I've been relatively insistent on LL(1) since it is a nice
intersection-of-inputs, practically guaranteed to parse under any
On 04/25/2013 05:25 AM, Nathan Myers wrote:
On 04/24/2013 03:38 PM, Brian Anderson wrote:
## String encoding
I have not yet put much thought about how to deal with string
encoding and decoding. The existing `io` module simply has Reader and
Writer extension traits that add a number of
On 25/04/2013 7:18 AM, Gábor Lehel wrote:
I'm an outsider, so apologies if I'm off the right track. But this
sounds wrong to me. Isn't the point of condition handlers to /handle the
condition/? Meaning resolve the problem, so that processing can
continue? Here as far as I can tell, they're only
On 04/25/2013 01:39 AM, Abhijeet Gaiha wrote:
There is an issue on Servo #282, which talks about having a uniform
string internment strategy across Rust, Spidermonkey and NetsurfCSS.
Is there any existing string internment library in Rust?
If not, any plans to provide one?
This is not and
John,
Functional ways would be an approach I would admire and +1 for.
I like the alternative also. In OpenRefine with the GREL expression
language, we did something similar.
Parenthesis rule. Go Lisp. err, wait, Go Go. Oops, wrong business... Go
Rust !
On Thu, Apr 25, 2013 at 1:46 PM, John
On 04/25/2013 11:46 AM, John Clements wrote:
Huh? Looks like my first message didn't go through. Perhaps I'm being
moderated, and I just didn't know it?
Apologies if this appears twice.
Per our meeting today, I'm sending this out to see whether we want to make a
change.
Currently, our
On 04/25/2013 07:12 AM, Daniel Micay wrote:
On Thu, Apr 25, 2013 at 8:25 AM, Nathan Myers n...@cantrip.org wrote:
On 04/24/2013 03:38 PM, Brian Anderson wrote:
## String encoding
I have not yet put much thought about how to deal with string encoding and
decoding. The existing `io` module
FWIW, I both enjoy and have written things along the lines of `14 + if
(true) {3} else {4}` (a.k.a. Rust's answer to C's ternary operator) and
`for foo.each |a| {f(a)}.bar()` (method chaining FTW). I would be sad to be
forced to wrap either of those in parens.
But more pertinently I worry that
On 04/25/2013 12:09 PM, Graydon Hoare wrote:
On 25/04/2013 7:18 AM, Gábor Lehel wrote:
I'm an outsider, so apologies if I'm off the right track. But this
sounds wrong to me. Isn't the point of condition handlers to /handle the
condition/? Meaning resolve the problem, so that processing can
On 4/25/13 3:46 PM, Brian Anderson wrote:
enum FileStream {
RtFileStream(rtio::FileStream), // Not an fd_t, a boxed wrapper
around uv/rt handles
FileSimulation(~Stream),
NullFileStream
}
With this factoring though you are going to be duplicating a lot of
logic for FileStream,
On 04/25/2013 03:46 PM, Brian Anderson wrote:
On 04/25/2013 12:09 PM, Graydon Hoare wrote:
and so forth on other types. Then your file conditions would look like:
condition! {
no_such_file : Path - FileStream;
}
and
condition! {
write_error : (libc::fd_t, libc::errno_t) - FileStream;
On 25/04/2013 4:02 PM, Brian Anderson wrote:
The main TCP implementation, `TcpStream for ~RtTcpStream`, will delegate
to whatever boxed RtTcpStream it is given. Because TcpStream is
responsible for raising conditions, then you can configure the scheduler
to provide you with either uv-based or
On Thu, Apr 25, 2013 at 10:00 PM, Brian Anderson bander...@mozilla.comwrote:
On 04/25/2013 07:18 AM, Gábor Lehel wrote:
Whether to respond to failure by failing the task or by indicating it in
the return value seems like it would be better handled by having separate
functions for each. In
On 04/25/2013 05:08 PM, Gábor Lehel wrote:
On Thu, Apr 25, 2013 at 10:00 PM, Brian Anderson
bander...@mozilla.com mailto:bander...@mozilla.com wrote:
On 04/25/2013 07:18 AM, Gábor Lehel wrote:
Whether to respond to failure by failing the task or by
indicating it in the
On 4/25/13 5:29 PM, Brian Anderson wrote:
It's almost taboo here, but we could consider adding catchable exceptions.
I would be in favor of catchable exceptions, for what it's worth.
Patrick
___
Rust-dev mailing list
Rust-dev@mozilla.org
What if Result implemented the Drop trait and fail()'ed in drop() unless
it's been disarmed by calling some method (get_err?) which indicates that
the error has been observed?
On Thu, Apr 25, 2013 at 5:30 PM, Patrick Walton pwal...@mozilla.com wrote:
On 4/25/13 5:29 PM, Brian Anderson wrote:
On 04/24/2013 09:25 PM, Thad Guidry wrote:
I've been working on getting the right settings, configure options,
etc... for Windows users to setup a Cygwin installation and be able to
use it to build Rust with Clang / LLVM.
We've run into a few problems and I'm asking the community for a bit
On 24/04/2013 8:42 PM, Lindsey Kuper wrote:
On Wed, Apr 24, 2013 at 6:58 PM, Graydon Hoare gray...@mozilla.com wrote:
Agreed. This packaging will be of a sort that _does_ represent a level
of support from the language maintainers, version-to-version. So ...
absent other suggestions I will
Comments inline. I'm glad to see integer division getting this level
of attention.
Erik
On 4/25/2013 11:12 AM, Matthieu Monrocq
wrote:
Of course, having an infix syntax would make things
easier: 5 % 3 vs 5 rem 3 vs
On 24/04/2013 23:38, Brian Anderson wrote:
What I am focused on now is the design of a synchronous API for
sending and receiving streams of bytes, along with an implementation
built on an internal *asynchronous* I/O interface attached to the
scheduler event loop. This includes reading and
43 matches
Mail list logo
