On 6/12/2022 3:02 PM, Ben Bacarisse wrote:
> Andy Walker <
a...@cuboid.co.uk> writes:
>
>> On 11/06/2022 21:10, Ben Bacarisse wrote:
>>> There's nothing interesting about pure functions from a theoretical
>>> point of view, but PO has ditched all notions of a formal model of
>>> computation, [...].
>>
>> Yeah, but others seem to be insisting on "PURE FUNCTIONS" for no
>> good reason that I can discern.
>
> OK, but I've also seen such insistence when it might matter. I do think
> it's the wrong thing to focus on (H could go consult the WWW for all I
> care) but it is one way to try to pin PO's nonsense down a bit.
>
>>> This program prints 1 (on my system) and halts because H_Hat(H_Hat)
>>> "halts" (i.e. returns to main) even though H_Hat is correctly
>>> constructed from H.
>>
>> Except that your "H" is not the decider but merely a subroutine of
>> your program. A correctly constructed "H_Hat" is not based just on such a
>> subroutine but on the entire program which contains "H". [I know you know
>> all this, but it bears occasional repetition.]
>
> Yes, but that's exactly why some people worry about pure functions. By
> re-framing the problem in terms of subroutines (and PO is not alone in
> this -- see Strachey's oft-cited note) extra care is needed.
>
>>> My guess is that it is trickery like this that makes people worry about
>>> functions being pure.
>>
>> Sure, but it's not really to do with purity as much as with replacing
>> an input tape [or near equivalent] by compiled [and non-standard] code invoked
>> from within the program. So the program is not deciding about a program and
>> its input but just running a particular program.
>
> <cut>
>>> Another approach, using C, would have been to make H take the source
>>> code of a C program as a string,
>>
>> That, for me, is what the HP /is/. If "H" then includes a compiler
>> and some way of running/emulating the compiled code, so be it. ...
>
> But there is a "halting problem" for functions entirely analogous to the
> one for whole programs. When PO shifts from Turing machines (about
> which he has nothing to say anymore, having exhausted all avenues for
> confusion) to C-like code, it's not actually wrong to do that, but the
> notion of what a computation is and what "halting" means need to be
> carefully pinned down. I think people reach for pure functions as a
> simple way to deal with some of that.
>
Finally mutual agreement on one key point.
Now that H(P,P)==0 is derived on the basis of a pure function of its
inputs I will be able to post the code for H and P. Prior to that it
would have been rejected on the basis that it depended on static local
data. This only needs very slight code clean up.
If I strip out all of work-in-progress code H, H0, H1, H2 and P takes
ten pages of code. If I add the support code that actually implements
the x86utm operating system this is fifty more pages. This needs lots of
code clean up.
The slightly adapted original x86 emulator (hundreds of pages) has been
adapted to compile under Windows and has the single additional function
of disassembling all of the functions in its machine language input. The
adapted code is very clean.
>>> rather than elide the issue of
>>> representation by using a code pointer but PO rejected any notion of
>>> "encoding" as being "extraneous complexity" for years and he still does
>>> not understand the concept.
>>
>> ... Such a solution may be complex, but it's not "extraneous"!
>
--
Copyright 2022 Pete Olcott
"Talent hits a target no one else can hit;
Genius hits a target no one else can see."
Arthur Schopenhauer