[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