liberty-eiffel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Infix "*" in ABSTRACT_STRING


From: Patrick Cloarec
Subject: Re: Infix "*" in ABSTRACT_STRING
Date: Tue, 2 Jan 2024 09:23:21 +0100
User-agent: Mozilla Thunderbird

Hi Laurie

My first concern is practical : what is the precedence of an infix  ? "#+" has the same precedence as "#*", but a higher precedence than "+" and "*", whereas "*" has a higher precedence than "+" (cf ETL L.4 or ECMA 8.28.5). That is error-prone and very limitative.

My second concern is that the definition and syntax of binary operator are always constrained by the left term of the expression.

Thus said, infix syntax is of nearly no importance.

In any class where some additive (or even any) operator is defined, it is possible to define a repetition of that additive operator. I don't know the best class to define this one.

In doubt, I prefer to define it in a specific class, and, in a second time, define it in a parent class if it needs to be reconsidered. That is the modelling principle I generally apply.

Patrick


Le 31/12/2023 à 21:33, Laurie Moye a écrit :
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)




reply via email to

[Prev in Thread] Current Thread [Next in Thread]