[m-users.] A question about in-place updating...

[Sean Charles (emacstheviking)]

I have some understanding but not 100% clear picture in my head of it all. In the past I have managed to pass higher order functions around etc after some 'learning' and help from this great list.

I am actually using your curated list of mercury resources and reading all the code from all the people top to bottom to find examples.

All your code belong to us.

This is the thing I both love and hate about Mercury... for a while it stops you dead in your track, everything things utterly pointless and fruitless, but as the days pass and ones perseverance weakens not, eventually there are photons at the end of the collider. And then, whooosh, it all makes sense and life is wonderful again. Given the time investment I've made, I'm not walking away from this fight either!

:)

> On 28 Aug 2023, at 16:34, Volker Wysk <post at volker-wysk.de> wrote:
> 
> Am Montag, dem 28.08.2023 um 16:25 +0100 schrieb Sean Charles
> (emacstheviking):
>> Without understanding there is nothing!
>> 
>> Thanks for trying but if I don't understand it then only pain awaits along
>> the road... I need the flip-flops of understanding to cover my feet first.
> 
> This sentence from the Reference Manual has lead me: "Mercury also provides
> “unique” insts unique and unique(…) which are like ground and bound(…)
> respectively"
> 
> And this: ":- mode uo == free >> unique."
> 
> You need to have an understanding of insts in order to make sense of it.
> 
> Cheers,
> Volker
> 
>> 
>> :D
>> 
>> 
>> 
>>> On 28 Aug 2023, at 16:22, Volker Wysk <post at volker-wysk.de> wrote:
>>> 
>>> Hi, Sean.
>>> 
>>> I haven't used unique modes myself yet. But I've tried out your example.
>>> More by guessing than knowing, I found out how to make it compile. See
>>> below.
>>> 
>>> Am Montag, dem 28.08.2023 um 14:59 +0100 schrieb Sean Charles
>>> (emacstheviking):
>>>> OK, so, I've started on the journey again... here's the smallest little
>>>> example I tried, just to try to even create something that could later be
>>>> used as a destructively updated instance,
>>>> 
>>>>    104 :- type blob ---> blob(int).
>>>>    105 
>>>>    106 :- func mk_blob1(int::in) = (blob::uo) is det.
>>> 
>>> Replace this line by:
>>> 
>>> :- func mk_blob1(int::in) = (blob::(free >> unique(blob(ground)))) is det.
>>> 
>>>>    107 mk_blob1(X) = blob(X).
>>>>    108 
>>>>    109 :- pred blob1_info(blob::in, io::di, io::uo) is det.
>>>>    110 blob1_info(B, !IO) :-
>>>>    111     B = blob(Val),
>>>>    112     io.format("blob: %i\n", [i(Val)], !IO).
>>>>    113 
>>>>    114 :- func mk_blob2 = (blob::uo) is det.
>>>>    115 mk_blob2 = blob(42).
>>>>    116 
>>>>    117 :- pred blob2_info(blob::ui, io::di, io::uo) is det.
>>> 
>>> And this one by:
>>> 
>>> :- pred blob2_info(blob::di, io::di, io::uo) is det.
>>> 
>>>>    118 blob2_info(B, !IO) :-
>>>>    119     B = blob(Val),
>>>>    120     io.format("blob: %i\n", [i(Val)], !IO).
>>>> 
>>>> the compiler output is:
>>>> 
>>>> g1.m:107: In clause for `mk_blob1(in) = uo':
>>>> g1.m:107:   mode error: argument 2 did not get sufficiently instantiated.
>>>> g1.m:107:   Final instantiatedness of `HeadVar__2' was
>>>> `unique(blob(ground))',
>>>> g1.m:107:   expected final instantiatedness was `unique'.
>>>> 
>>>> g1.m:120: In clause for `blob2_info(ui, di, uo)':
>>>> g1.m:120:   mode error: argument 1 did not get sufficiently instantiated.
>>>> g1.m:120:   Final instantiatedness of `B' was `unique(blob(ground))',
>>>> g1.m:120:   expected final instantiatedness was `unique'.
>>>> 
>>>> In the manual is says:
>>>> 
>>>> "Mode uo is used to create a unique value."
>>>> "Mode ui is used to inspect a unique value without losing its uniqueness."
>>>> "Mode di is used to deallocate or reuse the memory occupied by a value
>>>> that will not be used. "
>>>> 
>>>> I have so far interpreted this, obviously incorrectly, that wanting to
>>>> create a new 'blob' meant that the output would be 'uo' but it seems I
>>>> have done something to upset the compiler regarding HeadVar__2, presumably
>>>> the returned value given the error message. The second version works
>>>> presumably because the number 42 is a ground value, but right now, I have
>>>> no idea how I would pass in a bunch of values, mangle them and return a
>>>> new instance of something that I would later want to use destructively.
>>>> Learning time...
>>>> 
>>>> Some explanation of what I have done wrong would help as, once again, I
>>>> find myself reading the section 6 content and it mostly going over my
>>>> head. Ultimately, I want to be able to create a list of things, then in-
>>>> place modify those things, and ultimately junk them on program exits.
>>>> That's all. My problem i guess is not fully understanding what the
>>>> compiler means by 'unique' and 'dead'.
>>>> 
>>>> Thanks,
>>>> Sean.
>>>> 
>>>>> On 28 Aug 2023, at 13:10, Volker Wysk <post at volker-wysk.de> wrote:
>>>>> 
>>>>> Am Montag, dem 28.08.2023 um 13:02 +0100 schrieb Sean Charles
>>>>> (emacstheviking):
>>>>>> OK, I am now creating flight-path / animation / tweening system, that
>>>>>> on
>>>>>> every iteration of the game loop, will have to process every single
>>>>>> instance of display objects and update their coordinates and set
>>>>>> flags,
>>>>>> alpha values etc etc. The number of such objects could become high,
>>>>>> not
>>>>>> punishingly high, for now I can't see it being more than a thousand,
>>>>>> even
>>>>>> with a primitive particle system generating explosions using texture
>>>>>> maps
>>>>>> it should not be massively high.
>>>>>> 
>>>>>> Currently I am just 'making it work', gut I am wondering longer term
>>>>>> about
>>>>>> what techniques might be open to me in Mercury given that it manages
>>>>>> memory, does the garbage collection for me etc. such that I can
>>>>>> minimise
>>>>>> object allocation etc as instances are updated frame-by-frame.
>>>>>> 
>>>>>> 1) When I use list.reverse(), is it a shallow or deep copy of the
>>>>>> original? I am assuming a shallow copy, with may be copy-on-write
>>>>>> behind
>>>>>> the scenes?
>>>>>> 
>>>>>> 2) If I have a list of say a thousand instances of a tween object,
>>>>>> then as
>>>>>> I process them, they will need to be updated as I save the current
>>>>>> value
>>>>>> in the instance along with a done flag, so either the values changes
>>>>>> or
>>>>>> the done flag changes, either way it means that a new instance will be
>>>>>> created. Is there a way to make it so that Mercury can in-place update
>>>>>> these instances rather than allocating new ones, so that it reduces
>>>>>> memory
>>>>>> thrashing and heap activity etc?
>>>>>> 
>>>>>> It's an interesting question for me to ponder at the moment! Given all
>>>>>> that Mercury does, I am guessing that there are no ways to 'pin' a
>>>>>> block
>>>>>> of memory such that it can then be reused over and over, I have played
>>>>>> around with bitmap but that's not really built for generic structures
>>>>>> etc.
>>>>>> I guess if it came to the crunch I could always re-code those things
>>>>>> that
>>>>>> need maximal performance in C but that kind of negates the reason I
>>>>>> decided to write this game in Mercury.
>>>>> 
>>>>> What you describe seems to be a case for unique modes. See section 6 in
>>>>> the
>>>>> Language Reference Manual.
>>>>> 
>>>>> Cheers,
>>>>> Volker
>>>>> _______________________________________________
>>>>> users mailing list
>>>>> users at lists.mercurylang.org
>>>>> https://lists.mercurylang.org/listinfo/users
>>>> 
>>> 
>> 
>