AI Slop

[Liberty Lover]

Hi All,

Feedback encouraged and welcomed!

The following will take you to some write-ups and prompting about "AI Slop"

See what you think.

Best,

Larry

[Chris Tillman]

The prompts encapsulate an excellent Eiffel development practice in a machine readable format. It seems to me one could pick this up and use it with an AI right away; is that the intent? I'm intrigued by the maintenance prompts. So, this could be a way to, for example, bring void safety to https://github.com/finnianr/Eiffel-Loop ?

--
You received this message because you are subscribed to the Google Groups "Eiffel Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to eiffel-users...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/eiffel-users/7d9128be-9a74-4fa3-a07e-3aa0631eea00n%40googlegroups.com.

--

Chris Tillman
Developer

[Liberty Lover]

  Chris,

  Yes, that's exactly the intent. The prompts are designed to be copy-pasted directly into an AI session (esp. Claude code, which has direct access to a limited part of your local environment) to guide it through disciplined Eiffel development. The key insight is that AIs generate "slop" when given vague instructions, but can be remarkably rigorous when given structured workflows with explicit verification gates.

  Regarding Eiffel-Loop and void safety - absolutely. The maintenance workflow (06_maintenance) is purpose-built for exactly this scenario. The prompts enforce a disciplined sequence:

  1. Audit Phase (M01-M04): Read the actual code, document findings with line numbers
  2. Strengthen Phase (M05-M06): Add missing contracts, fix void-safety issues
  3. Validate Phase (M07-M08): Compile and test after each modification

  The critical "anti-slop" rule: the AI must paste actual compiler output and test results. No claiming "I improved the code" without proof. This prevents the common failure mode where AI confidently describes changes it never made.

  For a codebase the size of Eiffel-Loop, you'd likely work class-by-class or cluster-by-cluster through the workflow.

  The newer 07_maintenance-xtreme workflow goes further with adversarial testing and mutation analysis if you want to stress-test the hardened code. I have used this workflow sequence about four times today on four separate projects and can attest that it does do what it says it can and will do. Additionally, it has found bugs as well — not many, but enough to know that it works as advertised. Here is an executive report of one of the applications I did with it today.

  Happy to discuss further if you want to experiment with it on a specific Eiffel-Loop component.

  Best,
  Larry

To view this discussion visit https://groups.google.com/d/msgid/eiffel-users/CAO299FuE4miZZZyRFMnNeMHiSwq216-0w%3Dn2S%2BMDWG%3Dqx9nHQQ%40mail.gmail.com.

[Liberty Lover]

  Chris,

  The newer 07_maintenance-xtreme workflow goes further with adversarial testing and stress analysis if you want to battle-test
  hardened code. I used this workflow today on simple_email and here's the executive summary:

  ---
  Executive Report: simple_email Hardening

  Library: simple_email (SMTP/TLS email client)
  Workflow: 07_maintenance-xtreme
  Date: 2026-01-18

  Reconnaissance (X01-X02)

  - 5 source files analyzed (SE_TLS_SOCKET, SE_SMTP_CLIENT, SE_MESSAGE, SE_ATTACHMENT, SIMPLE_EMAIL)
  - 103 features catalogued with contract coverage
  - 24 vulnerabilities documented including:
    - CRLF injection vectors in email addresses
    - Missing postconditions on network operations
    - Unbounded input sizes

  Contract Assault (X03)

  - 15 assault contracts deployed
  - Added email validation: address_has_at, address_no_newlines
  - Added state verification postconditions
  - Result: All existing tests still pass (contracts harden without breaking)

  Adversarial Testing (X04)
  ┌──────────────────────────┬────────────────────────┬────────────────────────────┐
  │           Test           │        Purpose         │           Result           │
  ├──────────────────────────┼────────────────────────┼────────────────────────────┤
  │ test_empty_email_address │ Block empty input      │ PASS (precondition fired)  │
  ├──────────────────────────┼────────────────────────┼────────────────────────────┤
  │ test_no_at_in_email      │ Block invalid format   │ PASS (precondition fired)  │
  ├──────────────────────────┼────────────────────────┼────────────────────────────┤
  │ test_crlf_injection_from │ Block SMTP injection   │ PASS (precondition fired)  │
  ├──────────────────────────┼────────────────────────┼────────────────────────────┤
  │ test_crlf_injection_to   │ Block header injection │ PASS (precondition fired)  │
  ├──────────────────────────┼────────────────────────┼────────────────────────────┤
  │ test_very_long_email     │ Boundary testing       │ PASS (1000+ chars handled) │
  ├──────────────────────────┼────────────────────────┼────────────────────────────┤
  │ test_binary_attachment   │ Special characters     │ PASS (null bytes accepted) │
  └──────────────────────────┴────────────────────────┴────────────────────────────┘
  Stress Testing (X05)
  ┌─────────────────────────────┬───────────┬────────┐
  │            Test             │   Scale   │ Result │
  ├─────────────────────────────┼───────────┼────────┤
  │ test_1000_recipients        │ 1000      │ PASS   │
  ├─────────────────────────────┼───────────┼────────┤
  │ test_100_attachments        │ 100       │ PASS   │
  ├─────────────────────────────┼───────────┼────────┤
  │ test_large_body             │ 1MB       │ PASS   │
  ├─────────────────────────────┼───────────┼────────┤
  │ test_rapid_message_creation │ 1000 msgs │ PASS   │
  └─────────────────────────────┴───────────┴────────┘
  Final Verification

  Results: 52 passed, 0 failed
  ALL TESTS PASSED

  Artifacts Produced

  - 7 hardening documentation files in hardening/
  - 16 new adversarial/stress tests committed
  - 15 new DBC contracts in production code

  ---
  The workflow found one test error during stress testing (my test used STRING.make + fill_with instead of make_filled), which
  demonstrates the value of actual execution over theoretical analysis.

  Happy to discuss further if you want to experiment with it on a specific Eiffel-Loop component.

  Best,
  Larry

[Liberty Lover]

Chris,

You have sparked my interest, which has caused me to clone the Eiffel Loop project from Github. Claude found that the place to start is Eiffel Loop's "base" library. We shall see what comes of it! Wish me godspeed!

Larry

On Sun, Jan 18, 2026 at 1:54 PM Chris Tillman <toff.t...@gmail.com> wrote:

To view this discussion visit https://groups.google.com/d/msgid/eiffel-users/CAO299FuE4miZZZyRFMnNeMHiSwq216-0w%3Dn2S%2BMDWG%3Dqx9nHQQ%40mail.gmail.com.

[Liberty Lover]

On Sun, Jan 18, 2026 at 1:54 PM Chris Tillman <toff.t...@gmail.com> wrote:

To view this discussion visit https://groups.google.com/d/msgid/eiffel-users/CAO299FuE4miZZZyRFMnNeMHiSwq216-0w%3Dn2S%2BMDWG%3Dqx9nHQQ%40mail.gmail.com.

[Liberty Lover]

First assessment:

● Assessment Complete

  Files Created in D:\eiffel_loop\:

  1. void-safety-conversion-plan.md - Detailed conversion strategy
  2. compilation-assessment.md - Full analysis of compilation errors
  3. ecf-files.md - List of all ECF files (created earlier)

  Key Finding: Modernization Required First

  Compilation with void_safety = "transitional" stopped at Degree 4 (Analyzing Inheritance) with 60+ errors. Most are NOT void-safety
   related:
  ┌────────────────────┬───────┬──────────────────────────────────────────────────┐
  │     Error Type     │ Count │                   Description                    │
  ├────────────────────┼───────┼──────────────────────────────────────────────────┤
  │ Obsolete syntax    │ ~50+  │ #$ and @ operators deprecated                    │
  ├────────────────────┼───────┼──────────────────────────────────────────────────┤
  │ VDRS               │ ~20   │ Redefine clauses for non-existent features       │
  ├────────────────────┼───────┼──────────────────────────────────────────────────┤
  │ VMFN               │ ~15   │ Feature name conflicts from multiple inheritance │
  ├────────────────────┼───────┼──────────────────────────────────────────────────┤
  │ ECMA-VHPR          │ 6     │ Generic derivation conflicts                     │
  ├────────────────────┼───────┼──────────────────────────────────────────────────┤
  │ VNCP (Void safety) │ 3     │ Only 3 visible - blocked by other errors         │
  └────────────────────┴───────┴──────────────────────────────────────────────────┘
  Root Cause

  The library was written for an older EiffelStudio version. ISE base library APIs have changed (features renamed/removed), and
  obsolete Eiffel syntax is used throughout.

  Recommended Next Steps

  Option A: First modernize to compile with void_safety = "none"
  - Fix obsolete operators (#$ → substitution calls, @ → item(n))
  - Resolve inheritance conflicts
  - Update for ISE API changes
  - THEN assess void-safety

  Option B: Use the 02_spec-extraction workflow to document current behavior before making changes

  Would you like me to proceed with fixing the modernization issues first, or would you prefer a different approach?

✻ Churned for 5m 23s

❯ do option A and then B???

● Let me start Option A - modernization. First, I'll set void_safety back to "none" to isolate non-void-safety issues.

● Update(eiffel_loop\library\base\base.ecf)
  ⎿  Added 1 line, removed 1 line
      20      </option>
      21      <capability>
      22        <concurrency support="none"/>
      23 -      <void_safety support="transitional"/>
      23 +      <void_safety support="none"/>
      24      </capability>
      25      <mapping old_name = "ZSTRING" new_name = "EL_ZSTRING"/>
      26      <mapping old_name = "DTC" new_name = "DATE_TIME_CODE"/>

● Bash(export ISE_EIFFEL="C:/Program Files/Eiffel Software/EiffelStudio 25.02 Standard" && export ISE_PLATFORM="win64"  timeout: 5m
      && export ISE_LIBRARY="$ISE_EIFFEL" && cd "D:/ei…)                                                                0s
  ⎿  Error: Exit code 127
     Eiffel Compilation Manager
     Version 25.02.9.8732 - win64

     Degree 6: Examining System
     Degree 5: Parsing Classes
     Degree 4: Analyzing Inheritance
     -------------------------------------------------------------------------------

     Obsolete syntax used at line 80 in class EL_USER_INPUT_VALUE [G]
     … +219 lines (ctrl+o to see all)

* Compiling and capturing modernization errors… (ctrl+c to interrupt · ctrl+t to hide todos · 42s · ↓ 1.7k tokens · thinking)
  ⎿  ☒ Change ECF to void_safety=none to isolate modernization issues
     ☐ Compile and capture modernization errors
     ☐ Fix obsolete #$ operator syntax (~50 occurrences)
     ☐ Fix obsolete @ operator syntax
     ☐ Fix VDRS redefine clause errors (~20)
     ☐ Fix VMFN feature name conflicts (~15)
     ☐ Fix ECMA-VHPR generic derivation conflicts (6)
     ☐ Fix remaining type/signature errors
     ☐ Compile cleanly with void_safety=none
     ☐ Run spec-extraction workflow (02)

On Sun, Jan 18, 2026 at 1:54 PM Chris Tillman <toff.t...@gmail.com> wrote:

To view this discussion visit https://groups.google.com/d/msgid/eiffel-users/CAO299FuE4miZZZyRFMnNeMHiSwq216-0w%3Dn2S%2BMDWG%3Dqx9nHQQ%40mail.gmail.com.

[Liberty Lover]

If anyone would like to join in with me, I have opened up a ZOOM meeting:

https://us06web.zoom.us/j/82538098721?pwd=ZRpbKEQlLc6ucaooY3a6BdwxjbhqQI.1

Larry's Zoom Meeting

Meeting ID

825 3809 8721

Passcode

452124

Invite link

https://us06web.zoom.us/j/82538098721?pwd=ZRpbKEQlLc6ucaooY3a6BdwxjbhqQI.1

Host

Larry

Participant ID

376304

[Liberty Lover]

I can already tell you all what I am going to do: Once I have the "Base" library for Eiffel Loop compiling in full modern Void Safety — I am going to drag it over into Simple Eiffel (e.g. a new simple_loop library) and then stepwise replace all of the Eiffel base library with corresponding simple_* libraries, until Eiffel Loop (simple_loop) is built on Simple Eiffel libs. Then, I will have the remaining ISE/Gobo dependencies replaced with additional simple_* where needed. Once I have that all done. I will attack the entire thing with a first-push round of adding testing and then to the maintenance-Xtreme round to harden the entire thing. I will wash back over it several times with design, refactor, updated specs, and research for RFC and other notions. The goal will be to completely extend, expand, harden, prove, and modernize Eiffel Loop Base as simple_loop. Once that is done, then it will be on to pulling over the other Eiffel Loop libraries one at a time until the entire thing is living in SImple Eiffel. Thus, we will be able to (in modern times) take wonderful full advantage of all of the excellent work that has been put into Eiffel Loop, but fell behind.

Wish me luck.

[Bertrand Meyer]

Void safety can be a pain. But there is no going back. One should not even think of using Eiffel otherwise.

 

-- BM

To view this discussion visit https://groups.google.com/d/msgid/eiffel-users/CA%2B3qnjdmRhEPKggL2-4qdTyeA%2B%2B6bSkWf%3DYXUyUq4KdvNPhujw%40mail.gmail.com.

[Liberty Lover]

Utterly true, which is why I NEVER used Eiffel Loop. It wasn't even an option. Now, once Claude and I get this updated to Void Safe, then it will open up the dam to using it, extending, and improving it.

To view this discussion visit https://groups.google.com/d/msgid/eiffel-users/1b8a01dc88c0%2462fb5890%2428f209b0%24%40inf.ethz.ch.

[Liberty Lover]

Bertrand,

FWIW: It's almost at the point where it will be compiling on the latest compiler and ready to be made completely Void Safe.

Larry

On Sun, Jan 18, 2026 at 4:21 PM Bertrand Meyer <Bertran...@inf.ethz.ch> wrote:

To view this discussion visit https://groups.google.com/d/msgid/eiffel-users/1b8a01dc88c0%2462fb5890%2428f209b0%24%40inf.ethz.ch.

[Liberty Lover]

  Assessment: Eiffel-Loop Base Library Modernization

  Summary

  This work focuses on modernizing the Eiffel-Loop base.ecf library to compile with EiffelStudio 25.02 using void_safety="none". The
  library contains 1,027 source files and serves as the foundation with no external Eiffel-Loop dependencies.

  Completed Work

  1. ECF Modernization: Updated base.ecf from schema 1-16-0 to 1-23-0 with proper capability sections for void safety.
  2. Obsolete Syntax Fixes (14 files):
    - Removed #$ (string evaluation) operator syntax from 12 files
    - Removed @ (address) operator syntax from 2 files
  3. Inheritance Error Fixes:
    - VDRS(4): Fixed redefine clauses that listed deferred features
    - VHRC(1): Removed renames for features that no longer exist in ISE libraries
    - VLEL(2): Removed exports for non-existent features
    - VMFN: Resolved feature name conflicts from multiple inheritance (particularly with PLAIN_TEXT_FILE changes in EiffelStudio
  25.02)
  4. Generic Derivation Conflicts (ECMA-VHPR): Fixed by replacing problematic EL_STRING_X_BIT_COUNTABLE inheritance with direct
  EL_X_BIT_IMPLEMENTATION in:
    - EL_STRING_8_ROUTINES_IMP
    - EL_STRING_32_ROUTINES_IMP
    - EL_ZSTRING_ROUTINES_IMP
    - EL_IMMUTABLE_STRING_8_GRID
    - EL_IMMUTABLE_STRING_32_GRID

  Outstanding Issues

  1. has alias conflicts: The ISE SET class now adds alias "∋" to has, creating repeated inheritance conflicts through multiple paths
   (TRAVERSABLE_SUBSET vs FINITE vs CONTAINER). Requires careful handling of select clauses and renamed versions.
  2. is_subset alias: TRAVERSABLE_SUBSET adds alias "⊆" which must be preserved in redefinitions.
  3. EL_ZSTRING plus alias conflict: The + operator is inherited through multiple paths with different names (plus vs
  readable_plus_general), requiring select clauses.

  Technical Observations

  1. ISE EiffelStudio 25.02 API Changes: Significant changes to standard library classes (PLAIN_TEXT_FILE now has encoding,
  set_encoding, put_string_general, put_string_32) cause cascading inheritance conflicts.
  2. Unicode alias handling: EiffelStudio on Windows requires UTF-8 BOM for files containing Unicode aliases like ∋ and ⊆. Files
  without BOM fail to parse.
  3. The alias system complexity: Unicode operator aliases create significant maintenance burden when inherited through multiple
  paths, as each path may rename or redefine the feature differently.

  Recommendations

  1. Complete the remaining has and is_subset alias fixes by:
    - Using consistent rename strategies in inheritance clauses
    - Adding implementations for renamed deferred features
    - Using UTF-8 BOM encoding for all files with Unicode aliases
  2. Consider whether the custom EL_SET class should be reconciled with ISE's SET alias conventions.
  3. After achieving clean compilation with void_safety="none", proceed with spec-extraction (workflow 02) to document current
  behavior before void-safety conversion.

✻ Churned for 49m 46s

  Todos · ctrl+t to hide todos
  ☒ Fix obsolete syntax (#$ and @)
  ☒ Fix VDRS redefine clause errors
  ☒ Fix remaining VDRS error (EL_REFLECTED_NUMERIC_FIELD)
  ☒ Fix VHRC(1) invalid rename (EL_SYSTEM_TIME)
  ☒ Fix VLEL(2) invalid export (EL_STEP_TOKEN_LIST)
  ☒ Fix VMFN feature name conflicts
  ☐ Fix ECMA-VHPR generic derivation conflicts (~7)

  ☐ Compile cleanly with void_safety=none
  ☐ Run spec-extraction workflow (02)

[Liberty Lover]

● The inheritance conflicts (ECMA-VHPR, VMRC, VDRS, etc.) are now resolved. The remaining ~530 errors are type-checking issues due to
   ISE library API changes.

This is coming from the fact that Eiffel Loop is VERY stale relative to the modern ISE and Gobo libraries upon which it depends. Claude is hammering through the issues. We shall see what comes of it all.

[Liberty Lover]

● The inheritance and structural issues are now fixed. The remaining ~530 errors are API compatibility issues with EiffelStudio
  25.02:

  Error patterns:
  - cursor_index unknown identifier (55+ occurrences) - ISE changed iteration cursor API
  - item unknown identifier - similar cursor changes
  - VUAR (169) - feature signature changes

  Current state:
  - Degree 4 (Analyzing Inheritance) ✅ passes
  - Degree 3 (Checking Types) - 530+ API compatibility errors

  This is a significant undertaking. The cursor_index pattern alone affects 34 files. These are ISE library API breaking changes, not
   issues with the Eiffel-Loop code design.

  Would you like me to:
  1. Continue systematically fixing these type-checking errors (starting with cursor_index pattern)?  ✅ 
  2. Document the current state and errors for Bertrand/Chris to review?
  3. Something else?

[Chris Tillman]

Wow. Just wow. I think documenting the current state is very important, and will also serve as a benchmark for how quickly this type of task can be completed. An amazing result already. 

To view this discussion visit https://groups.google.com/d/msgid/eiffel-users/CA%2B3qnjfTtKWm%2BJO_roQoW82hibr_cv4xQZU370kWimuB9jQ44Q%40mail.gmail.com.

--

Chris Tillman
Developer

[Liberty Lover]

The experiment to BRUTE FORCE Eiffel Loop to modern Void Safe Eiffel has ... regrettably ... FAILED. So, another approach that is AI-friendly is warranted.

----

❯ stop ... please revert the Eiffel Loop Base lib back to its original from github.

● I'll revert the Eiffel Loop Base library to its original state from GitHub.

● Bash(cd D:/eiffel_loop/eiffel_loop && git status --short | head -30)
  ⎿   D example/manage-mp3/nul
      M library/base/base.ecf
      M library/base/data_structure/arrays/el_version_array.e
     … +27 lines (ctrl+o to expand)

● Bash(cd D:/eiffel_loop/eiffel_loop && git checkout -- library/base/)
  ⎿  (No content)

● Bash(cd D:/eiffel_loop/eiffel_loop && git status --short library/base/ | wc -l)
  ⎿  2

● Bash(cd D:/eiffel_loop/eiffel_loop && git status --short library/base/)
  ⎿  ?? library/base/EIFGENs/
     ?? library/base/exception_trace.log

● The source code has been reverted. Let me clean up the generated files too.

● Bash(cd D:/eiffel_loop/eiffel_loop && rm -rf library/base/EIFGENs/ library/base/exception_trace.log)
  ⎿  (No content)

● Bash(cd D:/eiffel_loop/eiffel_loop && git status --short library/base/)
  ⎿  (No content)

● Done. The Eiffel Loop Base library has been reverted to its original state from GitHub. The library/base/ directory is now clean
  with no modified files.

✻ Churned for 46s

❯ That was a completely heroic try but we're going to have to do this a different way.

● Understood. The VGCC(2) errors turned out to be deep architectural issues - deferred classes inheriting features that create like
  Current. Fixing those would require significant structural changes across many classes.

  I'll clear the todo list since we're starting fresh.

● Ready when you are. What's the new approach?

To view this discussion visit https://groups.google.com/d/msgid/eiffel-users/CAO299FtpoB3LbK%2B4_MNtg-_-VqK0p%2BKxKON%3DQCfFgr5BLR51Kw%40mail.gmail.com.