Model purity escape hatch as adoption enabler?

[Rob Meijer]

Working on a DSL I have been gradually reusing a keyword (I'll call it a keyword for practical reasons, it isn't actually) to denote non idiomatic constructs like awaiting inside of a semantic locks, hard coding an API key as a string literal, assigning a value roman integer that the compiler can't see will always fit, etc, etc. 

This keyword "hazardous" is basically an escape hatch for the purity of the least authority and overall robustness of the base language, but a help, I hope, in hacking together prototype code. 

By default the code wont be accepted by the compiler or scripting runtime because basically the semantic lexer errors out on the keyword unless a compiler flag is used. 

And by default, the compiler flag isn't transitive to modules, you need to explicitly enable modules (merge) transitivity.

For example:

compiler /my/app/dir --trustmebro=literal

would allow an API key as string literal in the main program but not in any modules.

compiler /my/app/dir --trustmebro=ALL

would allow all possible uses of "hazardous" in the main program and still none in the modules.

compiler /my/app/dit --trustmebro=blocker --trustmebro=cast,merge

would allow the main program to use "hazardous" for blockers inside of semantic locks, for questionable casts and for marking hazardous as transitive to specific module includes (merge), while allowing unprovable safe integer casts to be used by these module functions.

The idea is that the programmer will look at the --trustmebro in their makefile and the "hazardous" in their source file and think: yes, I need to fix this later, but still feel free to sprinkle then in while prototyping to get things done and maintain velocity.

I'm both interested and a bit nervous about the view of others regarding this idea of this "you shouldn't want to do this, but we'll let you, just remind yourself to fix it" philosophy.

Is this a practical language feature? Extra "get things working now, get them robust later"?  Or is this a collection of things that shouldn't be in a least authority languages in the first place, and should the least authority pain of "there is only the safe and robust way to do things" be an immutable reality?

I had the hunch that a language feature like this could be an adoption enabler, but maybe I'm just setting things up so that everyone is just going to write --trustmebro=merge,ALL and never ever think about it again.

[Alan Karp]

In my experience, prototypes end up shipping, so your proposal looks dangerous to me.

--------------
Alan Karp

--
You received this message because you are subscribed to the Google Groups "cap-talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cap-talk+u...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/cap-talk/CAMpet1WCKk5r_uCSnwStLTYE_F9w1%2B015mL7ddxRPmQoXq_2TQ%40mail.gmail.com.

[Rob Meijer]

That's actually a major reason to name the compile flag --trustmebro (trust me bro) and not --nonstrict, and why I called the expression modifier by one name, "hazardous" and not by multiple more descriptive words for each such escape hatch.  ("checked" for integer sizes, "highprio" for awaits inside a lock, "sensitive" for sensitive data literals).

The idea that "hazardous" as a single term stands out as a FIXME, and that --trustmebro has such an unprofessional feel that no PM would want it in their pipeline.

Make it hurt to everyone's eyes to leave it in there. 

But maybe I'm overestimating the aesthetic power of words in that sense. 

To view this discussion visit https://groups.google.com/d/msgid/cap-talk/CANpA1Z1JLD3YU_fp1XxQ4cj%3Dd3EGLd9jDjxMxhTD8DnWfjo9SA%40mail.gmail.com.

[Alan Karp]

On Sat, Jan 3, 2026 at 1:48 PM Rob Meijer <pib...@gmail.com> wrote:

But maybe I'm overestimating the aesthetic power of words in that sense. 

I think you are also underestimating the pressure to ship.  That's why API keys appear in executables in the first place.

--------------
Alan Karp

[Rob Meijer]

I'm not sure, because that pressure could potentially incept lying to the type system too, so maybe it's a critical  band of pressure to ship that determines what is a good balance for a language?

I mean, my parser doesn't have the intelligence to determine if a literal of a type with the capacity to carry a medium to high entropy value is sensitive or inert.

Let me illustrate:

inert float128 π = 3.1415926535897932384626433832795028; sensitive string apiKey1 = ambient.settings.vault.innuendofs "innuendo-api-key";

hazardous string apiKey2 = "secret_07b4aa79cf653" ;

The first is ok because the user promised that pi is inert. The second is OK because the sensitive data is extracted from a vault. The third is not OK for production because the sensitive data is hard coded into he source code.

But if I "never" allowed hazardous code like this, the user under pressure to ship could also just lie to the type system:

inert string apiKey2 = "secret_07b4aa79cf653" ;

So I feel the question is: how likely is it that the pressure to ship is high enough to leave in a "hazardous" that removing a --trustmebro would make illegal, but low enough for the user not to lie to the type system and just leave the lie in?

--------------
Alan Karp

--
You received this message because you are subscribed to the Google Groups "cap-talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cap-talk+u...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/cap-talk/CANpA1Z3PdedrJCWaTj2%2BU_5zPhk7tyTtN8ziEH7%2BVW6E_%3DgFRQ%40mail.gmail.com.

[Raoul Duke]

another way of saying it, perhaps: when & how should errors be treated as warnings?

as long as there is a way for CI on PRs to the main branch to be strict no matter what,  short of the string cheat you showed, ie CI must never run with --trustmebro, then the developer could use the flag locally "safely". 

[Rob Meijer]

For completeness, this is currently the complete list of situations where the "hazardous" modifier applies:

* hazardous <scalartype> : When puting sensitive data in a scalar literal
* hazardous typecast : When casting an integer into an integer type the compiler thinks may be too small to hold the value
* hazardous prune : When soft-pruning a DAG and relying on non-deterministic restructuring of the remaining graph into a still rule-compliant DAG.
* hazardous blocker : When using a blocker inside of a lock
* hazardous <custom operator> : Whatever meaning a user operator-extending the language assigns to hazardous for their operators.
* hazardous frozen : When the compiler can't figure out if a mutable is frozen or not, and the user is sure that it is.
* hazardous merge : When communicating to the lexer in a merge (surgical import) that an imported function or same-module code it invokes is allowed to use hazardous and for what.

On Sun, Jan 4, 2026 at 6:53 PM Raoul Duke <rao...@gmail.com> wrote:

another way of saying it, perhaps: when & how should errors be treated as warnings?

as long as there is a way for CI on PRs to the main branch to be strict no matter what,  short of the string cheat you showed, ie CI must never run with --trustmebro, then the developer could use the flag locally "safely". 

--
You received this message because you are subscribed to the Google Groups "cap-talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cap-talk+u...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/cap-talk/CAJ7XQb6xZ%2BSxC3xBZwMkQ9O7RiXKTjPYxzwqXL8XxU1pBLUmTA%40mail.gmail.com.