[developers] ECL/PET

[Stephan Oepen]

hi ben, apologies for the long turn-around.  australia and back takes a
surprising amount of time :-).

> The latest release of ECL (0.9i) provides a certain amount of support
> for use of Unicode:
> 
> "ECL can also be built with support for strings and symbols with unicode
> characters (patches by B. Spilsbury). However, since the reader still
> does not understand external formats, there is some way until we can
> claim that ECL supports unicode."
> 
> Unicode support is needed by the (C++) fspp module in order to
> compute (Unicode) character offsets. Would anyone object to upgrading
> PET to this new version of ECL? (There is some non
> backwards-compatibility in the naming of functions calls in the new
> version, which presumably could be worked around with suitable
> #ifdef's.) 

it sounds as if we are not going to have a UniCode-enabled version of
FSPP when moving to ECL 0.9i quite yet?  right now, when i turn on the
FSPP tokenizer in PET, i get several messages like the following:

  read-preprocessor(): [96] invalid pattern ` (["]) '

i suspect the reader got confused by two-byte characters in the file?

in a nutshell, if we gained a working FSPP by requiring 0.9i, then i
would be happy making that move.  if not, i would rather wait for the
ECL version that actually has enough UniCode for FSPP to work.

                                                         best  -  oe

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
+++ Universitetet i Oslo (IFI); Boks 1080 Blindern; 0316 Oslo; (+47) 2284 0125
+++     CSLI Stanford; Ventura Hall; Stanford, CA 94305; (+1 650) 723 0515
+++       --- oe at csli.stanford.edu; oe at ifi.uio.no; stephan at oepen.net ---
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++