From ok@atlas.otago.ac.nz  Mon Jun 12 00:58:45 2000
Received: from atlas.otago.ac.nz (atlas.otago.ac.nz [139.80.32.250])
	by swi.psy.uva.nl (8.9.3/8.9.3) with ESMTP id AAA12256
	for <prolog@swi.psy.uva.nl>; Mon, 12 Jun 2000 00:58:43 +0200 (MET DST)
Received: (from ok@localhost)
	by atlas.otago.ac.nz (8.9.3/8.9.3) id KAA31710;
	Mon, 12 Jun 2000 10:59:19 +1200 (NZST)
Date: Mon, 12 Jun 2000 10:59:19 +1200 (NZST)
From: "Richard A. O'Keefe" <ok@atlas.otago.ac.nz>
Message-Id: <200006112259.KAA31710@atlas.otago.ac.nz>
To: pjb@imaginet.fr, prolog@swi.psy.uva.nl
Subject: Re:  Suggestion regarding the classification of the characters.

The intent of C/UNIX locales and their aspects such as LC_ALL
LC_MESSAGES LC_MONETARY LC_COLLATE LC_TIME LC_NUMERIC LC_CTYPE
is so that a program can adapt its *data* handling.

To set the *syntax* of the programming language from the locale
is a bad idea.  There are plenty of excellent reasons why Quintus
Prolog decoupled its data character classification predicates
from its syntax tables.

Instead of everyone coming up with their own ideas about which characters
are "more like alpha" and which characters are "more like punct", let's
appeal to unidata*.txt.  For example, the SUPERSCRIPT DIGIT characters
are classified as 'Nd'.  That way we'll all have the _same_ way of
classifying characters, and be able to share code and data.

It could be quite simple.  Prolog should use the number and
identifier syntax spelled out in the Unicode book, and should
accept a
:- text_encoding(<coded character set name>).
directive at the top of a file to tell it how the bytes in the
file map to Unicode characters.  (ISO 2022 is the official mechanism
for things like that, but for something like a source file, it is better
to be readable.)
	

