<DIV style="font-family:Arial, sans-serif; font-size:10pt;"><BR><BR>-Rodney Bates<BR><BR>--- jay.krell@cornell.edu wrote:<BR><BR>From: Jay K <jay.krell@cornell.edu><BR>To: "Rodney M. Bates" <rodney_bates@lcwb.coop>, m3devel <m3devel@elegosoft.com><BR>Subject: RE: [M3devel] cm3 does not support Scan.LongInt<BR>Date: Mon, 16 Dec 2013 09:31:57 +0000<BR><BR>

<DIV dir="ltr"> > like f.i. UCHAR in order not to break code that does rely on the current 16bit character width.<BR> <BR> <BR>It might as well be UINT32 or UInt32?<BR> <BR> <BR>In C++, std::string is std::basic_string<char>, std::wstring = std::basic_string<wchar_t>.<BR>Could/should we use generics similarly?<BR> <BR> <BR>CharText, WIDECHAR=UINT16, WideCharText, UInt32Text?<BR> <BR> <BR>> There is the problem of text literals.<BR>> The current "text" can change between "char" and "widechar".<BR><BR>Actually this is not quite the right view of the abstraction of TEXT.  As long<BR>as you keep your fingers out of the pie of its implementation, Text.T is just<BR>a heavy weight but very easy-to-use functional style abstraction of strings<BR>of WIDECHAR.   Since the value set of CHAR is a subset of WIDECHAR,<BR>this means you can put CHAR values into a TEXT and get them out, but<BR>the distinction lies only on the type of what is passed to/returned from the<BR>procedures in Text.  How Text represents this internally is, usually, its<BR>own private business.<BR><BR>The fact that there are two kinds of string literals creates confusion,    <BR>They differ only in the way the value is specified in source code.  Both<BR>have the same type TEXT.  This is unlike [WIDE]CHAR, where the two kinds<BR>of literals have different types as well as different value specification<BR>rules.  <BR> <BR>> Can "widechar" vary per-target?<BR>> In particular, I think C/C++ wchar_t is 32bits on some platforms, so it might be reasonable for Modula-3 WIDECHAR to match it?<BR>> (I just checked -- Linux/amd64 does have 32bit wchar_t).<BR> <BR> <BR>> it is a thorny issue though, there are pluses and minuse either way.<BR>> An alternative would be to have WIDECHAR be the same for all targets.<BR><BR> There is no reason to do otherwise.  Nobody has concern for using the <BR>most efficient native hardware arithmetic opcodes on WIDECHAR.<BR> </DIV>
</DIV>