Path: utzoo!mnetor!uunet!mcvax!enea!zyx!grzm
From: grzm@zyx.UUCP (Gunnar Blomberg)
Newsgroups: comp.lang.prolog
Subject: Re: behavior of read/get0 at end_of_file
Message-ID: <2409@zyx.UUCP>
Date: 25 Mar 88 12:14:47 GMT
References: <608> <1197@kulcs.kulcs.uucp> <783@cresswell.quintus.UUCP> <518@ecrcvax.UUCP> <801@cresswell.quintus.UUCP>
Reply-To: grzm@zyx.SE (Gunnar Blomberg)
Organization: ZYX Sweden AB, Stockholm, Sweden
Lines: 23
Keywords: get0 read end_of_file

In article <801@cresswell.quintus.UUCP> ok@quintus.UUCP (Richard A. O'Keefe) writes:
>[...]  So the alternatives I can see at the moment
>are
>    o	construct a new string every time.
>    o	precompute 2^16 strings.
>    o	cache 2^8 strings, and construct a new string every
>	time for Kanji and other non-Latin alphabets.
>    o	not support Kanji or other non-Latin alphabets at all.

How about:
     o	support an immediate representation for characters.
if you've got room for them in your pointers. Or
     o	cache them as they occur.
if you haven't.

I can't see that the fact that characters look like one-element strings
to the Prolog programmer in any way would stop an implementor from
implementing them using the same tricks as if characters were a
separate data-type.  Yes, it makes the internal string-handling
somewhat more convoluted, but not unduly so, I would say.

-- 
Gunnar Blomberg, ZYX, +46 8 6653205, grzm@zyx.se