On Wed, Mar 10, 2010 at 1:06 AM, Michal Suchanek <[email protected]> wrote: > If you are just running on top of the runtime you can use any string > representation equally well (and as Jonathan says he is not going to > use the native string library so all this magic in it is quite moot).
Umm. In CLI, "interoperability" presumably includes the ability to call other languages. While BitC can provide a sane native string library, we can't really stop people from manipulating strings in other language contexts, and we need to "tame" those interactions. > The other thing is interoperability with libraries which requires > somehow handling the string conversion. Still there are bound to be > libraries and runtimes with different string representations (at the > very least POSIX with UTF-8) so recoding support is required however > you look at the problem, there is no encoding that fits everywhere. So far as I can tell, recoding in the JVM/CLI model is only done at I/O boundaries. All strings in the heap use the same format. > One more possibility is to not choose a single representation but > allow multiple internal representations of strings with an unified > high-level interface. This becomes a nightmare when strings from > multiple systems/runtimes end up in a single application, though. Also > requires quite a bit of additional testing. Yes. I considered declaring that string was a type class including conversion operators before realizing that BitC can simply remain silent on string representation. The issue is native "char" size. shap _______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
