Return-Path:
Return-Path: <john.harrison-request@uk.ac.cam.cl>
Received: from ted.cs.uidaho.edu by swan.cl.cam.ac.uk with SMTP (PP)
          id <24966-0@swan.cl.cam.ac.uk>; Sat, 27 Jul 1991 13:34:06 +0100
Received: from uu.psi.com by ted.cs.uidaho.edu (15.11/1.34) id AA04045;
          Sat, 27 Jul 91 05:18:50 pdt
Received: from port6.boston.pub-ip.psi.net
          by uu.psi.com (5.65b/4.0.071791-Performance Systems International)
          id AA03917; Sat, 27 Jul 91 08:13:57 -0400
Received: from (manjusri) by ely (4.1/SMI-4.1) id AA29143;
          Sat, 27 Jul 91 07:27:31 EDT
Received: from ely by (4.1/SMI-4.1) id AA19999; Sat, 27 Jul 91 07:28:42 EDT
Date: Sat, 27 Jul 91 07:28:42 EDT
From: ian@com.oracorp.cambridge (Ian Sutherland)
Message-Id: <9107271128.AA19999@>
To: info-hol@edu.uidaho.cs.ted
Subject: Re: More on the choice function

>I believe what Josh meant to say is that the value of
>
>       @x. P x
>
>is not determined by P because it depends on some "hidden"
>well-ordering that can't be referred to in the language.

Actually, if the value of the @ function was always picked out by a
well-ordering, you could at least refer to the restriction of this
well ordering to a given type by

        \x:T.\y:T.((@z.((z = x) \/ (z = y))) = x)

Forgetting about well-orderings, there's a choice function generated
in SOME way being used to pick the values of "@" expressions, and it's
nameable as

        \x:(*->bool).(@y.(x y))

This doesn't change Josh's original point about the value of "@"
expressions not being determined by their contents, but you can talk
about the function being used to determine these values IN HOL, and
could even state axioms or hypotheses about it (although why you'd
want to I don't know).

