Not obvious what the right answer is here. My sense is that we'll learn a lot going through the compiler port, and we should defer this question until after that.
On Sun, Mar 27, 2011 at 6:00 AM, Ben Kloosterman <[email protected]> wrote: > 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 > >
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
