Re: relations aren't types?

John Jacob <jingleheimerschmitt_at_hotmail.com> schrieb:
>> Of the "types of values" you list, some are (usually) type classes or
>> abstract data types (bag, set, collection), while others are just plain
>> polymorphic types (relation, list).
>
> I don't know what you mean by polymorphic types. If you mean that
> they can contain values of different types, then why are bag, set, and
> collection not polymorphic types. I'm sorry, I don't know what you
> mean by this.

Foldoc to the rescue:
http://foldoc.doc.ic.ac.uk/foldoc/foldoc.cgi?query=polymorphism

I say Collection is a type class because many different types can be used AS collections. But on second though I'm probably wrong about Bag and Set since these do have specific restrictions on the data they can hold, so you're right, they are also just polymorphic types.

>> Normally I'd consider atomic types provided by the system, like Char or
>> Int, to be scalar types. What confuses me is:
>> 1. that you claim that tuples (an algebraic datatype) are scalar but
>> lists (also an algebraic datatype) aren't, and
> Tuples are not scalar.

But records (like the two you user-defined "scalars" you mentioned earlier) are? Since records and tuples are isomorphic I don't understand this.

>> 2. that you want to be able to create new "scalar" types but using a
>> different syntax for them than for other algebraic datatypes.
> I don't know what an algebraic type is as opposed to a non-algebraic
> type.

Here's a pretty good description at foldoc (though a google search wasn't very helpful):
http://foldoc.doc.ic.ac.uk/foldoc/foldoc.cgi?query=algebraic+datatype

> I do, however want to use different syntax to define new scalar types,
> just as I would want different syntax to define tuple types, and
> different syntax to define relation types. In general, if a language
> supports a specific category of type, then it should have different
> syntax for dealing with values of those types. For example, C# has a
> different type generator for classes than for enums.

Personally I think extra syntax obscures or even inhibits opportunities for generalization. Sugar can be provided for common type constructors, like lists and records, but these can be trivially transformed into the prefix notation of user-defined types so it's ok. I definitely can't take C# seriously as an example of a good type-definition syntax.

>> I have no idea what "logical structure" is, but it almost sounds like
>> abstract datatypes are scalar but concrete datatypes aren't?
>
> For me, the simplest explanation (the one where I finally understood
> the difference) is that if the type specifier describes the structure
> of values of the type, that is logical structure. A relation type
> specifier exposes the attributes of relation values of that type
> (relation { ID : Integer }). An array type specifier exposes the type
> of the elements that values of that type contain (array[Integer]). A
> scalar type specifier is simply the name of the type in question, like
> Integer, Degree, Coordinate, etc. By looking at a scalar type
> specifier, the user cannot determine any logical structure for values
> of that type.

So indeed it is the difference between abstract and concrete datatypes. There's nothing inherent in the type "Degree" which makes it scalar, only how you happen to be using it. In languages with good type systems (I'm thinking Haskell) which don't create artificial distinctions between system and user-defined types, it's much more obvious that the distinction you're talking about is subjective.

> By designing the language to be aware of relation and tuple types, we
> can provide much more intuitive mechanisms for dealing with values of
> these types.

Maybe that's because you're used to languages where these "intuitive mechanisms" have to be built in to the language because they can't be expressed IN the language. What intuitive mechanisms did you have in mind? Received on Sun Jan 11 2004 - 00:25:57 CET