[m-users.] di / uo -- some clarification please.

[emacstheviking]

Thanks mark. I had considered passing around a map and then changing things
in the map as and when needed.

Mostly my "game" is to learn Mercury rather than write a game, but since
age 11 I realised that writing games covers just about everything a
language has in terms of I/O, logic, decisions etc and it's an old habit
now!  I considered "pong" but hell that's been done to death.

The attraction of Mercury for me for games is that it feels like a "better
C", and I mean "better" in a stratospheric kind of way as Mercury has a lot
to offer I think... I have also seen the Cinnabar video on YouTube and
looked at the code and TBH it's nice looking code.

My nightmare is of producing a game in C or C++ that has a nightmare bug
related to garbage/memory corruption or dangling pointers etc so my game
plan (!) is to code the logical part of the game in Mercury and let my FFI
wrapper for SDL shunt out the pixels.

Thanks all once again,
Sean.




On Tue, 6 Aug 2019 at 08:08, Mark Brown <mark at mercurylang.org> wrote:

> On Tue, Aug 6, 2019 at 3:19 AM emacstheviking <objitsu at gmail.com> wrote:
> >
> > Hello,
> >
> > I seem to have somehow conflated the use of the state variable form !X
> with the use of the modes "di" and "uo" because so far the the only place I
> have used such notation has been with the special !IO state variable.
> >
> > I now have a game loop:
> >
> > :- pred game_loop(
> >     app_state::di,  app_state::uo,
> >     game_state::di, game_state::uo,
> >     io::di,         io::uo)
> > is det.
> >
> > game_loop(!AppState, !GameState, !IO) :-
> >      :
> >      : game state and app state code...
> >      :
> >     game_loop(!AppState, !GameState, !IO).
> >
> > This is condensed for clarity(!) but have I understood the concepts
> correctly. My intention is that after one pass of the game loop the "old"
> (di) application and game states can be junked i.e. their memory
> deallocated as the new incarnations are now the current ones, ready for the
> tail-cail back into the next iteration of the game loop.
> >
> > Is that the correct use case?
> >
> > The game state will contain all the mutable stuff for the game and the
> application state is slightly higher level stuff like "should I terminate"
> etc.
>
> Hi Sean,
>
> As others have said, it's likely you will hit difficulties this way
> (unfortunately). I've had a fair bit of success with this kind of
> thing, however, by separating out parts of the data structures that
> are (mostly) unique and passing them via their own state variables.
> The recursive predicate usually ends up looking something like:
>
>     loop(Info, !State, !A1, !A2, ...)
>
> where
>  - Info is an 'in' argument containing parameters that don't change
> (including things like mutvars)
>  - !State is an 'in, out' argument pair that collects together all of
> the non-unique, changeable state
>  - !A1, ... are 'di, uo' (or 'mdi, muo', or 'array_di, array_uo')
> argument pairs, with standard library types such as array, random, io,
> etc.
>
> The obvious drawback is that there's no saying how many argument pairs
> you might end up needing to pass around, although in practice maybe
> that won't be too big a problem for you? (Technically there is a way
> around this if really needed, albeit using unsafe promises and a bit
> of boilerplate).
>
> Mark
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mercurylang.org/archives/users/attachments/20190806/8359a874/attachment.html>