From: Markus <markus@...>
Date: 2004-10-06T12:01:40+09:00
Subject: Re: [RCR] New [] Semantics

On Tue, 2004-10-05 at 13:43, trans. (T. Onoma) wrote:
> On Tuesday 05 October 2004 10:13 am, Markus wrote:
> > >   r = 0<..<43
> > >   r = 0<..<=42
> > >   r = 0<=..<43
> > >   r = 0<=..<=42
> > >
> > >   r = 0<..+<42
> > >   r = 0<..+<=42
> > >   r = 0<=..+<42
> > >   r = 0<=..+<=42
> >
> >      I'm not sure what distinction you are making here with the '+'.
> 
> length

      I prefer mine (0 <..+ 42 & 0 <..<+ 42), but that could just be NIH
thinking.

> > > Basically tie-fighter ranges ( and x-wing ranges ;)  F'ugly! :( Alhtough
> > > I like your direction.
> >
> >      The core idea is actually peripheral to this (or visa versa); I'm
> > modifying parse.y to extend the idea of tOP_ASGN ( +=, -=, etc.) to
> > include (as user redefinable methods like <=> is presently) _all_
> > combinations of operator characters.
> 
> That's cool. Does it complexify or simplify the parser?

     *smile*  Simplifies, from a non-C programmer's point of view.  

     I suspect C purists will blanch a bit, but first my goal is to make
something that is clear and works.  If it turns out to be too slow or
too easy to read or something, a fast-and-loose-with-pointer-games pass
can always be done to turn it into idiomatic C.

> > >   r = :(0,43)
> > >   r = :(0,42]
> > >   r = :[0,43)
> > >   r = :[0,42]
> > >
> > >   r = :(0:43)
> > >   r = :(0:42]
> > >   r = :[0:43)
> > >   r = :[0:42]
> >
> >      Hmmm.  That would be a little harder--or at least, I don't quite
> > see how to bend the parser to handle it.
> 
> They should parse as symbols. I recall reading that symbol notation will be 
> made more flexible in the future so quotes don't always have to be used for 
> odd cases. But I'm certainly reaching here.

     Uh, burdening symbols with semantics?  I can see how it could be
made to work, but I hear the villages mumbling to each other already.

> This seems better:
> 
>    r = 10..43.0
>    r = 10..42
>    r = 10..43.0
>    r = 10..42
> 
>    r = 10++33.0
>    r = 10++32
>    r = 10++33.0
>    r = 10++32
> 
> Where floats are exclusive and integers are inclusive.

     Ugh.  Integer ranges and float ranges are both meaningful (and
useful); why try to paste the inclusive/exclusive distinction over the
integer float distinction?

     I noticed in a sibling thread you're working on the implementation
end.  If I get a compiler patch done in a reasonable time I'll send you
a copy to try out.  If I don't have it done in a week it will have to
wait, since I'm going to be travelling for a week or so, and then
getting caught up when I get back.

    -- Markus