On 14 Nov 2005, at 13:12, Frank Heckenbach wrote:
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
Much more complicated than I would have expected. I can see why gpc works the way it does now. My concern is that a runtime incompatibility with a language standard makes porting code more error-prone and leads to unexpected bugs that may be discovered only late in the development process ("late" as in, when users already have your product). Thus, IMHO, a fairly high priority among the factors above to weigh is that array slice bounds not differ among implementations, and not differ when the -extendedpascal option is turned on and off.
Thoughts on options:
1. Having the array slice always shift to the lower bound, as you suggest is not unreasonable. It is comparable to having an array slice be the "base type" of the expression. (My coding intuition, by the way, is that if I change the lower bound of an array, I'm going to have to look carefully at all my code accessing that array, anyway.)
2. Having the array slice shift only for true strings, appears less desirable from my limited perspective. This might be preferable to the current situation because it does not introduce runtime incompatibilities across systems. If the confusion you note is a problem, perhaps a warning could be issued for arrays of char that are not strings.
3. You make a strong case for retaining non-string slice accesses.
Hope this is helpful in thinking through what the best design is.
Willett Kempton Visible Software