From jan@swi.psy.uva.nl  Tue Jun 13 17:08:40 2000
Received: from gollem.swi.psy.uva.nl (root@gollem [145.18.152.30])
	by swi.psy.uva.nl (8.9.3/8.9.3) with ESMTP id RAA07917;
	Tue, 13 Jun 2000 17:08:40 +0200 (MET DST)
Received: from localhost (localhost [[UNIX: localhost]])
	by gollem.swi.psy.uva.nl (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) id RAA25512;
	Tue, 13 Jun 2000 17:09:22 +0200
From: Jan Wielemaker <jan@swi.psy.uva.nl>
Organization: SWI, University of Amsterdam
To: <pjb@imaginet.fr>, "Pascal J. Bourguignon" <pjb@imaginet.fr>,
        prolog@swi.psy.uva.nl
Subject: Re: Suggestion regarding the classification of the characters.
Date: Tue, 13 Jun 2000 16:52:31 +0200
X-Mailer: KMail [version 1.0.28]
Content-Type: text/plain
References: <20000610042240.178ED3B193@triton.local.net>
In-Reply-To: <20000610042240.178ED3B193@triton.local.net>
MIME-Version: 1.0
Message-Id: <00061317092209.24662@gollem>
Content-Transfer-Encoding: 8bit

On Sat, 10 Jun 2000, Pascal J. Bourguignon wrote:
>Abstract:
>    - The classification of characters in SWI-Prolog is not consistent.

This has been pointed out by Richard O'Keefe as a useful feature. 
Reading source-files should not depend on the locale, just data
manipulated by the program.

>    - I'd suggest to tune char_type to match its documentation.

From what I understand, the problem is that I do not initialize the
locale environment.  Instead of setting all locales, both the Linux and
Solaris manpage suggests it satifies to do

	setlocale(LC_ALL, "");

Or am I overlooking something?

>    - I'd suggest to add a feature to allow the user to customize char_type
>      (with effect on atom/1, var/1, ...).

Influence on basic parsing is out of the question as explained above.

I don't think I'm very happy with that.  One of the problems is that
global switches have implications on all code, which is a nuisance if
you put code from different sources together.  This could be solved
using modules, but that complicates things even further.

Right now code_type/2 has a clear purpose: bringing the functionality
of the POSIX locale handling to the application user.  Making it
programmable confuses things.  If you want something else, just write
a wrapper around it and all is clear: you can have the functionality
as you please and anyone reading your program knows what you are doing.

	Regards --- Jan

