[mercury-users] Re: Mercury Tutorial / Functions

[Goncalo Jorge Coelho e Silva]

> mailing list which is read by a large number of people who can offer
> help.

Thanks Ralph for the insight on your reply.
 
I'll first address some of the subsiding problems 
and later, some of your considerations.

When I get to compile your sample code, I get a 
'mode error'. Now modes and pred declarations
are not my strongest side :\ and I couldn't figure
out what was wrong.

 Appearently, the 'Ss' variable isn't unified with
anything and/or can't get 'grounded'. The 'unique'
issue and the passing of state_of_the_word arguments
like the IO0 and IO, are still not very strong to
me.

 As with list VS arrays, I had prevously seen the
great easiness with which one can be converted into
the other and vice-versa. It's indeed more clever
to use lists once you don't know the size of the
inout at the STD_IN.

Here's the compilation error:

inter.m:023: In clause for predicate `inter:main/2':
inter.m:023:   warning: variable `Ss' occurs only once in this scope.
inter.m:040: In clause for `read_strings_2(in, out, di, uo)':
inter.m:040:   mode error in conjunction. The next 3 error messages
inter.m:040:   indicate possible causes of this error.
inter.m:040: In clause for `read_strings_2(in, out, di, uo)':
inter.m:040:   mode mismatch in disjunction.
inter.m:040:   `IO' :: unique, free, not_reached.
inter.m:029: In clause for `read_strings_2(in, out, di, uo)':
inter.m:029:   in argument 2 of clause head:
inter.m:029:   mode error in unification of `HeadVar__2' and `Ss'.
inter.m:029:   Variable `HeadVar__2' has instantiatedness `free',
inter.m:029:   variable `Ss' has instantiatedness `free'.
inter.m:029: In clause for `read_strings_2(in, out, di, uo)':
inter.m:029:   in argument 4 of clause head:
inter.m:029:   mode error in unification of `HeadVar__4' and `IO'.
inter.m:029:   Variable `HeadVar__4' has instantiatedness `free',
inter.m:029:   variable `IO' has instantiatedness `free'.
make: *** [run] Error 1


Here the sample code:

:- pred main(io__state, io__state).
:- mode main(di, uo) is det.

:- pred read_strings(list(string), io__state, io__state).
:- mode read_strings(out,          di, uo) is det.

:- pred read_strings_2(list(string), list(string), io__state, io__state).
:- mode read_strings_2(in,           out,          di, uo) is det.

:- implementation.
:- import_module exception.

main -->
        read_strings(Ss).
  
  
read_strings(Ss, IO0, IO) :-
        read_strings_2([], Ss, IO0, IO).

read_strings_2(RevSs, Ss, IO0, IO) :-
        io__read_line_as_string(Result, IO0, IO1),
        (
                Result = ok(S),
                %io__write_string(S,IO0, IO1),
                read_strings_2([S | RevSs], Ss, IO1, IO)
        ;
                Result = eof,
                Ss     = list__reverse(RevSs)
        ;
                Result = error(_),
                exception__throw(Result)
        ).


> An array is a vector of values indexed by number with O(1) lookup and
> update operations.  In order for the update operation to be O(1) we have
> to use update-in-place (as opposed to making a copy of the original
> array with the new value at the given index.)  In order to preserve
> referential transparency, we therefore have to "destroy" the old version
> of the array in such a way that the program is guaranteed never to
> refer to it again.  (This allows us to create the new array by just
> doing update-in-place on the old array.)  This is what uniqueness is
> used for: only unique values can be "destroyed" in the required way and
> therefore be subject to update-in-place.
> 
> Back to coding.  Just as you have to ensure that the types match up, you
> also have to ensure that the modes match up.  In your example you write
> 
> > %:- pred myRead(array(T)).
> > %:- pred myRead(T).     
> > %:- mode myRead(in, in, out) is nondet.
> > %:- mode myRead(in) is nondet.
> :- mode myRead(in) is nondet.
 
> There are a number of errors here.
> Next, you have two mode declarations.  This is not a problem, but again
> there are problems.  The declaration

Right. I had been trying diferent predicate and mode
declarations (to suit each one). Those were lines
I didn't clean properly. Sorry.

> > %myRead(MyArray) -->
> > myRead(MyArray):-   

Right again. This was where I was using those mischivious
'mode' declarations with 3 arguments. :(

> > 
> >                 {
> >                 array__set(MyArray,0,String,MyArrayB),
> >                 %       array__set(MyArray,1,2,MyArrayB),
> 
> I'm not sure what's going on with this commented out call to
> array__set/4.

 OK, this was the non-conscious error I wrote in that mail.
This was my try to handle uniqueness, meaning I was expecting
to construct another array so that I could pass it on
the next call to the predicate. Still, a bad solution, I
know :\
 
Thanks a lot.

Cheers, 
Goncalo
--------------------------------------------------------------------------
mercury-users mailing list
post:  mercury-users at cs.mu.oz.au
administrative address: owner-mercury-users at cs.mu.oz.au
unsubscribe: Address: mercury-users-request at cs.mu.oz.au Message: unsubscribe
subscribe:   Address: mercury-users-request at cs.mu.oz.au Message: subscribe
--------------------------------------------------------------------------