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

Tue Aug 29 01:34:04 AEST 2023

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

-------------- 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/e91f4423/attachment-0001.sig>