IDE versus MSG Box - Field Tabstops

[Richard Gaskin]

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:
 >
 >   put "1,2,3" into x
 >   put 4 before item 7 of x
 >   put x -- puts "1,2,3,,,,4"
 >
 > In this case, since empty items are possible, the list is padded to
 > make the command possible in a stricter sense than what was possible
 > with characters. I doubt I'm demonstrating anything obscure here, but
 > I'm trying to illustrate one of the beautiful things about LC: in many
 > circumstances, it simply "does the right thing," even when given
 > potentially counterintuitive input. I'd hate to lose that.

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

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.

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.

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.

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. :)

-- 
  Richard Gaskin
  Fourth World Systems
  Software Design and Development for Desktop, Mobile, and Web
  ____________________________________________________________
  Ambassador at FourthWorld.com        http://www.FourthWorld.com