IDE versus MSG Box - Field Tabstops

[Geoff Canyon]

On Thu, Aug 15, 2013 at 1:20 AM, Richard Gaskin
<ambassador at fourthworld.com>wrote:

> Geoff Canyon wrote:
>
> > To me, this is very much like the following, which works:
> >
> >   put "test" into x
> >   put z before char 7 of x
> >   put x -- puts "testz"
> >
> > There is no character 7 of x. The length of x is 4 (and then 5,
> > obviously). The engine takes an unexpected input and interprets it in
> > a sensible, predictable, and useful way. Interestingly, this does
> > something quite different:
> >
>

<snip>


>
> Did you mean to post that in reply to the other thread on delimiters?
> Neither of those examples are of tabStops.
>

No, I meant them for this thread, because they both illustrate how LC can
take input that doesn't match the obvious inputs and still do something
useful with it. Negative chunk references are another example: I doubt
anyone new to programming intuitively knows what char -3 of "mississippi"
is -- but they're incredibly useful, and they're easy to understand after
you've thought about it for a moment.

The tabStops issue is distinguished from those by one key principle:
>
> Whether we prefer the behavior those examples exhibit or not, the behavior
> is consistently applied, regardless of the values in the data being acted
> on.
>
> But with tabStops, the behavior differs with different data.
>
> That's a big ouch, making it impossible to write a handler which can
> reliably automate the setting of tabStops if the range of values is
> sufficiently dynamic.
>

I don't know what you mean by , can you give me an example?

It's funny -- now it's my turn to have my head explode, because I would
have assumed that the color names were an example of the same sort of
"different info out than in" behavior that you dislike about the tabstops.
But after I tested, it turns out that:

set the backgroundcolor of this card to red
put the backgroundcolor of this card -- puts "red" -- geoff's mind is blown

I would have sworn that red translated to some RGB combination internally,
and that the second line above would return that RGB value instead of
"red." Is there some function I don't know about that translates from
colornames to RGB. The same thing happens with HTML colors -- set the color
to "#808080" and you get "#808080" back when you ask for the color.

How would anyone write a command like:

on darkenObject pID
   -- darkens whatever you hand it
   get the backcolor of pID
   repeat with i = 1 to 3
      put max(0,item i of it - 20) into item i of it
   end repeat
   set the backcolor of pID to it
end darkenObject

The moment you hand that an object with a backcolor of red, or #808080,
that command dies an ugly death.

 Sure, it's been around for a long time.  So has "destroyStack", which
> doesn't destroy a stack.  I think the world of Dr. Raney, but I think he'd
> be the first to say that sometime he took short cuts (ever hear the one
> about how the boundingRect property was first implemented in a different
> order from all other rects in the language?).
>
> In this case, the convenience once offered by having this one token
> crudely attempt to serve two different goals was fixed with tabWidths,
> which supports relative offsets consistently and reliably.
>

I still don't understand why you use words like "crudely." The solution as
implemented seems clever and elegant to me, but that's what makes a
ballgame I guess.

That said, I agree here with the one thing this has in common with the
> delimiter thread:
>
> > Further, I think all the arguments against changing the behavior of
> > the terminating itemdelimiter apply here as well: given the long
> > history of this behavior, changing it is risky for existing code.
>
> I seem to be in a minority when it comes to changing the behavior of
> tokens that have been in the language for a long time, but it's encouraging
> to see that number growing.
>
> As I noted earlier:
>
>
>    But before I file a bug report, let's see if it's worth the time:
>    has anyone ever had code that produced unexpected/unwanted results
>    from this inconsistent treatment of the input values of tabStops?
>
> So far we've only heard from Peter on this.  Maybe there are others, but
> maybe there aren't.
>
> There are enough dumb things in the language that I don't think anyone
> wants to see RunRev take time away from more critical things to address
> them all.
>

"dumb" -- you're killing me, Richard ;-)


> So I won't file this as a bug report until there's evidence that it's as
> problematic in practice as it is in theory.  And even then, there's
> certainly no reason to believe that if I did file a bug report anyone would
> bother with it in light of the bigger goals they're working on right now.
>
> If it's a problem it can be fixed.  And if it's not a problem this thread
> will die a natural death. :)


Not as long as you and I draw breath, my friend ;-)