Re: Infix "*" in ABSTRACT_STRING

[Laurie Moye]

Hi,

I feel I should get involved in this discussion about repeated strings 
because I sense that it is getting a bit ideological.

My criteria for a good language are:
that is should enable one to get the job done efficiently,
that the code should be easy to understand, and
it should not lead one into pitfalls.

In other words, it should be efficient and safe.

By my criteria, Patrick's dislikes of "STRING*INTEGER => STRING", and 
"'*' is already commutative" (in other classes) are more stylistic than 
practical.

A long time ago (Small Eiffel-0.75) I wrote VECTOR and MATRIX classes 
which naturally had things like:
MATRIX #* VECTOR => VECTOR , and
VECTOR #. VECTOR => NUMBER. (scalar product)
(the rules of free operators require them to start with one of @ # | &, 
so my MATRIX and VECTOR ones all started with # to avoid confusion) 
Creating these infix operators seemed a perfectly natural thing to do 
because that's what the maths does.

So I would say that if STRING*INTEGER => STRING is useful, why not use it.

I have just found a load of lines like:
            put_string("%B %B%B %B%B %B%B %B%B %B%B %B%B %B")
in some code I wrote in 1997 which backspaced over comfort messages 
before rewriting them.  I would have found  "%B "*n_bspace  a very 
useful feature.


I would agree with Paolo that "integer/natural types and "collections" 
share at least conceptually a "mathematical structure" that offers 
repetition".

Patrick "dislike[s] the fact that an infix has to be a feature of the 
class of the left object", but he also write that, "infix is just a 
syntactic shortcut for a feature with one parameter". Yes, that is 
exactly what it is. ETL says (of infix operators), "A simple one is @, 
used in infix form as a synonym for array access: a @ i is the i-th item 
of a".  So what's to dislike?

Please let us not worry about what we like and don't like; let's worry 
about what enables us to write good, safe code easily.

And (sorry, I can't resist this moan) please don't ever change the 
syntax solely for stylistic reasons. On too many occasions I (and 
presumably many others) have had to spend hours editing tens of 
thousands of lines of code because of changes to, for example, the rules 
limiting identifiers, making no differenced to the functionality of the 
code.

Wishing all GNU Eiffel users a happy and productive 2024,
                    Laurie (he/him)