Re: Why equal(x[n], x[n..n])=0 ?

new topic     » goto parent     » topic index » view thread      » older message » newer message

Hi Andy! Thanks for your reply.

Andy Drummond wrote:
> 
> 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 ?
> > 
> > Regards,
> >    Fernando
> 
> At a rough guess I'd say x[n] is an atom, the n'th item in the sequence,
> (assuming a sequence of atoms), whereas x[n..n] is a one-element sequence.
> So you're comparing an atom and a sequence. Essentially the first is an item
> from the sequence, the second is a sequence containing the item.
> 
> Andy

Ok. But my question, using your example, is: why the second is a sequence? Why
not an atom?
I know that slice is defined that way, but my question is why?
Please, look at my reply to Derek.

Regards,
   Fernando

new topic     » goto parent     » topic index » view thread      » older message » newer message

Search



Quick Links

User menu

Not signed in.

Misc Menu