Well Gisle...

> -----Original Message-----
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, April 04, 2000 11:15 AM
> 
> One thing that bothers me is that I can't specify a return type for
> functions in REBOL. Many people consider this to be a bad idea so I'm
> wondering what the idea behind this is.
> 
> There are obviously advantages and disadvantages with this, but do the
> advantages really outweigh the disadvantages?

This question can be answered 3 ways, from the perspective of REBOL
in particular, of functional languages, and in general.

REBOL is currently an interpreted language. This means that all of
the various language processing, including type-checking, is done at
runtime. Under these circumstances, type-checking is a luxury, only
done to catch errors. Since any errors in the function return type
are localized to the function, there are often more efficient ways
to deal with them than declarative type-checking. Regardless, these
types of errors should be handled within the function before return;
any error that results from the return itself would need handling by
the caller of the function.

For functional languages in general, strong typing is typically done
a little differently than in procedural languages. Although function
parameters are typed, function return types are usually determined
by inference. Type inference allows strong typing without requiring
the programmer to specify return types that the compiler is perfectly
capable of figuring out for itself. REBOL already lets you specify
enough information to perform type inference, but it currently doesn't
do type inference because of the runtime overhead this would cause in
an interpreter. A type inferencer for REBOL would be possible to do,
but would be a better preliminary testing tool than a runtime tester.

In general, declarative type checking only makes sense when the types
are checked before runtime. Runtime checking should only be done by
code that can recover from any errors, and usually close to the source
of the error (in the function) rather than distributed all over the
place in calling functions. An exception to this is functions that
primarily run code passed to them (language functions like foreach),
which should handle any errors internal to the function, but pass on
ones caused by the code passed to them. None of these cases are helped
by declarative return type checking.

Does this make any sense?
Brian

Reply via email to