Path: news.eternal-september.org!eternal-september.org!feeder3.eternal-september.org!news.quux.org!news.nk.ca!rocksolid2!i2pn2.org!.POSTED!not-for-mail
From: Richard Damon <richard@damon-family.org>
Newsgroups: comp.theory
Subject: Re: Enforcing Flibble's Constraint
Date: Sun, 1 Jun 2025 07:20:29 -0400
Organization: i2pn2 (i2pn.org)
Message-ID: <8ac3facf73ec753bf266d8a06c491cfac923c867@i2pn2.org>
References: <XnU_P.277992$VBab.231491@fx08.ams4>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Sun, 1 Jun 2025 11:26:09 -0000 (UTC)
Injection-Info: i2pn2.org;
	logging-data="2818686"; mail-complaints-to="usenet@i2pn2.org";
	posting-account="diqKR1lalukngNWEqoq9/uFtbkm5U+w3w6FQ0yesrXg";
User-Agent: Mozilla Thunderbird
In-Reply-To: <XnU_P.277992$VBab.231491@fx08.ams4>
Content-Language: en-US
X-Spam-Checker-Version: SpamAssassin 4.0.0

On 6/1/25 4:42 AM, Mr Flibble wrote:
> 
> If HHH (the Simulating Halt Decider) embedded inside DDD simulates DDD as
> if DDD were executed externally, the question becomes one of modeling and
> intent:
> 
> Key Question:
> -------------
> Can DDD, which contains a call to HHH(DDD), simulate itself as though it
> were an external object?
> 
> This depends on how HHH treats the input DDD:
> - If HHH(DDD) simulates a clean copy of DDD, where DDD is treated as data,
> not code that is already running, then it avoids immediate recursion
> during actual execution.

Right, which is what HHH(DDD) needs to do. It needs to evaluate what the 
code of DDD actually does, independent of anything else that is 
happening in the currect execution context.

> - But if DDD is executed (rather than symbolically simulated), it causes
> recursion: DDD() calls HHH(DDD) which simulates DDD() again, leading to
> infinite descent.

Why is that? A symbolic simulaton should result in the same exact 
behavior as the direct execution.

If the behavior seen in the simulation done by HHH doesn't match the 
behavior of the direct exectution of the program given as the input, or 
the actual correct pure simulation of it, then HHH's simulation is just 
shown to be incorrect.

A SHD needs some method to stop its simulation, as deciders must always 
answer in finite time. This stopping doesn't releive them of the 
requirement to predict the behavior of the actual correct simulation, 
which will continue until a final state is reached (or continue forever).

Since, if HHH does stop and return, DDD will halt when run or be 
correctly simulated, HHH is just incorrect to say it doesn't halt.

The only case we get infinite decent, is the case where HHH isn't 
actualy a SHD, because it fails to meet the requirement to be a decider 
and to answer for this input.

> 
> Scenario Analysis:
> ------------------
> 
> Case 1: Symbolic Simulation (Safe)
> ----------------------------------
> int DDD() {
>      HHH(DDD); // HHH symbolically simulates DDD as data, not by executing
> it
> }

A SHD can NEVER just "execute" its input, as it is a type error to 
actually execute "data". It needs to determine what would happen if we 
executed the program that data represents.

> - This is type-safe under Flibble’s model.
> - There is no contradiction or paradox because:
>    - DDD is not being run, it's being simulated.
>    - Simulation stays at the meta-level.

But the definition of the correct answer is what would happen when we 
run the program that the input represents.

> 
> Case 2: Implied Execution (Unsafe)
> ----------------------------------
> int DDD() {
>      HHH(DDD); // HHH simulates DDD as if it were running as code
> }
> - If HHH simulates DDD() as if it were being run, and inside DDD() is
> HHH(DDD), then:

ALL simulation is "as if the program described by the input was run"

>    - The simulation mimics an execution which includes a simulation of an
> execution, and so on.

As it needs to.

>    - You get infinite recursion within the simulation, not the actual
> runtime stack.

No you don't, as this only happens when you presume that HHH isn't 
actually a SHD, which will abort

> 
> Result: This is not a type error per se, but it still leads to non-halting
> simulation. The program itself never finishes simulation and thus is
> correctly categorized as non-halting by HHH.

But that result is only for a non-SHD HHH, as a SHD HHH *WILL* abort 
after some time and return an answer to be a decider, and thus the DDD 
being run WILL halt. It just shows that it is incorrect of the SHD HHH 
to return 0, as that is the wrong answer.

> 
> Flibble's Typing Principle Preserved:
> -------------------------------------
> Even when DDD contains HHH(DDD), as long as:
> - DDD is only ever passed to HHH as an object of analysis,

Right, *TO HHH* it is only passed as an object of analysis.

The definition of which is that the input represents a program that can 
be run, and the correct answer for HHH is whether said program, 
represented by that input, will halt when it is run.

> - and HHH does not attempt to execute DDD directly but simulate its
> structure,

And give the answer about what the direct execution of the program 
described by its input will do when it is run.

> 
> then type stratification holds and paradox is avoided.
> 
> Summary:
> --------
> - Simulating DDD inside HHH, even if DDD includes HHH(DDD), is acceptable
> so long as execution never escapes the simulation layer.

But simulation is always defined to reveal what is at that execution layer.

> - This enforces Flibble's constraint: DDD must only ever be analyzed,
> never directly executed once it includes HHH(DDD).

WHich means that SHD are a non-semantic type, as their definition is 
self-contradictory, then need to report on the behavior that they 
prohibit being done.

Sorry, just shows that your theory is just a case of Natural Stupidity.