3 small questions

[Alexey Kanatov]

Hi all, just wonder 

1. why () are prohibted in ISE Eiffel 

make () do 

   foo ()

end

is no longer a valid syntax ? 

2. What is wrong with a: expanded A - why is it treated as obsolete?

3. Expanded conformance

   class A end

   class B inherit A end

    ....

    a: expanded A

    b: expanded B

    ...

     a:= b -- validity rule violation - why? What is wrong with polymorphism for expanded obejcts?

Tnx, Alexey

P.S. I did not use Eiffel for years and not aware of latest changes ... so, just wonder ...

[Bertrand Meyer]

On the first point, empty parentheses, the general idea regarding syntax is: (A)  encourage a clear and simple style, and (B) don’t bother programmers with pesky syntax issues.

 

Compare with optionality of semicolons: (A) the recommend style is to omit semicolons between lines (instructions, declarations) because they bring absolutely nothing and instead obscure reading, and include a semicolon between instructions/declarations on the same line for similarly obvious reasons of readability; (B) ignore extra semicolons, and don’t require semicolons, because this is a small matter and it does not cause any semantic risk (wrong program behavior). (In rare cases the semicolon has to be included to remove potential ambiguity.)

 

With empty parentheses: (A) They obscure the text and bring no semantic value. (B) Who in the world would write empty parentheses?

 

The answer to the last question is: only someone who has done too much C, C++, Java etc. and is keeping the only style he knows. We are sympathetic of course (that’s one of the reasons we benignly look the other way when they add unnecessary semicolons all over the place.) But then (A) comes back because if such a person is encouraged to continue in that style he will naturally write things like an_account.balance () and then, the day balance changes from a function to an attribute, he will be stuck. In other words he loses the advantage of Eiffel’s Uniform Access principle. Small short-time syntactic convenience (preserve a classical if sloppy idiom) traded for big long-term semantic problem.

 

-- BM

--
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.
Visit this group at https://groups.google.com/group/eiffel-users.
For more options, visit https://groups.google.com/d/optout.

[Ian Joyner]

() is a syntactic horror of C. I suspect that it was in there originally for an empty parameter list because they could not make their parser work otherwise – they needed something to be nothing, which is contradictory. I don't think () has ever been valid syntax in Eiffel. Don’t assume that the stupidities are arcaneness of C syntax has to be in other languages.

C people would hate the CALL operator of COBOL and FORTRAN. () IS the call operator. All that is needed in ‘modern’ language is to say this name is associated with a variable (memory cell), or a routine. The compiler knows that if a name is associate with a routine, all you can do is call it, so a call operator is superfluous. Bertrand has already talked about the principle of uniform access. A variable used on the right-side of an expression (r-value from Christoper Strachey, but l-value and r-value exposes implementation) is just a function – a function that returns a value from a memory cell. (This difference between mathematics and computing was something that Strachey invented the notions of l-value and r-value – C exposes this in a rather ugly way. The problem of computing varlables – vs mathematics variables - is still a problem).

Although not a question you posed, but related to this is why other languages care to distinguish assignment ‘:=' from ‘=‘. Again it is to preserve the difference between mathematics and computing – something which C again confuses and is the source of many bugs.

The other thing is that in C a function name without () refers to a reference to the function. This is the rarer use to assign a function reference into a dispatch table.

In Eiffel it is treated differently, as it should in an OO/functional language.

Ian

[Alexey Kanatov]

Bertrand,

I am trying to look at the case of () as the one who used to program in the world where () are mandatory for function calls and they are unlikely to get the subtle difference between optionality of ; (semicolon) and ().  So, the syntax rule for () is more stricter than for ; - it implies that programmers are forced to do things they were so used to in a different manner and they are unlikely to see much value initially that one can redefine a function with no arguments into constant or variable attribute (though it is a very elegant solution which I used a lot). So, for me it is mostly phycological aspect rather than technical .... Compiler may give just style recommendation but not the syntax error message ...

 

Moreover, all the viewers (short form, flat form, source code restored from internal representation) will follow the Eiffel style guidelines ignoring the mess one may have in his/her source code

 

So, probably I should have asked if it makes sense to make treatment of () a bit more relaxed …

Kind regards, Alexey

[Alexey Kanatov]

Ian, really I do not want to debate ;-) Probably it was my mistake when I did Eiffel scanner/parser for Visual Eiffel in 1993 - () was optional ;-) and I guess I used syntax ruels from ETL2. 

[Colin Adams]

It does not seem reasonable to change Eiffel because you come from a particular programming tradition.

Other traditions (e.g. Haskell, Idris) do not use parentheses at all. So by your argument we would have to eliminate parentheses all-together for function calls if a Haskell programmer wished to switch to Eiffel.

[Ian Joyner]

Hi Alexey,

I’m really not debating, just pointing out the facts about (). It seems a whole generation of programmers have been brought up on ’this is THE way to invoke a function’. As many of us know, even small syntactic items have profound – but maybe – obscure and difficult to explain effects on semantics and thus the thinking of programmers.

It is the underlying and fundamental criticism of C that it exposes implementation that should not be exposed and thus breaks abstractions. These issues are subtle, but frequently not understood by many imperative programmers who think programming is about instructing a computer rather than describing a problem in the mathematical and functional programming sense.

If you think I am wrong, then you are certainly entitled to enlighten me. I’m always interested in improving my reasoning and being able to explain it to others in clearer ways (the purpose of the text of a program). That is the nature of discussions in the Eiffel world (although not perfect!).

Ian

[Alexey Kanatov]

:-) I like Eiffel and of cousre I agree that () have no usefull semantics in the Eiffel context, but when we send a message to a programmer that they may optionally use semicolons (in some cases they help to improve readability), but never use () as compiler treats them as syntax error - well ... I'd better see style warining rather that syntax error .... But once again that is so minor thing ...

On debating - may be in 1993 () were optionaly in the syntax, but really it does not matter  in 2019 :-)

[Ian Joyner]

Actually, I’m not sure what you mean by debating – we don’t seem to be having any argument, at most looking at things from a slightly different perspective.

While () in the syntax might seem a small thing, it is semantically much more significant. It really is making the programmer think (although implicitly and many don’t notice it) about the how, not the what.

A name is attached to an entity (variable or routine, etc). The compiler knows what that is (once declared) and does not need help from the programmer – in fact, if it is still the case, IIRC, you can changed the implementation of a function in a parent class to a variable in a subclass due to principle of uniform access.

Optional semicolons are a different case – they allow multiple very closely related instructions to be put on a single line. This should normally not be done, but for rare cases you can.

[Larry Rix]

RE: () ... I don't miss this at all. Like C/C++/Java/etc, the Visual FoxPro language insisted on empty parentheses as well. I will also come down on the sensible side of the Uniform Access Principle as well. As an engineer, I ought not be forced to locate every stray instance of () just because I want to change a query to an attribute.

RE: Semicolons ... I actually do use semicolons from time to time to place lines of code on the same line. Such as:

a.do_something;  a.do_something_else;  a.do_another thing
b.do_something;  b.do_something_else;  b.do_another thing

The long the list of things to do, where only the target is changing, the more apt I am to do the above. Now—understand that I also have another choice! I can factor this out to a routine where `a' and `b' are sent in as an argument. That ends up being the better solution, so even my periodic use of semicolons (as above) is unnecessary.

There is one time when a semicolon is required and it happens because of a particular nuance in the Eiffel compiler. If one adds a note clause to the end of a class and the last feature of the class is an attribute, the compiler generates a syntax error. The way to eliminate this error is to put a semicolon between the end of the attribute and the start of the note clause.

So—to conclude—the end of the matter is: If you're used to empty parentheses and semicolons and you want to write code in Eiffel, just let your old C/C++ muscle memory slip away quietly. It'll be good therapy for you! :-)

[Gachoud Philippe]

I could tell of my experience of working with eiffel and typescript now everyday, I'm so much used to use no () that when I forget some of a function and not attribute in typescript (same as javascript) nothing is said by the compiler and the function is simply not working! so yes, the only answer I'd give is that it would have sense to unify bad practices on other languages with eiffel. But thats really not a reason enough to change eiffel to C like syntaxes.

--

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.
Visit this group at https://groups.google.com/group/eiffel-users.
For more options, visit https://groups.google.com/d/optout.

--

**********************************************

Philippe Gachoud

Nuestra señora del Rosario 629

Las Condes

Santiago de Chile

0056 2 27 27 21 29
ph.ga...@gmail.com
**********************************************

[Larry Rix]

BTW—multiple lines on the same line separated by semicolons is a "code smell". I generally do not want to leave code like this, but do it initially to not write the routine, but I then return to it later and create the routine with appropriate contacts.

I will say this as well—once one brings aboard the notion of contacts, the reasons for doing what I have illustrated above utterly melt. Code is safer and less buggy when it is embraced by contacts protecting it. I could so a similar thing with the check contract, but I would end up copy-pasting code. Bertrand once made a statement that I have hung on to for many years: "If you are copying-and-pasting code, you're already wrong!" It was true 25 years ago and it is true today!

[Bertrand Meyer]

Dear Philippe,

 

> multiple lines on the same line separated by semicolons is a "code smell".

 

Here our tastes differ. I prefer this

 

            if x > y then                            -- Swap

                        t := x ; x := y ; y := t

                end

 

to the version using two more lines. Clarity does not mean length. For straightforward elements concision is good. Lengthiness should be reserved for more elaborate stuff. At least that’s my approach.

 

I am influenced in part by my experience of writing programs for publications, where the number of lines matter. In that case using a whole line for every short instruction implies removing a line of text somewhere and is not worth it.

 

But even in  a program meant just for compilation and execution rather than publication I don’t see anything wrong in packing a couple of short instructions into a line. Again a matter of taste, but I would not legislate in this area.

 

Thanks for the comments,

 

-- BM

 

 

From: eiffel...@googlegroups.com [mailto:eiffel...@googlegroups.com] On Behalf Of Larry Rix

Sent: Friday, February 8, 2019 17:15
To: Eiffel Users <eiffel...@googlegroups.com>

--

[Woland's Cat]

related: prior to

    across thing_list as thing_csr loop | some | all ...

I was doing

   

    from thing_list.start until thing_list.off loop

on a single line for many years now. Much clearer. No semi-colons though...

On making programming expressions more like maths, I completely agree. I would love to be able to routinely use the ∀, ∃ and ∈ symbols as well as the symbols for the basic logic operators. What a pity these are not standardly available on the keyboard.

- thomas

[Alexander Kogtenkov]

The ability to enter Unicode without switching from the usual keyboard input is on our radar. However, adding Unicode Boolean and set operators for kernel classes might become problematic because multiple aliases are not allowed. For example, one cannot change the class BOOLEAN to have:

    implication alias "implies" alias "⇒" ...

Alexander Kogtenkov

Woland's Cat <wolan...@gmail.com>:

[Woland's Cat]

A proper meta-model for that would be to consider that 'implies' etc is not just a name alias for 'implication' but instead as the name for an 'operator' which can be used in syntax instead of the function call form. Then, if an operator is an entity, it can have a name, and a symbolic alias. In this way you get all three and it makes sense. Going further, you would probably allow synonyms both for text and symbol aliases.

- thomas

--

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.
Visit this group at https://groups.google.com/group/eiffel-users.
For more options, visit https://groups.google.com/d/optout.

--
Thomas Beale
Principal, Ars Semantica
Consultant, ABD Project, Intermountain Healthcare
Management Board, Specifications Program Lead, openEHR Foundation
Chartered IT Professional Fellow, BCS, British Computer Society
Health IT blog | Culture blog | The Objective Stance

[Bertrand Meyer]

Indeed. But if we wanted to lift that restriction I think we could. Does not seem like a big deal to implement. The question is whether it’s worth it or we fear it would lead to a baroque explosion of multiple names for the same thing. As to me in the absence of clear counter-arguments I would go for it. Give programmers that flexibility.

 

It goes well with Unicode.

 

-- BM

--

[r...@amalasoft.com]

Perhaps, as these math-like expressions seem very much like extensions, they should look like extensions - and be obvious about it.  That way, the object- (class-)oriented model is not corrupted and the language doesn't become like C++  with a slide rule.

It has, from where I'm sitting, always been a kind of rule (and Bertrand might have said this explicitly), that the language is meant to be extended by classes, and not by artificial sweeteners.

Just as Eiffel does a very good job of working with C as an external, perhaps a variant of 'external' could be the answer.  Perhaps a "formula translation", oops, sorry I guess that's been done.  Maybe something along the lines of the existing external mechanism for formulas, one that permits the use of different operators than the core Eiffel language/code, calling out a separate parser/evaluator.  The approach could work for integrating all manner of different means of expression (sorry for the pun), without screwing up a good thing.

R

[Larry Rix]

This is quite sensible! It's obvious by this example, I have not encountered all of the good, bad, and ugly of use cases where semicolon use is or is not sensible and improves readability. I find the code below to be concise.

[Eric Bezault]

What about:

implication alias "implies", implication_unicode alias "⇒" ...

with synonyms? Ugly, but that would with the current Eiffel standard.

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