[m-dev.] Type info convention

[Nancy Mazur]

> > > The work done by Simon on the type spec change causes a few problems for
> > > structure reuse.  This is because type_info's are a `hidden' type, ie
> > > they don't appear in mode declarations. 
>  
>  ...
>  
> > > Simons latest changes places
> > > some new type infos at the end of the headvars, making it very hard to
> > > determine which headvars are `real'.
> > 
> > Could you be more specific?  Which change of Simon's?
> > Have you got a simple example program which demonstrates this?
> 
> I think Peter means the change which added `:- pragma type_spec'
> declarations to the library. For a specialization
> `:- pragma type_spec(p/1, T = var(V))', a type-info for `V' needs
> to be added to the argument list. higher_order.m adds that argument
> to the end of the list.
> 
> Procedures created by deforestation will cause the same problems.
> Deforestation works out the order of the arguments of procedures
> it creates by calling `set__to_sorted_list' on the non-locals of a goal.
> 
> > > Simon would it be possible to change this so that the type infos are
> > > placed at the head of the list?  How much work would it be?
> > > 
> > > I think we should obey the convention that any head var which doesn't
> > > have an explicit mode declaration should go at the start of the
> > > headvars.
> > 
> > That might be reasonable.
> 
> Code which relies on the argument order of specialized procedures
> is not very robust. Structure reuse should be fixed.

I agree and I don't agree. 
At the structure reuse moment, there is no way to find out what
the `real' headvars where from a procedure. I.e. I'm generating
pragma's with signatures corresponding to the predicate declarations,
in some way, example: 

:- pragma pa_alias_info(append:app((builtin:in), (builtin:in), (builtin:out)),
vars(HeadVar__1, HeadVar__2, HeadVar__3), REST... ). 

I need to be able to link the headvars with REST, which is expressed
in terms of those headvars. 

Anyway, I think the best solution is to add a field to the proc_info
which keeps the real headvars: once set, they will never change. 
It is just impossible to retreive them otherwise. 

Hmmm... but then, next question: the problem mainly occurs with 
the specialized predicates. How do I get to know the `real' headvars?
O well, I'll try to check it out by myself.. 

As i said: I agree to fix my structure reuse, but it relies on 
information I'm not really sure I can find at that stage... 

Nancy

PS: I replied earlier to Pete's mail, but it didn't get through... 
the point was to rectify Pete's opinion about making some convention.. 
The only thing I need is a predicate with which I can get the
real headvars... and I don't care how they are or are not represented
internally. 
--------------------------------------------------------------------------
mercury-developers mailing list
Post messages to:       mercury-developers at cs.mu.oz.au
Administrative Queries: owner-mercury-developers at cs.mu.oz.au
Subscriptions:          mercury-developers-request at cs.mu.oz.au
--------------------------------------------------------------------------