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

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.
    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.
    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 <[email protected]> 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
> [email protected] <mailto:[email protected]>
> https://lists.mercurylang.org/listinfo/users

_______________________________________________
users mailing list
[email protected]
https://lists.mercurylang.org/listinfo/users