> * The system _must_ not prevent, some day, developers from calling Rust > from JavaScript. > * The system _must_ not prevent, some day, developers from calling > JavaScript from Rust.
I'm not aware of any precedents for calling out of or into Javascript, in any language. What specific constraints does this impose? On Wed, May 23, 2012 at 8:47 AM, David Rajchenbach-Teller < dtel...@mozilla.com> wrote: > Actually, one of the conclusions of our previous discussion is that > Java/C++/ML-style exceptions are probably not what we want for Rust. I > seem to remember that we also concluded that using failures as > exceptions was probably not the right course. > > Hence this new thread :) > > Let me put together what I believe are a few desirable qualities of an > "issue management system". For the moment, let's not wonder whether that > system is a language feature, a library or a coding guideline. > > * The system _must_ not prevent developers from calling C code from Rust. > * The system _must_ not prevent developers from passing a pointer to a > Rust function to C code that will call back to it. > * The system _must_ not prevent, some day, developers from calling Rust > from JavaScript. > * The system _must_ not prevent, some day, developers from calling > JavaScript from Rust. > * Issues _must_ not be restricted to integers (or to one single type). > * The default behavior in case of untreated issue _should_ be to > gracefully kill the task or the application. > * Whenever an untreated issue kills a task/application, it _should_ > produces a report usable by the developer for fixing the issue. > * It _should_ be possible to deactivate that killing behavior. There > _may_ be limitations. > * It _should_ be possible to deactivate that killing behavior > conditionally (i.e. only for some errors). > * The system _should_ eventually have a low runtime cost – in > particular, the case in which no killing happens should be very fast. > > > Do we agree on this base? > > Cheers, > David > > On 5/22/12 4:56 AM, Bennie Kloosteman wrote: > > Are exceptions a good model for systems programming ? > > > > - legacy C programs cant call you without a wrapper which translates > > all possible exceptions > > - unwinding a stack is probably not a good idea in a kernel or when > > you transition into protected/user mode.( I know of very few kernels > > that use exceptions ). > > - Its not just legacy , Winrt uses C++ classes but returns error codes > > tor low level APIs. > > > > However its very nice for user programs . These days these different > > worlds works quite well , c libs which Is mainly used for system > > programming don't use them and C++ apps are more user programs and > > they do , C++ calls C , C rarely calls C++. Obviously if you write a > > kernel or shared library you cannot use exceptions if c programs > > call your code and there is a lot of c out there.... While not really > > an issue for the language ( just dont use exceptions) it means a > > standard lib that throws an exception would be a pain for such work > > and you would need a different standard lib , which is an issue . > > > > BTW could Rust use tasks as a substitute for exception scopes ? Tasks > > have error bubbling , hiding , "stack unwinding" , throw ( fail) and > > should have integrated logging . You could put a sugar syntax around > > it but it would still work when being called by c. Also with tasks > > you can cancel or do timeouts giving asynronous exceptions which are > > really needed ( eg in most systems cancel a long running task is very > > anoying very long pause). and which most trivial exception > > implementations don't do ..Not sure if this is the right way but there > > seems a lot of overlap and it would work with C and systems > > programming,. > > > > Ben > > _______________________________________________ > > Rust-dev mailing list > > Rust-dev@mozilla.org > > https://mail.mozilla.org/listinfo/rust-dev > > > -- > David Rajchenbach-Teller, PhD > Performance Team, Mozilla > > > _______________________________________________ > 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
