[m-rev.] fore post-commit review: improve the speed of the typechecker

[Zoltan Somogyi]

On 30-Jul-2010, Paul Bone <pbone at csse.unimelb.edu.au> wrote:
> If so could you add "... and then use this call to set the list.".

Isn't that obvious?

> Should this be called filter_by_key, and below.

Any opinions by others?

> > +    % assoc_list.merge(L1, L2, L):
> > +    %
> > +    % L is the result of merging the elements of L1 and L2, in ascending order.
> > +    % L1 and L2 must be sorted on the keys.
> > +    %
> 
> Is L sorted also?

That's part of the definition of merge.

> > +assoc_list.merge(As, Bs) = ABs :-
> > +    assoc_list.merge(As, Bs, ABs).
> > +
> > +assoc_list.merge([], [], []).
> > +assoc_list.merge([A | As], [], [A | As]).
> > +assoc_list.merge([], [B | Bs], [B | Bs]).
> > +assoc_list.merge([A | As], [B | Bs], Cs) :-
> > +    (
> > +        A = AK - _AV,
> > +        B = BK - _BV,
> 
> You can put these two deconstructions outside of the ITE, the compiler will
> assert that they are deterministic.

I know. The compiler will generate the same code either way.

Zoltan.
--------------------------------------------------------------------------
mercury-reviews mailing list
Post messages to:       mercury-reviews at csse.unimelb.edu.au
Administrative Queries: owner-mercury-reviews at csse.unimelb.edu.au
Subscriptions:          mercury-reviews-request at csse.unimelb.edu.au
--------------------------------------------------------------------------