[TYPES] What's a program? (Seriously)
Guillaume Munch-Maccagnoni
Guillaume.Munch-Maccagnoni at inria.fr
Sat May 22 06:28:14 EDT 2021
Le 19/05/2021 à 17:59, Thomas Streicher a écrit :
> [ The Types Forum, http://lists.seas.upenn.edu/mailman/listinfo/types-list ]
>
> n Wed, May 19, 2021 at 05:26:52PM +0200, Gabriel Scherer wrote:
>> I am not convinced by the example of Jason and Thomas, which suggests that
>> I am missing something.
>>
>> We can interpret the excluded middle in classical abstract machines (for
>> example Curien-Herbelin-family mu-mutilda, or Parigot's earlier classical
>> lambda-calculus), or in presence of control operators (classical abstract
>> machines being nicer syntax for non-delimited continuation operators). If
>> you ask for for a proof of (A \/ not A), you get a "fake" proof of (not A);
>> if you ever manage to build a proof of A and try to use it to get a
>> contradiction using this (not A), it will "cheat" by traveling back in time
>> to your "ask", and serve you your own proof of A.
>>
>> This gives a computational interpretation of (non-truncated) excluded
>> middle that seems perfectly in line with Talia's notion of "program". Of
>> course, what we don't get that we might expect is a canonicity property: we
>> now have "fake" proofs of (A \/ B) that cannot be distinguished from "real"
>> proofs by normalization alone, you have to interact with them to see where
>> they take you. (Or, if you see those classical programs through a
>> double-negation translation, they aren't really at type (A \/ B), but
>> rather at its double-negation translation, which has weirder normal forms.)
> All these computational interpretations of classical logic are
> actually constructive interpretations of their negative translations.
> This is maybe not so transparent because macros are used. But if you
> consider the cps translation of these macros you again get the negative
> translations.
>
> I know the French school (Krivine in particular) is very fond of these
> macros. But these macros don't add too computational power.
> More generally, all effects can be translated to a purely functional kernel.
>
> Whether one likes these macros or not presumably depends on whether
> one is more CS person or a mathematician. But these preferences don't
> change strength.
>
> Thomas
I believe this applies CS terminology incorrectly. A whole-program
translation can increase computational expressiveness. This is very
useful as this lets CS people give us compilers from high-level
languages to low-level languages. “Macro” in general indeed refers to
something which does not add computational power. But if call/cc was
macro-expressible in the lambda calculus, then I expect CS people to be
the first to notice. A negative translation is a whole-program translation.
The examples were really about the incompatibility of a notion of
constructive LEM with other, unspecified, hypotheses. A whole-program
translation lets you ignore features from the target language, whereas a
macro does not.
Alternatively, if your notion of computational power does not account
for computational expressiveness, I suspect there are some kind of
emergent phenomena in your system your notion might miss.
There have been attempts at making the idea of macro-expressiveness and
comparison of expressive power rigorous, to begin with Felleisen [1]
which is a transposition at the level of terms of Kleene's notion of
eliminability at the level of provability.
Le 20/05/2021 à 13:15, Thomas Streicher a écrit :
> One can extract witnesses only for Pi^0_2 sentences. Otherwise
> classical proofs of existential statements don't give you witnesses.
>
> That's part of our conditio humana...
>
(There are sketches of this conservativity result alluded to in this
thread, which I will not continue here, instead one can refer to a
textbook, for instance [2, pp. 198-201].)
The interesting part is of course not going to be that different models
of computation agree on the notion of computable function from N to N (a
Pi^0_2 sentence), and that they can disagree beyond. This is a basic
expectation. What is interesting is what it says beyond.
I find one step missing in Gabriel's and other explanations. The “fake”
or “cheating” proof (in Gabriel's words) is meant to be used at some
point inside a bigger program of type N, Bool, or any other type one
expects to enjoy canonicity, in order to get a final value. Which one
obtains in the end, because canonicity holds for purely positive types
(Sigma^0_1 formulae). When one extracts a witness for a Pi^0_2 formula,
there is no restriction on the shape of the proof: it works as well for
those obtained by composing presumably-non-constructive ones. This
relies on the “fake” or “cheating” proofs always providing enough
information to move the argument forward. Which they do. Then, I believe
that such proofs are not cheating but constructive.
Is it possible to say that one argues less in good faith than the other,
between the classical player that backtracks on their position, and the
intuitionistic opponent who demands amounts of evidence up-front
unnecessary to the computation of the end result?
And so I believe they are certainly all programs of their respective
types, for some notion of computation, regardless of whether this notion
can also be explained in terms of a negative translation of this type
plus a way of running the result of the transformation of a whole
program (cf. Friedman's trick, or Prop 10.11 in the reference).
- - - - - - - - - - - - - - - - - - - - - - - - - - -
- - -
This situation, it turns out, is very similar to the one proposed in
Talia's message: a language in which some terms relying on axioms are
deemed not computing or "mostly computing" (when seen through an
intuitionistic lens), but in which some other terms still "fully
compute". But we have additional guarantees that some terms will always
"fully compute" depending on their type, rather than their shape.
[1] Felleisen, M., “On the expressive power of programming languages”
<https://doi.org/10.1016/0167-6423(91)90036-W>.
[2] Krivine, J.-L., “Lambda-calculus, types and models”,
<https://cel.archives-ouvertes.fr/cel-00574575/>.
--
Guillaume Munch-Maccagnoni
Researcher at Inria Bretagne Atlantique
Team Gallinette, Nantes
More information about the Types-list
mailing list