OpenEuphoria

Re: Type-check behavior

• Posted by Roderick Jackson <rjackson at CSIWEB.COM> Mar 15, 1999
• 587 views

Boehme, Gabriel[SMTP:gboehme at MUSICLAND.COM] wrote:

>Maybe this is just me, but I think it's silly for Euphoria to do =
this...
>
> -- Example 1
>type string(sequence s) -- abend line
>   ...
>end type
>
>? string(5) -- abends w/ type-check fail @ "abend line" (argh!)
>            -- ideally, it would just print 0 here
> --

I think I agree here, this warrants a re-evaluation. I understand that =
Euphoria types are supposed to act like functions; but, this leads to =
the above situation when taken to it's extreme. After all, the above =
SHOULD return a 0. Doesn't it make since that if you use a type as a =
function to check an object, it should be able to respond TRUE or FALSE =
to that object, instead of aborting?

I know, I know, if we want to have it act that way, we should make all =
types accept objects and put the sub-type code within the type. But, if =
(in order to make types behave the way they SHOULD) we do that to all of =
our types, what's the point? Why even make (let?) programmers specify =
the "parameter" when it could lead to the above inconsistancy?

Rob, here's an idea; why not save us the hassle and inelegance of the =
above by having types be tokenized differently during the preprocessing =
stage? If for a particular type the programmer declares the parameter as =
anything other than "object", would it not solve everything to have the =
interpreter view that as an object parameter, but insert a check for the =
parameter type at the beginning of the type code? For example, the =
programmer types:

   type string (sequence s)
      -- the type code
   end type

but the interpreter automatically tokenizes it into

   type string (object s)
      if not sequence (s) then
         return 0
      end if
      -- the type code
   end type

It shouldn't slow things down much, if at all... the interpreter must =
already be doing the check. And it would save us the hassle from =
implementing things in a way so that types behave "correctly" as =
functions. I can't see a reason why anyone would NOT want this added as =
a feature--those who don't define their types to accept objects wouldn't =
even notice a change.

It has my vote.


Rod Jackson