This is the mail archive of the
xconq7@sources.redhat.com
mailing list for the Xconq project.
Re: time.g weirdness
- From: Eric McDonald <mcdonald at phy dot cmich dot edu>
- To: Jim Kingdon <kingdon at panix dot com>
- Cc: xconq7 at sources dot redhat dot com
- Date: Thu, 12 Aug 2004 12:53:10 -0400 (EDT)
- Subject: Re: time.g weirdness
On Thu, 12 Aug 2004, Jim Kingdon wrote:
> > (set relative-infinity 9999)
>
> Is this better than adding infinity to the lisp object system (with
> infinity getting its own value in enum lisptype)?
I don't know. I haven't forgotten that you have suggested adding
an actual infinity quantity before, but I have some qualms about
that too, some of which you bring up below.
>I guess for the
> latter you'd need to figure out comparisons, arithmetic, etc, anew,
> which might be a bit of a pain. And of course there would be the
> problem of when it is brought into C code, does it turn into TABHI, or
> does the code need to check for it specifically, or what?
In the case of tables, the only storage type that they currently
support is 'short'; even TABDICE are just shorts. Even in the case
of properties, assignments of varying types are not supported, and
so if there is an integer property it could not be bound to an
'Obj* lispinf' or whatever.
> What I had in mind was something much less deep. If
> mp-to-enter-terrain says you need 99 movement points, and
> acp-per-turn, free-mp, etc, say that a unit can never get 99 movement
> points in a turn, then have the help report it as infinite. The big
> problem with that is that it is very case-by-case, and it would be
> easy for this computation to be out of sync with the action code.
Exactly. This is not such a big deal as long as one writes
functions that are common to both.
>So
> maybe one of the infinity variants would make more sense anyway.
The relative infinity idea would be the easiest to code, in my
estimation, but it is also the crudest. The case-by-case logic
probably makes the most sense in the long run. I have already been
heading in this direction with the common ACP and MP arithmetic
functions that I have been written (with more to come). Hans has
already created some fairly decent volume checking functions that
can be used rather ubiquitously as well.
Eric