[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: User-defined Types



This approach, as Shriram points out, has been around for a long time.
I'd caution you not to think that what you list below is a complete
solution, however. Although the predicates tell you when something
fails, you also need to be able to say whose should be blamed for the
failure. It's pretty easy when dealing with functions on flat values,
but in object oriented languages and languages with higher-order
functions (or any other interesting construct) these become very
interesting questions. 

Eiffel is another language with these kinds of contracts (and iContract
is and adaptation of Eiffel to Java), if you're interesting in trying
out these ideas in your own systems. 

Also, DrScheme also has such a contract checker that supports
higher-order functions.

Robby

At Mon, 15 Jul 2002 21:56:38 +0200, "Herchenroeder, Thomas" wrote:
> I'd like to through in a thought about strong-typed languages and
> user-defined types. One problem I found with languages that require you to
> supply type declarations was that with user-defined types they never
> provided you with sufficient means to define *precisely* which values your
> new type should have.
> 
> There's another little language called Euphoria
> (http://www.RapidEuphoria.com/), that comes with a very convincing solution.
> Types are effectively single-argument, user-supplied functions, and take the
> form:
> 
> 	type <name>(<basetype> parm) <code> end type
> 
> where <code> must return a boolean value. So e.g. to define a new type
> "hour" you could say (from the doc,
> http://www.RapidEuphoria.com/refman_2.htm#43):
> 
>         type hour(integer x)
>             return x >= 0 and x <= 23
>         end type
> 
> For the <basetype>, you can fall back to "object", which matches any type.
> Any algorithm can be used to include or exclude values. This function will
> be called at runtime, whenever a variable of the type is assigned to or a
> parameter of that type is passed to a function, to check the value
> constraints are met. But this runtime check can be disabled. 
> 
> I think this is a wonderful solution, giving you maximum power to specify
> what your types should be like, in a generic and elegant manner.
> 
> =Thomas