Eiffel 24.11 Suggestions

[Brother Bill]

When creating a new Console class, the wizard should have Concurrency initially UNCHECKED.  SCOOP is not for Eiffel newbies.

When newbies get warning/error messages regarding `separate' issues, they have no idea what `separate' means and how to go about fixing them.

This increases support costs and reduces adoption.

It is so much easier to have Concurrency unchecked by default, and then those wanting SCOOP to simply check [x] Concurrency.

Is there a way in Eiffel 24.05 to change the wizard so as to have Concurrency unchecked when opened for Console applications?

[Brother Bill]

Consider adding (op) :=, such as Result (+) := 1
This would be syntactic sugar, equivalent to Result := Result + 1

As this would not be in DbC contracts, this would be a way to cut down some typing.
We would wrap the operator in parentheses to make it stand out.
Result +:= 1  or Result + := 1 looks off.
Result (+) := 1  stands out and is comfortable for C# developers
Result += 1 does not look like Eiffel syntax.
The operator could be named, such as Result (plus) := 1

An alternative is Result := (+) 1, but this doesn't match C# developer expectations.

[rfo amalasoft.com]

If fewer keystrokes are a goal, then readability, understandability, and proper command/query separation, will be the victims.  Sugar rots your teeth and diminishes your ability to digest.

---

From: eiffel...@googlegroups.com <eiffel...@googlegroups.com> on behalf of Brother Bill <brother...@gmail.com>
Sent: Friday, June 14, 2024 11:39 AM
To: Eiffel Users <eiffel...@googlegroups.com>
Subject: [eiffel-users] Re: Eiffel 24.11 Suggestions

 

--
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 on the web visit https://groups.google.com/d/msgid/eiffel-users/dea4090e-f9e0-4fb0-b1b6-be777ca290a8n%40googlegroups.com.

[mischa.megens]

Excessive sugar consumption has been implicated in obesity, metabolic disorders, diabetes, cardiovascular disease, cancer, depression, and cognitive impairment.

[rfo amalasoft.com]

Guilty as charged.  Wait, what were we talking about? 🙂

---

From: eiffel...@googlegroups.com <eiffel...@googlegroups.com> on behalf of mischa.megens <mischa...@gmail.com>
Sent: Friday, June 14, 2024 2:23 PM
To: Eiffel Users <eiffel...@googlegroups.com>
Subject: Re: [eiffel-users] Re: Eiffel 24.11 Suggestions

 

To view this discussion on the web visit https://groups.google.com/d/msgid/eiffel-users/7b9da0f1-ba67-4f7c-8bf7-eb8d6211f3e6n%40googlegroups.com.

[Bertrand Meyer]

The question was about improvements to the environment. For the moment the language is pretty stable.

 

-- BM

To view this discussion on the web visit https://groups.google.com/d/msgid/eiffel-users/CYXPR08MB96101DD57371083B414F9643A0C22%40CYXPR08MB9610.namprd08.prod.outlook.com.

[Ian Joyner]

I think +:= opens up a whole new can of worms that Bertrand does not want to.

I’m kind of against it, since it is a C idea. However, that might be attractive to C/C++ people coming to Eiffel seeing some familiar syntactic sugar. I don’t think these operators have the same side effect problems as ‘++’ (what a terrible choice to use as a language name, the worst operator!).

But the reason, I say this here is that we should not have these ‘double (or triple) character’ operators. They were a technology constraint on limited character sets. ‘:=‘ itself was a compromise. The ALGOL people (as I understand) wanted a single arrow ←, but there was no such character on most keyboards (they were no where near standard in the 1950s).

Now Ken Thompson devolved that for C so he did not have to type ‘:’ on the old clunky teletype keyboards they had. Programmers like a flow of thinking, and not have to think too much about typing. In that Thompson was right, but devolving := to = was wrong.

They then needed the ugly and trap-prone ‘==‘ for equality tests. And that is escaping to natural language, where I’ve seen ‘==‘ used, where there is no ambiguity between = and :=. Or in the boolean operators in Wireshark where there is no assignment. Now C++ (and Haskell) use the awful ‘::’.

We now have extensive standardised character sets in ucode. Lexical considerations in languages could use single meaningful characters instead of the double characters which were constrained by the technology of limited character sets.

But then there is the problem of mapping all these fancy characters to keyboards. They are often a pain to type (Thompson’s original problem).

So there is the opportunity for shortcuts. Perhaps if the programmer types:

a = …

the IDE goes “aha it can’t be equality, it must be assignment” so substitute := or better ← (an arrow).

Thus the environment can lexically correct programs. But that also needs care – I quite often find a spell checker substitutes a completely wrong word, sometimes I notice, sometimes I don’t, which causes confusion later.

Perhaps for the +=, *= Thompson shortcuts there could be composite characters of ‘:=' with a + on top of the ‘=‘ (like the EBNF ∆ on top of = for ‘is defined as’), or a ‘+’ on top of ‘←’.

Similarly we should have ‘≠’ converted from typing ‘/=‘.

Now there are a lot of programs with assignment typed as ‘:=‘, so maybe an environment option for each individual programmer to choose ‘Display := as ←’. That avoids the inevitable style wars where one programmer likes ← but others want to stick to ‘:=‘.

Many other style wars can be avoided by environmental options.

https://www.quora.com/What-does-mean-in-C-programming-19/answer/Ian-Joyner-1

Ian

To view this discussion on the web visit https://groups.google.com/d/msgid/eiffel-users/CYXPR08MB9610B2DC31A64A17CEEC8E22A0C22%40CYXPR08MB9610.namprd08.prod.outlook.com.

[Bertrand Meyer]

As a matter of fact, Alan Perlis, the first ever Turing Award winner, wrote many years ago that “syntactic sugar causes cancer of the semicolon”. (https://www.cs.yale.edu/homes/perlis-alan/quotes.html.)

 

To which I would add “All our operators are currently overloaded. Typing errors may result”.

 

-- BM

To view this discussion on the web visit https://groups.google.com/d/msgid/eiffel-users/7b9da0f1-ba67-4f7c-8bf7-eb8d6211f3e6n%40googlegroups.com.

[Ian Joyner]

I often quote:

Alan Perlis (first recipient of the ACM Turing Award for computing): “A programming language is low level when its programs require attention to the irrelevant. While, yes, this definition applies to C, it does not capture what people desire in a low-level language.”

which I got from:

https://queue.acm.org/detail.cfm?id=3212479

Ian

To view this discussion on the web visit https://groups.google.com/d/msgid/eiffel-users/0fc801dabee8%243977e5e0%24ac67b1a0%24%40inf.ethz.ch.

[Ulrich Windl]

But essentially any programming language is just syntactic sugar for machine language. Maybe the real question is: What is the smallest convenient subset? In classical top-down design you would define operations as needed from the existing subset. I think highly complex syntax is to be avoided.

Ulrich

--

Mit freundlichen Grüßen
Ulrich Windl

14.06.2024 21:23:39 mischa.megens <mischa...@gmail.com>:

> Excessive sugar consumption has been implicated in obesity, metabolic disorders, diabetes, cardiovascular disease, cancer, depression, and cognitive impairment.
>
> On Friday, June 14, 2024 at 11:03:06 AM UTC-7 rfo wrote:
>> If fewer keystrokes are a goal, then readability, understandability, and proper command/query separation, will be the victims.  Sugar rots your teeth and diminishes your ability to digest.

>> ----------------------------------------
>> *From:* eiffel...@googlegroups.com <eiffel...@googlegroups.com> on behalf of Brother Bill <brother...@gmail.com>
>> *Sent:* Friday, June 14, 2024 11:39 AM
>> *To:* Eiffel Users <eiffel...@googlegroups.com>
>> *Subject:* [eiffel-users] Re: Eiffel 24.11 Suggestions

>>  
>> Consider adding (op) :=, such as Result (+) := 1
>> This would be syntactic sugar, equivalent to Result := Result + 1
>> As this would not be in DbC contracts, this would be a way to cut down some typing.
>> We would wrap the operator in parentheses to make it stand out.
>> Result +:= 1  or Result + := 1 looks off.
>> Result (+) := 1  stands out and is comfortable for C# developers
>> Result += 1 does not look like Eiffel syntax.
>> The operator could be named, such as Result (plus) := 1
>> An alternative is Result := (+) 1, but this doesn't match C# developer expectations.
>>
>> On Friday, June 14, 2024 at 8:14:13 AM UTC-4 Brother Bill wrote:
>>> When creating a new Console class, the wizard should have Concurrency initially UNCHECKED.  SCOOP is not for Eiffel newbies.
>>> When newbies get warning/error messages regarding `separate' issues, they have no idea what `separate' means and how to go about fixing them.
>>> This increases support costs and reduces adoption.
>>> It is so much easier to have Concurrency unchecked by default, and then those wanting SCOOP to simply check [x] Concurrency.
>>> Is there a way in Eiffel 24.05 to change the wizard so as to have Concurrency unchecked when opened for Console applications?
>>
>> --
>> 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 on the web visit https://groups.google.com/d/msgid/eiffel-users/dea4090e-f9e0-4fb0-b1b6-be777ca290a8n%40googlegroups.com[https://groups.google.com/d/msgid/eiffel-users/dea4090e-f9e0-4fb0-b1b6-be777ca290a8n%40googlegroups.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 on the web visit https://groups.google.com/d/msgid/eiffel-users/7b9da0f1-ba67-4f7c-8bf7-eb8d6211f3e6n%40googlegroups.com[https://groups.google.com/d/msgid/eiffel-users/7b9da0f1-ba67-4f7c-8bf7-eb8d6211f3e6n%40googlegroups.com?utm_medium=email&utm_source=footer].

[Ulrich Windl]

Interesting related questions might be: So why did these atchtitecturs fail all: Was it Intel and Microsoft, or didn't programmers accept it?
LISP Machine
SPARC
EPIC (Itanium)

For EPIC you couldn't get the performance of the much cheaper x86 CPUs. A simple experiment I had made showed that the compilers were creating code that did use the instruction slots very poorly. So maybe Intel though: Do let the CPU do it ...

Ulrich

[Ian Joyner]

"But essentially any programming language is just syntactic sugar for machine language.”

I could not disagree more. Any language is a vehicle for thinking. A programming language is for thinking about problems. Coding a computer is just a happy outcome.

Only thinking of a programming language as syntactic sugar for machine language is the C/C++ way of thinking. C just added structured syntax as syntactic sugar, but really missed the point of structured programming and undermined it.

C++ added syntactic sugar (although the syntax is hardly sweet like sugar) for OO but missed the point of OO, again doing more to undermine the method.

Thinking of a language as just syntactic sugar is thinking in translational and operational semantics, rather than denotational and axiomatic semantics, which Eiffel is really based on.

Leave the coding to the code generator in the compiler and don’t think about the machine. That is the old, primitive, unsophisticated thinking of C/C++.

"Maybe the real question is: What is the smallest convenient subset? In classical top-down design you would define operations as needed from the existing subset. I think highly complex syntax is to be avoided.”

Yes, but syntax must be clean, clear, and direct. There is no one language to rule them all, which is what C and C++ have tried to be.

Ian

To view this discussion on the web visit https://groups.google.com/d/msgid/eiffel-users/49b7ee50-fefc-4d43-afdb-ff630a87a80d%40gmail.com.

[Ian Joyner]

Good observations. But things in computing don’t fail because of lack of quality. People have always looked for the one solution to everything. That is a disaster, like I said about languages.

This is a good article on processor architecture:

https://cacm.acm.org/practice/how-to-design-an-isa/

It makes the important point that there are certain tradeoffs in processors and there are those for big cores (for multiprogramming) and small cores for single-purpose embedded.

Similar things for languages — those for serious large-scale complex development, and those for small problems.

Ian

[Brother Bill]

Bertrand, regarding Cancer of the Semicolon.
There is one required location of semicolons in Eiffel.
This is as the formal arguments separators as in 
do_something (arg1: CLASS1; arg2: CLASS2)

Eiffel has already accepted some conventional syntactic sugar, such as using square brackets for assignment statements.
These were not in OOSC2 back in 1997.

[Brother Bill]

Consideration of String Interpolation.
A current typical print instruction would be:
print ("Count: " + count.out + "%N")  -- for Console applications
An interpolated version might have syntax, borrowed from C#
print ($"Count: {count}%N")

Seriously, I don't see the benefit of this.  The original version is clear enough.
The C# versions would have been:
Write("Count: " + count.ToString() + "\n");
Write($"(Count: {count)\n");
In the C# case, the ToString with parentheses is rather heavy.
For Eiffel, out is only three letters, with no parentheses.
Recommendation: Don't add string interpolation to Eiffel.
One less thing that Eiffel newbies need to learn.

[rfo amalasoft.com]

Everything, to be consumable, must be in the "language of the consumer" (note well that I did not say "customer").  The compiler consumes the high level language, at the tail end of the chain, the processor consumes the instructions.  Then the picture changes when the software needs to be shared, maintained, fixed, etc.  Then the consumer is the poor S.O.B. who has to wade through the swamp of syntax to get to the meaning of that passage.  Often, the poor S.O.B. Is the one who wrote it, but not always.  Above all, any "written work" that includes some form of logic or instruction must convey, clearly, the intent.

Saving a keystroke is simply stroking the producer, at the cost to the consumer (the aforementioned S.O.B.).

Readability is the single most important characteristic of written works, including software.  Without it, understandability is unnecessarily tedious and elusive.

Eiffel, even with its lofty ambitions w/r/t modeling power and correctness, has been perhaps the most readable of languages.  Running headlong into the syntactic sugar swamp only compromises that great value, for the benefit of the few.

R

---

From: eiffel...@googlegroups.com <eiffel...@googlegroups.com> on behalf of Ulrich Windl <u202...@gmail.com>
Sent: Saturday, June 15, 2024 3:50 AM
To: eiffel...@googlegroups.com <eiffel...@googlegroups.com>
Subject: Re: [eiffel-users] Re: Eiffel 24.11 Suggestions

 

To view this discussion on the web visit https://groups.google.com/d/msgid/eiffel-users/49b7ee50-fefc-4d43-afdb-ff630a87a80d%40gmail.com.

[Ulrich Windl]

Hi!

I think the inefficiency is building a string just to output it, and then discard it. If print would allow to receive an ARRAY[ANY] argument, building the extra string might be avoided (but an array would be constructed).
Extending print to parse the value of string may seem handy, but it's both, inefficient and incompatible. Unfortunately it seems you cannot write such function yourself if needed (unless you set up some abstract environment for your variables).

Ulrich

15.06.2024 14:35:01 Brother Bill <brother...@gmail.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 on the web visit https://groups.google.com/d/msgid/eiffel-users/9e1f94f4-68e1-46a8-80fd-4f65bca12d50n%40googlegroups.com[https://groups.google.com/d/msgid/eiffel-users/9e1f94f4-68e1-46a8-80fd-4f65bca12d50n%40googlegroups.com?utm_medium=email&utm_source=footer].

[rfo amalasoft.com]

In my printf library, I offer an option to print a container's items.

Here is a description.

R

Using AEL Printf Routines

The AEL Printf routines provide a means by which to format strings in a manner

reminiscent of, but not strictly duplicating, the traditional printf functions

in C.

Format string construction (in order):

%

[<decoration_flag>]

[<agent_flag>]

[<alignment_flag>]

[<fill_specifier>]

[<field_width>]

<field_type>

Where:

  The ‘%’ character denotes a format specifier, as it does in C printf.

    The ‘%’ character is also Eiffel’s escape character.  As such, when

    creating a format string, be sure either to use a verbatim string, or

    to add another ‘%’ character before each format specifier, lest Eiffel

    treat it as an escape character.

    For example, "name=%s", if not a verbatim string, will be interpreted

    by Eiffel as an attempt to use ‘s’ as a character code, and because ‘s’

    is not an Eiffel character code, the compiler will flag it as a syntax

    error.

    To compensate, simply double up the ‘%’ characters.  The successful form

    would then be "name=%%s".

    When using verbatim strings, Eiffel does not interpret the ‘%’ character,

    and so only a single ‘%’ is needed in that case.

"{

name=%s

}"

And Where:

  <decoration_flag> ::=  '#'

    Decoration (triggered by the decoration flag) consumes part of the field

    width.

    Decoration is applied as follows:

      "0x" preceding hexadecimal values

      "0" preceding octal values

      "b" following binary values

      Delimiters between thousands for decimal values (commas by default)

      Newline between list values (See ‘L’ field type, below)

    Examples:

      printf (“%%#10x”, << 123 >>)

      yields:

0x0000007B

      printf (“%%#10o”, << 123 >>)

      yields:

0000000173

      printf (“%%#10b”, << 123 >>)

      yields:

001111011b

      printf (“%%#10d”, << 1230 >>)

      yields:

     1,230

      printf (“%%#L”, << << 1, 2, 3 >> >>)

      yields:

1

2

3

And Where:

  <agent_flag> ::=  '~'

    Valid for List (%L), Matrix (%M), and Table (%H) formats only.

    Cannot be combined with decoration flag (and is ignored in that case).

    Example (List format):

      printf (“%%~L”, << << 1, 2, 3 >>, agent item_out >>)

      yields:

         1         2         4

      In the case where ‘item_out’ is a FUNCTION that produces

      10-character-wide fields of right-justified decimal numbers

And Where:

  <alignment_flag> ::=   '-' |   '='  |  '+'

    Specifies left, center, or right alignment, respectively

    Valid for String and numeric formats.

    When ‘+’ is applied to Matrix format, forces column-major output

    (row-major is default).

And Where:

  <fill_specifier> ::=  <character>

    Fills remainder of field width with given character (default is blank)

And Where:

  <field_width> ::=  <simple_width> | <complex_width>

  <field_type> ::=  <character>

    Field types include the following:

      A denotes an Agent expression.

        Argument must be a function that accepts an argument of type ANY

        and returns a STRING.

      a denotes an ANY expression.

        Argument is untyped and the output is <arg>.out.

      B denotes a Boolean expression

        This shows as "True" or "False"

        A global flag, for the AEL Printf subsystem, can be set to change

        BOOLEAN values to all lower case (“true” or “false”), as needed for

        some protocols.  See Shared Printf Settings, below.

      b denotes a Binary integer expression

        This shows as ones and zeroes.

        If no field width is specified, the field width will be the smallest

        whole integer size (8, 16, 32, 64) that can hold the value of the

        argument.  Values from 0 through 255 have an implicit field width

        of 8, values between 256 and 65535 have 16, values between 65536

        and 4294967295 have 32, and larger values have an implicit field

        width of 64.

        When a field width is specified, the default padding character is blank.

        A ‘0’ padding character can also be specified (as with other integral

        types) for positive values, but when the value being rendered is

        negative, the pad character used is a ‘1’.

      C denotes a Complex expression, enabling formatted output of a container

        and its items, and having the form:

          "%C(" <container_fmt> [ <sub_fmt> ] ')'

            <container_fmt> ::= List, Matrix or Table std syntax

            <sub_fmt> ::= '[' <fmt> "][" <fmt_args> ']'

            <fmt> ::= per-item format string, std syntax

            <fmt_args> ::= <tags>   (position-relative, unseparated)

            <tags> ::= <tag> [<tags>]

            <tag> ::= V | I | K | R | C

          Where:

            V=item value (all containers)

            I=item position (List and Table)

            K=item key (Hash Table only)

            R=item row (Matrix only)

            C=item column (Matrix only)

            Examples:

             %C(#L[%-4d: %+16s][IV])

             %C(+M[(%04d,%04d) %+16s][CRV])

             %C(,H[%a (by %s, at %d)][VKI])

             %C(L)

      c denotes a single CHARACTER

      d denotes a Decimal integer expression

        Type specifier can be preceded by a delimiter character with which

        to separate groups of 3 adjacent digits (thousands).

        Alignment characters cannot be used as delimiters.

      f denotes a Floating Point (REAL_* or DOUBLE) expression

        Field width for floating point values are given in the form:

          <overall_width>"."<right_width>

        Where <overall_width> is the minimum width of the entire representation,

        and <right_width> is the width for the fractional part (precision).

        A precision of 0 results in a whole number representation, without

        decimal point (effectively rounding to integer).

      H denotes a (Hash) Table expression

        Type specifier can be preceded by a delimiter character with which to

        separate items (default is blank).

        Alignment characters cannot be used as delimiters.

        In place of a delimiter, the agent flag ('~') can be used.  In that

        case, the argument must be a TUPLE [HASH_TABLE, FUNCTION] instead of

        a container alone.

        Note that hash tables can be used as arguments to List formats.

        The Complex expression is preferred for outputing hash table contents

        when the desire is to include the per-item key.

      L denotes a List-like expression (any FINITE container)

        Type specifier can be preceded by a delimiter character with which

        to separate list items (default is blank).

        Alignment characters cannot be used as delimiters.

        In place of a delimiter, the agent flag ('~') can be used.  In that

        case, the argument must be a TUPLE [CONTAINER, FUNCTION] instead of

        a container alone.

        Because newline characters (‘%N’) in Eiffel include escape characters,

        it is not possible to use the newline character as a delimiter (“%%NL”).

        Eiffel interprets that sequence as an escaped percent sign, followed

        by “NL”.

        There is, however, a way to accomplish the same thing.  By specifying

        the format as “%#L”, the '#' character is interpreted as requesting

        newline-separated items (the default decoration for LIST-like formats).

        It is also possible to specify a delimiter character to precede each

        newline by including the delimiter character between the ‘#’ character

        and the ‘L’ character in the format string (e.g. “%%#,L).

        Example:

          printf (“%%#,L”, << << 1, 2, 3 >> >>)

          yields:

1,

2,

3

        Specifying the delimiter between the percent character and the ‘L”,

        without the ‘#’ character, will insert the delimiter character between

        elements of the container in the output, and will not insert newlines.

        Example:

          printf (“%%,L”, << << 1, 2, 3 >> >>)

          yields:

1,2,3

      M denotes a Matrix expression (an ARRAY2)

        Type specifier can be preceded by a delimiter character with which to

        separate items (default is blank).  Using ‘,’ as a separator produces

        a CSV format.

        Alignment characters cannot be used as delimiters.

        The ‘+’ alignment character, when used, creates column-at-a-time output

        (default is row-at-a-time).

        In place of a delimiter, the agent flag ('~') can be used.  In that

        case, the argument must be a TUPLE [ARRAY2, FUNCTION] instead of

        a container alone.

        In row-major format, newlines separate rows.  In column-major format,

        newlines separate columns.

        Example:

          my_matrix contents:

            11 12 13 -- Row 1, columns 1-3

            21 22 23 -- Row 2, columns 1-3

          printf (“%%,M”, << my_matrix >>)

          yields:

11,12,13

21,22,23

      o denotes an Octal INTEGER expression

      P denotes an Percent expression (float value multiplied by 100 and

        followed by a percent symbol)

      s denotes character STRING

      u denotes a NATURAL (unsigned Decimal integer) expression

      x denotes a Hexadecimal INTEGER expression

In use, a class calls one of the AEL Printf routines with at least a format

string and an argument list.

The argument list can be an object of any type, but for expected behavior,

there are a few restrictions.

  o When the format string has no format specifiers, then the argument list can

    be an empty manifest ARRAY, and empty TUPLE, or an explicit Void.

    Example:  printf (“This has no format specifiers”, Void)

    Example:  printf (“This has no format specifiers”, << >>)

    Example:  printf (“This has no format specifiers”, [])

  o When the format string contains a single format specifier, then the

    argument list can be either a container with a single item of a type

    conforming to the single format specifier, or an object of a type

    conforming to the single format specifier.

    Example:  printf (“This has %%d format specifier”, 1)

    Example:  printf (“This has %%d format specifier”, << 1 >>)

  o When the format string contains multiple format specifiers, then the

    argument list must be either a TUPLE or a proper descendent of FINITE [ANY],

    in which each item, related by position to its corresponding format

    specifier, has a type conforming to its corresponding format specifier.

    Example:

      printf (“This has %%s (%%d) format specifiers”, << ”multiple”, 2 >>)

---

From: eiffel...@googlegroups.com <eiffel...@googlegroups.com> on behalf of Ulrich Windl <u202...@gmail.com>
Sent: Sunday, June 16, 2024 12:45 AM
To: eiffel...@googlegroups.com <eiffel...@googlegroups.com>
Subject: Re: [eiffel-users] Eiffel 24.11 Suggestions

 

To view this discussion on the web visit https://groups.google.com/d/msgid/eiffel-users/65894e83-db82-40f9-a10b-3434b822a0de%40gmail.com.

[Rosivaldo Fernandes Alves]

Indeed, semicolons are optional in that context.

Rosivaldo F Alves

Em 15/06/2024 08:26, Brother Bill escreveu:
> Bertrand, regarding Cancer of the Semicolon.
> There is one required location of semicolons in Eiffel.
> This is as the formal arguments separators as in
> do_something (arg1: CLASS1; arg2: CLASS2)
>

> (...)

[Brother Bill]

Rosivaldo, semicolons may be optional between formal arguments, but they look odd without them.