OpenEuphoria

Re: 3.0.3

• Posted by Juergen Luethje <j.lue at gmx.de> May 13, 2007
• 736 views

CChris wrote:

> Juergen Luethje wrote:
> > 
> > CChris wrote:
> > 
> > <snip>
> > 
> > > PS for Pete: anyway, I'd expect boolean() to crash if fed a sequence, so
> > > my
> > > routine can indeed be used as a function. If you want a return of 0 for
> > > sequences, then indeed it is not suitable.
> > 
> > So you can use it yourself as a function, because it works like you expect.
> > However, I think about 99% of the Euphoria programmers expect a type when
> > used as function _not_ to crash, but to return either TRUE or FALSE.
> > 
> > Regards,
> >    Juergen
> 
> Are you sure?

Yes, I am.

> It depends on the context, in my view, as an atom may be a
> boolean and a sequence never can.

Sure. And therefore the following code

[Definition of a type 'boolean']

sequence s
s = {}           -- or whatever else
? boolean(s)

should print 0 (FALSE) -- but it should not crash.
It should never crash, regardless of the context.
Only the result of the type function depends on the
context, i.e. on its argument.
I never would expect a tool for checking something
to crash deliberately -- it should work properly and
tell me the result of the check.

The following code snippet is copied from the
documentation of gets():

sequence buffer
object line
integer fn

-- read a text file into a sequence
fn = open("myfile.txt", "r")
if fn = -1 then
   puts(1, "Couldn't open myfile.txt\n")
   abort(1)
end if

buffer = {}
while 1 do
   line = gets(fn)
   if atom(line) then
      exit    -- -1 is returned at end of file
   end if
   buffer = append(buffer, line)
end while

I believe code like this is well known and often used
by many Eu programmers. The built-in type-check function
atom() does not crash when 'line' isn't an atom, it just
returns 0, as probably everyone would expect. And I think
most Eu coders would expect user-defined types to work
according to the same principle.

> This is why the argument type for a type
> is not "object" by default,

This is correct. It is not "object" by default, because
there is no default for it at all.
In all my type functions, I use "object" as argument type.
And I recommend everyone to do so, who wants to write code
which should follow the "principle of least surprise".

> which your comment would imply.
> 
> At any rate it is easy to conform to that no crash policy:
> }}}
<eucode>
> global constant FALSE = 1=0
>                ,TRUE = not FALSE
> 
> global type boolean(object x)
> integer y
> y=not compare(x, TRUE) -- y is TRUE iff x is, otherwise it is FALSE
> return not compare(x, y)
> end type
> </eucode>
{{{

> I'm afraid it would slow things down a little. Any benchmarks?

After having tested my code, I write at the beginning

without type_check

and only then I do benchmarking. So I don't know why it is so
important to save some microseconds in the user-defined type
boolean(). Am I missing something here?

Regards,
   Juergen