[DGD] Invalid ranges...

[Troels Therkelsen]

On Sun, 21 Oct 2001, [ISO-8859-1] Pär Winzell wrote:

> > Feature for as far as I can remember working with DGD.  It's the
> > degenerate case of splitting up an array by doing something like this:
> >
> >   arr_beg = arr[.. i];
> >   arr_fin = arr[i + 1 ..];
> >
> > Where i == sizeof(arr) gives your first case, same for strings.
>
>
> That's what I recall as the practical reason -- however, defending the
> design as consistent is a different matter. The argument that I make in
> favour of it is this:
>
>    ({ 1, 2, 3 }) + ({ 4 }) -> ({ 1, 2, 3, 4 })
> and
>    ({ 1, 2, 3, 4 })[3 ..] ->({ 4 })
>
>
> Therefore it makes sense that
>    ({ 1, 2, 3 }) + ({ }) -> ({ 1, 2, 3 })
> should have
>    ({ 1, 2, 3 })[3 ..] -> ({ })
>
>
> No such analogy could be made for [4 ..] and higher, so there -is- a
> logical difference between the two cases in the original mail.
>
> Zell
>
Ok, I personally think that is a bit far-fetched and contrived.  Out of
bounds is out of bounds, period.  IMHO, anyway.  And if

  ({1, 2, 3})[3..] == ({ })  <=>   ({1, 2, 3})[3..2] == ({ })

why doesn't it work for range underflow:

  ({1, 2, 3})[-1..0] == error

My whole point is just that I don't feel ranges should ever fail with an
error but give the value of the 'empty' datatype ("", ({ }) and ([ ])).
And if it should fail, it should fail for all the cases that simple
indexing fails.

I can accept Erwin's explanation, because it makes sense why it would have
evolved that way, but DGD is so clean in all other aspects, which is why I
wondered about it.  It seems very kludgy, is all.

Ah well, didn't mean to spark a religious war over this; I can learn to
code around this quirk. :-)

Regards,

/Troels Therkelsen


_________________________________________________________________
List config page:  http://list.imaginary.com/mailman/listinfo/dgd