On Mar 18, 8:30 am, Andrew Haley <andre...@[EMAIL PROTECTED]
>
wrote:
> Doug Hoffman <no.spam> wrote:
> > Andrew Haley wrote:
> >> Doug Hoffman <no.spam> wrote:
> >>> Andrew Haley wrote:
> >>>> Doug Hoffman <no.spam> wrote:
>
> >>>> This one has been asked by you before, and answered:
>
> >>> I had forgotten. Thanks for the reminder. Everyone can stop
reading
> >>> this now.
>
> >>>> My opposition is not based on some sort of a priori theoretical
> >>>> objection, but on what I've seen happen when people use locals and
> >>>> avoid factoring.
>
> >>> "...based on...what I've seen happen when people use locals and
avoid
> >>> factoring"
>
> >>> What about people that drink milk and avoid factoring?
>
> >> That's bad too.
> > The point of course is the provided cause and effect are logically
> > equivalent.
> >> The point, of course, is that people sometimes use
> >> locals as a way to avoid having to factor.
> > Just because sometimes some people misuse any given feature of Forth
> > is *not* a reason to discourage the use of that feature. Locals and
> > Named Input Parameters are not a panacea for everything. Never said
> > that, never will. But in some situations they are dandy, IMO
> > (remember the context, resource-rich).
>
> OK. I'm not arguing with you; I'm just saying that locals and badlly-
> factored code often go together, because locals can be used to avoid
> factoring. I'm not telling anyone not to use locals.
>
> >> Marcel recently posted a useful example of what happens.
> > It usefully showed what?
>
> It shows what happens when locals are used to write unfactored code.
>
> I am not trying to prove that using locals causes bad factoring.
>
>
>
> >> What would convince you? A survey?
> > No, reason/logic and probably some illustrative examples would help.
> > From Thinking Forth, The Stylish Stack:
> > **BEGIN EXCERPT FROM TF
> > Although we're using the stack to get the four arguments,
> > the algorithm for drawing a box doesn't lend itself to the
> > nature of the stack. If you're in a hurry, it would probably
> > be best to take the easy way out:
> > VARIABLE TOP ( y coordinates top of box)
> > VARIABLE LEFT ( x " left side)
> > VARIABLE BOTTOM ( y " bottom)
> > VARIABLE RIGHT ( x " rightside)
> > : [BOX] ( x1 y1 x2 y2)
> > BOTTOM ! RIGHT ! TOP ! LEFT !
> > LEFT @[EMAIL PROTECTED]
TOP @[EMAIL PROTECTED]
RIGHT @[EMAIL PROTECTED]
TOP @[EMAIL PROTECTED]
LINE
> > RIGHT @[EMAIL PROTECTED]
TOP @[EMAIL PROTECTED]
RIGHT @[EMAIL PROTECTED]
BOTTOM @[EMAIL PROTECTED]
LINE
> > RIGHT @[EMAIL PROTECTED]
BOTTOM @[EMAIL PROTECTED]
LEFT @[EMAIL PROTECTED]
BOTTOM @[EMAIL PROTECTED]
LINE
> > LEFT @[EMAIL PROTECTED]
BOTTOM @[EMAIL PROTECTED]
LEFT @[EMAIL PROTECTED]
TOP @[EMAIL PROTECTED]
LINE ;
> > **END EXCERPT FROM TF
> > Though with today's extensions one would probably do it like this:
> > : 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 (in 1995!) at
>
> http://groups.google.co.uk/group/comp.lang.forth/msg/f0d35aaa4ae7a25c
>
> > If I were someone taking a first look at Forth I believe that I would
> > find the above BOX2 solution quite readable, understandable, and would
> > want to try Forth. If the definition were chock full of ROTs OVERS
and
> > so on I would probably skip Forth and move on.
>
> No stack manipulation needed.
The relent part is at the end.
Drawing primitive:
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.
: DRAW-BOX ( top left bottom right)
2OVER AT >X DRAW >Y DRAW >X DRAW >Y DRAW ;
Or, in other words, take drawing the box as the target, rather than
drawing the box with a line draw primitive appearing in the word where
that line draw primitive takes a pair of doubles as its argument.
|
