does anyone have a shorter name for a "algebraic data type" --the thing that is created by the declaration beginning with the keyword "data"? "ADT" is already in use, meaning "abstract data type", in many textbooks like Essentials of Programming Languages. the best I could come up with is "SPT", short for "sum-of-products" type.
They remind me of union types, as in C (IIRC - I never used them), for what little that's worth. -- Mark
Richard wrote (on 28-08-01 13:38 -0700):
does anyone have a shorter name for a "algebraic data type" --the thing that is created by the declaration beginning with the keyword "data"?
"ADT" is already in use, meaning "abstract data type", in many textbooks like Essentials of Programming Languages.
I have seen ADT used with both meanings.
the best I could come up with is "SPT", short for "sum-of-products" type.
Lots of people just say "datatype", to contrast with simply "type". Other terms are "inductive datatype" and "recursive datatype", and there are other terms which are longer, but I don't know of any shorter ones except "ADT". Maybe "initial algebra". You could also say "signature", though that is not quite the same thing (signatures _induce_ datatypes). -- Frank Atanassow, Information & Computing Sciences, Utrecht University Padualaan 14, PO Box 80.089, 3508 TB Utrecht, Netherlands Tel +31 (030) 253-3261 Fax +31 (030) 251-379
Hello! On Tue, Aug 28, 2001 at 03:44:26PM -0500, Mark Carroll wrote:
They remind me of union types, as in C (IIRC - I never used them), for what little that's worth.
No. C-unions are untagged and thus, not really type safe. Haskell's sum types *are* tagged and thus quite safe (except for incomplete pattern matches which may cause some evaluation to diverge). Kind regards, Hannah.
On Wed, 29 Aug 2001, Hannah Schroeter wrote: (snip)
On Tue, Aug 28, 2001 at 03:44:26PM -0500, Mark Carroll wrote:
They remind me of union types, as in C (IIRC - I never used them), for what little that's worth.
No. C-unions are untagged and thus, not really type safe. Haskell's sum types *are* tagged and thus quite safe (except for incomplete pattern matches which may cause some evaluation to diverge).
I only said they reminded me of them, and C was just an example of where I'd seen such things! (-: I can imagine that the term "union types" connote something confusingly wrong, but I'd hardly imagine that the type safety issue would be it, given that in Haskell one can largely take type safety for granted - nowhere did I intend to say that Haskell's algebraic types behave exactly as C's union types do! In the same way, I don't think it's unreasonable for many languages to have floats and integers and whatnot even though they tend to treat them subtly differently (in how they approach with 0/0, overflows, etc.), I'm not meaning to be defensive - I don't care what shorter term someone uses for such types - I just wanted to express the idea that I find the being tagged or not as an implementation detail that isn't the first thing I think of with union types - instead, I more or less think of why they're named - the thing's possible types are a union of a few types - and that I'm surprised that others strongly associate the lack of tagging with this concept. I'll have to watch out for that in future. -- Mark
participants (5)
-
Frank Atanassow -
Hannah Schroeter -
Mark Carroll -
Richard -
Tom Pledger