[m-rev.] for review: mix mercury code with foreign_proc

[Tyson Dowd]

On 13-Dec-2001, Fergus Henderson <fjh at cs.mu.OZ.AU> wrote:
> On 30-Jul-2001, Tyson Dowd <trd at cs.mu.OZ.AU> wrote:
> > Allow foreign_proc clauses to replace Mercury definitions.
> > Or alternately viewed, allow the compiler to fall back on Mercury
> > definitions of procedures if a suitable foreign_proc clause is unavailable.
> > 
> > (This is only possible with mode-specific Mercury procedures).
> 
> I just discovered a problem with this extension:
> it doesn't work for zero-arity procedures, because there's
> no way to write a mode-specific clause for a zero-arity procedure.

Yep, this is true.

> What was the rationale for only allowing this with mode-specific
> Mercury clauses?  Is it just an implementation issue?

Yes, it is just an implementation issue.  At first I tried to implement
it without this restriction, but it was a bit of a hard slog and I was
making very slow progress.

It seemed to be a lot easier to implement this feature if it was done on a
procedure by procedure basis -- each procedure could "override" other
procedures, with the Mercury procedure having lowest priority, and
then foreign langauges ordered according to the grade. 

So the easiest way to be sure you get this code write is to ensure that
the user has to write a clause for each procedure.  It also seemed
sensible, given that such code is likely to be mode specific anyway, and
should be considered impure by default.  

I believe I tried to write the code in
clauses_info_add_pragma_foreign_proc so that it handled cases where the
Mercury clause handled multiple modes, but I'm not sure whether it
correctly handled all cases.  I believe problems were cropping up where
the list of proc_ids for a clause was simply [0], yet the clause was
actually expected to implement multiple modes.  Perhaps the required
proc_id information simply wasn't available when make_hlds was running.

However, the drawback is that zero-arity procedures can't be written in
this style.

We could possibly make a special exception for them (should be
relatively modulo unforseen complications), or we could try to relax the
restriction on mode-specific clauses.  I suspect the later would be
easier when we also fix the known bugs with intermodule optimization and
multiple language foreign_proc -- we could keep all the clauses around
until a much later stage of the compiler (after semnatic analysis and
intermod), and then process them (eliminating the ones we decide not to
use), which would probably side-step any difficulties I was encountering
with incomplete information.

-- 
       Tyson Dowd           # 
                            #  Surreal humour isn't everyone's cup of fur.
     trd at cs.mu.oz.au        # 
http://www.cs.mu.oz.au/~trd #
--------------------------------------------------------------------------
mercury-reviews mailing list
post:  mercury-reviews at cs.mu.oz.au
administrative address: owner-mercury-reviews at cs.mu.oz.au
unsubscribe: Address: mercury-reviews-request at cs.mu.oz.au Message: unsubscribe
subscribe:   Address: mercury-reviews-request at cs.mu.oz.au Message: subscribe
--------------------------------------------------------------------------