[m-dev.] Miinor grief with field access syntax and higher order code

Ralph Becket rbeck at microsoft.com
Fri Apr 6 00:41:40 AEST 2001


[I know we've done this debate to death, but...  Anyway, this is a low
priority whinge.]

The following code presents two ways of using field access syntax, each
of which looks perfectly reasonable to me.  The former is more concise,
but doesn't work.

:- module foo.
:- interface.
:- import_module int, list.

:- type t ---> t.

:- func f(int, t) = int.

:- func t_map(t, list(int)) = list(int).

:- implementation.

f(X, _T) = X.

        % This is broken.
        %
t_map(T, Xs) = list__map(T ^ f, Xs).

        % This works.
        %
t_map(T, Xs) = list__map(func(X) = T ^ f(X), Xs).

The broken version returns the following error:

foo.m:017: In clause for function `foo:t_map/2':
foo.m:017:   in function result term of clause head:
foo.m:017:   in argument 1 of functor `list:map/2':
foo.m:017:   type error in unification of argument
foo.m:017:   and functor `f/1'.
foo.m:017:   argument has type `((func int) = int)',
foo.m:017:   functor `f/1' has type
foo.m:017:   `f(int) :: ((func (foo:t)) = int)'.
        The partial type assignment was:
        HeadVar__1 :: (foo:t)
        HeadVar__2 :: (list:list(int))
        HeadVar__3 :: (list:list(int))
        T :: (foo:t)
        Xs :: (list:list(int))
        V_6 :: ((func int) = int)

This happens whenever you want to use a function both with field access
syntax and in higher order code.  Also, I always have to check the 
reference manual to get the argument order right for the long-hand
version, grumble...

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



More information about the developers mailing list