Forwarded to the list.
Thanks for your reply Patrick. BTW love the single threaded Task based approach , I was working on an runtime which I have had to stop ( i was waiting on bitc) which was based on lots of single threaded processes resizable stacks with point to point pipes and was deeply asynchronous ie completely non blocking ( well almost but the iPC was non blocking , blocking would occur when waiting on a resource like disk or memory) . The runtime would control the scheduling of tasks ( eg compression , encryption) and can add , reduce them on a machine wide basis ( and recover from errors) . Since all requests were asynchronous system wide hotspots could get additional resources. Anyway you can see my interest in Rust though your tasks are more fine grained. On Mon, May 21, 2012 at 12:06 AM, Patrick Walton <[email protected]> wrote: > On 05/20/2012 05:23 AM, Bennie Kloosteman wrote: >> >> New member to the list im no genius but am looking for a replacement >> for c for system programming. >> >> 1) Great work on UTF8 strings and USC4 chars ( I do some work with >> chinese chars and USC-2 just doesn't work here) . BTW why null >> terminated strings if you have arrays . Any c interop will require >> conversion to Unicode chars anyway fr a generic lib ( and for most >> IO the perf cost of a copy is pretty irrelevant) > > > At the moment we aren't willing to risk that the cost of a copy for C > interoperability is irrelevant. Might be worth measuring once we have more > of Servo up and running though. (The operative constraint here is basically > that it's fast enough to build a competitive browser with.) I don't think its good design to cover the specific "browser" case or when you have doubts on the impact to then design it for performance before you have measured it to be an issue ..If your writing a browser than 90% of desktop platforms are windows where you need to convert to USC-2 so no impact. The same design decision would say my most common bench mark will be windows so I should have utf16 strings. ( That is not my opinion I like UTF8) . The bigger issue , in most cases you don't know the UTF8 string is ascii , so you need to parse it each time before passing to a c lib and fault if you have a UTF8 string and are calling an ascii API. In most cases the code will look like this right if ( receiveLib.StringType == ASCII) { if ( str.IsAscii() callAscii (str) else fault } if ( receiveLib.StringType == USC2()) { let unistr = str.GetUCS2() callunicode(unistr) } if ( receiveLib.StringType == UTF8()) { callutf8(str) } the above would be quite annoying for multi platform apps in lots of locations since you already have c string and str ( utf8) is it worth burying them under a qstring like construct in the standard lib ? In which case it would be let qstr = qstr.GetString(receiveLib.StringType ); callLib(qstr); > > >> , Speaking of which >> its very useful in utf8 [edit] strings keeping the char count as well as the >> byte >> length mainly so you can go if ( str->length == str->count) to avoid >> any Unicode parsing when you convert to ascii. ( you could use a >> flag or the high bits of a int64 ) - or use a subtype stating its >> ASCII. > > > Interesting idea. Patches welcome! UTF8 strings in a runtime is pretty rare ( C is ascii which supports UTF8 but only for non character based functions) and I think this is needed for interop. eg parsing looking for null or 10 UTF8 escapes can be costly. So you need to know is it ASCII or Unicode to call the appropriate lib call when you work with chars. ( Converting everything to USC-4 when you do char based work is too expensive) . BTW if Rust strings are null terminated why is there a from/to cstr is it because they were vectors and when you have arrays it disappears ? A patch is a bit beyond me yet I just started looking at rust ,and would want to do so some quick and dirt apps first, if I do commit it will be more seriously > > >> 2) Does Rust have anything like bitc HasField ,? >> >> BitC introduced has field constraint and this was very useful , the >> field could be a function or property >> but you can then put on a method that the type HasField x and like >> an interface it hides the implementation , >> you could use any type with met the constraint. . > > > I don't see any reason why we couldn't have HasField, although none of us > have needed it yet. If your talking about encapsulation than you do need something like it. I would say for larger projects and libs - You don't need private variables with hasfield and it avoids confusion with the increasing C++ class model (bitc hit a stumble there) - For larger project and public libs you can export hasfield to hide the internal implementation details. This would be better IMHO ( due to the above) than introducing private variables. - Note has field can work on fields which includes function pointers , length on an array (but without exposing the array data...) > > >> It also meant encapsulated types and the associated "this" pointer / >> vcall issues could possible be avoided since the method only specified >> what filed it used the rest would be private ( for that method) .To >> me this greatly reduced the need of having private fields/members >> which existing c programmers will just follow as they find it hard to >> pick up type classes initially. You may be able to use hashfield for >> a fascade to further effect to hide internals . Since you guys are >> now considering this and objects I would read the below comments very >> carefully. > > > I have ideas as to how we could implement inheritance if we need it (and I > think we might well need it, as I'm running into issues with not being able > to exploit the prefix property for subclassing with Servo). It's not totally > sketched out, so I don't have a concrete proposal. That notwithstanding, > basically it involves unifying enums and classes so that (a) enum variants > are actual types, subtypes of the enclosing enum to be exact; (b) enums are > classes and can have fields and methods; (c) enum variants can access fields > and methods of the enclosing enum; (d) enum variants can contain other > sub-variants. all this is pretty strange to me no idea what servo us , still reading on enums , the enum name is confusing from a C /C# background as it is not an enumeration of values but more a union of types ( or for d) a struct./ value type ) or even a class pulling functions and data together. ? Doesn't this association work better on a separate name ( class , struct , trait ) Be very careful here trying to be all things , that's the path Bitc went down and eventually you have a C#/Java class system with single inheritance and you have generics and then you ask , why do I need Type classes. You will get Typeclass style libs and Java style libs but they wont cooperate elegantly since one lib function calls are on type classes and the other on structs / classes/ In BITC they wanted inheritance to port the compiler from C++ , however most system programming is in C and not C++ . If you can solve the module compile issue ( eg DLL /so 's ) for multiple type classes , than I think avoided classes , encapsulation , virtual calls and inheritance . To me the integration of these type systems ( type classes and C#/Java like objects ) is research and has not been done before and a few case statements or function pointers on structs for some manual polymorphism are not a big issue as the places that needs them with type classes is low ( except for porting ) Ben _______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
