Doug Hoffman <no.spam> wrote:
> Elizabeth D Rather wrote:
> > Doug Hoffman wrote:
> >> Andrew Haley wrote:
> >>> Doug Hoffman <no.spam> wrote:
> >>
> >>
> >>>> : BOX2 { l t r b -- }
> >>>> l t r t Line
> >>>> r t r b Line
> >>>> r b l b Line
> >>>> l b l t Line ;
> >>>
> >>> And that's still bad. I provided a much better way to do that
> >long>> ago
> >>
> >> AT ( y x) Set the current drawing position.
> >>
> >> >X ( x - y x) Set the target x co-ordinate; get y from current
> >> >Y ( y - y x) Set the target y co-ordinate; get x from current
> >>
> >> DRAW ( y x) Draw a line from the current position to the
> >target, > then set current to target.
> >>
> >> Using these primitives, the following code requires no mental
> >> gymnastics:
> >>
> >> : DRAW-BOX ( top left bottom right)
> >> 2OVER AT >X DRAW >Y DRAW >X DRAW >Y DRAW ;
> >> Please redo DRAW-BOX using the same drawing primitive and stack
> >input > order as Brodie. Show all of the code.
> >
> > It proves
> > nothing to show comparisons if the constraints are set such that
> > Forth's main strength (being able to design and factor things to
> > simplify the code) is removed from the contest.
>
> It isn't the reordering of stack arguments that I object to (for the
> most part). It's the use of different line drawing primitives. That
> *totally* changes the comparison.
2VARIABLE point-focus
: DRAW ( y x -- )
SWAP 2DUP point-focus 2@[EMAIL PROTECTED]
Line point-focus 2! ;
\ SWAP point-focus 2@[EMAIL PROTECTED]
2OVER Line point-focus 2! ;
\ better when it actually matters where the line ends
: AT ( y x -- )
SWAP 2DUP point-focus 2! 2DUP Line ;
\ not entirely right because it draws one point when it should not draw
any.
\ If you always draw a line right after this might not be a problem.
Now it uses your line drawing primitive.
Was that so hard?
> Would you agree that Andrew *did* use stack manipulation, counter to
> his claim? I'm not knocking stack manipulation, I actually use it
> myself when needed. Just wanting to get the facts right.
Sure. Often implicitly inside things that look like primitives, and a
little bit explicitly. I took his meaning to be "no excessive stack
manipulation" rather than no stack words. Like "No stack thra****ng.".
> > IMO the useful challenge is to draw a box. True, Andrew left out
> > some sup****ting definitions, and it might be useful to see them to
> > get a clear picture of the overall clarity of his approach, but I
> > think it's counter-productive to insist on the identical factoring.
>
> No. Asking to use the same drawing primitives only makes logical
> sense.
> Otherwise the comparison is meaningless.
Forth is pretty good at letting you rearrange things. All it took for me
above was 2 SWAPs.
> > I suspect there were a couple of variables in the original graphics
> > that Andrew was quoting. Again, I don't see that as invalidating
> > his approach.
>
> So introducing more variables is a good thing in Forth? Interesting
> concept.
If we're talking sheer esthetics, I prefer global variables to locals.
They aren't re-entrant, but I can get by wrthout re-entering DRAW .
But apart from esthetics, doesn't it make sense to use whatever works?
|
