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

'indefinite' element types

As I read http://www2.camellia.org/drm-march/drm_68.htm#HEADING68-0, it
appears that 'indefinite' element types are there to let you escape from
strong typing.

If I define:

define constant <int-vector> = limited(<vector> of: <integer>);

define function frobozz(x :: <vector>)
  x[0] := "foo";
end;

frobozz(make(<int-vector>, size: 1, initial-element: 0));

will result in an error only when the assignment is executed.  If the
definition and call were separately compiled, this would only be detected at
run time.  Whereas:

define constant <real-vector> = limited(<vector> of: <real>);

define function xyzzy(x :: <real-vector>)
  x[0] := 4.2;
end;

xyzzy(make(<real-vector>, size: 1, initial-element: 0.0));

will result in an error when the actual is bound to the formal.  If the
definition and call were separately compiled, the type error would be
detected at compile time.

Q1. Is my understanding of the meaning and purpose of 'indefinite' correct?

Q2. Is there a way to construct new subtypes of collection that have
'indefinite' element types, but whose type is a subtype of something other
than <object>?  This would seem like a useful facility that would give some
compile time type checking (the element type must be more specific than
<object>) but escape the straight-jacket of strict co- and contra-variance
on the element getter and setter.

---

The alternative is some form of parameterized function signature, e.g.:

define function element-frobber(
    new :: (element-type :: <type>),
    coll :: limited(<collection> of: element-type)
  )
  ...
end;

Q3. Wasn't there some discussion of parameterized functions at Harlequin?
Follow-Ups: