1. Bug report
Robert, your definition as to where short-circuiting applies is:
" Whenever the interpreter can be sure a TRUE/FALSE is the wanted result "
Or something simerlar. Anyways, IMHO this includes type check's.
However, after 4 hours of bug-chasing it was brought to my attention, that the
only thing wrong with my code is that its type
check function returned a sequence.
I want to use the oppertunity, to point out 3 problems:
(-) Bugs with short-circuiting are hard to find. I have said that before, but
the general opinion was that they should be
added. And I gave up on the discussion. Now its too late I guess.
(-) Returning a sequence in a type check function should generate a special
error message like:
" You are only allowed to return boolean values from type check functions "
(-) Short-circuiting should always be the case when using a type-check function
in an expression. Type check functions generate
non-recursive boolean values, which should simply not be mixed with recursive
boolean values. I can not see any case, where this
would be the wanted behaviour.
My code (an example of the problem-code is at the end of this mail) would work
if either the return statements of type check
functions would 'short-circuit' or when expressions involving type check
functions would be 'short-circuited'.
Off course i have the opinion both cases should be short-circuiting (or no cases
at all, but I wont enter that discussion
again), but the current situation is messy, unclear and inconsistent.
Code that shows the problem:
type one (object i)
return equal (i, "Euphoria")
end type
type two (object i)
return (integer (i) and i >= 0) or one (i)
end type
type three (object i)
return two (i)
end type
three var_x
one var_y
var_y = "Euphoria"
var_x = var_y
-- Crash!!
-- Type check failure: var_x = { 69, .. }
I hope this is fixed before the final release of Euphoria 2.1
Ralf Nieuwenhuijsen
.... Mailto://nieuwen at xs4all.nl
.... Http://www.xs4all.nl/~nieuwen
.... Uin://9389920
2. Re: Bug report
First of all. I haven't done a close examination but don't you want?
type two (object i)
return one (i) or (integer (i) and i >= 0)
end type
and Second. You are right. that is a bug.
Your arrangement of:
return (integer (i) and i >= 0) or one (i)
should have skipped and i>=0 because integer(i) is clearly False.
It can't possibley be (integer(i) and i >= 0) because it isn't
an integer. I do suggest trying my reverse and see if it works.
I don't have v2.1 as of yet. I'm not brave enough to leave my
registered v2.0 behind. :) I like having my over 300 Statements.
I will eventually get v2.1. Well maybe. I might wait until the
next version, Whatever it happens to be.
Lucius L. Hilley III
--This is Shareware. If you feel this message helps in any way
--please send your $0.02 worth. :)
On Sat, 20 Feb 1999 13:13:36 +0100, Ralf Nieuwenhuijsen <nieuwen at XS4ALL.NL>
wrote:
>Robert, your definition as to where short-circuiting applies is:
> " Whenever the interpreter can be sure a TRUE/FALSE is the wanted result "
>
>Or something simerlar. Anyways, IMHO this includes type check's.
>However, after 4 hours of bug-chasing it was brought to my attention, that the
>only thing wrong with my code is that its type
>check function returned a sequence.
>
>I want to use the oppertunity, to point out 3 problems:
>
>(-) Bugs with short-circuiting are hard to find. I have said that before, but
>the general opinion was that they should be
>added. And I gave up on the discussion. Now its too late I guess.
>
>(-) Returning a sequence in a type check function should generate a special
>error message like:
>" You are only allowed to return boolean values from type check functions "
>
>(-) Short-circuiting should always be the case when using a type-check function
>in an expression. Type check functions generate
>non-recursive boolean values, which should simply not be mixed with recursive
>boolean values. I can not see any case, where this
>would be the wanted behaviour.
>
>My code (an example of the problem-code is at the end of this mail) would work
>if either the return statements of type check
>functions would 'short-circuit' or when expressions involving type check
>functions would be 'short-circuited'.
>
>Off course i have the opinion both cases should be short-circuiting (or no
>cases at all, but I wont enter that discussion
>again), but the current situation is messy, unclear and inconsistent.
>
>Code that shows the problem:
>
>type one (object i)
> return equal (i, "Euphoria")
>end type
>
>type two (object i)
> return (integer (i) and i >= 0) or one (i)
>end type
>
>type three (object i)
> return two (i)
>end type
>
>
>three var_x
>one var_y
>var_y = "Euphoria"
>var_x = var_y
>
>-- Crash!!
>-- Type check failure: var_x = { 69, .. }
>
>I hope this is fixed before the final release of Euphoria 2.1
>
>Ralf Nieuwenhuijsen
>.... Mailto://nieuwen at xs4all.nl
>.... Http://www.xs4all.nl/~nieuwen
>.... Uin://9389920
3. Re: Bug report
- Posted by Robert Craig <rds at ATTCANADA.NET>
Feb 20, 1999
-
Last edited Feb 21, 1999
Ralf writes:
> Robert, your definition as to where short-circuiting applies is:
> "Whenever the interpreter can be sure a TRUE/FALSE is the wanted
> result "
No. The definition is "in if, elsif and while conditions only".
> (-) Short-circuiting should always be the case when using
> a type-check function in an expression. Type check functions
> generate non-recursive boolean values, which should simply
> not be mixed with recursive boolean values. I can not see
> any case, where this would be the wanted behaviour.
Unfortunately, the rule can't be "short-circuiting applies everywhere",
so I tried to keep it simple. There are other cases where
short-circuiting might legitimately be applied (because you know
that an atom is the intended result), but I did not want to
have a rule like "short-circuiting may be used on Wednesday
and Friday afternoons, between the hours of 2pm and 4pm,
during August and December, and also March if it's
a leap year, but not the year 2000 and..." 
> (-) Returning a sequence in a type check function should generate
> a special error message like:
> " You are only allowed to return boolean values from
> type check functions "
OK, I'll issue a better error message in this case.
Right now if a type returns a sequence during a type check,
it is simply treated as "false" and the standard type_check
error is printed.
The manual says a type function "should" return an atom (true or false).
I don't want to perform an extra test on all calls to all
types to enforce this. I'll just change the error message when a
type_check failure occurs due to a sequence being returned.
Calling a type as a normal function won't be checked.
Regards,
Rob Craig
Rapid Deployment Software
http://members.aol.com/FilesEu/
4. Bug report
\\\|/////
\\ - - //
( @ @ )
printf(1, "%02d, %02.2f\n", {3, 3.14})
the output should be:
03, 03.14
but in 2.0 beta you get
03, 3.14
Robert, Please squash him.
----------------------------------------------------------
-- Lucius L. Hilley III -- lhilley at cdc.net --
-- of -- --
-- Hollow Horse Software -- http://www.cdc.net/~lhilley --
--------------Oooo----------------------------------------
oooO ( )
( ) ) /
\ ( (_/
\_)
5. Re: Bug report
Lucius L. Hilley III writes:
> printf(1, "%02d, %02.2f\n", {3, 3.14})
> the output should be:
> 03, 03.14
> but in 2.0 beta you get
> 03, 3.14
The problem here is that %02.2f asks for
a total field width of 2, with 2 decimal places,
as well as leading 0's to fill up the field width.
This is impossible, so printf()
tries to make the best of the situation, by enlarging
the field width to 4, so you won't lose any significant digits.
However it decides not to add any leading 0's, since
you are already over the maximum field width that
you asked for.
All you have to do is pick a more reasonable field width,
such as 5. e.g.
printf(1, "%02d, %05.2f\n", {3, 3.14})
will do what you want. You are now allowing a total width
of 5, which will give you 5 characters: 03.14
Regards,
Rob Craig
Rapid Deployment Software
