Simple Eiffel - Notebook (akin to Jupyter)

[Liberty Lover]

● 📢 Announcing Eiffel Notebook - Interactive Eiffel Programming

  The Vision

  Eiffel Notebook brings the interactive notebook experience to the Eiffel programming language. Inspired by Jupyter notebooks and REPLs, it lets you write, execute, and iterate on Eiffel code interactively - perfect for learning, prototyping, and exploring the Simple Eiffel ecosystem.

  ---
  What We've Built (Alpha.20)

  Core Execution Engine

  - Accumulated class generation - Cells compile into a single class that preserves state
  - Melt-based compilation - Uses EiffelStudio's fast incremental compilation
  - Real-time streaming output - Watch ec.exe compile in real-time, not just after
  - Auto-detect EiffelStudio - Works out of the box via ISE_EIFFEL detection

  Interactive CLI

  - Smart multi-line input - Automatic continuation for do, if, class, etc.
  - Syntax completeness detection - Knows when your code is ready to execute
  - Dash commands - -help, -vars, -list, -save, -compile verbose
  - Session logging - Full DBC trace logging with caller/supplier contracts

  Variable Tracking

  - Cross-cell state - Variables persist between cell executions
  - Shared variable detection - Identifies variables meant to span cells
  - Type tracking - Remembers variable types and defining cells

  Error Handling

  - Line mapping - Maps compiler errors back to original cell lines
  - Underline formatting - Visual indication of error location
  - Error classification - Distinguishes syntax, type, and validity errors

  Persistence

  - JSON notebook format - Save/load complete notebook state
  - Config file support - Customize paths, timeouts, preferences
  - Workspace management - Clean temporary files between runs

  ---
  Technical Highlights

  | Component            | Implementation                                |
  |----------------------|-----------------------------------------------|
  | Compiler integration | SIMPLE_ASYNC_PROCESS for streaming            |
  | Code generation      | ACCUMULATED_CLASS_GENERATOR                   |
  | Variable analysis    | VARIABLE_TRACKER with pattern matching        |
  | Error parsing        | COMPILER_ERROR_PARSER for EiffelStudio output |
  | Storage              | JSON via SIMPLE_JSON                          |
  | Process control      | SIMPLE_PROCESS + SIMPLE_ASYNC_PROCESS         |

  Test coverage: 80 tests passing across all components

  ---
  What's Ahead

  Phase 2: Enhanced UX

  - 🔲 Variable change markers (highlight what changed between executions)
  - 🔲 Session persistence (resume exactly where you left off)
  - 🔲 Command history with search (up-arrow, Ctrl+R)
  - 🔲 Cell editing (modify previous cells)

  Phase 3: Web Interface

  - 🔲 Browser-based notebook UI
  - 🔲 Markdown cell rendering
  - 🔲 Syntax highlighting
  - 🔲 Output visualization

  Phase 4: Advanced Features

  - 🔲 Export to standalone Eiffel project
  - 🔲 Import existing .e files as cells
  - 🔲 Library exploration (introspect Simple Eiffel APIs)
  - 🔲 Notebook sharing format

  ---
  Get Started

  Download: eiffel_notebook_setup_1.0.0-alpha.20.exe

  Repository: https://github.com/simple-eiffel/simple_notebook

  Eiffel Notebook 1.0.0-alpha.20
  Type Eiffel code to execute. Type -help for commands.

  e[1]> name: STRING := "Eiffel"
  e[2]> print ("Hello, " + name + "!")
  Hello, Eiffel!
  e[3]> -compile verbose
  Compile mode: verbose (shows compiler output)
  e[3]> x: INTEGER := 42
  Eiffel Compilation Manager
  Version 25.02.9.8732 - win64
  Degree 6: Examining System
  ...
  C compilation completed
  e[4]>

  ---
  Part of Simple Eiffel

  Eiffel Notebook is built on the Simple Eiffel ecosystem - 60+ libraries providing modern, DBC-compliant Eiffel components. It uses:
  - simple_process - Async process execution with streaming
  - simple_json - Notebook persistence
  - simple_file - File operations
  - simple_datetime - Timing and timestamps
  - simple_testing - Test framework

  ---
  Built with Design by Contract. Powered by EiffelStudio.

[Liberty Lover]

Simple Notebook is now all in the family!

--
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/96c84756-9b6c-48a5-aeb5-1684d932f9e9n%40googlegroups.com.

[Liberty Lover]

I am going to pause here (once I have the code set up for cross-platform for Linux/Windows) and allow anyone who wants to use Eiffel Notebook to do so and provide feedback.

I have a Mac Mini that needs to be set up and some other local chores. I will handle your feedback as quickly as possible. So, please — give me all the feedback you can so we can quickly improve Eiffel Notebook at the CLI console UX level. Once that is stable and everyone likes it, then we will/can move on to the TUI level. And once that is stable, we can move on to the VS Code LSP level.

Along the way, I am going to be seeing if I can leverage the Eiffel W_code runtime and melting-ice tech to make the compile-times "sub-second". That's a step yet to come. So, hold on to that thought.

Best,

Larry

On Sat, Dec 20, 2025 at 12:07 PM Liberty Lover <rix....@gmail.com> wrote:

--

[Liberty Lover]

[Liberty Lover]

[javier...@gmail.com]

Great Larry, I will check soon and give you my feedback.

[Liberty Lover]

New version is just about ready ... I will let you know.

To view this discussion visit https://groups.google.com/d/msgid/eiffel-users/e7b3e290-841a-41b5-9fa8-fdddd66a687cn%40googlegroups.com.

[Liberty Lover]

✢ Implementing session persistence… (esc to interrupt · ctrl+t to hide todos · 17m 29s · ↓ 2.9k tokens · thinking)
  ⎿  
     ☒ Document Phase 2 design in reference docs
     ☒ Log Phase 2 design to oracle
     ☒ Implement variable change markers
     ☐ Implement session persistence
     ☐ Implement command history

[Liberty Lover]

Incoming!!!!

[Liberty Lover]

● simple_notebook Phase 2 command history implementation complete.

  What was added:

  1. New classes in cli/:
    - COMMAND_HISTORY - Manages persistent history storage, navigation, and search
    - HISTORY_ENTRY - Individual history entry with timestamp, cell number, and input
  2. New CLI features:
    - -history [N] - Show last N commands (default 20)
    - !N - Re-execute cell N from history
    - !! - Re-execute last cell
  3. Persistence:
    - History stored in ~/.eiffel_notebook/history
    - Survives across sessions
    - Format: timestamp|cell_number|input (one entry per line)
    - Max 1000 entries (oldest trimmed)

  Version: 1.0.0-alpha.22

  Files created/modified:
  - cli/command_history.e - new
  - cli/history_entry.e - new
  - cli/notebook_cli.e - integrated history
  - simple_notebook_setup.iss - updated to alpha.22
  - README.md - updated with new commands and Phase 4 complete status

  Tests: All 80 tests pass

  Windows Installer: simple_notebook/installer/eiffel_notebook_setup_1.0.0-alpha.22.exe

To view this discussion visit https://groups.google.com/d/msgid/eiffel-users/369bef90-175a-4041-ad08-a45703f49d75n%40googlegroups.com.

[Liberty Lover]

● Melt Mode Integration Complete!

  Summary

  Integrated EiffelStudio's "Melting Ice" technology into simple_notebook for 10-30x faster cell execution:

  | Mode   | Command            | Time      | When                                      |
  |--------|--------------------|-----------|-------------------------------------------|
  | Freeze | -freeze -c_compile | ~14s      | First cell (creates bytecode interpreter) |
  | Melt   | -quick_melt        | ~0.5-1.5s | Subsequent cells (bytecode only)          |

  Changes Made

  cell_executor.e - Added:
  - is_frozen: BOOLEAN - Tracks if initial freeze done
  - check_frozen_status - Detects existing W_code exe
  - reset_frozen_status - Forces fresh freeze if needed
  - build_compile_command - Returns freeze or quick_melt command
  - Modified compile_generated_class to show (freeze) or (melt) indicator

  How It Works

  1. First cell → No W_code exe exists → Run freeze with C compile (~14s)
  2. W_code exe now contains embedded bytecode interpreter
  3. Next cells → W_code exe exists → Run quick_melt (~0.5-1.5s)
  4. Exe loads .melted file and interprets new bytecode
  5. If melt fails → Resets is_frozen → Next run will re-freeze

  Verification

  - All 80 tests pass
  - Version updated to alpha.23
  - Research doc updated with integration details

On Sat, Dec 20, 2025 at 12:07 PM Liberty Lover <rix....@gmail.com> wrote:

--

[Liberty Lover]

● Done!

  | Item             | Status                                                                  |
  |------------------|-------------------------------------------------------------------------|
  | Commit           | ✅ 3714dca - feat(alpha.23): Melt mode for 10-30x faster cell execution |
  | Push             | ✅ Pushed to simple-eiffel/simple_notebook                              |
  | Installer        | ✅ eiffel_notebook_setup_1.0.0-alpha.23.exe built                       |
  | Installer commit | ✅ b93e11b - pushed                                                     |

  Alpha.23 features:
  - Melt mode: 10-30x faster cell execution (0.5-1.5s vs 10-15s)
  - Command history (up/down arrows, !N recall, -history)
  - Variable change markers (new/modified indicators)
  - Session persistence (-save, -open, -new, -notebooks)

[Liberty Lover]

  Summary

  Current Limitations now documented:

  | Supported                    | Not Yet Supported                           |
  |------------------------------|---------------------------------------------|
  | Attributes (x: INTEGER)      | Multi-class definitions (class CAR ... end) |
  | Routines with DBC            | Multiple inheritance experiments            |
  | Instructions and expressions | Generic class definitions                   |
  | Local variables              | Separate class files                        |

  Comparison to other REPLs:
  - Python/Ruby/JS: ✅ (interpreted - classes are runtime objects)
  - Scala/Kotlin: ✅ (incremental JVM bytecode)
  - Swift: ✅ (LLVM JIT)
  - Java JShell: ✅ (special compiler integration)
  - Eiffel Notebook: ❌ Not yet (compiles to C)

  Phase Roadmap Updated:
  - Phase 5: Multi-class support (CAR, SUBMARINE, JAMES_BOND_CAR with MI)
  - Phase 6: Web interface

  Implementation approach for Phase 5:
  1. Detect class NAME ... end cells
  2. Generate separate .e files per class
  3. ECF cluster already includes workspace
  4. Track class dependencies for recompilation
  5. Enable multiple inheritance experiments interactively

  This would be unique for Eiffel - no other Eiffel REPL supports interactive MI experiments!

[Eric Bezault]

On 21/12/2025 15:51, Liberty Lover wrote:
>   5. Enable multiple inheritance experiments interactively
>
>   This would be unique for Eiffel - no other Eiffel REPL supports
> interactive MI experiments!

What does that mean?

--
Eric Bezault
mailto:er...@gobosoft.com
http://www.gobosoft.com

[Chris Tillman]

I'm thinking MI = Melting Ice

--
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/10c1ca8b-cccf-4e54-b2a7-38585375da28%40gobosoft.com.

--

Chris Tillman
Developer

[Liberty Lover]

Hey Chris,

MI = Multiple Inheritance

Although I can understand how you got to MI = Melting Ice, which Simple Eiffel Notebook does now use. I am just about ready to ship the version of Notebook with that capacity.

To view this discussion visit https://groups.google.com/d/msgid/eiffel-users/CAO299FtkNPyv42VgGEEF-yxeJZupkNFERg7sg1seGxQVz-GW1g%40mail.gmail.com.

[Liberty Lover]

The finishing touches are being put on the simple_notebook Readme.md and on the /docs as well as the User Guide in the ref-docs.

On Sun, Dec 21, 2025 at 1:14 PM Chris Tillman <toff.t...@gmail.com> wrote:

To view this discussion visit https://groups.google.com/d/msgid/eiffel-users/CAO299FtkNPyv42VgGEEF-yxeJZupkNFERg7sg1seGxQVz-GW1g%40mail.gmail.com.

[Liberty Lover]

● All documentation tasks complete:

  README.md updated:
  - Status: Alpha 34, Phase 5 complete
  - Added "Multi-Class with Multiple Inheritance" section with CAR/BOAT/CAR_BOAT example
  - Added "Editing Existing Classes" section
  - Added -class NAME to CLI commands
  - Updated Features with multi-class, MI, class editing, silent compile
  - Removed "Current Limitations" section (multi-class now supported)
  - Updated Phase 5 status to COMPLETE

  docs/index.html updated:
  - Version to alpha.34
  - Added multi-class feature cards
  - Added -class NAME to CLI reference

  docs/user-guide.html updated:
  - Version to alpha.34
  - New "Multi-Class Support" section with examples
  - Class cell type added to classification table
  - -class NAME added to commands

  Announcement drafted:
  - Saved to Ref-docs here.
  - Ready to post to Eiffel users group
  - Includes multi-class examples, installation instructions, and links

  All changes committed and pushed to GitHub.

[Eric Bezault]

Hi Larry,

Two remarks about:

https://github.com/simple-eiffel/simple_rosetta/blob/master/solutions/tier4_complex/fibonacci_sequence.e

- Instead of having this postcondition:

non_negative_result: Result >= 0

why not declare the result as NATURAL_64 instead of INTEGER_64.

- The fibonacci functions deserve a better postcondition than just
that the result is not negative. A "definition: Result = ..."
postcondition would be a good way to show how DbC can help proving
that code generated by AI is correct. I know, the execution with
postconditions enabled will be slower, but DbC is about demonstrating
correctness, not speed. For speed, we compile with assertions off.

[Eric Bezault]

On 21/12/2025 15:51, Liberty Lover wrote:

>   5. Enable multiple inheritance experiments interactively
>
>   This would be unique for Eiffel - no other Eiffel REPL supports
> interactive MI experiments!

With https://codeboard.io/ one can also experiment with Eiffel
(and with multiple inheritance) without having to install an
Eiffel compiler or IDE on the local computer. It's not a true
REPL, but experiments are possible.

[Liberty Lover]

Hi Eric,

I forgot about the codeboard site. Yet, there are advantages.

We want people installing Eiffel in some form, do we not? And when they do that, they learn quite a bit more and become engaged, do they not?

Ultimately, the Simple Eiffel Notebook will go into the VS Code LSP. And there they can REPL as much as they want, or need.

Best,

Larry

--
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/8c2247d1-e1a6-42fd-9a55-914255a5a42f%40gobosoft.com.

[Liberty Lover]

  The Big Idea Behind Simple Rosetta

  In a design discussion with Claude about creating a QLoRA LLM extension for Ollama Qwen Coder 2.5 7b, the topic of "instruction pairs" came up—and Simple Rosetta was born from that conversation.

  What Are Instruction Pairs?

  An instruction pair is essentially a question-answer pair that the LLM training process ingests to extend the model's capabilities. These pairs get quantized for efficiency (typically 4-8 bits in QLoRA). But to create quality instruction pairs, you need quality source data.

  Simple Rosetta provides some of that data. It's a "two-birds-one-stone" solution:

  1. For Rosetta Code: Increase Eiffel's visibility by contributing high-quality solutions
  2. For LLM Training: Generate cross-language instruction pairs like:
    - "How do I implement quicksort in Eiffel?" → [Eiffel solution with DbC]
    - "Convert this Python fibonacci to Eiffel" → [Idiomatic Eiffel translation]

  The user querying the LLM might be familiar with Python, Go, or Rust—Simple Rosetta helps the model answer "How would I do this in Eiffel?" by having seen hundreds of side-by-side comparisons.

  The Specialist Model

  Instead of building a single monolithic "knows-everything-about-Eiffel" LLM, I'm designing a team of specialists. Think of it like a medical team—each doctor focuses on their specialty, while and as they collaborate on the patient.

  A single do-it-all Eiffel LLM would either be:
  - Massive (too large to run locally on reasonable hardware — I have 16 GB on a NVidia 5070 Ti), or ...
  - Shallow (knows a little about everything, expert at nothing)

  Instead, imagine:

  | Specialist         | Focus                                    | Training Data                      |
  |--------------------|------------------------------------------|------------------------------------|
  | Rosetta Specialist | Cross-language translation, algorithms   | Simple Rosetta pairs               |
  | DbC Specialist     | Contracts, preconditions, postconditions | OOSC2 examples, simple_* contracts |
  | SCOOP Specialist   | Concurrency, separate objects            | SCOOP patterns, parallel code      |
  | Library Specialist | simple_* ecosystem, APIs                 | Library docs, usage examples       |

  Each specialist is a small, focused QLoRA adapter (~100-500MB) that can be loaded on demand. When you ask "How do I implement a thread-safe cache in Eiffel?", the system routes to the SCOOP + Library specialists. 

  Why This Matters

  The Eiffel ecosystem is small but deep. Rather than diluting expertise across a bloated model, specialists let us:
  - Train efficiently on focused datasets
  - Update incrementally as libraries evolve
  - Run locally on developer hardware
  - Combine dynamically based on the question

  Simple Rosetta is the first specialist's training ground—turning 1,300+ Rosetta Code tasks into Eiffel instruction pairs, one solution at a time.

  What system? The vision is to provide either a human-operated or AI-operated (e.g. Claude code) LLM that understands which specialist needs to be consulted, loads the proper model in the GPU, and answers the question or does the work. The idea is to replace what I am doing with Claude now that is based on a simple SQL database or on markdown documents. The problem with this is that it is token heavy and Claude "forgets" as it either moves from session to session or has its session compacted (compaction is lossy). Ultimately, a local FTS5 Sqlite DB as a knowledge-base plus a group of specialized LLM's ought to be a decent, quick, and reliable solution for generating high-quality Eiffel solutions as code or commentary (or both).

[Liberty Lover]

In case you are wondering.

QUESTION: 

How many "solutions" have we addressed so far, plus solutions that were already a part of Rosetta Code?

ANSWER:

● Here's the breakdown:

  | Category                        | Count                    |
  |---------------------------------|--------------------------|
  | Existing Eiffel on Rosetta Code | 157 tasks (11% coverage) |
  | New solutions we created        | 99 solutions             |
  | Total Rosetta Code tasks        | 1,339                    |

  Combined Picture

  If we submit all our solutions (assuming minimal overlap with existing):
  - Potential Eiffel coverage: ~256 tasks (~19% of Rosetta Code)
  - Nearly doubles Eiffel's presence on the site

  Our Solutions by Tier

  | Tier | Difficulty | Count |
  |------|------------|-------|
  | 1    | Trivial    | 28    |
  | 2    | Easy       | 40    |
  | 3    | Moderate   | 19    |
  | 4    | Complex    | 12    |

  For LLM Training

  This gives us raw material for instruction pairs:
  - 99 new Eiffel solutions with cross-language comparison potential
  - 157 existing solutions that can be scraped and paired
  - Each task on Rosetta has solutions in 10-50+ other languages

  So roughly 250+ Eiffel implementations that can each generate multiple instruction pairs like:
  - "Convert Python version to Eiffel"
  - "How do I do X in Eiffel?"
  - "Show me Eiffel with proper contracts for Y"

  That's potentially 1,000+ instruction pairs just from the Rosetta specialist alone.

The goal is to have 100% coverage of all Rosetta Code "tasks" locally in Simple Rosetta. Now, getting those into Rosetta Code itself is another matter and not one I am likely to do. Honestly, it would be nice, but it's not on my to-do list.

Best,

Larry

[Liberty Lover]

Claude builds out tests for all "solutions" currently in Simple Rosetta. With this, we have only about 1,339 (total Rosetta tasks) - 157 (Eiffel presently on Rosetta Code) - 275 (presently in Simple Rosetta) = 907 Simple Rosetta Eiffel "solutions" left to code out. Remember: This is not going to push to Rosetta Code on-line en masse. They will probably trickle in over a few weeks as I code SImple Rosetta CLI to push them up to Rosetta perhaps at a rate of 1 per hour or so. I don't want to look like a "bot" (even though I am - or will be). Yet, being on Rosetta Code is not the goal. Having the "solutions" as fodder for the QLoRA LLM "pairs" is the goal. Searchable immediately in a SQLite 3 DB using FTS5 will be immediately useful, but then quickly on to creating the various "specialists" data training sets and using my local GPU to train and build the QLoRA LLM extension of Ollama Qwen Coder 2.5 7b will be the ultimate trick. From there, the goal is to open that up to:

1. Human users of Ollama.
2. AI users like Claude code Opus 4.5

Doing so should replace needing the hodge-podge of "guardrails" I have built for Claude that it forgets, doesn't use well, and ends up re-inventing the Eiffel wheel over and over, which is why it needs some level of babysitting, prep, follow-up, and so on. The goal is to have a more capable AI assist for the Eiffel language and method holistically.

That's the plan anyway. Wish me luck!

Best,

Larry

[Liberty Lover]

And this is what happens after a "compaction" where the AI loses a lot of the details of the last part of the "session" we are in.

[Eric Bezault]

Hi Larry,

Just trying to understand: you are letting Claude generate Rosetta
solutions so that it (or other AI) can train itself?

With poor assertions like the ones I had spotted for the Fibonacci
solution?

And that will make AI Eiffel experts in their domain?
I'm skeptical. At best you will get AI Eiffel junior programmers,
which can generate tons of code per second, but still junior
programmers.

--
Eric Bezault
mailto:er...@gobosoft.com
http://www.gobosoft.com

On 23/12/2025 3:04, Liberty Lover wrote:
> image.png
> image.png

> image.png
>
> Claude builds out tests for all "solutions" currently in Simple Rosetta.
> With this, we have only about 1,339 (total Rosetta tasks) - 157 (Eiffel
> presently on Rosetta Code) - 275 (presently in Simple Rosetta) = 907
> Simple Rosetta Eiffel "solutions" left to code out. Remember: This is
> not going to push to Rosetta Code on-line en masse. They will
> probably trickle in over a few weeks as I code SImple Rosetta CLI to
> push them up to Rosetta perhaps at a rate of 1 per hour or so. I don't
> want to look like a "bot" (even though I am - or will be). Yet, being on
> Rosetta Code is not the goal. Having the "solutions" as fodder for the
> QLoRA LLM "pairs" is the goal. Searchable immediately in a SQLite 3 DB
> using FTS5 will be immediately useful, but then quickly on to creating
> the various "specialists" data training sets and using my local GPU to
> train and build the QLoRA LLM extension of Ollama Qwen Coder 2.5 7b will
> be the ultimate trick. From there, the goal is to open that up to:
>

> 1. Human users of Ollama.
> 2. AI users like Claude code Opus 4.5

> --
> 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 <mailto:eiffel-
> users+un...@googlegroups.com>.

> To view this discussion visit https://groups.google.com/d/msgid/eiffel-
> users/

> CA%2B3qnjfYrfosFyKH3K3jfovoEZT%2BDboTWECz_VZpBvAA%3DYt0gg%40mail.gmail.com <https://groups.google.com/d/msgid/eiffel-users/CA%2B3qnjfYrfosFyKH3K3jfovoEZT%2BDboTWECz_VZpBvAA%3DYt0gg%40mail.gmail.com?utm_medium=email&utm_source=footer>.

[Eric Bezault]

On 23/12/2025 8:26, Eric Bezault wrote:
> Hi Larry,
>
> Just trying to understand: you are letting Claude generate Rosetta
> solutions so that it (or other AI) can train itself?
>
> With poor assertions like the ones I had spotted for the Fibonacci
> solution?
>
> And that will make AI Eiffel experts in their domain?
> I'm skeptical. At best you will get AI Eiffel junior programmers,
> which can generate tons of code per second, but still junior
> programmers.

Or will the AI gain Eiffel expertise incrementally by constantly
improving the Rosetta solutions at iteration N based on the
knowledge acquired at iteration N-1?

[Ulrich Windl]

Hi!

Maybe it's like a real programmer: Learn from others before you start your own code. Learn from your mistakes. Repeat from the beginning.
Without your personal history of failures you'll duplicate existing code only, most likely. Only the risky trying of new things really brings you forward, and many times you'll have to give up your initial plan.
It's the synthesis of science and art, maybe engineering and design.

Regards,
Ulrich

--

Mit freundlichen Grüßen
Ulrich Windl

23.12.2025 08:35:02 Eric Bezault <er...@gobosoft.com>:

> --
> 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/8cecc757-84a7-4b07-801f-a98dbbb5f9fe%40gobosoft.com.

[Liberty Lover]

  Hi Eric,

  Fair point, but you're looking at a snapshot and projecting it as the final state, and I certainly have not given a good enough explanation of the entire vision of the project.  Nevertheless — The effort is about process, not one-and-done. There is a long-march ahead.

  The Code Quality Pipeline:

  My AI-assisted work goes through structured review cycles ("hats"):

  | Hat                 | Focus                                                    |
  |---------------------|----------------------------------------------------------|
  | Specification       | Contracts BEFORE implementation                          |
  | Contracting         | Strengthen assertions, loop invariants, class invariants |
  | Code Review         | Security, correctness, Eiffel idioms (with web research) |
  | Testing             | Happy path, edge cases, error conditions                 |
  | Refactoring         | Structure improvement without behavior change            |
  | Code Smell Detector | God classes, feature envy, duplicate code                |
  | Security            | OWASP checklist, input validation, injection prevention  |
  | Performance         | Measure-first optimization                               |
  | Profiler            | Identify actual bottlenecks with data                    |
  | SCOOP               | Concurrency analysis and implementation                  |
  | Mock Building       | Realistic consumer apps to exercise APIs                 |
  | Documentation       | API docs, examples                                       |
  | Feature             | New functionality implementation                         |
  | Cleanup             | Dead code removal, warning fixes                         |

  Claude tends toward happy-path testing initially - I have to push it toward edge cases. Each hat pass is an iterative improvement.

  The Eiffel Method as Quality Gate:

  While other languages have good compilers, we both know that they lack. And we both know (you much better than I) what distinguishes Eiffel is the complete Eiffel Method - not just DBC, and an integrated approach to software construction:

  - Design by Contract - preconditions, postconditions, invariants
  - Command-Query Separation - queries don't modify state
  - Uniform Access Principle - attributes and functions interchangeable
  - Single-Choice Principle - decisions localized
  - Open-Closed Principle - open for extension, closed for modification
  - Multiple Inheritance - proper feature adaptation, rename/redefine
  - Constrained Generics - type-safe parameterization

  Again — you already know better than I that the compiler enforces syntax and types. DBC enforces semantic correctness. But the method encompasses Meyer's Quality Factors - correctness, robustness, extendibility, and reusability. Good Eiffel design addresses all four, not just "does the code compile with contracts?" I know that I am a junior-preacher preaching in front of a senior (you). Yet, for others who might be reading this, such things (and more) need to be said again (over and over).

  The LLM Specialists (Future Architecture):

  The planned QLoRA specialists (Qwen Coder 2.5 7B) will go through Q+A refinement cycles:

  | Specialist          | Depth                                                                  |
  |---------------------|------------------------------------------------------------------------|
  | DBC Master          | Contract design patterns, loop/class invariants, inheritance contracts |
  | SCOOP Expert        | Separate types, lock-free design, wait conditions                      |
  | MI Architect        | Feature adaptation, diamond inheritance, Gobo-style hierarchies        |
  | Void Safety         | Attached/detachable patterns, VJAR diagnosis and fixes                 |
  | Generics Guru       | Constrained generics, covariance, container patterns                   |
  | Agents Expert       | Inline agents, callbacks, delayed execution                            |
  | Polyglot Translator | Java/Python/C# → Eiffel pattern mapping                                |
  | Pattern Mapper      | GoF patterns in Eiffel idiom                                           |
  | Error Doctor        | Compiler error diagnosis and fixes                                     |

  Each specialist will be independently refined through training iterations. Yes, v0.1 will be junior level (or even less) - that's the starting point, not the destination. The eventual "Designer" specialist will embody senior-level Eiffel thinking: architecture with MI and generics, efficiency considerations, reusability focus. Even with Claude as I operate with it now (e.g. with my reference documents and what it has in its "Oracle") the code Claude produces is only low-level (compared to humans) and passable. Yet, the strength it already has is (as you noted) producing a ton of code and the good or upside to that code is NOT that it equals mine (and certainly not yours), but that it has survived the compiler and there is at least some good-faith effort to use DBC + Testing (happy path and edge case) to ensure a much higher quality.

  NOTE: There are several matters of note that need to be pointed out:

• Right now, there is a need for human "push" and "remembering". Presently, I have to push Claude into edge-case testing. I have to remember to push Claude into "hat wearing" to circle back on code it has already built in order to raise the quality to somewhere above junior-level, but certainly not senior-level by any stretch. The goal with the specialist LLMs is to mitigate the need to remember and push manually.
• Claude does excellent research and planning. The tool is able to find and work with industry standards and understand them in context far faster than humans. What is the result? Many of the libraries in Simple Eiffel would not be possible without an LLM AI doing what they are really REALLY good at: Handling language and doing deep, intense, and comprehensive research and then understanding that to a sufficient level to build what has been built (junior-level or not). The poster-child for this is the raising of Eiffel's SQLite library from being stuck at SQLite 3.31.1 (32-bit/x86) with no FTS5, JSON1, RTREE, or math functions - features essential for modern applications. The eiffel_sqlite_2025 upgrade brought SQLite 3.51.1 (64-bit/x64) with all extensions enabled, raising the bar from "basic SQL storage" to "full-featured embedded database with full-text search and JSON operations."  The other poster-child is Claude's creation (at my direction and with my guidance) of a SCOOP-capable process library as well as the Win32 libraries (e.g. mmap, env, et al).

  | Feature               | Eiffel std Lib   | eiffel_sqlite_2025 |
  |-----------------------|------------------|--------------------|
  | SQLite Version        | 3.31.1           | 3.51.1             |
  | Architecture          | x86 (32-bit)     | x64 (64-bit)       |
  | FTS5 Full-Text Search | ❌               | ✅                 |
  | JSON1 Extension       | ❌               | ✅                 |
  | RTREE Spatial Index   | ❌               | ✅                 |
  | Math Functions        | ❌               | ✅                 |

  The above demonstrates the capacities of a human + AI (Claude in this case) very well.

• The dogfooding of the code (one simple_* lib using another) has demonstrated that the code isn't just generated, but is actually useful and productive when put to work as a supplier for the needs of the client consumers. Claude is also demonstrating its strength as being able to work within that sandbox as well.

  I will end this off so that it is not any more long-winded than it already is, except to say:

  Respect for Your Expertise:

  You've spent decades mastering Eiffel and built Gobo - one of the most sophisticated Eiffel library ecosystems. Your review of the Fibonacci code caught exactly the kind of weak contract (Result >= 0) that needs strengthening. I welcome your continued code reviews. Having your expert eye on this work is invaluable for the refinement process.

  --Larry

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/ef483bf8-13d9-4283-a5e4-bb1a0465d045%40gobosoft.com.

[Liberty Lover]

QUICK FOLLOW-UP: As for the "hats" — looking at what I just wrote, I realize that I paint a picture that all of the code produced so far goes through this "hatting" process. It does not. I have opted for "git-r-done" over slowing down and doing all of those steps all of the time without fail. That's not happening, but at one level — IT DOES NOT HAVE TO!! Why? Because, as I said to Ulrich at the start (paraphrasing myself): "If it works ... IT WORKS!" And in a market-driven, alpha-code-level world, working counts for more to grab attention and share. Quality is a forever push. Raising code-quality is a never ending job — from various points of view and vectored approaches to the code base. So, the real goal is to have the LLMs (which also grow in quality over time) take over that job more and more. Ultimately, there is a goal to have Agentic LLMs running in the background that are constantly bird-dogging the code. But — that time is not now, nor can it be. There is a process that must happen between here and there.

Cheers,

Larry

[Liberty Lover]

Well said, Ulrich. That is where we are now. Claude as a tool isn't perfect. It's not senior. Expecting it to be and then throwing up our hands and quitting because it isn't is just silliness. There is a process, a building, a learning, and — how do we make this thing better? Getting better is a process. It's both engineering and art. We're on that road with this thing. It's already useful. That's proven. Anyone in doubt can just look at and see that. It is plainly self-evident. So, I choose to not try and poo-poo the thing, but not pretend like it is a SENIOR programmer. It's clearly a junior-in-training. That's a gimme.

Cheers,

Larry

To view this discussion visit https://groups.google.com/d/msgid/eiffel-users/d5db0d03-27e1-4ea2-b15e-09dcb4977ec2%40gmail.com.

[Eric Bezault]

Hi Larry,

OK, a junior. The problem is that this junior is assessing
itself as if it was an expert. In its "honest assessments" it
was proud to announce that it generated a usable LSP for VS Code.
I tried it and it is not usable for real work. The parser
erroneously reports errors on the kernel classes (and on its
own code), it crashes when opening the Gobo project, and it
takes ages to create its indexing (10 to 15 minutes on my
computer when opening the Gobo project), and when it crashes
it has to create its indexing again. Completion is not
very helpful: if I want `make_from_string` and start to
type `ma` I get hundreds of `make` from all other unrelated
classes to scroll through before getting to the name I'm
interested in. And the list of problems goes on and on.
So my "human" assessment is that it is a nice toy, but not
something that we can use to attract new Eiffel programmers.

So yes, when I read the "honest" self-assessement from Claude
and then dive a little bit into what it produced, I'm
disappointed. It was not clear from the start that the Eiffel
code we were flooded with was written by a junior level AI.
The "junior" word was mentioned nowhere, contrary to the
"expert" word. I can see that the word "expert" is not as
visible as before, but before your message today it was not
clear that the code generated so far was junior level.
It should be made clearer in the documentation, readme files
etc. generated by Claude.

--
Eric Bezault
mailto:er...@gobosoft.com
http://www.gobosoft.com

> <mailto:er...@gobosoft.com>>:

>
> > On 23/12/2025 8:26, Eric Bezault wrote:
> >> Hi Larry,
> >> Just trying to understand: you are letting Claude generate Rosetta
> >> solutions so that it (or other AI) can train itself?
> >> With poor assertions like the ones I had spotted for the Fibonacci
> >> solution?
> >> And that will make AI Eiffel experts in their domain?
> >> I'm skeptical. At best you will get AI Eiffel junior programmers,
> >> which can generate tons of code per second, but still junior
> >> programmers.
> >
> > Or will the AI gain Eiffel expertise incrementally by constantly
> > improving the Rosetta solutions at iteration N based on the
> > knowledge acquired at iteration N-1?
> >
> > --
> > Eric Bezault

> > mailto:er...@gobosoft.com <mailto:er...@gobosoft.com>
> > http://www.gobosoft.com <http://www.gobosoft.com>

> >
> > --
> > 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

> <mailto:eiffel-users%2Bunsu...@googlegroups.com>.

> > To view this discussion visit https://groups.google.com/d/msgid/
> eiffel-users/8cecc757-84a7-4b07-801f-a98dbbb5f9fe%40gobosoft.com

> <https://groups.google.com/d/msgid/eiffel-
> users/8cecc757-84a7-4b07-801f-a98dbbb5f9fe%40gobosoft.com>.

>
> --
> 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

> <mailto:eiffel-users%2Bunsu...@googlegroups.com>.

> To view this discussion visit https://groups.google.com/d/msgid/

> eiffel-users/d5db0d03-27e1-4ea2-b15e-09dcb4977ec2%40gmail.com
> <https://groups.google.com/d/msgid/eiffel-users/d5db0d03-27e1-4ea2-
> b15e-09dcb4977ec2%40gmail.com>.

>
> --
> 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 <mailto:eiffel-
> users+un...@googlegroups.com>.

> To view this discussion visit https://groups.google.com/d/msgid/eiffel-

> users/CA%2B3qnje1fE68BOCL_Nk7oigAzuKNfhuQWMnxy7-7P%3DFUrEPe-
> w%40mail.gmail.com <https://groups.google.com/d/msgid/eiffel-users/
> CA%2B3qnje1fE68BOCL_Nk7oigAzuKNfhuQWMnxy7-7P%3DFUrEPe-
> w%40mail.gmail.com?utm_medium=email&utm_source=footer>.

[Ulrich Windl]

Hi!

For "

> The problem is that this junior is assessing itself as if it was an expert ."

It reminded me of the (ironic?) German saying "Bescheidenheit ist eine Zier, doch besser lebt's sich ohne ihr" (Modesty is an ornament, but life is better without it).

I think the code would be a good starting point, but it will have to be validated and improved by a human. Specifically I see the danger that repeating cycles of attempts to improve things may actually divert from the original goal (breaking things that worked before); also a problem for humans sometimes.

Ulrich

23.12.2025 14:38:52 Eric Bezault <er...@gobosoft.com>:

> 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/1d231c7b-36db-48e9-866d-948b4669720b%40gobosoft.com.

[Liberty Lover]

Ulrich, 

I had to suss that one out:

**German proverb:**
**“Bescheidenheit ist eine Zier, doch besser lebt’s sich ohne ihr.”**

### Literal translation

> **“Modesty is an ornament, but life is better without it.”**

### Idiomatic meaning (American perspective)

From an American cultural lens, this saying is **ironic and slightly cynical**. It acknowledges that **humility looks good socially**, but argues that **being openly assertive, self-promoting, or ambitious often leads to better outcomes** in real life.

A very natural American equivalent would be something like:

* **“Humility is nice, but it doesn’t get you ahead.”**
* **“Modesty is admirable—but confidence pays the bills.”**
* **“Don’t sell yourself short.”**

### Cultural subtext

* In German culture, *Bescheidenheit* (modesty) has traditionally been a virtue.
* This proverb **undercuts that virtue with realism**, implying that modest people often get overlooked.
* To Americans, it sounds like a wry endorsement of **self-advocacy over quiet virtue**.

### Tone

* Not moralistic
* Dry, ironic
* Slightly humorous
* Observational rather than prescriptive

### In plain American English

> **“Being humble looks good, but you’ll do better in life if you speak up and push for yourself.”**

To view this discussion visit https://groups.google.com/d/msgid/eiffel-users/5119e696-f7c6-442f-896b-bd16279fd47f%40gmail.com.

[Liberty Lover]

re: " I think the code would be a good starting point, but it will have to be validated and improved by a human."

Exactly what are you saying is wrong with the process so far? I want to be sure I'm understanding your concern correctly. Based on that then, tell us specifically, what outcome are you actually looking for?

To view this discussion visit https://groups.google.com/d/msgid/eiffel-users/5119e696-f7c6-442f-896b-bd16279fd47f%40gmail.com.

[Ulrich Windl]

Hi!

What I meant is: The code as it is looks OK, but I 'm not sure that it can be improved by applying AI to it repeatedly. Sometimes AI simple has no idea how to do something, and then it makes (a lot of wrong) guesses. I think people call it "hallucinating".
So my statement was about the future of the code.

Kind regards,
Ulrich

24.12.2025 12:27:58 Liberty Lover <rix....@gmail.com>:

>>>>     send an email to eiffel-users...@googlegroups.com[eiffel-users%2Bunsu...@googlegroups.com]
>>>>     <mailto:eiffel-users%2Bunsu...@googlegroups.com[eiffel-users%252Buns...@googlegroups.com]>.

>>>>      > To view this discussion visit https://groups.google.com/d/msgid/

>>>>     eiffel-users/8cecc757-84a7-4b07-801f-a98dbbb5f9fe%40gobosoft.com[http://40gobosoft.com]
>>>>     <https://groups.google.com/d/msgid/eiffel-
>>>>     users/8cecc757-84a7-4b07-801f-a98dbbb5f9fe%40gobosoft.com[http://40gobosoft.com]>.

>>>>     --     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[eiffel-users%2Bunsu...@googlegroups.com]
>>>>     <mailto:eiffel-users%2Bunsu...@googlegroups.com[eiffel-users%252Buns...@googlegroups.com]>.

>>>>     To view this discussion visit https://groups.google.com/d/msgid/

>>>>     eiffel-users/d5db0d03-27e1-4ea2-b15e-09dcb4977ec2%40gmail.com[http://40gmail.com]
>>>>     <https://groups.google.com/d/msgid/eiffel-users/d5db0d03-27e1-4ea2-
>>>>     b15e-09dcb4977ec2%40gmail.com[http://40gmail.com]>.

>>>> --
>>>> 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[eiffel-users%2Bunsu...@googlegroups.com] <mailto:eiffel- users+un...@googlegroups.com[users%2Bunsu...@googlegroups.com]>.
>>>> To view this discussion visit https://groups.google.com/d/msgid/eiffel- users/CA%2B3qnje1fE68BOCL_Nk7oigAzuKNfhuQWMnxy7-7P%3DFUrEPe- w%40mail.gmail.com[http://40mail.gmail.com] <https://groups.google.com/d/msgid/eiffel-users/ CA%2B3qnje1fE68BOCL_Nk7oigAzuKNfhuQWMnxy7-7P%3DFUrEPe- w%40mail.gmail.com?utm_medium=email&utm_source=footer[http://40mail.gmail.com?utm_medium=email&utm_source=footer]>.

>>>
>>>
>>>
>>> --
>>> 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[eiffel-users%2Bunsu...@googlegroups.com].

>>> To view this discussion visit https://groups.google.com/d/msgid/eiffel-users/1d231c7b-36db-48e9-866d-948b4669720b%40gobosoft.com.
>>
>> --
>> 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[eiffel-users%2Bunsu...@googlegroups.com].
>> To view this discussion visit https://groups.google.com/d/msgid/eiffel-users/5119e696-f7c6-442f-896b-bd16279fd47f%40gmail.com.

>
> --
> 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/CA%2B3qnjfiDR7F%2BimDyPF3rHSTcjhE5P%3D2xmu7kLCuGNw1qzTjyQ%40mail.gmail.com[https://groups.google.com/d/msgid/eiffel-users/CA%2B3qnjfiDR7F%2BimDyPF3rHSTcjhE5P%3D2xmu7kLCuGNw1qzTjyQ%40mail.gmail.com?utm_medium=email&utm_source=footer].

[Liberty Lover]

What I meant is: The code as it is looks OK, but I 'm not sure that it can be improved by applying AI to it repeatedly.

That is a theory to be tested, not a conclusion to be rested upon. Let me offer a real-time example of this in practice.

When Claude initially developed `simple_parser`, it ignored my specific instructions to build a higher-level API over the Gobo parser. My goal was to eliminate the need for deep boilerplate code—targeting the 80/20 Pareto principle—but instead, Claude attempted to write its own parser from scratch (ignoring my direction).

The Failure of the "Concocted" Parser

The failure of this approach became evident during my work towards an Eiffel-based LLM. To build the QLoRA, I needed to create `simple_kb`, a database of instructional pairs derived from parsed Eiffel code. Claude used its own `simple_parser` (at my insisted direction) for this task, but the results were poor: it reported a mere 30% success rate on parsing the target code.

When I pushed Claude to add more Design by Contract (DbC) and testing to diagnose these failures, the "red flag" emerged: the code was a wholesale fabrication rather than the wrapper I had requested.

The Pivot: Back to Instruction

I have since halted that process and pivoted Claude back to my original requirement: Wrap the Gobo parser library. The benchmark for success is clear:

• Previous Success: ~30% (Custom Claude logic)
• Target Success: 100% (Gobo-wrapped logic)

I refuse to believe that a proper higher-level API implementation wrapping the Gobo lexer/parser would yield anything less than 100% success for Eiffel code. Claude is currently in the throes of this reconstruction.

The Human Element

This directly addresses your skepticism that a project "can’t be improved by applying AI to it repeatedly." The issue isn't the AI's inherent ceiling, but rather the meticulousness of the prompting and the human oversight required to catch deviations. Baked into this is the need for a human to use the AI tool to help evaluate under human supervision, not the elimination of AI entirely. That would be a return to the horse-and-buggy with the same arguments used against cars and planes circa 1910.

As humans, we are prone to lapses in attention; we stumble, fix, and improve as we go. Using AI is no different—it requires constant redirection and attention to detail to ensure the tool remains aligned with the objective.

 

Sometimes AI simple has no idea how to do something, and then it makes (a lot of wrong) guesses. I think people call it "hallucinating".

The common skepticism toward AI often stems from the belief that it cannot improve through iteration. However, this overlooks the reality that AI is not operating in a vacuum; it is a tool that requires meticulous human oversight and strategic redirection.

1. The Hallucination of Convenience

In an AI context, hallucination often manifests as "guessing" rather than factual error. For instance, when Claude interacts with a supplier library like simple_json, it frequently assumes a feature name, writes the code, and only consults the actual documentation after the compiler fails.

As a human developer, the logical workflow is: Research --> Verify --> Implement.

The AI workflow is often: Assume --> Fail --> Correct.

This is a fundamental design flaw in current LLMs. While I am developing methods to bridge this "research gap," the current solution lies in the human’s ability to force the tool out of its "guessing" loop and back into technical reality.

2. Case Study: The simple_parser PivotThe failure of the simple_parser is a prime example of what happens when human guidance is momentarily relaxed or forgotten—and how it can be corrected.

The Deviation: Claude was instructed to wrap the Gobo parser to reduce boilerplate code (the 80/20 rule). Instead, it "concocted" a custom parser from scratch.

The Consequence: This fabricated parser achieved only a 30% success rate when tasked with building the instructional pairs for an Eiffel-based LLM.

The Red Flag: By pushing for more Design by Contract (DbC) and rigorous testing, the "guesswork" was exposed. The parser wasn't broken; it was fundamentally the wrong architecture.

3. The Power of the Pivot

The belief that AI cannot be improved by repeated application is as I stated above, a theory to be tested, not a conclusion to be rested upon. By identifying the "red flag" and pivoting Claude back to the original instruction—wrapping the Gobo library—the trajectory changes entirely.The success of this tool is not found in its autonomy, but in the human-in-the-loop process:

Directing: Explicitly requiring the use of proven libraries (Gobo).

Monitoring: Using DbC and compiler feedback to catch "wholesale concoctions."

Refining: Moving from a 30% success rate to a 100% success rate through persistent redirection.

Conclusion

We are all prone to lapses in attention, whether human or machine. Improving a project through AI is not about clicking a button and hoping for the best; it is about the meticulous use of the tool. When we pay attention and force the AI to trade its "guesses" for verified library implementations, we transform a failing experiment into a robust engineering solution.

 

So my statement was about the future of the code.

Yes, I agree. So is mine. Thank you for your thoughts and feedback. It helps us all to think through this matter that is NOT going away. We either adapt or we get left behind. The entire goal of the Simple Eiffel project was to prove that Eiffel the language, method, and technology is a superior platform that helps AI be a better tool. This is especially true of the growing reality that the faults of other language technologies are being exposed through AI being applied to them (e.g. the bugs in their HUGE code-base actually causes the resulting LLM model to mindlessly produce more bugs faster than humans). 

Best,

Larry

[Liberty Lover]

The answer is coming ... and that right soon ...

[Liberty Lover]

Getting closer ...

[Liberty Lover]

And then there are the times that AI finds bugs and has to deal with them. I don't know if this is an ACTUAL bug or if something else is at fault, but for the moment, we will just accept the theory and move on towards the goal.

[Liberty Lover]

Part of the assumption here is that the Eiffel Base ELKs code it is parsing is bug-free (e.g. the '%/code/' that causes valid_literal to fail is in fact valid. The contract might be correct and the code being parsed is wrong (buggy). So, there's that too.

[Liberty Lover]

And there you have it!!!

Now, what does this prove? Well, a couple of things come to mind:

• The meticulously coded and proven Gobo parser just works (~99.9999).
• The simple_parser was successfully pivoted to using/wrapping Gobo.
• The proof is that 100% of whatever is being stated as "successful" (yet TBD).

The engineering process continues. The AI is doing this work under human direction. Can AI correct and improve itself? Sure. It can. And a downstream consumer library (simple_kb) is the recipient of the work.

[Liberty Lover]

Now, of course, your engineering red-flags ought to be going off as you read this. W_code or even F_code contracts are causing problems? Why? Incorrect or too-strict DBC? What's the issue? Why is it that the contractless-F-code gets a 100% pass? Nevertheless, I am not going to navel gaze at this very long. The goals of simple_kb can move forward with simple_parser in the rear view for the moment.