OpenEuphoria

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