On 18/11/2011 1:12 PM, Jim Peters wrote:
Let's say I have a function parse_file(), it might fail because of I/O
problems or syntax failures, or it may give me back a valid parsed
object. Given that both errors may be detected at any depth in the
internal call tree, in another language exceptions would be a good
approach, keeping the success path apart from the failure path.
With the approach above, this means using a task to contain the
failure, i.e. the model is spawn/wait, rather than try/catch.
To some extent. It depends a lot on the parsing task. I don't mean to be
dismissive. This is a great example. But I want to clarify things:
- In a Serious Parser, errors are managed explicitly because error
reporting to the user is an Important Diagnostic Feature of the
parsing. There's a whole error formatting, diagnostic emitting,
suppressing-and-counting logic built in that goes beyond what an
exception will do. You are always going to be doing manual work
All Through The Parser.
- In a Throwaway Parser, it's not clear to me that treating all
failures as interchangeable, as with tasks ("we can't get
meaningful input") is losing a lot of fidelity over an
exception-based approach. That's what failure is for in rust.
And in both cases, putting the parser in its own task has the wonderful
advantage of also allowing you do to other things while the parser is
waiting on I/O. It's a natural approach.
Sorry to blather on like this, but ... the point of "lightweight tasks"
in this language is that they're lightweight, and get used early and
often. If everyone's reaction to "use a task" is "oh bother, those are
far too heavy", I think we've made a mistake somewhere.
(Tasks are again taking a role like a language construct, not merely
as a scheduling entity.)
They originally were first class, and I am guilty-as-charged with being
willing to treat them as relatively high-ranking concepts in the design.
The design thesis in rust is that proper structured programming *needs*
task-like memory-and-concurrency partitioning to scale robustly, and
it's one of the things we've been falling down on all through the 80s,
90s, 2000s. Languages keep making devices that don't quite get used,
systems wind up with far too few internal boundaries, so are far too
serial and fragile.
-Graydon
_______________________________________________
Rust-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/rust-dev
