subtypep: handle struct type objects.

The subtypep function has poor requirements, handling only type
symbols. Let's extend it to handle structure type objects.

* lib.c (subtypep): In all cases when an argument is considered to be a
possible structure symbol, and thus subject to find_struct_type,
consider whether it already is a struct type, and just take it as-is.

* tests/012/type.tl: New tests.

* txr.1: Updated.

1 files changed, 14 insertions, 6 deletions

diff --git a/txr.1 b/txr.1
index 9e5651c1..3c606329 100644
--- a/txr.1
+++ b/txr.1
@@ -19203,18 +19203,26 @@ There are more kinds of objects, such as user-defined structures.
 
 .coNP Function @ subtypep
 .synb
-.mets (subtypep < left-type-symbol << right-type-symbol )
+.mets (subtypep < left-type << right-type )
 .syne
 .desc
 The
 .code subtypep
 function tests whether
-.meta left-type-symbol
+.meta left-type
 and
-.meta right-type-symbol
+.meta right-type
 name a pair of types, such that the left type is a subtype of the right
 type.
 
+The arguments are either type symbols, or structure type objects, as returned by the
+.code find-struct-type
+function. Thus, the symbol
+.codn time ,
+which is the name of a predefined struct type, and the object returned by
+.code "(find-struct-type 'time)"
+are considered equivalent argument values.
+
 If either argument doesn't name a type, the behavior is
 unspecified.
 
@@ -19222,10 +19230,10 @@ Each type is a subtype of itself. Most other type relationships can be inferred
 from the type hierarchy diagrams given in the introduction to this section.
 
 In addition, there are inheritance relationships among structures. If
-.meta left-type-symbol
+.meta left-type
 and
-.meta right-type-symbol
-both name structure types, then
+.meta right-type
+are both structure types, then
 .code subtypep
 yields true if the types are the same struct type, or if the right
 type is a direct or indirect supertype of the left.