1. Bug in types..
- Posted by Ralf Nieuwenhuijsen <nieuwen at XS4ALL.NL> Apr 26, 1998
- 504 views
I would like to mention this "bug", however it is more an inconsistency of Euphoria. --= Euphoria code =-- if atom ( "TEXT" ) then puts(1, "It seems /"TEXT/" is an atom\n") end if type pos_int (integer i) return i > 0 end type if pos_int ( "TEXT" ) then puts(1, "It seems /"TEXT/" is an positive integer\n") end if --= End of Code =-- This program will crash, unless you change the type definition to: --= Code =-- type pos_int (object i) if integer(i) then return i > 0 else return 0 end if --return integer (i) and i > 0-- doesn't work either! end type --= Code =-- I consider this to be very inconsistent and very unclear. There are a couple of options available to solve this: 1) Do not allow the argument of a type to be declared other than 'object'. You could also have 'object' as default, that is, people are not allowed to say what type it is, not even 'object', but I consider this to be more confusing for newcomers. 2) Change the complete grammer of a type definition, for example: --= Code =-- type pos_int as i do if integer (i) then return i > 0 else return 0 end if end type --= Code =-- 3) Do not break the program with an error when a type is checked, either assume 0 (user-defined type lookup) or crash with an type failure (it does crash with a type failure, but with the wrong type failure!). This means program declaring "integer i" suddenly also work, when we check a type ourselves. Answer ~~~~~~~~~ Well, solution 2 looks the best, it would break lots of code, or confuse the newcomers with 2 different type declarations. Solution 3 would only make old code work even better, but can be a bit confusing too, because of the resemblance with a function declaration. But something *has* to be done, about this, it would not be another bell or whistle, it would be a bug-fix. Whatever you do, at least point this inconsitence out in the documentation, so people don't fall over it. And in which case, it would mean people have to learn less with solution 2) or 3) than with the present situation. So lets get rid of this ugly whistle! (before we add another.. Ralf Nieuwenhuijsen nieuwen at xs4all.nl
2. Re: Bug in types..
- Posted by Robert Craig <rds at EMAIL.MSN.COM> Apr 26, 1998
- 500 views
Ralf writes regarding type checking: > type pos_int (integer i) > return i > 0 > end type > But something *has* to be done, about this, it > would not be another bell or whistle, it would be a bug-fix. > Whatever you do, at least point this inconsitence out in the > documentation, so people don't fall over it. I understand what you are saying. I think you mentioned this before. I will at least document the situation. I've often thought that I should give a better error message when i (above) is not an integer, i.e. something that would clearly indicate the variable-assignment that triggered the type check failure. Right now you only get that if the type function returns 0, rather than failing on the integer type check. If the type function failed in some unexpected way, due to a real bug, I think you'd still like it to appear at the top of the trace back. Regards, Rob Craig Rapid Deployment Software