[curry] Re: How to interpret a data type with no RHS

From: Wolfgang Lux <wolfgang.lux_at_gmail.com>
Date: Mon, 27 May 2019 09:49:44 +0200

Hi Andy,

> I can define an empty data type in Curry, e.g.:
> data A
> The built-in types such as Char, Int and Float are defined this way in the Prelude. Prior to the introduction of typeclasses the Curry frontend would translate this to a FlatCurry Type with no constructors. Newer versions produce a type with one constructor named “_Constr#A”.
> I’d like to understand how to interpret this. Is the above legal Curry? Is this perhaps a forward declaration or opaque type? Can the type, A, be defined later? If so, would it have to be defined in the same module? Is this documented somewhere?
> I’m tempted to reject such a declaration unless the system can find a built-in definition but I don’t want to reject legal programs.

data type declarations with an empty right hand side are mentioned in the language report as representing external data types.
Literally, a data type with no right hand side just represents the uninhabitated type, i.e., a type that has no values. This type is not very useful on itself, but may have some uses in some cornerstone cases as a base type in some libraries. The fact that the user/compiler cannot create values of such a type makes data types without a right hand side an obvious representation for abstract types, whose concrete representation is not available to the compiler. So, unless you plan to not provide an interface to external code I think you should support such types.
With the reasoning above the translation of such types into a type with a single constructor on the right hand side feels outright wrong to me, as the type would become equivalent to the unit type () (unless the constructor also has some arguments), but maybe Michael will shed some light on this.

curry mailing list -- curry_at_lists.rwth-aachen.de
To unsubscribe send an email to curry-leave_at_lists.rwth-aachen.de
Received on Mo Mai 27 2019 - 15:11:54 CEST

This archive was generated by hypermail 2.3.0 : Mi Aug 05 2020 - 07:15:04 CEST