[m-rev.] for review: subtypes

Peter Wang novalazy at gmail.com
Thu Jan 9 17:31:51 AEDT 2014


On Thu, 9 Jan 2014 16:35:27 +1100 (EST), Julien Fischer <jfischer at opturion.com> wrote:
> Hi,
> 
> On Thu, 9 Jan 2014, Peter Wang wrote:
> 
...
> >>
> >> I think it is just constructing dynamically that is a problem.
> >
> > The compiler could generate a function for each subtype which returns
> > true if a value fits that subtype, then we extend typeinfos to contain
> > pointers to such functions.  Construct could then check that its
> > arguments have the expected subtypes, otherwise fail.
> 
> If the arguments don't have the expected subtypes there should be a mode
> error (as mentioned elsewhere in this thread) -- I know in many cases
> there's not at the moment, but that's a problem (or more likely, several
> problems) with the mode checker.

Not if, as I hope, the use of subtypes for functor arguments can be kept
internal to a module.

To reiterate the example, say cord.m uses subtypes internally but
presents the same interface as before.  To an importing module, cord(T)
is an abstract type and cord values are just 'ground'.  There, you could
dynamically construct a cord value where arguments don't have the
expected subtypes, and there would be no mode error because the value
has inst 'ground' as expected.

Right?

Peter



More information about the reviews mailing list