In terms of getting of the ground Is it worth seeing if the framework lib can be made useful to supplement the initial anemic standard lib ? This has the advantage that if we wrap it we don't need to make native calls and hence can easily support both windows and Unix without the normal mess, it works pretty well for OCaml (F#) but that is an OO language.
I can think of some tricks .its all about representation we don't need inheritance ( as its not really used by the framework) , but we do need to express virt calls / interfaces in the CIL ( but not the language) Ben From: [email protected] [mailto:[email protected]] On Behalf Of Jonathan S. Shapiro Sent: Thursday, March 24, 2011 4:18 PM To: [email protected]; Discussions about the BitC language Subject: Re: [bitc-dev] strings and CLR interop was RE: String encoding, again On Mar 24, 2011 12:26 AM, "Ben Kloosterman" <[email protected]> wrote: > > > Shap wrote > >You are seeing a more fine grained interop and an almost opaque string can wrap / be a .NET string , I was looking more at doing strings the bitc way and sending it to the C or the CLR and then converting to our representation when we get it back. Yes. That's a pretty good summary. I'm looking for a solution where the native invoke layer really only needs to check for well-formedness. > If you want to use CLR strings what about collections , does List<String> fit into the picture? Oh you're just _full_ of cheerful thoughts tonight, aren't you?:-) Actually, with struct methods and type variables we are close. We're missing static members (no big deal), virtual functions, and... inheritance. Why not simply add type classes and regions to C# and see if we can hijack the ecma standards process?:-) Shap
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
