From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00
	autolearn=unavailable autolearn_force=no version=3.4.4
Path: 
 eternal-september.org!reader01.eternal-september.org!.POSTED!not-for-mail
From: Paul Rubin <no.email@nospam.invalid>
Newsgroups: comp.lang.ada
Subject: Re: Implicit actions & program correctness
Date: Mon, 25 May 2020 15:31:31 -0700
Organization: A noiseless patient Spider
Message-ID: <87o8qb7ikc.fsf@nightsong.com>
References: <d4cc5c66-b82a-4ef7-8e69-2fa9b7bd99a6@googlegroups.com>
	<r9mp29$6nd$1@dont-email.me>
	<3c545096-d000-4d09-b3fe-ad8530632457@googlegroups.com>
	<871rnk97ew.fsf@nightsong.com>
	<14afb70d-cb70-4ca2-bd24-f9d9664ee103@googlegroups.com>
Mime-Version: 1.0
Content-Type: text/plain
Injection-Info: reader02.eternal-september.org;
 posting-host="72b8d7bf960c0199ae80654d23ca070b";
	logging-data="17573"; mail-complaints-to="abuse@eternal-september.org";
	posting-account="U2FsdGVkX19un0Olv88+6zucDmtNAert"
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux)
Cancel-Lock: sha1:Qh2ePXNQIT4q5FENuYJAm76/hwE=
	sha1:TCJGDhEblJY/0GvJurZB5HaZByk=
Xref: reader01.eternal-september.org comp.lang.ada:58789
Date: 2020-05-25T15:31:31-07:00
List-Id: <comp.lang.ada>

deadhacker <gstover@gmail.com> writes:
> Sadly, his Java API is no longer available, so I can't see how he
> solved it.
> Do you (or anyone else here) know how it could be solved with Ada?

I didn't look at the Java code (don't know if it was posted somewhere)
but I'd expect it is done with Java classes and subclasses.  You'd have
a class for game state, and container (wrapper) classes for "initial",
"non-initial", "finished", and "non-finished".  Each wrapper would
either be empty, or contain a state of the specified type.

The "move" function would accept a non-finished state as a parameter,
and return three maybe-empty wrapper objects containing the new state.
To call "move" again you'd have to look in the "non-finished" wrapper to
get a non-finished state from it, in the event that there is one.  If
the non-finished wrapper is empty, then the game is finished and there
is no way to call "move" again.   Similarly with takeback, etc.

In Haskell, I did the exercise with numerically-indexed GADT's, but that
approach seemed hacky so I might try it again.