[m-rev.] for review: abstract insts and modes for .int3 files

Zoltan Somogyi zoltan.somogyi at runbox.com
Wed Mar 20 16:20:21 AEDT 2019

On Wed, 20 Mar 2019 04:48:03 +0000 (UTC), Julien Fischer <jfischer at opturion.com> wrote:
> > In the longer term, we may want to make abstract insts and modes a
> > user visible part of the language, for which the syntax in this diff
> > is NOT suitable; does anyone have a syntax that IS suitable? And would
> > user visible abstract insts and modes be desirable anyway?
> Abstract insts seem desirable, the current situation when declaring
> insts for abstract types is quite clumsy.  Is the proposal from section
> 4.5 of dmo's thesis (still) workable?

I haven't thought about it. Now that I have looked it up again,
dmo's proposal is trying to solve a completely different problem
than this diff. My sort of abstract diff intentionally says nothing
about the meaning of the inst; dmo's proposal is specifically designed
to say something. Having them use different keywords seems
a good idea.
> I can't really see a case for user visible abstract modes; can anyone
> else?

Nor can I. If e.g. the mode of an input argument of a predicate is given
by an abstract mode,  the compiler will never be able to tell when that
argument in a call to the predicate is sufficiently instantiated, since
it does not even have a name for the required instantiated state.
And a mirror image problem arises for outputs. And with abstract
modes, the caller cannot even tell inputs and outputs apart ...

> > The diff is with -b.
> That looks fine.

Thank you.


More information about the reviews mailing list