1. ESL Master Include File
How about this ... the booleans 'true' and 'false' in 'types.e' are the
kind of thing that almost all ESL modules might need and I'm pretty sure
there will be other 'universal features' as well, as we go along.
I would propose a 'master' include file for all esl modules, which would
make it easier for all coders to work within some common infrastructure.
This would also make it possible to have global constants and types that
are associated generally with the ESL, such as ESL_VERSION_NUMBER and
ESL_VERSION_DATE and later, even things related to documentation and error
handling that might also need to be common to all ESL modules.
Even if, for example, we decided at some point to introduce a
sophisticated error handling system, this could still be coded as a
separate module 'error.e' but 'included' in 'esl.e'. This would cut
down on the number of modules that coders would have to remember to
include for the basic features of the ESL that will be common to almost
all modules.
Gordon
2. Re: ESL Master Include File
Gordon Webster wrote:
>
>
> How about this ... the booleans 'true' and 'false' in 'types.e' are the
> kind of thing that almost all ESL modules might need and I'm pretty sure
> there will be other 'universal features' as well, as we go along.
>
> I would propose a 'master' include file for all esl modules, which would
> make it easier for all coders to work within some common infrastructure.
> This would also make it possible to have global constants and types that
> are associated generally with the ESL, such as ESL_VERSION_NUMBER and
> ESL_VERSION_DATE and later, even things related to documentation and error
> handling that might also need to be common to all ESL modules.
>
> Even if, for example, we decided at some point to introduce a
> sophisticated error handling system, this could still be coded as a
> separate module 'error.e' but 'included' in 'esl.e'. This would cut
> down on the number of modules that coders would have to remember to
> include for the basic features of the ESL that will be common to almost
> all modules.
>
> Gordon
>
An ESL master file could be very useful but I don't see anything more than
ESL_VERSION being in the file and even then how useful would they be? TRUE and
FALSE should *not* be in the file simply because in some applications the
programmer might want to make FALSE = -1 (I've done this in a few programs I've
written). Typically, unless they absolutely need to, Library coders should not
include other Library files into theirs. Some cases like, say, 3d_math.e
including math.e could be permissible but since it's easy in Euphoria to create
namespace clashes this could make more problems for the programmer using the
Library as well as others maintaining it. Another issue is if a Library file gets
changed and it breaks another file that was using it (ex. math.e gets an
efficiency overhaul and 3d_math.e no longer works).
3. Re: ESL Master Include File
On Mon, 25 Jul 2005 12:17:40 -0700, "D. Newhall"
<guest at RapidEuphoria.com> wrote:
>the programmer might want to make FALSE = -1
such programmers should be shot on sight.
Pete
4. Re: ESL Master Include File
- Posted by D. Newhall <derek_newhall at yahoo.com>
Jul 25, 2005
-
Last edited Jul 26, 2005
Pete Lomax wrote:
>
> On Mon, 25 Jul 2005 12:17:40 -0700, "D. Newhall"
> <guest at RapidEuphoria.com> wrote:
>
> >the programmer might want to make FALSE = -1
> such programmers should be shot on sight.
>
> Pete
Arguably, but is that not one of the primary uses of constants? If Rob decided
to change the end-of-file designator from -1 to 0 then all the code written that
uses -1 hardcoded in all the checks for end-of-file would have to be searched and
then tested to make sure that the -1 check in the main loop wasn't for something
else. However, if the coder used a constant named EOF or something to represet
the end-of-file designator then all they'd have to change would be the line that
says "constant EOF = -1" to "constant EOF = 0".
I've used a constant named FALSE that was set to -1 in a file before. It was a
logical inference tool that used 1 for TRUE, 0 for UNDEF, and 0 for FALSE.
5. Re: ESL Master Include File
On Mon, 25 Jul 2005 13:36:14 -0700, "D. Newhall"
<guest at RapidEuphoria.com> wrote:
>Pete Lomax wrote:
>>
>> >the programmer might want to make FALSE = -1
>> such programmers should be shot on sight.
>>
>> Pete
>
>Arguably,
There is no "Arguably" about it at all.
If you cannot see the fundamental difference between an arbitrary
end of file designator and the functional implications of TRUE and
FALSE then I can feel nothing but pity and contempt for you.
It may be that constant EOF=-1 makes code easier to read and
I guess would make it easier to change if the highly unlikely
occurred and Rob changed it. Despite the highly unlikely chance
of such things, some libraries actually do define TRUE=(1=1) and
FALSE=(1=0).
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.
(I note that you wrote UNDEF=0 and FALSE=0, somewhat proving my point,
although of course I accept [hope?] it was just a minor typo.)
Pete
6. Re: ESL Master Include File
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. One could have ...
constant TRUE = 't',
FALSE = 'f'
And all code that relied on using TRUE and FALSE would still work. One's code
should never be doing arithetic on boolean values and never doing relative
comparisions either (less than, greater than). Instead one's code should only be
doing assignments and equality tests.
BTW, and I'm sure you already know this, but there are plenty of languages that
implement TRUE as -1 instead of 1.
--
Derek Parnell
Melbourne, Australia
Skype name: derek.j.parnell
7. Re: ESL Master Include File
Derek Parnell 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. One could have ...
>
> constant TRUE = 't',
> FALSE = 'f'
>
> And all code that relied on using TRUE and FALSE would still work.
> One's code should never be doing arithetic on boolean values and never
> doing relative comparisions either (less than, greater than). Instead
> one's code should only be doing assignments and equality tests.
What about boolean operations such as 'not'?
constant
FALSE = 0,
TRUE = 1
? TRUE = not FALSE -- prints 1 (which equals TRUE here) -> correct
constant
FALSE = -1,
TRUE = 1
? TRUE = not FALSE -- prints 0 (which is not a boolean value here!)
constant
FALSE = 'f',
TRUE = 't'
? TRUE = not FALSE -- prints 0 (which is not a boolean value here!)
> BTW, and I'm sure you already know this, but there are plenty of
> languages that implement TRUE as -1 instead of 1.
Then hopefully the boolean operators in these languages work
consistently, so that always
not FALSE = TRUE
not TRUE = FALSE
FALSE xor TRUE = TRUE
etc.
Regards,
Juergen
8. Re: ESL Master Include File
Juergen Luethje wrote:
>
> Derek Parnell 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. One could have ...
> >
> > constant TRUE = 't',
> > FALSE = 'f'
> >
> > And all code that relied on using TRUE and FALSE would still work.
> > One's code should never be doing arithetic on boolean values and never
> > doing relative comparisions either (less than, greater than). Instead
> > one's code should only be doing assignments and equality tests.
>
> What about boolean operations such as 'not'?
LOL...Thanks Juergen, I forgot about the obvious ones : not, and, or, xor.
> }}}
<eucode>
> constant
> FALSE = 0,
> TRUE = 1
>
> ? TRUE = not FALSE -- prints 1 (which equals TRUE here) -> correct
> <font color="#330033"></eucode>
{{{
</font>
This is because 'not' is built into Euphoria and it assumes that FALSE is zero
and TRUE is 1. If we could define a replacement functions, they would go
something like ...
function not(boolean A)
if A = TRUE then
return FALSE
else
return TRUE
end if
end function
function and(boolean A, boolean B)
if A = TRUE and B = TRUE then
return TRUE
else
return FALSE
end if
end function
function or(boolean A, boolean B)
if A = TRUE or B = TRUE then
return TRUE
end if
return FALSE
end function
function xor(boolean A, boolean B)
if A = B then
return FALSE
end if
return TRUE
end function
Of course, this is grossly inefficient but that's just an implementation detail,
the principle theory still applies.
>
> > BTW, and I'm sure you already know this, but there are plenty of
> > languages that implement TRUE as -1 instead of 1.
>
> Then hopefully the boolean operators in these languages work
> consistently, so that always
> not FALSE = TRUE
> not TRUE = FALSE
> FALSE xor TRUE = TRUE
> etc.
Of course. They also have built-in 'not', 'and', 'or' and 'xor' boolean
operations.
--
Derek Parnell
Melbourne, Australia
Skype name: derek.j.parnell
9. Re: ESL Master Include File
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:
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
> One could have ...
>
>constant TRUE = 't',
> FALSE = 'f'
>
.. And one could have
constant TRUE = {"banana","grandmother","waspsting"},
FALSE = not TRUE
>And all code that relied on using TRUE and FALSE would still work.
Possibly, but there is certainly a much higher potential for error.
The example above works if you consistently use TRUE=1 and FALSE=-1,
but shows how easy it would be to slip and fall.
If you are going to have a global constant, it must adhere to the
principle of least astonishment.
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.
>BTW, and I'm sure you already know this, but there are plenty of languages that
>implement TRUE as -1 instead of 1.
And it would be equally wrong in such languages to define a global
constant of TRUE as +1.
Regards,
Pete
10. Re: ESL Master Include File
Pete Lomax wrote:
>
> Derek Parnell wrote:
>
> > One could have ...
> >
> >constant TRUE = 't',
> > FALSE = 'f'
> >
> .. And one could have
> constant TRUE = {"banana","grandmother","waspsting"},
> FALSE = not TRUE
>
LOL. Pete, you're on a roll in this thread... :)
Matt Lewis
11. 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
12. Re: ESL Master Include File
I have to say that I agree with Derek 100% here.
Definitions of both TRUE and FALSE should be done as (1=1) and (1=0) so that
they can match the language calculated values, else you end up with a
proliferation of varying values for what people think true and false should mean
- which is a crazy and very stupid situation to get into.
Eg. Language BibbleSplat equates a truth value to "Oink,Oink" and all the
internal functions have built in Assembler checking for that value to be a true
value. The user then tries to use those built-in language functions compaing
against a value of -99999 (which they have defined in a variable called TRUE
within their library code); then, strangely enough, those functions will not work
for them! Whereas if the user does not try to DEFINE the VALUE of true to
anything, but accepts what the language gives them, then they should have no
problems. [Obviously this is a ficticious example, 'cos the BibbleSplat language
has not been released yet!!!]
Derek Parnell wrote:
>
<snip>
> 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.
> > 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.
Can't do that, the cloud has already reached Thailand ;)
> --
> Derek Parnell
> Melbourne, Australia
> Skype name: derek.j.parnell
>
Cheers,
Dave
. .. : :: = == == = :: : .. .
Server-Side DB driven web sites,
Software Development
(and part-time games developer)
contact dave_p at purpletiger dot com
or probert.dave at gmail dot com
. .. : :: = == == = :: : .. .
13. Re: ESL Master Include File
- Posted by Pete Lomax <petelomax at blueyonder.co.uk>
Jul 26, 2005
-
Last edited Jul 27, 2005
On Tue, 26 Jul 2005 06:34:22 -0700, Derek Parnell
<guest at RapidEuphoria.com> wrote:
>If the function 'e()' returned either TRUE or FALSE, then it is wrong to code
>'if e(1,1) then'
Many win32lib functions return w32True or w32False and ARE used in
exactly this manner (eg isTopLevelWindow). If I see a function returns
TRUE or FALSE, then I WILL assume I can use the result in a condition.
Sure, w32True and w32False are defined correctly, so this is not an
issue in win32lib.
>Huh? There is just as much error as testing for the wrong return values of any
>function.
There *IS* a much higher potential for the obvious mis-assumption.
>I know its just my inability to explain myself clearly,
>But I fear that I'm too far to the left for most people,
Don't start that nonsense either.
The difference of opinion here is probably that you are stating
something which can be shown to work and is therefore theoretically
and technically "tolerable", whereas I am stating that such code is
nothing short of wilfully misleading, and therefore, I claim, wrong.
Regards,
Pete
14. Re: ESL Master Include File
On Tue, 26 Jul 2005 11:15:56 -0700, Dave Probert
<guest at RapidEuphoria.com> wrote:
>I have to say that I agree with Derek 100% here.
Sorry, but it was unclear from the remainder of your post. Are you
also agreeing with Derek that it is sensible to define TRUE as 't'?
Pete
15. Re: ESL Master Include File
Pete Lomax wrote:
>
> On Tue, 26 Jul 2005 06:34:22 -0700, Derek Parnell
> <guest at RapidEuphoria.com> wrote:
>
> >If the function 'e()' returned either TRUE or FALSE, then it is wrong to code
> >'if e(1,1) then'
> </font></i>
> Many win32lib functions return w32True or w32False and ARE used in
> exactly this manner (eg isTopLevelWindow).
Thanks for pointing out these bugs. I'll fix them in due course.
> If I see a function returns
> TRUE or FALSE, then I WILL assume I can use the result in a condition.
Not a safe assumption.
> Sure, w32True and w32False are defined correctly, so this is not an
> issue in win32lib.
>
> >Huh? There is just as much error as testing for the wrong return values of
> >any function.
> There *IS* a much higher potential for the obvious mis-assumption.
'Assumption' strikes again.
> >I know its just my inability to explain myself clearly,
> >But I fear that I'm too far to the left for most people,
> Don't start that nonsense either.
What singing fat lady?
--
Derek Parnell
Melbourne, Australia
Skype name: derek.j.parnell
