Simple Eiffel - Knowledge Base + Device Libs

[Liberty Lover]

Hey All,

  Announcing 5 new hardware libraries for Simple Eiffel:

  | Library          | Purpose                                              | Tests |
  |------------------|------------------------------------------------------|-------|
  | simple_ffmpeg    | Video/audio transcoding via FFmpeg (CLI + SDK modes) | 19/19 |
  | simple_usb       | USB enumeration, HID reports, gamepad input          | 29/29 |
  | simple_audio     | WASAPI streaming, PCM buffers                        | 17/17 |
  | simple_serial    | COM port communication                               | 6/6   |
  | simple_bluetooth | Bluetooth SPP                                        | 11/11 |

  Key themes:
  - Inline C pattern (no external DLLs)
  - Fluent APIs with facade classes
  - Windows-only (Windows APIs) - for now - Linux coming (Mac? I don't know)

Full announcement is here.

Cheers,

Larry

[Eric Bezault]

Hi Larry,

In https://github.com/simple-eiffel/simple_audio/blob/master/README.md:

> Dependencies
> WEL (Windows Eiffel Library for MANAGED_POINTER)

Please tell Claude that MANAGED_POINTER is defined in EiffelBase,
not in WEL.

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

> Full announcement is here <https://github.com/simple-eiffel/
> claude_eiffel_op_docs/blob/main/posts/DEVICE_LIBRARIES_ANNOUNCEMENT.md>.
>
> Cheers,
>
> Larry

[Eric Bezault]

Hi Larry,

I can see in the Readme file of many simple libraries:

> Fluent builder - Chain configuration calls for clean code

But when I see this code example in the same Readme file:

~~~~
config := config
.set_baud_rate (115200)
.set_data_bits (8)
.set_parity ({SERIAL_PORT_CONFIG}.parity_none)
.set_stop_bits ({SERIAL_PORT_CONFIG}.stop_bits_one)
.set_flow_control ({SERIAL_PORT_CONFIG}.flow_control_hardware)
~~~~

I cannot really see why this fluent pattern makes the code
cleaner than:

~~~~
config.set_baud_rate (115200)
config.set_data_bits (8)
config.set_parity ({SERIAL_PORT_CONFIG}.parity_none)
config.set_stop_bits ({SERIAL_PORT_CONFIG}.stop_bits_one)
config.set_flow_control ({SERIAL_PORT_CONFIG}.flow_control_hardware)
~~~~

On the other hand, fluent programming violates the
Command-Query Separation principle. So what is the
real advantage in doing fluent programming in Eiffel?

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


On 27/12/2025 1:28, Liberty Lover wrote:

[Liberty Lover]

Hey Eric,

On CQS "Violations"

I agree that CQS is a valuable design principle, and I think it is interesting for anyone else reading (including myself) to note that CQS violations cannot be statically detected by a compiler. I think the reason for that is that in order to detect "does this function modify state?", the compiler would need to solve the Purity Analysis Problem - tracing through all transitive calls, handling polymorphism, external code, etc. This is undecidable in the general case.

So, this leaves CQS as a human-interpreted guideline, not one that can be a mechanically compiler-enforced rule, which means or may mean:
  - Developers must use their own judgment about when violations are acceptable
  - The Eiffel ecosystem has always had pragmatic exceptions (iterators, certain container operations)
  - A transparent, obvious violation isn't the same as a dangerous one

  The fluent pattern is a safe, transparent deviation. Why?:
  - The set_* prefix clearly indicates mutation as a reasonable semantic
  - Returning Current is trivial and predictable
  - No hidden side effects or confusion possible

  - The .do_nothing capping call  semantically signals the end of the fluent call-chain

On the Readability Argument

The "config." repetition is genuine textual noise:

  -- Traditional: "config." repeated 5 times
  config.set_baud_rate (115200)
  config.set_data_bits (8)
  config.set_parity (...)
  config.set_stop_bits (...)
  config.set_flow_control (...)

  The reader's eye is forced to labor to parse "config." five times - 35 characters of redundant semantic context that dilutes focus away from what matters: the actual configuration values.

  -- Fluent: context establishes the "config context" ONCE, allowing the reader to focus on the "set_*" calls within that context.

  config := config
      .set_baud_rate (115200)
      .set_data_bits (8)

      .set_parity (...)
      .set_stop_bits (...)
      .set_flow_control (...)

  Additionally, the indented chain creates visual grouping. You immediately see "this block is about config" and then focus shifts to what's actually being set. The structure communicates intent.

  Summary

  The fluent pattern in simple_* is a conscious, defensible trade-off:

  | Concern              | Reality                                            |
  |----------------------|----------------------------------------------------|
  | CQS violation        | Safe exception - obvious mutation, trivial return  |
  | Compiler detection   | Not possible - CQS requires human judgment         |
  | Readability          | Reduces repetitive noise, creates visual structure |
  | Practical experience | Used successfully across the ecosystem             |

----

  Here are some citations for Static Side-Effect Detection Being Undecidable/Hard. I was unaware of the study behind why CQS is not baked into the compiler.

  1. Undecidability Foundation

  Landi, W. "Undecidability of Static Analysis" - ACM Letters on Programming Languages and Systems (1992)
  - https://dl.acm.org/doi/10.1145/161494.161501
  - Proves static analysis problems are undecidable via reduction to the halting problem

  2. Purity Analysis Research

  Sălcianu, A. & Rinard, M. "Purity and Side Effect Analysis for Java Programs" - VMCAI 2005, Springer
  - https://link.springer.com/chapter/10.1007/978-3-540-30579-8_14
  - Defines purity analysis and shows it requires sophisticated pointer/escape analysis
  - Even their advanced analysis can only determine purity "when mutation affects only objects created after method invocation"

  3. Side Effect Detection in Compilers

  Spuler, D. & Sajeev, A. "Compiler Detection of Function Call Side Effects"
  - https://www.semanticscholar.org/paper/Compiler-Detection-of-Function-Call-Side-Effects-Spuler-Sajeev/9cf47f729e175688b78b519fa07f8e9e904410be
  - Documents that detecting side effects requires analyzing the entire function body, tracking globals, references, I/O, etc.

  4. General Principle

  Rice's Theorem (1953) - Any non-trivial semantic property of programs is undecidable. Side-effect-freedom is a semantic property, therefore undecidable in the general case.

  The https://en.wikipedia.org/wiki/Static_program_analysis summarizes: "By a straightforward reduction to the halting problem, finding all possible run-time errors in an arbitrary program is undecidable."

--
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/66897503-70af-4716-afb4-ee90d093718f%40gobosoft.com.

[Liberty Lover]

Claude says, "Oops ... fixing it." :-) 

--
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/cab46218-85c9-45b7-97a6-0ee05bbeb68b%40gobosoft.com.

[Liberty Lover]

Eric,

One additional data point worth noting: Martin Fowler, in his https://martinfowler.com/bliki/CommandQuerySeparation.html, directly addresses Meyer's own pragmatism on this:

  "Meyer likes to use command-query separation absolutely, but there are exceptions. Popping a stack is a good example of a query that modifies state. Meyer correctly says that you can avoid having this method, but it is a useful idiom."

So even Meyer himself acknowledges that pop (which both returns a value AND modifies state) is a "useful idiom" - a pragmatic exception to his own principle.

The fluent builder pattern falls into this same category: a transparent, predictable deviation that provides ergonomic value. Like pop, you could avoid it (separate set_* procedures + a final query), but the fluent form is a useful idiom that clearly communicates intent.

I also note that your Gobo library takes the strict approach (separate item and remove), which is a valid choice. The simple_* libraries make a different valid choice. Both are defensible - CQS is a principle to be interpreted, not a law to be mechanically enforced.

[Eric Bezault]

About readability, I guess that it is subjective because
I find:

config.set_baud_rate (115200)
config.set_data_bits (8)
config.set_parity ({SERIAL_PORT_CONFIG}.parity_none)
config.set_stop_bits ({SERIAL_PORT_CONFIG}.stop_bits_one)
config.set_flow_control ({SERIAL_PORT_CONFIG}.flow_control_hardware)

more readable than:

config := config
.set_baud_rate (115200)
.set_data_bits (8)
.set_parity ({SERIAL_PORT_CONFIG}.parity_none)
.set_stop_bits ({SERIAL_PORT_CONFIG}.stop_bits_one)
.set_flow_control ({SERIAL_PORT_CONFIG}.flow_control_hardware)

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

On 27/12/2025 12:18, Liberty Lover wrote:
> Hey Eric,
>
> On CQS "Violations"
>
> I agree that CQS is a valuable design principle, and I think it is
> interesting for anyone else reading (including myself) to note that CQS
> violations cannot be statically detected by a compiler. I think the
> reason for that is that in order to detect "does this function modify
> state?", the compiler would need to solve the Purity Analysis Problem -
> tracing through all transitive calls, handling polymorphism, external
> code, etc. This is undecidable in the general case.
>
> So, this leaves CQS as a human-interpreted guideline, not one that can
> be a mechanically compiler-enforced rule, which means or may mean:
>   - Developers must use their own judgment about when violations are
> acceptable
>   - The Eiffel ecosystem has always had pragmatic exceptions
> (iterators, certain container operations)

>   - A /transparent/, /obvious /violation isn't the same as a /
> dangerous /one

>   - https://dl.acm.org/doi/10.1145/161494.161501 <https://dl.acm.org/
> doi/10.1145/161494.161501>

>   - Proves static analysis problems are undecidable via reduction to
> the halting problem
>
>   2. Purity Analysis Research
>
>   Sălcianu, A. & Rinard, M. "Purity and Side Effect Analysis for Java
> Programs" - VMCAI 2005, Springer
>   - https://link.springer.com/chapter/10.1007/978-3-540-30579-8_14
> <https://link.springer.com/chapter/10.1007/978-3-540-30579-8_14>
>   - Defines purity analysis and shows it requires sophisticated
> pointer/escape analysis
>   - Even their advanced analysis can only determine purity "when
> mutation affects only objects created after method invocation"
>
>   3. Side Effect Detection in Compilers
>
>   Spuler, D. & Sajeev, A. "Compiler Detection of Function Call Side
> Effects"
>   - https://www.semanticscholar.org/paper/Compiler-Detection-of-
> Function-Call-Side-Effects-Spuler-

> Sajeev/9cf47f729e175688b78b519fa07f8e9e904410be <https://
> www.semanticscholar.org/paper/Compiler-Detection-of-Function-Call-Side-
> Effects-Spuler-Sajeev/9cf47f729e175688b78b519fa07f8e9e904410be>

>   - Documents that detecting side effects requires analyzing the entire
> function body, tracking globals, references, I/O, etc.
>
>   4. General Principle
>
>   Rice's Theorem (1953) - Any non-trivial semantic property of programs
> is undecidable. Side-effect-freedom is a semantic property, therefore
> undecidable in the general case.
>

>   The https://en.wikipedia.org/wiki/Static_program_analysis <https://
> en.wikipedia.org/wiki/Static_program_analysis> summarizes: "By a

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

>
>
> On 27/12/2025 1:28, Liberty Lover wrote:
> > Hey All,
> >
> >    Announcing 5 new hardware libraries for Simple Eiffel:
> >
> >    | Library          | Purpose
> >       | Tests |
> >
> >
> |------------------|------------------------------------------------------|-------|
> >    | simple_ffmpeg    | Video/audio transcoding via FFmpeg (CLI +
> SDK
> > modes) | 19/19 |
> >    | simple_usb       | USB enumeration, HID reports, gamepad input
> >       | 29/29 |
> >    | simple_audio     | WASAPI streaming, PCM buffers
> >       | 17/17 |
> >    | simple_serial    | COM port communication
> >      | 6/6   |
> >    | simple_bluetooth | Bluetooth SPP
> >       | 11/11 |
> >
> >    Key themes:
> >    - Inline C pattern (no external DLLs)
> >    - Fluent APIs with facade classes
> >    - Windows-only (Windows APIs) - for now - Linux coming (Mac? I
> don't
> > know)
> >
> > Full announcement is here <https://github.com/simple-eiffel/

> <https://github.com/simple-eiffel/>
> > claude_eiffel_op_docs/blob/main/posts/
> DEVICE_LIBRARIES_ANNOUNCEMENT.md>.
> >
> > Cheers,
> >
> > Larry
>
>

[Liberty Lover]

Yes, I understand. Regrettably, the design choice doesn't flow both ways. It boxes one into one way or the other. I wish the compiler could see the Current being returned as the Result and simply assume that is there is no follow-on receiver of Current that it would assume .do_nothing and just swallow it. But — that has dangers as well. I guess it proves that there are no perfect solutions that accommodate everyone. I wish that was the case.

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/25dcb655-9ca0-42a6-a341-2b42b93e2bf7%40gobosoft.com.

[Eric Bezault]

About having separate features `item` and `remove` is class STACK,
I think that they deserve to be there. If I just want to get the
last inserted element in the stack, I prefer to write:

v := stack.item

rather than:

v := stack.pop
stack.push (v)

Likewise, if I just want to remove the last inserted element in
the stack, I prefer to write:

stack.remove

rather than:

stack.pop.do_nothing

Now, if people want to have more complex routines like `pop`,
or `pop_and_push_and_push_and_pop_again_and_call_f_on_it`,
so be it.

Note that I'm not a strick defenser of the CQS principle. You
will certainly find code in Gobo Eiffel violating this principle.
It's just that when I saw the example using Fluent, I was not
convinced that the code looked cleaner.

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

On 27/12/2025 12:31, Liberty Lover wrote:
> Eric,
>
> One additional data point worth noting: Martin Fowler, in his https://

> martinfowler.com/bliki/CommandQuerySeparation.html <https://
> martinfowler.com/bliki/CommandQuerySeparation.html>, directly addresses

> Meyer's own pragmatism on this:
>
>   "Meyer likes to use command-query separation absolutely, but there
> are exceptions. Popping a stack is a good example of a query that
> modifies state. Meyer correctly says that you can avoid having this
> method, but it is a useful idiom."
>
> So even Meyer himself acknowledges that pop (which both returns a value
> AND modifies state) is a "useful idiom" - a pragmatic exception to his
> own principle.
>
> The fluent builder pattern falls into this same category: a transparent,
> predictable deviation that provides ergonomic value. Like pop, you could
> avoid it (separate set_* procedures + a final query), but the fluent
> form is a useful idiom that clearly communicates intent.
>

> I also note that your Gobo library takes the strict approach (separate /
> item /and /remove/), which is a valid choice. The simple_* libraries

> make a different valid choice. Both are defensible - CQS is a principle
> to be interpreted, not a law to be mechanically enforced.
>
> On Sat, Dec 27, 2025 at 6:18 AM Liberty Lover <rix....@gmail.com
> <mailto:rix....@gmail.com>> wrote:
>
> Hey Eric,
>
> On CQS "Violations"
>
> I agree that CQS is a valuable design principle, and I think it is
> interesting for anyone else reading (including myself) to note that
> CQS violations cannot be statically detected by a compiler. I think
> the reason for that is that in order to detect "does this function
> modify state?", the compiler would need to solve the Purity Analysis
> Problem - tracing through all transitive calls, handling
> polymorphism, external code, etc. This is undecidable in the general
> case.
>
> So, this leaves CQS as a human-interpreted guideline, not one that
> can be a mechanically compiler-enforced rule, which means or may mean:
>   - Developers must use their own judgment about when violations
> are acceptable
>   - The Eiffel ecosystem has always had pragmatic exceptions
> (iterators, certain container operations)

>   - A /transparent/, /obvious /violation isn't the same as a /
> dangerous /one

>   - https://dl.acm.org/doi/10.1145/161494.161501 <https://
> dl.acm.org/doi/10.1145/161494.161501>

>   - Proves static analysis problems are undecidable via reduction
> to the halting problem
>
>   2. Purity Analysis Research
>
>   Sălcianu, A. & Rinard, M. "Purity and Side Effect Analysis for
> Java Programs" - VMCAI 2005, Springer
>   - https://link.springer.com/chapter/10.1007/978-3-540-30579-8_14
> <https://link.springer.com/chapter/10.1007/978-3-540-30579-8_14>
>   - Defines purity analysis and shows it requires sophisticated
> pointer/escape analysis
>   - Even their advanced analysis can only determine purity "when
> mutation affects only objects created after method invocation"
>
>   3. Side Effect Detection in Compilers
>
>   Spuler, D. & Sajeev, A. "Compiler Detection of Function Call Side
> Effects"

>   - https://www.semanticscholar.org/paper/Compiler-Detection-of-
> Function-Call-Side-Effects-Spuler-
> Sajeev/9cf47f729e175688b78b519fa07f8e9e904410be <https://
> www.semanticscholar.org/paper/Compiler-Detection-of-Function-Call-
> Side-Effects-Spuler-Sajeev/9cf47f729e175688b78b519fa07f8e9e904410be>

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

[rfo amalasoft.com]

Pop is a weak example of an "allowable exception" to CQS.  "top" exists to query the topmost element.  "pop" can be purely directive.  Having to make 2 calls when one can work is what leads to lazy code (and coders) and failures.

As for "I'm too tired to read (or type) all those words" argument, that too seems a poor excuse for the loss of explicit code, and the motivation behind some of worst language errors in history. 

R

---

From: eiffel...@googlegroups.com <eiffel...@googlegroups.com> on behalf of Liberty Lover <rix....@gmail.com>
Sent: Saturday, December 27, 2025 6:31 AM
To: eiffel...@googlegroups.com <eiffel...@googlegroups.com>
Subject: Re: [eiffel-users] Simple Eiffel - Knowledge Base + Device Libs

 

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

[Eric Bezault]

Perhaps it was not the best example to show how fluent programming
can make the code simpler. I use "simpler" here because I'm not
convinced that it is "cleaner". And it goes well with the name of
the Simple project. Here is some pseudo-code which shows how simpler
the code can be:

api.regexp ("[a-z]").with_case_insensitivity.matches ("Gobo")

- No need to know the class name of the regexp object.
- No need to declare it in a local variable.

Experimenting with `with_...` instead of `set_...` here to see if
it makes the code more readable or not.

In any case, in my opinion fluent code is acceptable when we can
write it on a single line, and when it hides the complexity of the
code. But when the complexity is not hidden (as in the example with
`config`), and when the code needs to be written on several lines,
I don't appreciate its usefulness compared with "traditional"
programming style.

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

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

> dl.acm.org/doi/10.1145/161494.161501> <https://dl.acm.org/ <https://
> dl.acm.org/>

> Call-Side- <http://www.semanticscholar.org/paper/Compiler-Detection-

> of-Function-Call-Side->
> > Effects-Spuler-Sajeev/9cf47f729e175688b78b519fa07f8e9e904410be>
> >    - Documents that detecting side effects requires analyzing the
> entire
> > function body, tracking globals, references, I/O, etc.
> >
> >    4. General Principle
> >
> >    Rice's Theorem (1953) - Any non-trivial semantic property of
> programs
> > is undecidable. Side-effect-freedom is a semantic property,
> therefore
> > undecidable in the general case.
> >
> >    The https://en.wikipedia.org/wiki/Static_program_analysis

> <https://en.wikipedia.org/wiki/Static_program_analysis> <https://
> > en.wikipedia.org/wiki/Static_program_analysis <http://

> en.wikipedia.org/wiki/Static_program_analysis>> summarizes: "By a
> > straightforward reduction to the halting problem, finding all
> possible
> > run-time errors in an arbitrary program is undecidable."
> >
> > On Sat, Dec 27, 2025 at 4:43 AM Eric Bezault <er...@gobosoft.com
> <mailto:er...@gobosoft.com>

> > http://www.gobosoft.com <http://www.gobosoft.com> <http://

> >     <https://github.com/simple-eiffel/ <https://github.com/

[Ulrich Windl]

Good points, Eric.

27.12.2025 10:43:05 Eric Bezault <er...@gobosoft.com>:

[Ulrich Windl]

Hi!

I think returning "like Current" makes most sense if it's a modified copy of Current.
I don't have an Eiffel example in my mind, but a stupid one for Perl:
@a = sort grep { /whatever/ } map { "x=$_" } @a
map would return a different array, grep would return a reduced array, and sort will return a different array as well. Otherwise one would have to write:
@a = map { "x=$_" } @a
@a = grep { /whatever/ } @a
@a = sort @a

These are functions. With OO notation those could be procedures as well, like
self->map({ "x=$_" })
...
self->sort

Or when returning "like self":
@a = map ("x=$_", @a).grep(/whatever/).sort

Ulrich

27.12.2025 12:18:21 Liberty Lover <rix....@gmail.com>:

> Hey Eric,
>
> On CQS "Violations"
>
> I agree that CQS is a valuable design principle, and I think it is interesting for anyone else reading (including myself) to note that CQS violations cannot be statically detected by a compiler. I think the reason for that is that in order to detect "does this function modify state?", the compiler would need to solve the Purity Analysis Problem - tracing through all transitive calls, handling polymorphism, external code, etc. This is undecidable in the general case.
>
> So, this leaves CQS as a human-interpreted guideline, not one that can be a mechanically compiler-enforced rule, which means or may mean:
>   - Developers must use their own judgment about when violations are acceptable
>   - The Eiffel ecosystem has always had pragmatic exceptions (iterators, certain container operations)

>   - A /transparent/, /obvious /violation isn't the same as a /dangerous /one

>> 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/66897503-70af-4716-afb4-ee90d093718f%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.

> To view this discussion visit https://groups.google.com/d/msgid/eiffel-users/CA%2B3qnjem%2Bxw%3Dn8rrOdNRy18y8%2B5fo-zMnY5-vh4EhPiw8t42tg%40mail.gmail.com[https://groups.google.com/d/msgid/eiffel-users/CA%2B3qnjem%2Bxw%3Dn8rrOdNRy18y8%2B5fo-zMnY5-vh4EhPiw8t42tg%40mail.gmail.com?utm_medium=email&utm_source=footer].

[Ulrich Windl]

Maybe we need Pascal's "with config do ..." to pre-select an object to apply features. 😉

27.12.2025 13:28:29 Liberty Lover <rix....@gmail.com>:

>>> www.semanticscholar.org/paper/Compiler-Detection-of-Function-Call-Side-[http://www.semanticscholar.org/paper/Compiler-Detection-of-Function-Call-Side-]

>>> Effects-Spuler-Sajeev/9cf47f729e175688b78b519fa07f8e9e904410be>
>>>    - Documents that detecting side effects requires analyzing the entire
>>> function body, tracking globals, references, I/O, etc.
>>>
>>>    4. General Principle
>>>
>>>    Rice's Theorem (1953) - Any non-trivial semantic property of programs
>>> is undecidable. Side-effect-freedom is a semantic property, therefore
>>> undecidable in the general case.
>>>
>>>    The https://en.wikipedia.org/wiki/Static_program_analysis <https://

>>> en.wikipedia.org/wiki/Static_program_analysis[http://en.wikipedia.org/wiki/Static_program_analysis]> summarizes: "By a

>> 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/25dcb655-9ca0-42a6-a341-2b42b93e2bf7%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.

> To view this discussion visit https://groups.google.com/d/msgid/eiffel-users/CA%2B3qnjfXhhW9HBnZGLUFRSE7%3D7RkawhHmJF5VHMsPuvzBK5hqw%40mail.gmail.com[https://groups.google.com/d/msgid/eiffel-users/CA%2B3qnjfXhhW9HBnZGLUFRSE7%3D7RkawhHmJF5VHMsPuvzBK5hqw%40mail.gmail.com?utm_medium=email&utm_source=footer].

[Liberty Lover]

  Proposal: Dual-Style Setter Pattern for CQS Harmony

  The Problem: The Eiffel community has two camps:
  - CQS Purists: Prefer config.set_x (...) as separate procedure calls
  - Fluent Advocates: Prefer config.set_x (...).set_y (...) chaining

  Current designs force a choice - you can't serve both groups with one API.

  The Solution: Provide both styles with clear naming:

  feature -- Configuration (CQS-compliant procedures)

      set_baud_rate (rate: INTEGER)
              -- Set baud rate. No return value.
          do
              baud_rate := rate
          end

      set_data_bits (bits: INTEGER)
          do
              data_bits := bits
          end

  feature -- Configuration (Fluent functions)

      with_baud_rate (rate: INTEGER): like Current
              -- Set baud rate and return Current for chaining.
          do
              set_baud_rate (rate)
              Result := Current
          end

      with_data_bits (bits: INTEGER): like Current
          do
              set_data_bits (bits)
              Result := Current
          end

  Usage - Both Camps Happy:

  -- CQS-compliant style (no return value, explicit calls)
  config.set_baud_rate (115200)
  config.set_data_bits (8)
  config.set_parity (parity_none)

  -- Fluent style (chainable, single expression)
  config := config
      .with_baud_rate (115200)
      .with_data_bits (8)
      .with_parity (parity_none)

  Naming Convention:
  - set_* = pure procedure (CQS-compliant command)
  - with_* = fluent function (returns Current)

  The with_ prefix semantically signals "configure with this and continue" - it reads naturally in chains and clearly differentiates from the procedural set_.

  Benefits:
  1. No forced choice - Library users pick their preferred style
  2. CQS remains an option - Purists aren't forced into violations
  3. Fluent remains an option - Those who find it cleaner can use it
  4. Clear semantics - Naming makes intent obvious
  5. No duplication of logic - with_* simply calls set_* then returns Current

  Thoughts?

--
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/8f5f6750-40de-4158-866d-bfe7d20ada27%40gobosoft.com.

[Mischa Megens]

The Dutch expression for this approach translates roughly as:
'Trying to save the cabbage *and* the goat'
(with the implication that it is unlikely to be very successful)

To view this discussion visit https://groups.google.com/d/msgid/eiffel-users/CA%2B3qnjdLA6%3DPpUAzm4zg6kA_dNB9sNHG1uWmY83vvV5un%3DJVsQ%40mail.gmail.com.

[Liberty Lover]

Hi Mischa,

LOL — I think I actually get the "cabbage-and-goat" expression — the goats are eating the cabbages so one is in a dilemma. One can have one or the other, but not both.

In this case, we can actually have both our cake and eat it too, where the "set_*" form works for the Eiffel normies and the "with_*" works for the fluent pattern. And with Eiffel's dead code removal, whichever one you pick is the only one that ends up in the finalized binary. This also means that you can use both in different contexts as you wish or like. Furthermore, because I am not a single human being trying to maintain this mountain of code, I actually find no burden to maintain both approaches in all of the "fluent-using" libs.

It also helps us as a community to sluff off the perception (right or wrong) of being Eiffel purists or elitists (e.g. "Our way or the highway — you didn't bring any good ideas that we haven't already thought of anyhow!"). It was the entire reason I set about a massive refactor recently based on having multiple feature names based on semantic context and approach to any of the simple_* libraries. We don't have to let everything through the gate, but we ought not to be resistive towards everything in a knee-jerk manner.

We have a saying in America: Good fences make good neighbors. Thus, the idea I presented is just fencing in the goats so they leave the cabbages alone. :-) 

Cheers,

Larry

To view this discussion visit https://groups.google.com/d/msgid/eiffel-users/4ec7dd4d-2b30-402a-88e6-b72ee8fd9f21%40gmail.com.

[Liberty Lover]

Ulrich,

RE: Pascal's "with config do ..." — that's kind of the idea, but I cannot speak to the Eiffel language itself and adding yet another keyword to the mixture. The idea of "config.with_* (...).with_* (...). and so on kind of heads in the same semantic direction as a "naming convention" applied to the idea of "fluent" APIs without necessitating language bloat. But the idea seems contextually heading the same direction. 

To view this discussion visit https://groups.google.com/d/msgid/eiffel-users/2688f1d3-d347-46c5-aaf0-b1ae32c470e3%40gmail.com.

[Eric Bezault]

Hi Larry,

Sounds good to me.

It looks like you liked my naming experiment with `with_`
instead of `set_` for the fluent style ;-)

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

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

> On 27/12/2025 13:28, Liberty Lover wrote:
> > Yes, I understand. Regrettably, the design choice doesn't flow both
> > ways. It boxes one into one way or the other. I wish the compiler
> could
> > see the Current being returned as the Result and simply assume
> that is
> > there is no follow-on receiver of Current that it would
> > assume .do_nothing and just swallow it. But — that has dangers as
> well.
> > I guess it proves that there are no perfect solutions that
> accommodate
> > everyone. I wish that was the case.
> >
> > Larry
> >
> > On Sat, Dec 27, 2025 at 7:21 AM Eric Bezault <er...@gobosoft.com
> <mailto:er...@gobosoft.com>

> > <mailto:er...@gobosoft.com <mailto:er...@gobosoft.com>>> wrote:
> >
> >     About readability, I guess that it is subjective because
> >     I find:
> >
> >           config.set_baud_rate (115200)
> >           config.set_data_bits (8)
> >           config.set_parity ({SERIAL_PORT_CONFIG}.parity_none)
> >           config.set_stop_bits ({SERIAL_PORT_CONFIG}.stop_bits_one)
> >           config.set_flow_control
> >     ({SERIAL_PORT_CONFIG}.flow_control_hardware)
> >
> >     more readable than:
> >
> >           config := config
> >               .set_baud_rate (115200)
> >               .set_data_bits (8)
> >               .set_parity ({SERIAL_PORT_CONFIG}.parity_none)
> >               .set_stop_bits ({SERIAL_PORT_CONFIG}.stop_bits_one)
> >               .set_flow_control
> ({SERIAL_PORT_CONFIG}.flow_control_hardware)
> >
> >     --
> >     Eric Bezault
> >     mailto:er...@gobosoft.com <mailto:er...@gobosoft.com>

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

> > dl.acm.org/doi/10.1145/161494.161501 <http://dl.acm.org/

> doi/10.1145/161494.161501>> <https://dl.acm.org/ <https://

> dl.acm.org/> <https://
> > dl.acm.org/ <http://dl.acm.org/>>

> >      > doi/10.1145/161494.161501>
> >      >    - Proves static analysis problems are undecidable via
> >     reduction to
> >      > the halting problem
> >      >
> >      >    2. Purity Analysis Research
> >      >
> >      >    Sălcianu, A. & Rinard, M. "Purity and Side Effect
> Analysis for
> >     Java
> >      > Programs" - VMCAI 2005, Springer

> >      >    - https://link.springer.com/ <https://link.springer.com/>
> >     chapter/10.1007/978-3-540-30579-8_14 <https://
> link.springer.com/ <https://link.springer.com/>
> >     chapter/10.1007/978-3-540-30579-8_14>
> >      > <https://link.springer.com/
> chapter/10.1007/978-3-540-30579-8_14 <https://link.springer.com/

> chapter/10.1007/978-3-540-30579-8_14>
> >     <https://link.springer.com/
> chapter/10.1007/978-3-540-30579-8_14 <https://link.springer.com/
> chapter/10.1007/978-3-540-30579-8_14>>>

> >      >    - Defines purity analysis and shows it requires
> sophisticated
> >      > pointer/escape analysis
> >      >    - Even their advanced analysis can only determine
> purity "when
> >      > mutation affects only objects created after method invocation"
> >      >
> >      >    3. Side Effect Detection in Compilers
> >      >
> >      >    Spuler, D. & Sajeev, A. "Compiler Detection of Function
> Call Side
> >      > Effects"
> >      >    - https://www.semanticscholar.org/paper/Compiler-
> Detection-of- <https://www.semanticscholar.org/paper/Compiler-
> Detection-of->
> >     <https://www.semanticscholar.org/paper/Compiler-Detection-of-
> <https://www.semanticscholar.org/paper/Compiler-Detection-of->>
> >      > Function-Call-Side-Effects-Spuler-
> >      > Sajeev/9cf47f729e175688b78b519fa07f8e9e904410be <https://
> >      > www.semanticscholar.org/paper/Compiler-Detection-of-

> Function- <http://www.semanticscholar.org/paper/Compiler-Detection-
> of-Function->
> >     Call-Side- <http://www.semanticscholar.org/paper/Compiler-
> Detection- <http://www.semanticscholar.org/paper/Compiler-Detection->
> >     of-Function-Call-Side->
> >      > Effects-Spuler-

> Sajeev/9cf47f729e175688b78b519fa07f8e9e904410be>
> >      >    - Documents that detecting side effects requires
> analyzing the
> >     entire
> >      > function body, tracking globals, references, I/O, etc.
> >      >
> >      >    4. General Principle
> >      >
> >      >    Rice's Theorem (1953) - Any non-trivial semantic
> property of
> >     programs
> >      > is undecidable. Side-effect-freedom is a semantic property,
> >     therefore
> >      > undecidable in the general case.
> >      >
> >      >    The https://en.wikipedia.org/wiki/

> Static_program_analysis <https://en.wikipedia.org/wiki/
> Static_program_analysis>
> >     <https://en.wikipedia.org/wiki/Static_program_analysis

> <https://en.wikipedia.org/wiki/Static_program_analysis>> <https://
> >      > en.wikipedia.org/wiki/Static_program_analysis <http://

> en.wikipedia.org/wiki/Static_program_analysis> <http://

> > en.wikipedia.org/wiki/Static_program_analysis <http://
> en.wikipedia.org/wiki/Static_program_analysis>>> summarizes: "By a
> >      > straightforward reduction to the halting problem, finding all
> >     possible
> >      > run-time errors in an arbitrary program is undecidable."
> >      >
> >      > On Sat, Dec 27, 2025 at 4:43 AM Eric Bezault
> <er...@gobosoft.com <mailto:er...@gobosoft.com>
> >     <mailto:er...@gobosoft.com <mailto:er...@gobosoft.com>>

> www.gobosoft.com <http://www.gobosoft.com>> <http://

> simple- <https://github.com/simple->
> >     eiffel/ <https://github.com/simple-eiffel/ <https://

> github.com/simple-eiffel/>>
> >      >     <https://github.com/simple-eiffel/ <https://

> github.com/simple-eiffel/> <https://github.com/ <https://github.com/>

[Liberty Lover]

Eric,

Indeed. The "with_*" semantic comes off really well and flows nicely. 

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/7637f7c9-2e83-4fd0-90c1-44096cdcad3c%40gobosoft.com.

[Ulrich Windl]

Hi!

As my memory was faint, I asked AI:
---------
**Solution to the classic river‑crossing puzzle**

The goal is to move the farmer, the wolf, the goat (or sheep), and the cabbage across the river using a boat that can carry only the farmer plus one item, without leaving the wolf alone with the goat or the goat alone with the cabbage.

**Step‑by‑step sequence**

1. **Farmer takes the goat across** → left bank: wolf, cabbage; right bank: goat. 
2. **Farmer returns alone** → left bank: farmer, wolf, cabbage; right bank: goat. 
3. **Farmer takes the wolf across** → left bank: cabbage; right bank: goat, wolf. 
4. **Farmer brings the goat back** → left bank: farmer, goat, cabbage; right bank: wolf. 
5. **Farmer takes the cabbage across** → left bank: goat; right bank: wolf, cabbage. 
6. **Farmer returns alone** → left bank: farmer, goat; right bank: wolf, cabbage. 
7. **Farmer takes the goat across** → left bank: empty; right bank: farmer, wolf, goat, cabbage.

All items are now safely on the opposite bank (or island) with no prohibited pair left alone together.
--------
And I think the Mexicans will become good neighbors 😉

--

Kind regards,
Ulrich Windl

27.12.2025 20:24:00 Liberty Lover <rix....@gmail.com>:

>>>>>     dl.acm.org/doi/10.1145/161494.161501[http://dl.acm.org/doi/10.1145/161494.161501]> <https://dl.acm.org/ <https://
>>>>>     dl.acm.org/[http://dl.acm.org/]>

>>>>>      > doi/10.1145/161494.161501>
>>>>>      >    - Proves static analysis problems are undecidable via
>>>>>     reduction to
>>>>>      > the halting problem
>>>>>      >
>>>>>      >    2. Purity Analysis Research
>>>>>      >
>>>>>      >    Sălcianu, A. & Rinard, M. "Purity and Side Effect Analysis for
>>>>>     Java
>>>>>      > Programs" - VMCAI 2005, Springer
>>>>>      >    - https://link.springer.com/
>>>>>     chapter/10.1007/978-3-540-30579-8_14 <https://link.springer.com/
>>>>>     chapter/10.1007/978-3-540-30579-8_14>
>>>>>      > <https://link.springer.com/chapter/10.1007/978-3-540-30579-8_14
>>>>>     <https://link.springer.com/chapter/10.1007/978-3-540-30579-8_14>>
>>>>>      >    - Defines purity analysis and shows it requires sophisticated
>>>>>      > pointer/escape analysis
>>>>>      >    - Even their advanced analysis can only determine purity "when
>>>>>      > mutation affects only objects created after method invocation"
>>>>>      >
>>>>>      >    3. Side Effect Detection in Compilers
>>>>>      >
>>>>>      >    Spuler, D. & Sajeev, A. "Compiler Detection of Function Call Side
>>>>>      > Effects"
>>>>>      >    - https://www.semanticscholar.org/paper/Compiler-Detection-of-
>>>>>     <https://www.semanticscholar.org/paper/Compiler-Detection-of->
>>>>>      > Function-Call-Side-Effects-Spuler-
>>>>>      > Sajeev/9cf47f729e175688b78b519fa07f8e9e904410be <https://

>>>>>      > www.semanticscholar.org/paper/Compiler-Detection-of-Function-[http://www.semanticscholar.org/paper/Compiler-Detection-of-Function-]

>>>>>     Call-Side- <http://www.semanticscholar.org/paper/Compiler-Detection-
>>>>>     of-Function-Call-Side->
>>>>>      > Effects-Spuler-Sajeev/9cf47f729e175688b78b519fa07f8e9e904410be>
>>>>>      >    - Documents that detecting side effects requires analyzing the
>>>>>     entire
>>>>>      > function body, tracking globals, references, I/O, etc.
>>>>>      >
>>>>>      >    4. General Principle
>>>>>      >
>>>>>      >    Rice's Theorem (1953) - Any non-trivial semantic property of
>>>>>     programs
>>>>>      > is undecidable. Side-effect-freedom is a semantic property,
>>>>>     therefore
>>>>>      > undecidable in the general case.
>>>>>      >
>>>>>      >    The https://en.wikipedia.org/wiki/Static_program_analysis
>>>>>     <https://en.wikipedia.org/wiki/Static_program_analysis> <https://

>>>>>      > en.wikipedia.org/wiki/Static_program_analysis[http://en.wikipedia.org/wiki/Static_program_analysis] <http://
>>>>>     en.wikipedia.org/wiki/Static_program_analysis[http://en.wikipedia.org/wiki/Static_program_analysis]>> summarizes: "By a

>>>>>     www.gobosoft.com[http://www.gobosoft.com] <http://www.gobosoft.com>>

>>>> 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/8f5f6750-40de-4158-866d-bfe7d20ada27%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.

>>> To view this discussion visit https://groups.google.com/d/msgid/eiffel-users/CA%2B3qnjdLA6%3DPpUAzm4zg6kA_dNB9sNHG1uWmY83vvV5un%3DJVsQ%40mail.gmail.com[https://groups.google.com/d/msgid/eiffel-users/CA%2B3qnjdLA6%3DPpUAzm4zg6kA_dNB9sNHG1uWmY83vvV5un%3DJVsQ%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.

>> To view this discussion visit https://groups.google.com/d/msgid/eiffel-users/4ec7dd4d-2b30-402a-88e6-b72ee8fd9f21%40gmail.com[https://groups.google.com/d/msgid/eiffel-users/4ec7dd4d-2b30-402a-88e6-b72ee8fd9f21%40gmail.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.

> To view this discussion visit https://groups.google.com/d/msgid/eiffel-users/CA%2B3qnjf-ZWaLH79Kg9LLEkQ57Brfcq2d0mjORh21KW7Fn_8SmQ%40mail.gmail.com[https://groups.google.com/d/msgid/eiffel-users/CA%2B3qnjf-ZWaLH79Kg9LLEkQ57Brfcq2d0mjORh21KW7Fn_8SmQ%40mail.gmail.com?utm_medium=email&utm_source=footer].

[Jakub Pavlík]

From languages where fluent setters are widely used, I'm used to with_* methods as an idiom for immutable interfaces: they return a copy of Current with the single property changed. I find a with_* method returning simply a reference to Current pretty counter-intuitive.

Regards,

Jakub Pavlík

[Liberty Lover]

Jakub,

I really like the "with_*" pattern semantically. It tends to flow. There are perhaps other words that fit the semantic context well. I can see getting used to this form of "reading" which means that the matter then becomes one of taste and personal semantic framing rather than "right-or-wrong" (which it never is in this subjective context).

Cheers,

Larry

To view this discussion visit https://groups.google.com/d/msgid/eiffel-users/4f295b6d-baab-43a8-ab09-b979e558b733n%40googlegroups.com.