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

Tue Aug 29 01:22:56 AEST 2023

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
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part
URL: <http://lists.mercurylang.org/archives/users/attachments/20230828/41bc71f5/attachment.sig>