[Nickle]UTF8 and bool type

[Bart Massey]

Is there any reason not to simply change getc(), ungetc(),
and putc() to have the specified behavior, and have special
names for the "raw" functions (e.g. getb(), ungetb(),
putb())?  It seems to me like the UTF-8 behavior is both the
common and the "character"-oriented case.  Failing that, I
vote for getuc(), ungetuc(), putuc().

	Bart

In message <E17WtDh-0000Tw-00@localhost> you wrote:
> 
> I'd like to propose a couple of changes to nickle, the first is to switch
> the string representation to Unicode.  Strings will appear as a sequence of
> 32-bit Unicode values.  Strings read and written in "raw" form will be
> encoded using UTF-8.  The internal representation is also UTF-8, but this 
> isn't visible to applications.
> 
> Three new File namespace functions are needed:
> 
>  File::getcharacter (file f)		- parse the next UTF-8 char
>  File::ungetcharacter (int c, file f)	- push the specified char back as UTF-8
>  File::putcharacter (file f)		- output c in UTF-8 format
> 
> As always, suggestions for the names are welcome.
> 
> The second change is a bit more fundemental.  Nickle has always allowed any
> type to appear in expressions where a boolean value was needed; the test 
> was always whether the computed value was not equal to 0.  I propose to 
> add a real boolean type (name bool).  This type will have two values, 
> 'true' and 'false' and will be the required type for all primitive 
> conditional tests (if, while, do, for, twixt, ?:).
> 
> The 'bool' type will be extremely useful in the future as algebraic types 
> are added, but even now, it should catch a large class of errors which 
> would otherwise go undetected.
> 
> -keith
> 
> 
> 
> _______________________________________________
> Nickle mailing list
> Nickle@nickle.org
> http://nickle.org/mailman/listinfo/nickle