Returning to Eiffel

[Richard]

As life has it I drifted away from Eiffel as an interest, but lately  i am looking to catch up with the evolution of the language.

My last understanding of the syntax equals the 2006 ECMA-367 standard definition.

Question: where can I find documentation on syntax changes since then?

Thanks for any and all pointers.

ps. at first glance much of the docu provided at https://dev.eiffel.com/Main_Page seems fairly dated and isn't very helpful.

[Germán Arias]

Hi, maybe this can help you:

http://eiffel-guide.com/

https://www.eiffel.org/doc/eiffel/Language_reference

Germán

--
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.
To view this discussion on the web visit https://groups.google.com/d/msgid/eiffel-users/d3c47f17-b694-486a-8542-240c91f692ce%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Gachoud Philippe]

I can say having lived a similar experience as yours returning to Eiffel after almost 15 years 9 months ago, I bought the old books, and it wasn't easy for me to get the updates. A page on eiffel website with short tips like

- !! deprecated

- default_create

etc.

would have been greatly apreciated for me as a reference of changes, even if I imagine its quite difficult to have something concise on changes since...

Don't know exactly the how, but share your experience

Cheers

--

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.
To view this discussion on the web visit https://groups.google.com/d/msgid/eiffel-users/d3c47f17-b694-486a-8542-240c91f692ce%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

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

Philippe Gachoud

Puerto Williams 6657

Las Condes

Santiago de Chile

+56 934022210
ph.ga...@gmail.com
**********************************************

[Hank Lenzi]

I can say having lived a similar experience as yours returning to Eiffel after almost 15 years 9 months ago, I bought the old books, and it wasn't easy for me to get the updates. 

Same problems here with the old books. What I do is that go methodically through the book and then check the new Eiffel class spec. I also do version control and then upgrade the code step by step, documenting it (say, there was a formula for calculating "Pi" with arc tangent,  but now MATH_CONST does it for you - change the types - and the compiler - oh, wow, what a great tool! - and you're done. Stuff like that...I have a few on my git repository, but the book's copyright doesn't seem to allow me to make the repository public. I'm thinking of asking one of the authors. This would help greatly, I think.

Also, I see that the Smalltalk community made a move to ask the authors of old books to have them released on the web. The books are old and no-one wants to buy them anymore (except us few). This would be a healthy undertaking for the Eiffel community. 

Cheers, 

-- Hank 

[Richard]

Thanks for the first pointers.

Just in case anyone picks up this thread in search of answers, here two links:

Differences between ETL 2nd printing and Eiffel Software implementation

and

Differences between standard ECMA-367 and Eiffel Software implementation

[Hank Lenzi]

Em sexta-feira, 12 de julho de 2019 20:29:47 UTC-3, Richard escreveu:

Thanks for the first pointers.

Just in case anyone picks up this thread in search of answers, here two links:

Thanks! Let's get this thing rolling (again).

-- Hank 

PS: Lots of good info out there. Why are we not blogging / posting / advocating ?

[Richard]

H/T to Philippe Gachoud for asking and discussing this my problem last October, Google was my friend in finding the references.

I am just working a small vintage 2002 educational Eiffel project into the current Eiffel Studio and compiler environment. The ancient .ews /.ewd project descriptions did not make the evolution :( I had to coerce EStudio to make a new project and pick up the existing files with a bit of tweaking.

The compiler balked at this construct:

the_option : INTEGER

  register_property, register_customer, record_visit, reset_customer, reset_property,

    list_properties, list_customers, help, quit, invalid : INTEGER is unique

Philippe asked in the commenting section of https://www.eiffel.org/doc/eiffel/Eiffel_programming_language_reserved_words and pointed to a short thread on StackOverflow https://stackoverflow.com/questions/52707519/eiffel-red-green-blue-foo-bar-integer-is-unique/52708248#52708248 for a discussion.

Summary: unique did not make its way into the ECMA standard.

Workaround discussed in above Stack Overflow thread. 

[Richard]

Question re EStudio especially in the Windows implementation:

Is there an option to only keep the project name in the window title rather then switching thru class names etc. ?

I find the continuous flickering of the window title very annoying and it doesn't convey any information to me. I know where the files are stored.

[Richard]

Question Estudio editor:

Is there a way to tie a class to an editor tab so that other classes don't reuse the tab when clicked on in the Groups tool?

Is there a way to have a new class open in a fresh tab when clicking rather than requiring shift-right-click?

With tab reuse by several classes I have the forward/backword moving icons, are there any keybindings available on these icons?  (I have still to study the redefinition of all of the keybindings)

[Richard]

Question Estudio editor - part 2

When I right-click on a class etc in the Groups pane I activate the drag-and-drop feature.

Enhancement: I would like to drop the object into the tab area with the effect that a new tab opens with the chosen object

[Gachoud Philippe]

Doesn't it do the trick dropping your object into the tab bar not on an existing tab? I'm refering to after last tab

--
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/5ac0cd02-0d65-45fa-84fa-9dc5e35a2c3f%40googlegroups.com.

[Richard]

Did you work remote magick on my machine? Suddenly things work as intuitively expected.

Trying to find out what I had done wrong a day long, I think I dragged the class icon after keeping the right mouse button clicked and expecting it to drop in place after releasing the button, Windows experience like. And clicking the left mouse button of course deselected my choice. I still have to get the hang on the automatism of right-click (and release button), move to destination and right-click once more.

On Wednesday, July 24, 2019 at 2:10:59 PM UTC+2, Gachoud Philippe wrote:

On Wed, Jul 24, 2019 at 8:06 AM Richard <eiffel-...@rth10260.info> wrote:

Question Estudio editor - part 2

When I right-click on a class etc in the Groups pane I activate the drag-and-drop feature.

Enhancement: I would like to drop the object into the tab area with the effect that a new tab opens with the chosen object

Doesn't it do the trick dropping your object into the tab bar not on an existing tab? I'm refering to after last tab

--
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...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/eiffel-users/5ac0cd02-0d65-45fa-84fa-9dc5e35a2c3f%40googlegroups.com.

--

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

Philippe Gachoud

Puerto Williams 6657

Las Condes

Santiago de Chile

+56 934022210
ph.g...@gmail.com
**********************************************

[Richard]

Question Estudio / Preferences.

I am looking at some entry and see a Status field as Default or User Set. At times I cannot remember when I ought to have changes that setting and would like to revert to the default.

How can I revert a single entry when I dont know the original value (not all have a simple checkbox to flip)?

[Richard]

More on Preferences in Estudio:

It's a pity that not all options have a description of their functionality but display No description available for this preference. Also the description box does not do text wrp around but displays a signle line only requiring horizontally scrolling within the description field. And as I am complaining: the Description box seem too small to wholly display a longer text over several lines.

[Richard]

More on Preferences in Estudio:

After a negative expierience I am unhappy to note that when assigning a keyboard shortcut in Preferences I don't get any notice that I am, likely accidentially, reassigning a shorcut. Estudio just leaves the prior setting empty. While I have not sufficient expiereince in using Estudio with shortcuts I have the feeling that reusing a shortcut in a different context ought to be possible. Let the user sort out the confusion they may create.

And: is there a existing function to print out a chart of assigned shortcuts as reference next to the computer? Else I will use this as an exercise to use a save of the preferences file.

[Richard]

Question Estudio :  When creating a new class the following lines get placed into the header section

note

date: "$Date$"

revision: "$Revision$"

Is the tool to replace date and revision something I have not yet found in Estudio or external tools, or are simple *ix tools and scripts used prior to the last finalizing compilation?

[Peter Gummer]

Some version control systems will replace those strings automatically when you commit the file.

- Peter Gummer

[Richard]

from the prior discussion of the removed unique I find this code snippet by Alexander Kogtenkov

feature -- Enumeration

    red: QUX

        once

            Result.make (1)

        ensure

            instance_free: class

        end

Please help me understand this assertion clause:  class seems to be a boolean here in my reading of ECMA at 8.9.1.  Where is this feature defined (I didn't find it ANY)?. What would turn this value to False as to trigger an eror?

[Bertrand Meyer]

This is a recent addition. See https://dev.eiffel.com/EiffelStudio_18.01_Releases.

 

It was described in this group: https://groups.google.com/forum/#!topic/eiffel-users/Y1FXpFBfInA

 

To allow for such a postcondition, the feature must not use the object state, i.e. it must not access any attributes, and any feature it calls must recursively satisfy the same condition. Then clients can use the feature without a qualifying object, e.g. {COLORS}.red.

 

And yes, there will be a collated language description including all recent extensions.

 

-- 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.
To view this discussion on the web visit https://groups.google.com/d/msgid/eiffel-users/14854363-8ecd-460f-90c9-9e0a779fb5ac%40googlegroups.com.

[Richard]

For Discusssion

Following my introduction to the new semantics of ONCE class constant and from the prior discussion of the removed unique with the code snippet by Alexander Kogtenkov as suggested replacement  I would like to see the inspect construct expanded as follows:

-- -- experimential suggestion

somecolor : {QUX}
...
somecolor := {QUX}.red   -- sample
...

inspect somecolor

when {QUX4}.green then -- do something for green

when {QUX4}.red then -- do something for red

else

-- perhaps unassigned

end

[Richard]

For the record and free to steal the suggestion.

Based on the prior discussion of the removed unique and with the code snippet supplied by Alexander Kogtenkov as suggested replacement I tinkered and came up with following minimalistic approach.

note

description: "Minimalistic enumeration class derived  %

% from class QUX by Alexander Kogtenkov"

author: "rws"

date: "29.07.2019"

revision: "0.1"

expanded class QUX4

feature -- Enumeration

-- use condensed coding style (hint: clickable view expands nicely)

-- invokes default_create

-- just ordered aplphabetic by chance

  colorless: QUX4 once ensure instance_free: class end

  black: QUX4 once ensure instance_free: class end

blue: QUX4 once ensure instance_free: class end

  green: QUX4 once ensure instance_free: class end

red: QUX4 once ensure instance_free: class end

yellow: QUX4 once ensure instance_free: class end

white: QUX4 once ensure instance_free: class end

end

use like in 

somecolor : {QUX}
...
somecolor := {QUX}.red   -- sample
...

if     somecolor = {QUX}.red    then print ("somecolor matches as red%N")

elseif somecolor = {QUX}.green  then print ("somecolor matched as green%N")

else                                 print ("somecolor didn't match one or two %N")

end

Note: as I have dropped the original item for tracking the color and only rely on object comparison I have no possibility to detect a created instance that has not been assigned a color of the class. In the version of A.K. the unassinged default object would identify by {QUX}.item = 0.

[Richard]

Me Culpa! I should not be posting late night to a mailing list, cannot silently fix like on a forum ;)

i

Of course my "minimalistic" version has gone too minimalistic by dropping the item that implies the difference of the objects. Different names for the same stuff makes no different objects ;(

[Richard]

Eiffel dot Org - the Community information portal

While several sections have a comment function this is not the case for erverything.

Question: how do I contact the web host for pointing out discrepancies?

Like in the Resources division, the Libraries page at https://www.eiffel.org/resources/libraries where on the followup pages of library entities the forwarding links, eg to documentation, mostly end up pointing to the main page Eiffel.com and not to the promised content.  

[Jocelyn Fiat]

Hi,

Thanks for all the valuable feedback. We'll try to address each of them, especially for the preferences and shortcuts.

About eiffel.org, you can contact the Eiffel.org webmaster team using https://www.eiffel.org/contact

-- Jocelyn

--

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/14439016-4f70-41ac-9160-fb4d0d9a490e%40googlegroups.com.

--

Jocelyn
------------------------------------------------------------------------
Eiffel Software
https://www.eiffel.com
Customer support: https://support.eiffel.com
User group: https://groups.google.com/forum/#!forum/eiffel-users
------------------------------------------------------------------------

[Richard]

Some words of wisdom, please

From a VisualEiffel example the main class below with a snippet of interest highlighted in blue. I attempt to replace it by the snippet highlighted in brown.

The compiler is cautious on void saftey and marks my code with VUTA(2) (see below).

My question: 

What is the fine difference between first creating a local object and assigning it to the class variable as compared to CREATE the class variable directly?  Why does the compiler analyze this as a differece, or, why can't the compiler deduct that after creation the class variable is not void.

Thanks - RIchard

note 

        description : "Root class for this application."

  legal: "See notice at end of class."
status: "See notice at end of class."

author : "Generated by the New Vision2 Application Wizard."

date : "$Date: 2010-11-02 11:05:49 +0000 (Tue, 02 Nov 2010) $"

revision : "1.0.0"

class

APPLICATION

inherit

EV_APPLICATION

create

make_and_launch

feature {NONE} -- Initialization

make_and_launch

-- Initialize and launch application

do

default_create

prepare

launch

end

prepare

-- Prepare the first window to be displayed.

-- Perform one call to first window in order to

-- avoid to violate the invariant of class EV_APPLICATION.

local

w: like first_window

do

-- ==================== originally generated ====================================

-- -- create and initialize the first window.

-- create w

-- first_window := w

--

-- -- Show the first window.

-- --| TODO: Remove this line if you don't want the first

-- --|       window to be shown at the start of the program.

-- w.show

-- ==============================================================================

-- #################### what i tried to to   ####################################

-- create and initialize the first window.

create first_window

-- Show the first window.

--| TODO: Remove this line if you don't want the first

--|       window to be shown at the start of the program.

first_window.show 

-- ##############################################################################

end

feature {NONE} -- Implementation

first_window: detachable MAIN_WINDOW;

-- Main window.

note

copyright: "Copyright (c) 1984-2006, Eiffel Software and others"

license: "Eiffel Forum License v2 (see http://www.eiffel.com/licensing/forum.txt)"

source: "[

 Eiffel Software

 356 Storke Road, Goleta, CA 93117 USA

 Telephone 805-685-1006, Fax 805-685-6869

 Website http://www.eiffel.com

 Customer support http://support.eiffel.com

]"

end -- class APPLICATION

source code above

error message

Error code: VUTA(2)

Error: target of the Object_call might be void.

What to do: ensure target of the call is attached.

Class: APPLICATION

Feature: prepare

Type: detachable MAIN_WINDOW

Line: 52

          --|       window to be shown at the start of the program.

->      first_window.show

  -- ##############################################################################

[Colin Adams]

Probably first_window is an attribute of the class. Then there is the possibility of multi-threading to take into account (first_window might become detached on another thread).

--

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/c3786980-e6d1-499b-9cde-408bf7b34393%40googlegroups.com.

[Larry Rix]

Is this not why we have SCOOP?

To unsubscribe from this group and stop receiving emails from it, send an email to eiffel...@googlegroups.com.

[Richard]

I guess I have found the relevant discussion to my question at Void-safety: Background, definition, and tools on Eiffel.org.

[Richard]

I created a small window layout in EiffelBuild and generate / compile it.

The presentation looks vey different in the run time version than in the develpment presentation.

EIffelBuild shows:

Runtime started out of EiffelStudio (native Windows, not dot-net)

Question 1: do I need to set some extra options to get rid of the unwanted 3D style and back to a plain flat visual?

Question 2: why does the runtime version show some extra white space between the text box and the up/down buttons?

Question 3: it's my impression that the fonts used as displayed in the run time version are lacking some crispyness, like blurred after passing thru a bitmap / pixelmap of lesser resolution than my screen offers.

Thanks for any insight.

[Larry Rix]

You need the Windows manifest file in the same folder as the EXE. Stupid, I know, but there it is.

[Richard]

Thanks for a first hint.

 

Windows didn't seem to pick up the manifest, although tailored according to https://docs.microsoft.com/en-us/windows/win32/controls/cookbook-overview , and dropped side-by-side to the exe, both in workbench mode and in a finalized version. 

Still looking for an answer.

 

 

[Larry Rix]

<?xml version="1.0" encoding="UTF-8" standalone="yes"?> 

<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0"> 

<assemblyIdentity version="1.0.0.0" processorArchitecture="*" name="YOUR_PRODUCT_NAME" type="win32" /> 

<description>YOUR_EXE_NAME</description>

<dependency> 

<dependentAssembly> 

<assemblyIdentity type="win32" name="Microsoft.Windows.Common-Controls" version="6.0.0.0" processorArchitecture="*" publicKeyToken="6595b64144ccf1df" language="*" /> </dependentAssembly>

</dependency>

</assembly>

[Bernd Schoeller]

Hello ECMA people ;-)

Just a short question concerning this:

Had it been discussed to use 'Current = Void' instead of 'class' ? Why was this dismissed?

Regards,
Bernd

To view this discussion on the web visit https://groups.google.com/d/msgid/eiffel-users/402901d545cc%24ebfdee70%24c3f9cb50%24%40inf.ethz.ch.

[Richard]

That's what I had setup too, though with a snafu: the program name is case sensitive in the XML file so at first StepThree did not match stepthree.exe.

But still don't see the other presentation I hope to get. I wonder if there is a hidden switch in the WEL package that does not get properly set when using plain vanilla VISION2. There aer also VISION2 examples that pick up the less good looking display.

[Eric Bezault]

On 18/08/2019 0:43, Bernd Schoeller wrote:
> Hello ECMA people ;-)
>
> Just a short question concerning this:
>
> Had it been discussed to use 'Current = Void' instead of 'class' ? Why
> was this dismissed?

I don't think this has been discussed.
But it does not work anyway because we also want to be able to call
this kind of features in regular object calls:

c := {COLOR}.red
c := my_color.red

So, to follow your suggestion, it should have been:

Current = Void or Current /= Void

which is equivalent to:

True

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

[Bertrand Meyer]

No.

 

-- BM

To view this discussion on the web visit https://groups.google.com/d/msgid/eiffel-users/4476f1b7-34b8-2447-a1fc-c4c9f2032399%40gmail.com.

[Richard]

Lost in the woods

or In search of a treasure... 

When looking thru some source code of the Eiffel distribution for inspirations I stumbled upon a formerly unknown operator - the tilde symbol. From the context it was obvious that it was about STRINGs. 

My search for its definition was a walk thru the forest of information overflow hitting trees in the darkness. The search engine of Eiffel-dot-org did not give me any help. My hunt led me to Google, a search applied to this domain gives me a single only small pointer:

This blog entry from December 2008 - https://www.eiffel.org/blog/manus_eiffel/eiffelstudio_6_4 lists the tilde operator as a change to the 6.4 release. 

To my dismay I cannot find the tilde operator listed in any source code file of the STRING libraries. 

I find it very concerning that such information is not better accessible to newbies and recovering Eiffelists.

[Colin Adams]

It's not STRING, it's ANY.

Equality by object (not reference)

--

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/a0a13064-d581-41f5-a038-6083c7d9064d%40googlegroups.com.

[Bertrand Meyer]

Search engines are still not very good at handling special symbols.

 

~ is simply the object equality operator. If a and b are two non-void references, then

 

                a = b holds if and only if a and b are references to the same object.

                a ~ b holds if and only if the objects to which they refer are of the same type and equal.

 

The first implies the second. In the second, the definition of when objects are “equal” is given by the `is_equal‘ function, in its version for the common type.

 

Previously object equality would have to be written in one of the two forms

 

                a.is_equal (b)

                equal (a, b)

 

but they raise the risk of a run-time “catcall” (non-matching types, here harmless in principle but potentially causing a run-time interrupt anyway). The idiom using ~ is always safe, hence preferred.

 

And yes, we continue to work on improving the documentation of newer mechanisms.

 

-- BM

 

From: eiffel...@googlegroups.com <eiffel...@googlegroups.com> On Behalf Of Richard
Sent: Wednesday, August 21, 2019 02:26
To: Eiffel Users <eiffel...@googlegroups.com>
Subject: [eiffel-users] Re: Returning to Eiffel

 

Lost in the woods

--

[Richard]

Thank you!

R. 

[Richard]

Hi!

The tilde operator may conceptually be allocated to ANY but there is no code that explains it as  the_better_is_equal alias "~"

Thinking of it, the equal operator "=" is neither. But within computer languages the equal sign seems to be self evident, while its sibling the tilde is a newcomer.

In ANY is_equal is defines as an external "built_in". I guess formally the equal operators "=" and "~" ought to have similar documentation in ANY.

[Gary Smithrud]

It should not be defined as such in ANY, since it can be overridden.  Even if the features are frozen, = and ~ can be renamed and replaced by new infix operators.  Please correct me if I'm wrong...I've thought about how to this...for obvious reasons.

--
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/5294fe34-6124-4a7b-ab31-df2e9006c35d%40googlegroups.com.

[Finnian Reilly]

There is one aspect of Eiffel comparisons for equality that has been troubling me this year. And that is the inconsistency in the following code fragment in relation to applied occurrences of names. To explain what I mean I will first refer to the article on name binding in wikipedia.

Use of an identifier id in a context that establishes a binding for id is called a binding (or defining) occurrence. In all other occurrences (e.g., in expressions, assignments, and subprogram calls), an identifier stands for what it is bound to; such occurrences are called applied occurrences.

Now keeping this principle in mind, look at the following code fragment

   my_routine
      local
         a1, a2, a3: INTEGER_REF
         b1, b2: INTEGER
      do
         if a1 = a2 then
            -- something
         end
         if b1 = b2 then
            -- something
         end
      end

In the latter comparison, the identifiers b1 and b2 do indeed stand for what they are bound to.

But in the first comparison, it seems that a1 and a2 cannot stand for what they are bound to, since they may not be bound to anything. What is really being compared is some real (or abstract) pointer to a memory location. If the reference is not attached then it is the null pointer.

For the sake of consistency, I would argue that reference variables should each be prefixed with an address of operator indicating the memory address of the attached object. If we were to borrow the C operator the first comparison would look like this.

 

if &a1 = &a2 then

If this syntax was adopted then it would no longer be necessary to have a second symbol (~) for object comparison.

Instead the tilde character could be reassigned to represent approximate equality, which could be very useful when comparing floating points numbers.

[Bertrand Meyer]

Dear Finnian,

 

Thanks for raising this issue but… I don’t think so!

 

The cited Wikipedia definition, as it stands (I don’t know what book or article it came from), is not quite sound.  “An identifier stands for what it is bound to” takes for granted that an identifier is bound to something. But that’s not always true, as the definition itself specifies in its first part: if one can use “an identifier id in a context that establishes a binding for id”, a consequence is that an identifier can be not-bound -- for example, before we establish the first-ever binding for it.

 

So a sound definition should say “an identifier, if bound, stands for what it is bound to”. (And preferably say what it stands for if not bound.)

 

The Eiffel approach is simpler and unlike the above definition is, I believe, logically sound. An entity (the kind of identifier relevant here) is always bound at run time to a value. If that value is a reference, it is void or attached (to an object). The semantics of all operations, for example equality a1 = a2, or object equality, is precisely defined by the standard for both of these cases.

 

Note the three levels: the identifier (entity); the value; the object.

 

(For reference types the value is a reference. For expanded types the value is an object so there are only two levels, not three.)

 

It is the goal of a higher-level language, through abstraction, to protect programmers from unnecessary details, as long as the semantics is clear and surprise-free. I don’t think that forcing on programmers the explicit introduction of addresses would help. In fact the need to distinguish between L-values and R-values, even in the vast majority of cases for which no confusion would arise, introduces worse confusion instead and is in my view one of the main deficiencies of C programming.

 

Still, it’s always good to go back to the fundamental questions. Thanks.

 

-- BM

 

From: eiffel...@googlegroups.com [mailto:eiffel...@googlegroups.com] On Behalf Of Finnian Reilly

Sent: Friday, 23 August, 2019 13:09
To: Eiffel Users <eiffel...@googlegroups.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/8538281c-036c-4e63-824f-364a58679ea2%40googlegroups.com.

[Richard]

Peeking behind the curtains of EiffelStudio I find that the icons used are packed into a matrix within a single PNG file.

Question (1): Was an Eiffel tool used to splice the bitmaps into a single png image file?

Question (2): What class(es) is/are used to extract the icons for application use? ( I am still attempting to locate them in the source code on GitHub) 

Quetsion (3) Didi I possibly totally miss them among the regular distribution?

Regards - Richard

[Richard]

Answer to Q1 found on GitHub: *ix scripts, including extracting.

PS. I did like what I got to see:  conversion from old style BMP to crispy looking SVG design.  Thumbs Up!  

[Gachoud Philippe]

Sorry, out of topic...

As I mentioned in this thread, I'd advise to create (also in some cases) some stackoverflow questions for some eiffel topics and questions which could be really useful (to me included) to find. Google seems better to find topics into stackexchange than in its own groups ;-)

On Sunday, June 30, 2019 at 12:53:28 AM UTC-4, Richard wrote:

As life has it I drifted away from Eiffel as an interest, but lately  i am looking to catch up with the evolution of the language.

My last understanding of the syntax equals the 2006 ECMA-367 standard definition.

Question: where can I find documentation on syntax changes since then?

Thanks for any and all pointers.

ps. at first glance much of the docu provided at https://dev.eiffel.com/Main_Page seems fairly dated and isn't very helpful.

[Richard]

Thanks for the invitation! While I have only snooped ove at Stackoverflow a few times I know have signed up. Will be known by my internet pseudonym RTH10260 / Richard.

[Richard]

Lifelong learning  ;)

Please point me to the BNF-E definition that allows white space like I discovered by accident in the naming of an object feature like

-- some syntax coding surprises

print ("Tuple count " + tup.count.out + "%N") -- some info

print ("Tuple count " + tup.count. out + "%N") -- some info

print ("Tuple count " + tup.count .out + "%N") -- some info

print ("Tuple count " + tup.count . out + "%N") -- some info

print ("Tuple count " + tup . count . out + "%N") -- some info

[Carl Langford]

4. Not everything in the ECMA spec is expressed as a bnf, but this seems to address your concern:

   
   

   
   

   
   

   8.32.4  Semantics: Break semantics

   Breaks serve a purely syntactical role, to separate tokens. The effect of a break is independent of its makeup (its precise use of spaces, tabs and newlines). In particular, the separation of a class text into lines has no effect on its semantics.

   Because the above definition of “break” excludes break characters appearing inCharacter_constant, Manifest_string and Comment components, the semantics of these constructs may take such break characters into account.

Carl

[Richard]

Thanks for tracking this down for me!

At first sight it looked fairly exotic to me, but on second thought of a deeply encapsulated inheritence tree it makes sense to be able to brake up, at least for a new line, a long name.

[Richard]

Scanning thru ECMA-367 I see the special smbols (| and |) reserved and new to me.

I find their application used in 8.23.2 Syntax: Feature calls as:

Parenthesized_target =Δ"(|" Expression "|)"

Question: can someone please show or point me to a samlpe of  application of this language construct?

[r...@amalasoft.com]

Hi Richard

I've seen this used in the 'difference' function in CHARACTER_*_REF and maybe a few other places I can't remember at the moment.

R

--
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/be0070ef-1c25-45d2-8770-4de1823ac51c%40googlegroups.com.

[Carl Langford]

I've searched around a bit and I don't see it used anywhere. I wonder if this was someone's clever idea that never went flew. 

It seems to me that a single parenthesis would do the same job. 

I can see that it is helpful to the reader to indicate that the expression inside of {| ...... |} is a target for an object call.

Carl

[Richard]

Curious - 

Eiffel defines a Conditional Expression https://www.eiffel.org/doc/eiffel/Conditional_expression like:

   a_greeting := if time < noon then

      "Good morning"

   elseif time < evening then

      "Good afternoon"

   else

      "Good evening"

   end

Eiffel also defines the multi-branch instruction with inspect (at https://www.eiffel.org/doc/eiffel/ET-_Instructions#Multi-branch).

So far so good. Has there ever been a discussion over a matching Multi-branch Expression ?

Something like this:

a_text := inspect a_number
            when 1 then "one"
            when 2 then "two"
            else        "do not know"
            end

rather than current valid code of

inspect a_number
   when 1 then a_text := "one"

   when 2 then a_text := "two"

   else        a_text := "do not know"

   end

[Ian Joyner]

Interesting. I like it. I once made a proposal for Burroughs ALGOL to do =
case expressions.

--
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/96a2cf9a-7f51-47bf-9c7d-bcc3c68b3629%40googlegroups.com.

[Richard]

I have a small test program with one small class I want to exercise.

Compilation errors out with the message of

 Error code: VEVI

Error: variable is not properly set.
What to do: ensure the variable is properly set by the corresponding
  setter instruction.

Class: MY_INTEGER_MATH
Source class: ANY
Feature: default
Variable: Result
Line: 360
      do
->    end
 

Error message pointing to this feature in class ANY

feature -- Basic operations
frozen default: detachable like Current
 -- Default value of object's type
 do
 end

Any hints how to find the originating true error in my own code, please?

Thanks!

[Gary Smithrud]

I don't like it.  It completely changes the semantics of inspect and for what?  To save.some typing...

To view this discussion on the web visit https://groups.google.com/d/msgid/eiffel-users/EEFAC0D3-F980-4F15-B7C6-BFFC99BFBC5E%40acm.org.

[Ian Joyner]

I think it is more than just saving typing. It makes an expression which is rather adding more functional programming and semantic features. Operationally, maybe it might result in better performance or smaller code. I think it’s worthy of deeper investigation.

Of course there might be counter-example problems with it that I have not imagined yet.

To view this discussion on the web visit https://groups.google.com/d/msgid/eiffel-users/CABuDMNMJyDHT%3D316mpNin%3D5Uhvh_zSnmQrTFxeePg%3D_kFOsLpg%40mail.gmail.com.

[Bertrand Meyer]

There are no particular problems, other than the growth of language size as with any new mechanism. It would continue the trend of offering similar mechanisms for expressions as for instructions, illustrated by conditional expressions.

-- BM

To view this discussion on the web visit https://groups.google.com/d/msgid/eiffel-users/560285BA-AA76-4740-AF04-B95027F36093%40acm.org.

[Richard]

Seems that at some point EiffelStudio / Compiler screwed up. After recompiling from scratch (eg EIFGEN gets removed) all works as expected.

I have the dark suspicion that Windows may have been at some limit (memory?) and induced a problem. The system was running several weeks until I now had to boot cause the system did hang when I intended to sign-off of my development accont.

Thanks once again and I hope I did not disturb anyones sleep and dreams.

R.

On Friday, September 13, 2019 at 2:21:59 AM UTC+2, Richard wrote:

I have a small test program with one small class I want to exercise.

Compilation errors out with the message of

............................ 

[Ian Joyner]

Seems justified then, making the language a bit larger to provide a convenience to the user (not adding to a bloated language to add extra complexity for user). It seems like it would be orthogonal to other features.

Ian

To view this discussion on the web visit https://groups.google.com/d/msgid/eiffel-users/88ffc56f-fdaf-431f-bc61-0e8a390e8092%40www.fastmail.com.

[r...@amalasoft.com]

Mixing expressions with assignments can make the language less readable and lead to more errors, especially by secondary authors (or the primary author a few weeks later).  Not a good idea, even if it saves typing and isn't too difficult to do.  Next stop, e++

That said, I've often wished that inspect could be more flexible, but that feeling passes and I once again appreciate the rigor for what it is.  I feel the same way about a number of "fresh" features/constructs added to the language over the past few years.  The purpose of Eiffel is to enable high quality software.  High quality software exists beyond the instant of authorship and is tested over time, by readership and its suitability to modification.  If the purpose is lost, there are plenty of alternatives out there, already more popular than Eiffel will ever be.

R

-------- Original Message --------
Subject: Re: [eiffel-users] Returning to Eiffel
From: Ian Joyner <i.jo...@acm.org>
Date: Fri, September 13, 2019 5:57 am
To: Eiffel Users <eiffel...@googlegroups.com>

To view this discussion on the web visit https://groups.google.com/d/msgid/eiffel-users/55FE1F42-A091-4C4E-A65B-988DB59ECCEE%40acm.org.

[Eric Bezault]

On 13/09/2019 13:30, r...@amalasoft.com wrote:
> Mixing expressions with assignments can make the language less readable
> and lead to more errors, especially by secondary authors (or the primary
> author a few weeks later).  Not a good idea, even if it saves typing and
> isn't too difficult to do.  Next stop, e++

In my opinion, the primary use of conditional expressions should be in
assertions, where no assignments are possible. In other parts of the
code where assignments and more generally instructions are possible,
I would rather use a conditional instruction.

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

[Gary Smithrud]

Which would then mean being able to use the mechanism in each parameter of a feature call.  An inspect within an inspect as a parameter.  You can see where I am going here.  You may think that no one would do this, but from my experience, some one will.  One of the reason why I view Eiffel as the best OO language is the difficulty in writing obfuscated code (for those who do not know what I'm referring to, look up Obfuscated C Code Contest).  I've had to deal with too much code that should have be contenders in the C, C++, and Java version of this contest.

Thinking some more about it, I would be ok with a restricted syntax for this version of inspect...such as the example provided.

To view this discussion on the web visit https://groups.google.com/d/msgid/eiffel-users/55FE1F42-A091-4C4E-A65B-988DB59ECCEE%40acm.org.

[Larry Rix]

This form of an assigning inspect seems reasonable. The best I could come up with was:

Larry Rix

To view this discussion on the web visit https://groups.google.com/d/msgid/eiffel-users/55FE1F42-A091-4C4E-A65B-988DB59ECCEE%40acm.org.

[r...@amalasoft.com]

int five_divided_by_x = ( x != 0 ? 5 / x : 0 );

Have we come to this?

R

-------- Original Message --------
Subject: Re: [eiffel-users] Returning to Eiffel
From: Larry Rix <lar...@moonshotsoftware.com>
Date: Fri, September 13, 2019 9:11 am
To: Eiffel Users <eiffel...@googlegroups.com>

To view this discussion on the web visit https://groups.google.com/d/msgid/eiffel-users/CAJ7KgmA8PqoYiqmvGn5sdOzqRAUgQ%3DLLpzjc%3DY9UVVKG4jYsAA%40mail.gmail.com.

[Bertrand Meyer]

No.

It was a modest proposal for "inspect" instructions.

I am as conservative as the next guy, more I think, but I see no reason to shoot down every proposal for an abbreviated notation by crying "C++!".

Abbreviations are not evil in essence, otherwise we would all be writing "ADD 1 TO X GIVING...". Some are good and some are bad, and tastes evolve. I do agree that more are bad than are good, but each still deserves assessment on its specific merits.

In other words, dear Roger, in lieu of your cheap shot might we perhaps expect from you an expensive one?

-- BM

To view this discussion on the web visit https://groups.google.com/d/msgid/eiffel-users/20190913061805.cf48dd763fcaf5d42559c6c92f6fc53b.5d9ce7348f.wbe%40email25.godaddy.com.

Attachments:

• image.png
  

[r...@amalasoft.com]

Sure, but it's going to cost you :)

As you might recall from way back when, I had advocated a few shorthands myself, but I worry, a lot, about any loss of readability.  The reason for same is not my failing eyesight, but the firm belief that good software doesn't happen in a single burst of creative energy (and typing), but that a good piece of non-trivial software evolves, is refined, and otherwise tweaked, possibly by several authors.  For software to be good, it should do as it claims, certainly, and should be nearly free of bugs.  Apple pie and motherhood.  The reality is that for any piece of software to become good, it must be understandable by its readers/modifiers.  For it to be understandable, it must be readable - in syntax and style.  Anything then that compromises readability should be treated as suspect first, and only then to be examined as  a potentially worthwhile.

Commingling expression and statement is dangerous, but can be advantageous on balance.  The meaning of any statement or expression must, however, be very clear.

Apart from the infamous ternary expression, C (a language for which I have great respect) has another pair of all-stars with which we are familiar (and might even like): the pre/post increment/decrement operators.  While the more popular of these are the post variants, and their use is most often innocent enough, it's simply too easy to put in the wrong place, or to misinterpret.  Their less svelte siblings, the '+=' and '-=' operators, seem more in line with the "intent is obvious enough" and "first, do no harm" principles, and might actually have a place in a more disciplined language like Eiffel.

Getting back to the variants of inspect, I can certainly understand the desire for such, but I'm not convinced that their benefits outweigh their risks and especially the impact on readability, for the poor souls that comes after the original author.

R

To view this discussion on the web visit https://groups.google.com/d/msgid/eiffel-users/39eccafa-0aee-4ac8-81f8-7a8b5a1a7465%40www.fastmail.com.

[Larry Rix]

I read this (below) and instantly knew what it meant and what the mechanism was trying to do. Again—this seems to me to be a very reasonable suggestion and a nice addition. I have often wished that the inspect mechanism was more flexible in the same way that the from-loop and across-loop are. I totally love how the from and across loops work. I apply them all the time!

If I had an inspect that worked like the notion below, I would use it relentlessly instead of the verbose and wordy if-then-else version or even my silly attempt at using a manifest array.

Just my lil' ole' two cents worth.

Larry Rix
Moonshot Software

Rocket science for everyone!

Savannah, GA

770-295-9729

To view this discussion on the web visit https://groups.google.com/d/msgid/eiffel-users/39eccafa-0aee-4ac8-81f8-7a8b5a1a7465%40www.fastmail.com.

[Martin East]

I believe that a conditional inspect expression does far more than save typing. In Richard’s example below, the inspect statement repeats the assignment to A_Text in each branch. Even if it is the clear intention of the author, it is not possible to ensure that all branches of this statement – even new branches added by a different author - assign a value to A_Text.

 

Inspect statements/expressions are rightly, in my view, frowned on in an OO environment with polymorphism. For the rare cases where their use is unavoidable, it is better to ensure discipline through a language mechanism, instead of hoping that whoever edits the code will pay attention to author comments or, in their absence, divine the author’s intention.

 

From: eiffel...@googlegroups.com <eiffel...@googlegroups.com> On Behalf Of Gary Smithrud
Sent: 13 September 2019 03:21
To: eiffel...@googlegroups.com
Subject: Re: [eiffel-users] Returning to Eiffel

 

I don't like it.  It completely changes the semantics of inspect and for what?  To save.some typing...

To view this discussion on the web visit https://groups.google.com/d/msgid/eiffel-users/CABuDMNMJyDHT%3D316mpNin%3D5Uhvh_zSnmQrTFxeePg%3D_kFOsLpg%40mail.gmail.com.

[Gary Smithrud]

OK, but as I stated before...think about the worse case scenario and would the feature be worth it?  To me, no.  I've had to deal with too many things that people thought were good ideas.

To view this discussion on the web visit https://groups.google.com/d/msgid/eiffel-users/CAJ7KgmCTvE82izUg9DmAbsDOtGLoDCFbN7sOs7Fjz1Ft2XMozQ%40mail.gmail.com.

[Woland's Cat]

this is a (nice) simple form of when/then rules we use all the time in clinical decision support systems and other event-based systems. I'm working on a meta-model for generalised when/then that encompasses if/then/elseif, switch statements, and user interaction (e.g.overriding) for a decision support language we need in health. If anyone is interested, I'll share it here.

Our current form of the inspect stmt is:

    when <expression>
        matches <value_interval_1> then
            -- statements
        matches <value_interval_2> then
            -- statements
            ...
        matches <value_interval_N> then
            -- statements

        else
            -- statements
    end

- thomas

[Larry Rix]

How would this form of inspect have polymorphic or CAT-call issues?

Larry Rix

To view this discussion on the web visit https://groups.google.com/d/msgid/eiffel-users/CABuDMNNFKrReAgL9UjEwTRWkpP3O5a3hbvFSU32zaHfnPwMJ-w%40mail.gmail.com.

[Eric Bezault]

On 13/09/2019 16:38, r...@amalasoft.com wrote:
> Apart from the infamous ternary expression, C (a language for which I
> have great respect) has another pair of all-stars with which we are
> familiar (and might even like): the pre/post increment/decrement
> operators.  While the more popular of these are the post variants, and
> their use is most often innocent enough, it's simply too easy to put in
> the wrong place, or to misinterpret.  Their less svelte siblings, the
> '+=' and '-=' operators, seem more in line with the "intent is obvious
> enough" and "first, do no harm" principles, and might actually have a
> place in a more disciplined language like Eiffel.

Note that the expression 'i++' is violating one of Eiffel's principles:
Command-Query-Separation. An expression with side-effect: each call to
'i++' modifies its result. So there is no chance to have it adopted in
Eiffel. Conditional expressions do not suffer from this problem, neither
do '+=' and '-='.

[Eric Bezault]

On 13/09/2019 18:45, Martin East wrote:
> I believe that a conditional inspect expression does far more than save
> typing. In Richard’s example below, the inspect statement repeats the
> assignment to A_Text in each branch. Even if it is the clear intention

> of the author, it is not possible to ensure that _all_ branches of this

> statement – even new branches added by a different author - assign a
> value to A_Text.

That's a good point. I'll try to remember it when writing
code with conditionals.

[Richard]

I didn't expect this kind of response to my innocent question :)

To clarify, I was not asking for this to be implemented, I was only wondering why it was not implemented. The term I was looking for was "orthogonal", H/T to i.joyner.

I also asked cause I was used in other languages to work with "case"-like statements to similar effect.

I am a proponent for a language with minimal instruction set to be able to formulate all other things in  libraries. That's why in a former life I liked to work with Pascal. (Relative) ease of learning to speak correctly in a language and the gigantic task of getting to know and apply libraries.

Eric Bezault wrote "the primary use of conditional expressions should be in assertions". If that was the original intent of the conditional expression, I could agree to restricted semantics, only to be used in assertions. With or without a multi-branch variant. I guess its too late to restrict this element, how much code would really break (apart my own)?

Thanks to Larry Rix for that code sample. In the case I am looking at, I need to adapt it to a "sparse array", two handfull of non-contiguous values coded into a byte.

Regards - Richard.

On Thursday, September 12, 2019 at 8:55:11 PM UTC+2, Richard wrote:

Curious - 

Eiffel defines a Conditional Expression https://www.eiffel.org/doc/eiffel/Conditional_expression like:

..... 

Eiffel also defines the multi-branch instruction with inspect (at https://www.eiffel.org/doc/eiffel/ET-_Instructions#Multi-branch).

.....

So far so good. Has there ever been a discussion over a matching Multi-branch Expression ?

Something like this:....

[Ian Joyner]

I think that like i++, the += and -= forms expose the underlying operation of machines, although not as bac as the side effects in i++.

Thus the inspect expression is more abstraction oriented. If anyone read the hourglass model in July CACM (https://cacm.acm.org/magazines/2019/7/237714-on-the-hourglass-model/fulltext) I’d say that ++, +=, -= are in the bottom part of the hourglass and should not be exposed, whereas inspect expressions are more in the neck and upper part of the hourglass.

Ian

--
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/0e804ceb-da06-7a20-1bc1-5b2bb1f33fe3%40gobosoft.com.

[Bertrand Meyer]

Yes, readability is one of the key criteria, and was exactly the argument that the original proposer (Richard) was using when he contrasted (I am citing his example)

 

a_text := inspect a_number
            when 1 then "one"
            when 2 then "two"
            else        "do not know"
            end

 

with

 

inspect a_number
   when 1 then a_text := "one"

   when 2 then a_text := "two"

   else        a_text := "do not know"

   end

 

The second form contains redundancy. Redundancy can be good (static typing is a form of redundancy), but here it seems useless and distracting (you have to check that the same variable `a_text’ is being assigned in every case – waste of time, attention and effort). It is reasonable to argue that the first variant is more readable

 

I am not endorsing the proposal at this point (pending further evaluation, and assessment of other priorities in the language’s evolution) but I don’t think it is fair to dismiss it on the basis of generic gut feelings.

 

-- BM

To view this discussion on the web visit https://groups.google.com/d/msgid/eiffel-users/20190913073824.cf48dd763fcaf5d42559c6c92f6fc53b.fe34178ece.wbe%40email25.godaddy.com.

[Richard]

I started off based on your suggestion but with my mind set on sort of a sparse array, cause inspect picks out of a select list of  elements, not a range.

I ended up with this code:

 give_me ( n : array [STRING] ; i : INTEGER ) : STRING          -- arrays of names / the number to represent
 do
    if n.lower <= i and then i <= n.upper then Result := n [i]
    else Result := "invalid"
    end
 end -- give_me

together with naming arrays like this one:

 numbers_55_thru_77 : array [STRING]
    once
       create Result.make_filled ("unknown", 55, 77)
       Result [ 55 ] := "fiftyfive"
       Result [ 60 ] := "sixty"
       Result [ 61 ] := "sixtyone"
       Result [ 70 ] := "seventy"
    end -- numbers_55_thru_77

with this sample test code:

 print ("Give Me 55    as " + give_me (numbers_55_thru_77, 55)    + "%N")
 print ("Give Me 61    as " + give_me (numbers_55_thru_77, 61)    + "%N")
 print ("Give Me 77    as " + give_me (numbers_55_thru_77, 77)    + "%N")
 print ("Give Me 12345 as " + give_me (numbers_55_thru_77, 12345) + "%N")

Thanks for the inspiration - Richard

[Alexander Kogtenkov]

An "idiomatic" way to write

   n.lower <= i and then i <= n.upper

is

   n.valid_index (i)

Using a conditional expression, the code becomes

   Result :=
      if n.valid_index (i) then
         n [i]
      else
         "invalid"
      end

Regards,
Alexander Kogtenkov

Richard <eiffel-...@rth10260.info>:

[Bertrand Meyer]

Talking about “idiomatic” (and nitpicking), in Eiffel style we would not call a function “give_me” (a verbal form that suggests a command) but something more like “given_to_me” (or more likely just “item” in this case). Also, I think it has been a long time since anyone bothered to repeat the name of a routine as a comment at the end, Ada-style. The standard indentation style is also different from what’s below.

 

-- 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.

To view this discussion on the web visit https://groups.google.com/d/msgid/eiffel-users/1568449190.680267570%40f139.i.mail.ru.

[r...@amalasoft.com]

Hi Ian

The ++ and -- operators do, indeed reflect the underlying system, or at least they did in the days of the PDP-11, are the embodiment of evil, and so forth, agreed.

The += and -= operators are different.  They are little more than shorthand for assignment, and are abstract enough.

  i += 1  --> i := i + 1

Neither do they violate query-command separation (as the ++ and -- ops do) because they are instructions and not combo instructions/expressions, and do not present as values (except, of course, when used in a ternary op or similar "uncluttered" notation).

R

-------- Original Message --------
Subject: Re: [eiffel-users] Returning to Eiffel
From: Ian Joyner <i.jo...@acm.org>
Date: Sat, September 14, 2019 1:08 am
To: Eiffel Users <eiffel...@googlegroups.com>

I think that like i++, the += and -= forms expose the underlying operation of machines, although not as bac as the side effects in i++.

Thus the inspect expression is more abstraction oriented. If anyone read the hourglass model in July CACM (https://cacm.acm.org/magazines/2019/7/237714-on-the-hourglass-model/fulltext) I’d say that ++, +=, -= are in the bottom part of the hourglass and should not be exposed, whereas inspect expressions are more in the neck and upper part of the hourglass.

Ian

On 14 Sep 2019, at 04:39, Eric Bezault <er...@gobosoft.com> wrote:

On 13/09/2019 16:38, r...@amalasoft.com wrote:

Apart from the infamous ternary expression, C (a language for which I have great respect) has another pair of all-stars with which we are familiar (and might even like): the pre/post increment/decrement operators.  While the more popular of these are the post variants, and their use is most often innocent enough, it's simply too easy to put in the wrong place, or to misinterpret.  Their less svelte siblings, the '+=' and '-=' operators, seem more in line with the "intent is obvious enough" and "first, do no harm" principles, and might actually have a place in a more disciplined language like Eiffel.

Note that the expression 'i++' is violating one of Eiffel's principles:
Command-Query-Separation. An expression with side-effect: each call to
'i++' modifies its result. So there is no chance to have it adopted in
Eiffel. Conditional expressions do not suffer from this problem, neither
do '+=' and '-='.

--
Eric Bezault
mailto:er...@gobosoft.com
http://www.gobosoft.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/0e804ceb-da06-7a20-1bc1-5b2bb1f33fe3%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 on the web visit https://groups.google.com/d/msgid/eiffel-users/825F2E8C-80F3-4B06-B2B4-37781C1183BE%40acm.org.

[r...@amalasoft.com]

Sorry, Eric.  I should also have pointed out that you made this distinction earlier.

R

To view this discussion on the web visit https://groups.google.com/d/msgid/eiffel-users/20190914045138.cf48dd763fcaf5d42559c6c92f6fc53b.93339536a5.wbe%40email25.godaddy.com.

[Richard]

I appreciate the input. As I recently mentioned learning the services of a class is the real endeveour. While lower and upper were very obvious as often part of other languages, the vald_index was not yet ingrained. I had a good laugh over suggesting the use of the conditional expression as it was at the root of this animated discussion :)

[Ian Joyner]

Hi Roger,

Yes, I said += did not have the same problems as ++. However, I don’t see the point of a plethora of assignment operators – I’d rather see it spelt out and let a compiler optimizer generate the best code.

Ian

To view this discussion on the web visit https://groups.google.com/d/msgid/eiffel-users/20190914045138.cf48dd763fcaf5d42559c6c92f6fc53b.93339536a5.wbe%40email25.godaddy.com.

[Richard]

The code snippets were taken out of a small basic console test app, originally not intended for public consumption. I was enjoying hacking along rather than engineering the code ;)

My next best pick would have been simply "number_name". As using more descriptive names in the function arguments.

Re the commented end's: I have recently had to match up the correct number of ends with their leading construct name, it's not something I do regularily. Code templates are not always my best friend. Often I start over fresh with an "if" condition when the rest is already coded. That's when I overlook the inserted not needed "end".

The editor has the Highlighting Matching Braces functionality, my "newbie" coding (in-)expierience would suggest matching up things like a if/elseif/else/end costruct too.....

Richard.

[Chris Tillman]

Thanks for that Alexander! I didn't realise there was a syntax option to directly assign the if expression. Very clean in this case.

--
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/1568449190.680267570%40f139.i.mail.ru.

--

Chris Tillman
Developer

[Karsten...@gmx.de]

Dear Alexander,

does your conditional assignment example below
conform to the ECMA standard?

   Result :=
      if n.valid_index (i) then
         n [i]
      else
         "invalid"
      end

Thanks,
Karsten

[Alexander Kogtenkov]

Dear Karsten,

The current ECMA standard is quite old. Since its publication several language constructs were changed or added. Conditional expressions is one of them. The official ECMA standard does not include the corresponding specification. However, to my knowledge, all contemporary Eiffel compilers support conditional expressions.

Coming back to the construct itself, a short description is available at

    https://www.eiffel.org/doc/eiffel/Conditional_expression 

In particular, the rules rely on a notion of "common ancestor type" to obtain the type of such an expression. You can follow the links at the page mentioned above to see how this type is computed.

Best regards,
Alexander Kogtenkov

karsten...@gmx.de:

[Karsten Heusser]

Thanks for your steady help, Alexander.

Best,

Karsten

[Richard]

First, Happy New Year and Happy Eiffeling to everyone!

Worked my way thru Eiffel code in the past months since posting last time, and have seen some very interesting application of the Eiffel syntax.Ways I wouldn't have been thinking of.using the language.

The following: taken from https://dev.eiffel.com/EiffelStudio_ChangeLog

19.07.10.3368 (July 31st 2019, beta 19.07)
New features

• compiler: Added support for manifest immutable strings, once manifest immutable strings, and immutable string constants. Examples: {IMMUTABLE_STRING_32} "Unicode string...", once {IMMUTABLE_STRING_8} "once value", id: IMMUTABLE_STRING_8 = "abc".

 I came upone it when I did see this line:

if sub_node.has_same_name (once "SHORTCUT") then

Now my question:

What is the semantics behind these variations, why have they been introduced?

[Finnian Reilly]

Hi Richard

if sub_node.has_same_name (once "SHORTCUT") then

This particular syntax has been around since at least 16.01. For routines that are called many times, it is not desirable to create a new local instance of "SHORTCUT" each time, which is what would happen if not prefixed with `once'.

Finnian

[Richard]

Back to Eiffel after getting side tracked with other developer issues for several months.

My question now is how to correctly precompile a Eiffel library.

Especially I want to use the Date-Time library from the distribution at C:\Program Files\Eiffel Software\EiffelStudio 20.05 Standard\library\time.

I want to use the plain version as defined by time.ecf.

When I use the Windows context menu "Precompile" option it does some kind of compilation, but the classes remain "uncoloured" in the Class tree pane, and no features get listed in the Features pane.

Same when I copy the time.ecf file into the user space at C:\Users\Eiffel\Documents\Eiffel User Files\20.05\precomp\spec\win64 where the default library definitions are held.

But if I copy the distribution library over into the user space, here into C:\Users\Eiffel\Documents\Eiffel User Files\Libraries\time, and run the precompile here, I get a comppleted compilation as expected.

But in all cases, even the library compiled in user space, when I add the target to the project in EStudio menu>Project>Project settings and add "time" as a target, the editor will display only grey class names and no features in the feature pane.

Special quirk: 

Using Estudio>Tools<Precompilation wizard I get a list of the default entries offered, names have a prefix "precomp-" in the list. When I try to add the "time.ecf" as own library I get an error message "the configuration file you have selected is not valid", no further indication to why.

Thanks for any assistance.

Richard

[r...@amalasoft.com]

Hi Richard

The grayed classes / no features state is simply because there are no references to those classes from the classes in the application.  A simple trick to enable them is to select one of the classes from the library and refer to it, even as an uninstantiated local, in one of your active classes (e.g. you root class).

R

-------- Original Message --------
Subject: [eiffel-users] Re: Returning to Eiffel
From: Richard <eiffel-...@rth10260.info>
Date: Wed, August 19, 2020 12:57 am
To: Eiffel Users <eiffel...@googlegroups.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/2dda1a73-f4a1-441a-905f-82282304db1eo%40googlegroups.com.

[Larry Rix]

On Sunday, July 7, 2019 at 12:43:31 AM UTC-4 hank....@gmail.com wrote:

Same problems here with the old books. What I do is that go methodically through the book and then check the new Eiffel class spec. I also do version control and then upgrade the code step by step, documenting it (say, there was a formula for calculating "Pi" with arc tangent,  but now MATH_CONST does it for you - change the types - and the compiler - oh, wow, what a great tool! - and you're done. Stuff like that...I have a few on my git repository, but the book's copyright doesn't seem to allow me to make the repository public. I'm thinking of asking one of the authors. This would help greatly, I think.

For my part, my heavy push into Eiffel was the result of being on an Eiffel production team from 2009-2014. During that time, we started with direct teaching from a very wonderful man, who has since passed from cancer. It also helped to have a couple of strong Eiffel consultants on the team and then to be immersed.

My deepest problem was trying to think with Eiffel like I did with Visual FoxPro, which as a disaster. My saving grace was when I literally stopped trying to look at Eiffel through a FoxPro lens, tossed FoxPro over the side of the "ship-of-my-mind", and decided to "learn-how-the-compiler-thinks" and that meant going through the ECMA Standard with a fine-tooth-comb on one side and the Eiffel Studio on the other. I banged my head on the FoxPro door for about 9 months before my hard head finally hurt too much!

 

Also, I see that the Smalltalk community made a move to ask the authors of old books to have them released on the web. The books are old and no-one wants to buy them anymore (except us few). This would be a healthy undertaking for the Eiffel community. 

There are some newer books that are WELL WORTH the cost—Touch of Class is very up-to-date and full of good info, but it is huge! I use it like a reference book.

 

Cheers, 

-- Hank 

ps. at first glance much of the docu provided at https://dev.eiffel.com/Main_Page seems fairly dated and isn't very helpful.

[r...@amalasoft.com]

Hi Richard

Attached is a paper I whipped up a decade ago (and swept since to modernize the terminology).

It might be of some help to you (or perhaps not).  It doesn't even mention precompiling, btw.

[Larry Rix]

If I am understanding the issue correctly, then the "grayed-out" classes are those that are not "in-system" (e.g. some class from your root class procedure does not reference the class you're interested in).

So—in order for the class pebble (icon) to go from gray to blue, you need to simply give it a reference somewhere. The simplest way is to create a detachable reference (i.e. class feature or feature local variable). Once you have a reference to the class in-system, then it will change and you'll be able to explore it with pick-n-drop and other class and feature tools as you would expect.

[r...@amalasoft.com]

Perfect!

R

--
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/CAJ7KgmD8Ro9AsYiqQTqnLAVoGQ4fCYcikriftPvwZbTQ3Ssp2g%40mail.gmail.com.