[m-users.] Accumulator and mode declaration

[Sean Charles (emacstheviking)]

SOLVED, I think…. Ui and do were not what I wanted after all, I changed the list to be just ‘in’ and ‘out’ and the code that adds to the accumulator is as follows, after reading the list module predicate declarations,

translate_(Options, [File|Files], !Acc, !IO) :-
        trace [
            run_time(env("FELT_DBG")),
            io(!Dbg)
        ]
        (io.format("translate_: %s\n", [s(File)], !Dbg)),

    !:Acc = [File| !.Acc],
    translate_(Options, Files, !Acc, !IO).

This now feels much better. I guess deep down in the compiler code, ‘destructive’ literally means overwriting the memory.



> On 6 May 2021, at 08:23, Sean Charles (emacstheviking) <objitsu at gmail.com> wrote:
> 
> Morning!
> 
> I thought about it and I now have this which compiles and seems to work and ‘feels correct’ (!) but I am aware of the ‘mostly unique’ modes as well but in this case I don’t think that’s what I need, the purpose of the accumulator is to collect errors.
> 
> translate(Files, Options, !IO) :-
>     translate_(Options, Files, [], Errors, !IO),
>     io.print_line(Errors, !IO).
> 
> 
> :- pred translate_(
>     command_line.felt_options::in,
>     list(string)::in,
>     list(string)::di, list(string)::uo,
>     io::di, io::uo) is det.
> 
> translate_(_, [], !_Acc, !IO) :-
>         trace [
>             run_time(env("FELT_DBG")),
>             io(!Dbg)
>         ]
>         (io.format("translate_: all done\n", [], !Dbg)).
> 
> translate_(Options, [File|Files], !Acc, !IO) :-
>         trace [
>             run_time(env("FELT_DBG")),
>             io(!Dbg)
>         ]
>         (io.format("translate_: %s\n", [s(File)], !Dbg)),
>     translate_(Options, Files, !Acc, !IO).
> 
> 
> It dawned on me that my accumulator is in some sense the same as a state variable and thus requires handling as such; so I realised that if I used that `!` syntax then I could do what I wanted. I think I did the right thing, the compiler is happy but.. am I ?
> 
> Again, thanks for your time Zoltan.
> Sean
> 
> 
> 
>> On 6 May 2021, at 08:20, Sean Charles (emacstheviking) <objitsu at gmail.com <mailto:objitsu at gmail.com>> wrote:
>> 
>> I read this page for a good time now:
>> 
>> https://mercurylang.org/information/doc-latest/mercury_ref/Predicate-and-function-mode-declarations.html#Predicate-and-function-mode- <https://mercurylang.org/information/doc-latest/mercury_ref/Predicate-and-function-mode-declarations.html#Predicate-and-function-mode->declarations
>> 
>> …with the relevant part being:
>> 
>> >A function or predicate mode declaration is an assertion by the programmer that for all possible argument terms and (if applicable) result term for the function or predicate that are approximated (in our technical sense) by the initial instantiatedness trees of the mode declaration and all of whose free variables are distinct, if the function or predicate succeeds, then the resulting binding of those argument terms and (if applicable) result term will in turn be approximated by the final instantiatedness trees of the mode declaration, with all free variables again being distinct. We refer to such assertions as mode declaration constraints. These assertions are checked by the compiler, which rejects programs if it cannot prove that their mode declaration constraints are satisfied.
>> 
>> That’s a wake up call. Up to this point I had not made the connection between the declared determinism and the modes. It’s a lot to take in and it’s too late for my brain. I guess in the morning I will read it again and work on it. I am not schooled in predicate logic or maths; what I know I have taught myself as and when I need to for 35 years and counting but Mercury (and Prolog) continue to be most challenging. When you don’t know what half of the documentation is saying because the language is so hard to interpret into something meaningful to a mere mortal it feels very hard at times. But I haven’t given up thus far, the code I have feels incredibly lean and safe. Very reassuring actually.
>> 
>> Any links to learning resources that might help me on the way would be nice to see.
>> 
>> Good night!
>> Sean
>> 
>> 
>> 
>> 
>> 
>>> On 5 May 2021, at 23:00, Zoltan Somogyi <zoltan.somogyi at runbox.com <mailto:zoltan.somogyi at runbox.com>> wrote:
>>> 
>>> 
>>> 
>>> On Wed, 5 May 2021 22:55:11 +0100, "Sean Charles (emacstheviking)" <objitsu at gmail.com <mailto:objitsu at gmail.com>> wrote:
>>>> :- pred translate_(
>>>> 	command_line.felt_options::in,
>>>> 	list(string)::in,
>>>> 	list(string)::out,
>>>> 	io::di, io::uo) is det.
>>> 
>>> This promises that when translate_ succeeds, the third arg
>>> will be ground, but ...
>>> 
>>>> translate_(_, [], _Acc, !IO) :-
>>>> 	trace [
>>>> 		run_time(env("FELT_DBG")),
>>>> 		io(!Dbg)
>>>> 	]
>>>> 	(io.format("translate_: all done\n", [], !Dbg)).
>>> 
>>> ... as the error message says, this clause does NOT make it ground.
>>> 
>>> Zoltan.
>>> 
>>> 
>> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mercurylang.org/archives/users/attachments/20210506/2cdb3965/attachment-0001.html>