"Walter" <walter@digitalmars.com> wrote in message news:9uq413$26dn$2@digitaldaemon.com...

> I remember the first time I came across a mathematical expression:
>
>     A[0..foo)
>
> I just assumed it was a typo. I'd guess that having both A[0..foo) and A[0..foo] supported but meaning different things will result in bugs like not seeing the ; in:
>
>     while (expression);
>         statement;

Although I don't usually have such problems myself, I understand the drawbacks of such approach. Okay, so let's have a compromise version:

    A[0..foo];    // both ends inclusive
    A(0..foo);    // first inclusive, last exclusive

And no other ways. In fact, it's not very frequently when you
want first or both ends to be exclusive, so not much need in them...
On other hand, this syntax is more error-proof and all. Anybody
sees any drawbacks now?

<la7y6nvo@shamko.com> wrote in message news:s7citbotd5u.fsf@michael.shamko.com...
><SNIP>
> Syntax is another issue.  The problem with using []'s is that it "looks like" both ends are included.  The Mesa programming language had an interesting notation for Integer subranges, which was, IIRC, one of the following - all the following ranges are identical -
>
>     INTEGER [ 1 .. 10 ]
>     INTEGER [ 1 .. 11 )
>     INTEGER ( 0 .. 10 ]
>     INTEGER ( 0 .. 11 )
>

Assuming:

int[] a;
int[10] b;
And you want to copy all elements from b to a, without using the [] slice.

I definitely think the syntax above is the best and most intuitive.
- It follows mathematical standards
- It visually shows that the left and right 'parameter' to
   the slice work differently when you use incl .. excl
   indexes like this:   a = b[0..a.size);
- It allows the most flexibility without having to resort to
   strange or very unfamiliar syntax or operators such as '@'
- A rookie will not easily write a = b[0..a.size-1); to copy
   the first ten elements, because the different braces will look
   unfamiliar, so he will check the documentation to see what
   it means. However, I think a rookie might very easily write
   a = b[0..a.size] or a = b[0..a.size-1] depending on his
   personal thought processes. Either one could mean an error
   depending on the way you choose to implement slicing for D.
- The mistake rookies might tend to make, using
   a = b[0..a.size]; could very easily be cought.

Whatever way you choose, I think slicing is a very neat feature for D, and I really love the idea.


--
Stijn
OddesE_XYZ@hotmail.com
http://www.OddesE.f2s.com
__________________________________________
Remove _XYZ from my address when replying by mail

One of the neatest things about the Icon (now Unicon) string processing language is the definition of character positions between characters.  It is just amazing how this simple alteration makes string processing so much simpler.

I read some of the debate on syntax like (0,4] and [5,10).  Let me suggest consideration of the Icon approach for arrays and by extension, strings.  Then a slice is always inclusive and unambiguous.  Icon also has negative positions which work from the back of the array.

Mark

"Mark Evans" <Mark_member@pathlink.com> wrote in message news:algfjb$2r1k$1@digitaldaemon.com...
> I read some of the debate on syntax like (0,4] and [5,10).  Let me suggest consideration of the Icon approach for arrays and by extension, strings.
Then a
> slice is always inclusive and unambiguous.  Icon also has negative
positions
> which work from the back of the array.

Can you summarize it for us?

>Can you summarize it for us?

Short summaries here:

http://www.nmt.edu/tcc/help/lang/icon/positions.html http://www.nmt.edu/tcc/help/lang/icon/substring.html http://www.cs.arizona.edu/icon/docs/ipd266.htm http://www.toolsofcomputing.com/IconHandbook/IconHandbook.pdf Sections 6.2 and following.

Icon is simply unsurpassed in string processing and is for that reason famous among linguists.  There is more to the string processing than just character position indices.  Icon supports special clauses called "string scanning environments" which work like file i/o in a vague analogy.  (See third link above, section 3.)

Icon also has nice built-in structures like sets (*character sets* turn out to be insanely useful), hash tables, and lists.  Somehow Icon never made it to the Big Leagues and that is a shame.  It deserves to be up there with Perl.  Icon is wicked fast when written correctly.

The Unicon project is the next-generation Icon, and has added objects and other modern features to base Icon.  It is on SourceForge.

(There was only one project in which I recall desiring a new Icon built-in.  I wanted a two-way hash table which could index off of either data column.  The workaround was to implement two mutually mirroring one-way hash tables.)

Icon has a very interesting 'success/failure' paradigm which might also be something to study, esp. in light of D's contract emphasis.  The unique 'goal-directed' paradigm is quite interesting but may have no application to D.

I have for a very long time desired Icon's string scanning capabilities in my C/C++ programs.  Even with std::string or string classes from various class libraries (I've used them all), there is just no comparison with Icon.  I would become a total D convert if it could do strings like Icon.

Mark

http://www.cs.arizona.edu/icon/ http://unicon.sourceforge.net/index.html

Excellent, when I first saw the syntax, I was a bit supprised.  I soon figured that you did it so you could express a 0 length array.

Nice to see the logic works all around the world.


"Walter" <walter@digitalmars.com> wrote in message news:9te4ga$njn$2@digitaldaemon.com...
> Ok, the first index is inclusive, the second is exclusive. Making them
both
> inclusive would make it impossible to write a 0 length array. -Walter
>
> "Sean L. Palmer" <spalmer@iname.com> wrote in message news:9tdarf$6mq$1@digitaldaemon.com...
> > The point is that we need to know if array slice indices are both
> inclusive,
> > or if the 'end' index is exclusive.
> >
> > Do you write:
> >
> > a[0 .. a.length] // exclusive
> >
> > or
> >
> > a[0 .. a.length-1] // inclusive
> >
> > ?
> >
> > The second makes a lot more intuitive sense.  For a 1-element array
thus:
> >
> > int a[1];
> >
> > would you want people doing this:?
> >
> > int b[1] = a[0 .. 1]?
> >
> > or this:
> >
> > int b[1] = a[0 .. 0]?
> >
> > Sean
> >
> >
> > "Walter" <walter@digitalmars.com> wrote in message news:9td77n$4fc$1@digitaldaemon.com...
> > >
> > > "Pavel Minayev" <evilone@omen.ru> wrote in message news:9tcv3f$2vca$1@digitaldaemon.com...
> > > > "Walter" <walter@digitalmars.com> wrote in message news:9tche0$2n2v$3@digitaldaemon.com...
> > > >
> > > > > But the length is not the maximum index.
> > > >
> > > > Then [0..length] is not legal.
> > >
> > > I don't understand what you're driving at, then.
> >
> >
> >
>
>