[SWIPL] SWI 5.10.2 operator restriction

[Richard O'Keefe]

On 17/02/2011, at 12:33 AM, Ulrich Neumerkel wrote:

> Richard O'Keefe:
>> Now that we have Unicode, I suggest that perhaps it is time
>> for people to abandon the ASCII compromise and use ...
> 
> The differences already show for the symbol characters in Latin-1
> which is a subset of Unicode.  SWI classifies all symbol characters as
> solos.

Yeek.  There are three sensible things to do with characters outside
the range explicitly mentioned in the standard:

(1) See the table below.
(2) Reject them promptly.
(3) Treat them as letters (this is what Quintus did in the 80s to
    satisfy the most pressing need of our Asian customers, namely
    to be able to write words in their own script).  More precisely,
    this *was* sensible then.  It isn't any more.

As a general rule, I expect that Unicode characters should be
handled according to their General Category (see Unicode 6.0
section 4.5 table 4-9):

	Lu	upper case letter, starts a variable
	Ll	lower case letter, starts an atom
	Lt	title case letter, starts a variable
	Lm	modifier letter, allowed in variable/atom tail
	Lo      caseless letter, starts an atom

	Mx	allowed in variable/atom tail if modifying a
		letter or digit

	Nd	decimal digit, allowed in numbers
		-- it might make sense to reject numbers using
		mixed scripts
	Nl,No	allowed in variable/atom tail

	Px	if ASCII, have standard ASCII meaning.
		otherwise rejected if used unquoted.
	
	Sk	allowed in variable/atom tail
	Sx	agglutinating symbol characters otherwise

	Zx	white space

	Cc, Cf	only allowed in comments
	Cs, Co	only allowed in commands and quoted text
	Cn	rejected (with option to allow possible characters)
		-- precisely because they may be assigned some other
		character in the future, all but the explicit
		non-characters should be rejected now by default.

Something like this is how the standard should specify it to allow
adaptation to the ever-changing stream of Unicode version.

As for f(a:-b), if memory serves me C Prolog -- which I have on 8mm
tape, but have no reader for -- also allowed this, and it was viewed
by users as a big usability advance.  But it is definitely something
Prolog can manage without