Question about checks for min and max values

[Jay R. Ashworth]

On Mon, Jul 25, 2005 at 05:50:32PM -0400, Fairlight wrote:
> Is it just me, or did Nancy Palmquist say:
> > In early versions of filePro = was not allowed on an IF line.  It was 
> > allowed to be used instead of EQ in response to the programmers that did 
> > not understand the difference.  Filepro only responded to the community 
> > and their incorrect use of the = was accepted to make them happy.  I do 
> > not, however, see this as filepro admitting or accepting the change of 
> > meaning, it just did not cause any problem to allow it so they did.
> 
> It causes a problem in furthering a misperception--the very one we've been
> discussing.  They never should have caved on that one.

Well, here I waver, Mark.  C supplies == as the equals operator because
= as the assignment op is *in context* in many of the same places, and
disambiguation is necessary; I believe other languages that reassigned
"equal to" to a different token did it for the same reason.

> > I don't think that filePro misunderstands the difference, it is the 
> > programming communitity that is not clear on the difference.  I disagree 
> > that filepro is wrong.
> 
> They implemented it.  As with anything else they release, they have the
> final say.  If they were going on votes from the community, I doubt a
> spelling checker would be going into 6.0k.
> 
> They're the Responsible Party.
> 
> I'll agree that there are undoubtedly many in the community who don't
> understand the import of what they wanted/asked for.

I begin to suspect that the item being discussed is no longer clearly
defined, here...

> > I do not see anything wrong with filePro's behavior.  It behaves 
> > according to specification.  How is that wrong?
> 
> When you want inward migration rather than outward migration, you do your
> best to conform to known standards where possible.  Most CS graduates these
> days would probably run shrieking in horror at the use and results of this
> operand on strings.  4GL's tend to make their own rules, granted.  But for
> a language that's borrowed extensively from others (I recognise parts of
> FORTRAN, personally), it never should have been diluted with this quirk.
> 
> If you start doing things that flat-out contradict accepted practises (or
> if you don't keep up with emerging practises), you tend to find an erosion
> of user-base when people say, "Well that makes NO sense.  Gee, neither does
> that.  As a matter of fact, a lot of this goes against known practise.
> Okay, enough wasting time--drop it and install Access."  Sad, but I've seen
> it happen.

Sad from filePro's point of view, perhaps... but that's the point here,
isn't it?

> > How can you hold filePro to a standard that was created, from scratch, 
> > after filepro was designed?  It is impossible to change the behavior of 
> > a package that was designed more than 25 years ago, to match a standard 
> > that has been determined since.  Think of the headaches that would cause.
> 
> "
>    C came into being in the years 1969-1973, in parallel with the early
>    development of the Unix operating system; the most creative period
> "
> 
> Do a Google search on "history of C" (without quotes) and it's one of the
> first two articles, if not the first one.
> 
> I believe Profile 1 was written later than that.  I've heard '78 most
> often in discussions. 

And it would have been running on... what?  :-)  Did the Model-1
release that far back?  Ghod, I'm getting old...

Cheers,
-- jra
-- 
Jay R. Ashworth                                                jra at baylink.com
Designer                          Baylink                             RFC 2100
Ashworth & Associates        The Things I Think                        '87 e24
St Petersburg FL USA      http://baylink.pitas.com             +1 727 647 1274

      "...the rough cannot be mean and the love cannot be true, and that's
      as wise as I can get at 10 o'clock in the morning."
      	-- Bill Shatner, on being an anti-hero.