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

[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.

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