Re: Why equal(x[n], x[n..n])=0 ?
Fernando Bauer wrote:
>
> Hi All,
>
> I was debugging a function when I noticed that a slice with equal indexes is
> different from an access with one index. x[n] is different from x[n..n] where
> n is a valid index.
> According to the manual, a slice always result in a sequence (also when x[n]
> is an atom). But, in particular, when we have something like x[n..n], the
> result
> is x[n] with the its depth incremented by 1. In other words, the structure of
> the element depends on the access form (subscription or slicing). For me, this
> is a surprising fact.
> This kind of implementation affects some algorithms, because we have to test
> when the indexes are equal in order to not use slice.
> So, why equal(x[n], x[n..n])=0 ?
Because the syntax [n..m] is a slice which is a sequence - always. And the
syntax [n] is a element reference whose value depends in what is at location 'n'.
Specifically, the syntax [n..n] is a sequence which has a length of one.
Given the sequence (string) s = "qwerty", then s[3..3] is the string "e" and
s[3] is the character 'e'. And characters are not strings.
Another way to look at is this ...
s[3 .. 4] is "er"
s[3 .. 3] is "e"
s[3 .. 2] is ""
so making s[3..3] ("e") mean the same as s[3] ('e') is inconsistent.
And yet another look ...
Given that
s = {"one", "two", "three", "four"}
it means that s is a list of strings.
Thus s[3 ..4] is a list of two strings {"three", "four"} and
s[3 .. 3] is a list of one string {"three"} but
s[3] is not a list, but the element at location 3, which happens to be a string
in this case.
--
Derek Parnell
Melbourne, Australia
Skype name: derek.j.parnell
|
Not Categorized, Please Help
|
|
