On Mar 13, 11:50 pm, "Ed" <nos...@[EMAIL PROTECTED]
> wrote:
> "Bruce McFarling" <agil...@[EMAIL PROTECTED]
> wrote in message
> > On Mar 13, 9:50 pm, "Ed" <nos...@[EMAIL PROTECTED]
> wrote:
> > > Implementation. BETWEEN can't be defined from WITHIN and
> > > vice-versa.
> > This is false. It can't be defined from WITHIN without handling the
> > boundary case separately. See previous:
> > : BETWEEN ( x1 x2 x3 -- fl ) 1+ 2DUP = >R WITHIN R> OR ;
> > ... its just that the (Anton's) version of the definition of BETWEEN
> > without WITHIN is cleaner.
> Yes, I saw that in an earlier post.
> It's best to avoid workarounds if at all possible. They slow things
> down and can introduce errors, which need more work-arounds...
> In the end it becomes impossible to maintain. A nice example of
> work-arounds is FPOUT v2.2 :)
That's not a work-around, its a boundary correction. Its just that it
does about as much stack manipulation to use ``WITHIN'' correctly as
to directly compute ``BETWEEN'', so in this particular case the game
is not worth the candle.
> > And of course AFAIR, even in a 32-bit system with Unicode UTF32
> > characters,
> > : BETWEEN ( c1 c2 c3 -- fl ) 1+ WITHIN ;
> > ... is valid ... that is, if I recollect correctly $FFFFFFFF is
> > reserved and can not be a valid character code point.
> I hope you'll be calling it something other than BETWEEN :)
You mean like ``among-chars?''?
I don't know that I would bother factoring at that level anyway ...
the supposedly terrible 1+ WITHIN in this case would normally be in
low level code that will be hidden:
.... (1) TRUE >R @[EMAIL PROTECTED]
(2) BEGIN
DUP R@[EMAIL PROTECTED]
AND WHILE \ next-charset exists and still looking?
2DUP CELL+ 2@[EMAIL PROTECTED]
1+ WITHIN 0= IF RDROP FALSE >R THEN
REPEAT DROP R> NOT
....
\ (1) ( c &charset-list )
\ (2) ( c &charset#l R: fl-continue? )
I think I'd be factoring out ``CELL+ 2@[EMAIL PROTECTED]
1+ WITHIN'', since it starts
with the character to be matched and the address of a whole item from
the linked charset structure.
|
