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

[Paul Bone]

On Fri, Jul 30, 2010 at 05:36:29PM +1000, Zoltan Somogyi wrote:
> 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?

Not until my second reading, that's the point I'm trying to make.

> > 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.
>

Okay.

> > > +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.
>

Yes, but imagine you mistyped.

   A = AK - _AV,
   B = AK - _AV,

The second unification would be a test, if it where outside of the if then
else's condition it would be picked up since tests are semidet and the
enclosing goal would be det.  IMHO this is an advantage and I can't see any
disadvantage.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 489 bytes
Desc: Digital signature
URL: <http://lists.mercurylang.org/archives/reviews/attachments/20100731/581c5797/attachment.sig>