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

Volker Wysk <[email protected]> Mon, 28 Aug 2023 17:44:45 +0200
Newsgroups	gmane.comp.lang.mercury.general
Message-ID	<[email protected]>
Am Montag, dem 28.08.2023 um 16:37 +0100 schrieb 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. 

:-)) That's exactly how it is for me.

> Given the time investment I've made, I'm not walking away from this fight
> either!
> 
> :)

Your declaration can also be written like this:

:- func mk_blob1(int::in) = (blob::out(unique(blob(ground)))) is det.

This should look more familiar, if you have an understanding of insts. The
only difference to the non-unique case is that "bound(...)" has been
replaced by "unique(...)".

Cheers,
Volker

> 
> > On 28 Aug 2023, at 16:34, Volker Wysk <[email protected]> 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 <[email protected]> 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 <[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]
> > > > > > https://lists.mercurylang.org/listinfo/users
> > > > > 
> > > > 
> > > 
> > 
>

_______________________________________________
users mailing list
[email protected]
https://lists.mercurylang.org/listinfo/users
signature.asc (application/pgp-signature, 833 B)