Re: ESL Master Include File
Pete Lomax wrote:
>
> On Mon, 25 Jul 2005 19:24:24 -0700, Derek Parnell
> <guest at RapidEuphoria.com> wrote:
>
> >Pete Lomax wrote:
> >
> >[snip]
> >> Despite the highly unlikely chance
> >> of such things, some libraries actually do define TRUE=(1=1) and
> >> FALSE=(1=0).
> >
> >That would be me 
> >
> >> There is nothing wrong with using tri-logic with say isTLtrue=1,
> >> isTLunknown=0, and isTLfalse=-1, (though isTLfalse=0, and
> >> isTLunknown=-1 would probably be just as effective) but
> >> defining FALSE as -1 is just brain-dead stupidity.
> >
> >Why? The only requirement is that TRUE and FALSE have different values from
> >each other.
>
> What about code readability? In the following example, if the
> commented out lines are used instead of the line after them, it
> functions exactly the same:
> }}}
<eucode>
> constant FALSE=-1, TRUE=1
>
> function e(integer a, integer b)
> -- integer-only version of equal()
> -- return a=b
> if a=b then return TRUE else return FALSE end if
> end function
>
> -- if e(1,1)=TRUE then
> if e(1,1) then
> -- because TRUE was defined sensibly, this happens
> puts(1,"1 is equal to 1\n")
> else
> puts(1,"1 is NOT equal to 1\n")
> end if
>
> -- if e(1,0)=FALSE then
> if not e(1,0) then
> puts(1,"1 is not equal to 0\n")
> else
> -- because FALSE was defined wrong, this happens.
> puts(1,"1 is !!EQUAL!! to 0\n")
> end if
> <font color="#330033"></eucode>
{{{
</font>
I know its just my inability to explain myself clearly, but you have totally
missed my point.
If the function 'e()' returned either TRUE or FALSE, then it is wrong to code
'if e(1,1) then' because the syntax 'if expr then' is shorthand for 'if expr != 0
then', which you can see is not the same as 'if e(1,1) = TRUE then'
> > One could have ...
> >
> >constant TRUE = 't',
> > FALSE = 'f'
> >
> .. And one could have
> constant TRUE = {"banana","grandmother","waspsting"},
> FALSE = not TRUE
Exactly! Now you're getting it.
> >And all code that relied on using TRUE and FALSE would still work.
> Possibly,
No, not 'possibly' but *certainly* .
>but there is certainly a much higher potential for error.
Huh? There is just as much error as testing for the wrong return values of any
function.
> The example above works if you consistently use TRUE=1 and FALSE=-1,
Yes. Exactly.
> but shows how easy it would be to slip and fall.
But this argument applies to every function and expression.
> If you are going to have a global constant, it must adhere to the
> principle of least astonishment.
Exactly. If a function can only return either TRUE or FALSE, then its stupid to
test the return value against anything else.
> Presumably, by the warped logic occurring in this thread, if
> constant EOF="the end" is defined then getc() should analyse
> the program source, figure out what it is going to be tested
> against, and return -1 or "the end" appropriately? Maybe the same
> could be said for equal() and FALSE. I am being silly, of course.
Yes, you are. Why change getc()? If EOF was defined and *other* functions were
defined to return this, then that's what the caller would test for.
> >BTW, and I'm sure you already know this, but there are plenty of languages
> >that implement TRUE
> as -1 instead of 1.</font></i>
> And it would be equally wrong in such languages to define a global
> constant of TRUE as +1.
I think you are confusing built-in stuff with user-written stuff. If one wants
TRUE and FALSE to be the exact same values as Euphoria's built-in value then they
should be assigned thus ...
constant TRUE = (1=1)
constant FALSE = (1=0)
But if you are not trying to do that, then so long as they are not the same as
each other, the values can be anything at all.
But I fear that I'm too far to the left for most people, so just forget that I
even broke wind.
--
Derek Parnell
Melbourne, Australia
Skype name: derek.j.parnell
|
Not Categorized, Please Help
|
|
