On 11 March 2010 01:08, Jonathan S. Shapiro <[email protected]> wrote: > On Wed, Mar 10, 2010 at 3:18 PM, Michal Suchanek <[email protected]> wrote: >> On 10 March 2010 23:58, Jonathan S. Shapiro <[email protected]> wrote: > >>> System.Char is typed in BitC as "BitC.UCS2". >>> System.String is typed in BitC as "BitC.UCS2 Vector". >> >> Does this amend the contract to provide these types on any platform? > > I'm not clear about the question. The types BitC.UCS2, BitC.UCS4, > BitC.String and BitC.char are specified by BitC, and would be present > in all implementations. The statement about relationships to > System.Char and System.String are specific to the specification of > interoperability with .NET/CLR. > > Does that answer your question?
Yes, that's clear. >> Beware of the Chinese guy who comes and says in a polite manner that >> BitC sucks because it can only do Unicode and he needs additional >> characters for his Ancient Chinese texts (for which there is >> non-Unicode encoding). > > As Bob Asprin would say: "We'll burn that bridge when we get to it." > Today, BitC sucks for everybody because it isn't running at all. If we > can get that down to complaints from your Chinese guy, I'll consider > that a major improvement. Yes, just make sure you don't forget the oil and lighter. Since they specified PHP as Personal Homepage Preprocessor they are having one hell of a time turning it into a programming language. > > Even Ancient Chinese Guy has to build his own encoding, at least we > have a type system to help him. There already is one (or a few) encoding for that. > >>>> BitC.Char, if present, is a type alias for BitC.UCS4, a.k.a Unicode Code >>> Points. >> >> I guess we can avoid a Char altogether since it is just a confusing alias. > > All BitC "core" types are in the BitC namespace, which is implicitly > imported. BitC.Char is therefore seen by the programmer as Char. I > used the explicit qualifier here in the interest of clarity. > >>> Is that it? >>> >>> I think that this is one consistent position. The other consistent position >>> would be that "BitC.char" is a type alias for BitC.UCS2. >> >> What would be this consistent with? > > CLR and JVM, and consequently the expectations of the majority of > current programmers in the world. It's also consistent in the sense > that it's a clearly specified outcome even if it is one that you and I > think is sub-optimal. > When taking a feature from elsewhere it's necessary to ask who would use it and for what? I personally would understand an UCS4 or UCS2 type but a 32-bit or 16-bit Char? Char is confusing type as it is, no need to continue on that. I would expect people can add it as an alias if they really cannot live without it. Note also that the majority of programmers in the world happily write broken code in unsafe languages on broken systems so they are not any good measure of what should be the goal of a new language runtime. Thanks Michal _______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
