willett wrote:
(from prior thread: Re: test program for Extended Pascal strings)
On 13 Nov 2005, at 08:40, Frank Heckenbach wrote:
Then I get a range-check error in this line:
IF x1[j*k..20][1] <> 'k' THEN fail(34);This is because GPC does not shift the range of string slices to 1..x by default, only in EP mode. Currently we don't have a separate feature options for this, so I tried with --extended-pascal now (removing the non-EP parts). I then get:
Rather than adding a separate feature option, why not make shifting the range of string slices the default behavior? Aren't string slices a feature available only in Extended Pascal implementations, anyway?
GPC also supports string slices in its dialect, and also slices of other arrays. The latter is why we don't shift -- for general arrays there's no natural lower bound, so keeping the original range seems the only reasonable thing to do.(*) Then, if we do so for general arrays, it seems consistent to do so for strings, as otherwise we'd get strange behaviour:
var a: packed array [1 .. 10] of Char; b: packed array [0 .. 10] of Char;
a[5 .. 7] -> range 1 .. 3 according to EP
b[5 .. 7] -> range 5 .. 7 as it's no string
(According to strict EP rules, even the lack of `packed', which makes no implementation difference for Char-arrays in GPC, would have such an effect.)
(*) Perhaps one could think about always shifting to the lower bound of the actual array, which would be EP compatible in the case of strings. But it would also have strange effects, such as adding an element to the lower side of an array (say, changing from 1.. to 0.., would affect the result of slices far apart, both in terms of array elements and code position).
It may be argued to abandon non-string slice accesses altogether. So far, in most cases where they seemed useful, they actually weren't, e.g. due to strict type-checking, and to actually make them useful, we'd need to do more work, such as special type-compatibility rules, as have recently been discussed.
OTOH, array slices may be the only syntactically clean way (so far) to copy or fill parts of an array (instead of Move and FillChar), so there may be merit in having them (with special type-checking rules) ...
Frank