HDTenEightyP/NetNews huggingface dataset:
From: johnson@cs.uiuc.edu (Ralph Johnson)
Subject: Re: Object hidden state and side effects
Organization: University of Illinois, Dept. of Comp. Sci., Urbana, IL
Date: Sat, 19 Dec 1992 14:12:25 GMT


In article <1992Dec16.65250.10645@kei.is.s.u-tokyo.ac.jp> jeff@is.s.u-tokyo.ac.jp writes:

>I am really at a loss here.  What exactly (in concrete real terms) do
>you expect people to do differently when using true for example once
>it is recognized as a value and not an object?

dave@alex.uchicago.edu (Dave Griffith) writes:

>Express their actual intent clearly and precisely, without requiring 
>unneccessary contortions to map their intent to a overly limitted language.
>But I've always been a dreamer.

This does not seem to me to be an answer "in concrete real terms".

The difference between an "object" and a "value" seems to be that for
a value, equality can be implemented by bit comparison of the things,
while objects can only use identity of addresses in memory or else
require a user-supplied function.  Isn't this just a result of immutability?

>But most languages have no way to _enforce_ the requirement that they "only
>allow operations that are in line with their essential sameness".  

Most languages have no way to enforce anything that is interesting.
We can't really enforce that a subclass provides the same behavior
as a superclass.  In C++, I can enforce that a virtual function will
return an integer, but not a positive integer (except by making a
class for positive integers).  I can enforce that a sort function
take a boolean valued binary function as a parameter, but not that
it provide a total ordering on the collection to be sorted.  We need
to improve the expressive power of our languages.  I think that trying
to solve this problem just by making a value/object distinction is like
applying a bandaid to someone who had a leg cut off.  

-Ralph Johnson
From: jyl@burgess.eng.sun.com (Jacob Levy)
Newsgroups: comp.object
Subject: Q: Replicated Objects?
Date: 12 Dec 92 21:34:39
Organization: What?! Organization???
Reply-To: jyl@toss.eng.sun.com
NNTP-Posting-Host: burgess


This is to solicit descriptions of systems, architectures and ideas for
same, based on replicated objects. If you have built such a system, I would
like to hear from you. First, do you think replication in the context of
objects is important, and why? Of special interest to me is how you dealt
with the issues of consistency of the replicas, what your underlying
assumptions of quality of service were, and to what degree you were
successful in implementing your design. Also, what tools do you see as
essential to building your system?

If there is sufficient response (actually any :-), I will summarize to this
group.

--JYL

Newsgroups: comp.lang.eiffel
From: sakkinen@jyu.fi (Markku Sakkinen)
Subject: Re: Semantics of invariants
Organization: University of Jyvaskyla, Finland
Date: Thu, 17 Dec 1992 15:37:36 GMT

In article <159@eiffel.eiffel.com> ram@eiffel.com (Raphael Manfredi) writes:
>Quoting cflatter@nrao.edu from comp.lang.eiffel:
>>In article 16406@bony1.bony.com, richieb@bony1.bony.com (Richard Bielak) writes:
>>>Is the invariant supposed to be true *ALL* the time, once the object is
>>>created? 
>>>
>>You can invalidate a class invariant inside a function or procedure
>>provided that it is true on exit.  In other words the class invariant
>>is an implicit conjunct of both the precondition and the postcondition
>>of a function or procedure.
>
>Well, that's not completely true. The invariant is indeed added to the
>preconditions and postconditions of a feature ONLY when called remotely,
>i.e. when you write:
>
>	a.f;
>
>If you only call:
>
>	f;
>
>then the invariant is NOT checked. The reason behind this is that one class
>(e.g. SORTED_TWO_WAY_LIST) may temporarily violate its invariant (typically
> ...

Right.  This suggests the need for a declaration that certain routines
should _not_ be callable from the Current object itself (except from
read-only routines), since they may be written assuming that the invariant
holds.

There is an additional complication:  a remote call may cause other
remote calls back to the calling object before returning.
I.e. the same object may appear more than once on the execution stack
even in a purely sequential system.  This is no Eiffel-specific problem.
(Richard Bielak may have had it also in mind in his original question.)

----------------------------------------------------------------------
Markku Sakkinen (sakkinen@jytko.jyu.fi)
       SAKKINEN@FINJYU.bitnet (alternative network address)
Department of Computer Science and Information Systems
University of Jyvaskyla (a's with umlauts)
PL 35
SF-40351 Jyvaskyla (umlauts again)
Finland
----------------------------------------------------------------------
Newsgroups: comp.lang.eiffel
From: sakkinen@jyu.fi (Markku Sakkinen)
Subject: Re: barycenter
Organization: University of Jyvaskyla, Finland
Date: Tue, 15 Dec 1992 12:28:17 GMT

In article <fxg.724333849@bolgolam> fxg@bolgolam.informatik.rwth-aachen.de (Felix Gatzemeier) writes:
>A question about the graphics libraries:
>
>  >> what does barycenter mean? <<
>
>(The manual doesn't explain it, Webster (TM) doesn't know it
>and my imagination can't get it, either.)

It must mean 'centre of gravity' (Schwerpunkt) -- being derived
from the Old Greek word for 'heavy', I think.
(I know, I know:  this wasn't exactly an Eiffel question.)

----------------------------------------------------------------------
Markku Sakkinen (sakkinen@jytko.jyu.fi)
       SAKKINEN@FINJYU.bitnet (alternative network address)
Department of Computer Science and Information Systems
University of Jyvaskyla (a's with umlauts)
PL 35
SF-40351 Jyvaskyla (umlauts again)
Finland
----------------------------------------------------------------------
Newsgroups: comp.lang.eiffel,comp.compilers
From: langmack@inf.fu-berlin.de (Olaf Langmack)
Subject: Re: Public domain Eiffel-3 front-end available
Reply-To: langmack@inf.fu-berlin.de (Olaf Langmack)
Organization: Free University of Berlin, Germany
Date: Mon, 14 Dec 1992 13:11:08 GMT
Keywords: Eiffel, parse, available, FTP

Sorry for the inconvenience in trying to access "ep"!

There's an additional site where you can get it via anonymous file
transfer, you may give it a try:

Host:           ftp.zrz.TU-Berlin.DE [130.149.4.50]
Directory:      ~ftp/pub/unix/lang/eiffel
Files:          README 
                ep.tar.Z

Within some days - hopefully before christmas - we hope to have it at
other sites and in the US as well.

If you can't wait until then and don't get it from the sites mentioned
above, we'll send it to you on request as sequence of small uuencoded
files.

oL,
langmack@inf.fu-berlin.de
-- 
Send compilers articles to compilers@iecc.cambridge.ma.us or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
From: mod@cs.man.ac.uk (Mike O'Docherty (Teaching Company Associate))
Newsgroups: comp.lang.eiffel
Subject: Re: barycenter
Date: 16 Dec 92 09:35:27 GMT

fxg@bolgolam.informatik.rwth-aachen.de (Felix Gatzemeier) writes:

>  >> what does barycenter mean? <<

Centre of gravity I think...

Mike.
From: Sandor_Scari@st2.maus.de (Sandor Scari)
Newsgroups: comp.lang.eiffel
Subject: Re: Semantics of invariants
Date: 17 Dec 92 23:22:00 GMT
Article-I.D.: ST2.A3349
Organization: MausNet (Mitglied im IN e.V.)
X-Gateway: MausGate/News 1.14D/hb

r>Is the invariant supposed to be true *ALL* the time, once the object is
r>created?
No.  If the invariant is A+B=const you couldn't change A or B.  The invariant
is only true, while no methods of the objact in use is.

S\'andor jetzt  @ST2!
From: saiid@cis.ksu.edu (Saiid Paryavi)
Newsgroups: comp.lang.eiffel
Subject: Re: Semantics of invariants
Date: 16 Dec 92 15:46:25 GMT
Organization: Kansas State University
NNTP-Posting-Host: castor.cis.ksu.edu

richieb@bony1.bony.com (Richard Bielak) writes:

>Is the invariant supposed to be true *ALL* the time, once the object is
>created? 

>If this is so, you can imagine each object having an "invariant-checker"
>running continously on another processor.

>Or is it OK to invalidate the invariant while inside the object's routines,
>as long as the invariant is true on exit.

>What if one object routine calls another? What about recursive routines?


Invariants are checked at the time of object creation and every time a routine
is exited.  Invariants should not be checked during the execution of a routine`s
body.


Newsgroups: comp.lang.eiffel
From: richieb@bony1.bony.com (Richard Bielak)
Subject: Re: Semantics of invariants
Organization: multi-cellular
Date: Thu, 17 Dec 92 19:04:50 GMT

In article <1992Dec16.163847.17559@nrao.edu> cflatter@nrao.edu writes:
>In article 16406@bony1.bony.com, richieb@bony1.bony.com (Richard Bielak) writes:
>>Is the invariant supposed to be true *ALL* the time, once the object is
>>created? 

[...]

>
>You can invalidate a class invariant inside a function or procedure
>provided that it is true on exit.  In other words the class invariant
>is an implicit conjunct of both the precondition and the postcondition
>of a function or procedure.  Suppose that the class invariant is I and
>the P is the precondition of a procedure of the class as given in the
>require clause and Q is the postcondition as given in the ensure clause:
>then (P and I) is also a precondition of the procedure and (Q and I) is
>also a postcondition of the procedure.
>

[...]

OK. I understand all this, but consider this situation (in pseudo-Eiffel):

        class FOO is
                export r1, r2

            r1 is
               do
                  [...do something here to make the invariant false...]
                  r2;
               end; -- r1

            r2 is
               do
                 [... some stuff ...]
               end; -- r2

        invariant
                inv_condition

        end; -- FOO


If we have "x" of type FOO, does the call "x.r1" work or does it fail?
Note that the invariant is false, when routine "r2" is called.

One way to deal with this is to insist that the invariant should
always be true - I mean it is an *INVARIANT*.

...richie

-- 
* Richie Bielak   (212)-815-3072   |                                          *
* Internet:       richieb@bony.com | Rule #1: Don't sweat the small stuff.    *
* Bang {uupsi,uunet}!bony1!richieb | Rule #2: It's all small stuff.           *
*    - Strictly my opinions -      |                                          *
Newsgroups: comp.lang.eiffel,comp.compilers
From: langmack@inf.fu-berlin.de (Olaf Langmack)
Subject: Re: Public domain Eiffel-3 front-end available
Reply-To: langmack@inf.fu-berlin.de (Olaf Langmack)
Organization: Free University of Berlin, Germany
Date: Wed, 16 Dec 1992 12:50:54 GMT
Keywords: Eiffel, parse, available, FTP

Thanks to R. Bush "ep 1.0" is in the states at: ftp.psg.com:~/pub/eiffel.

Thanks to P. Henderson it runs on HP-800 series. (contact:
pbh@sbcs.sunysb.edu)

The next version, which we plan to release by end of March 1993, will
support MS-DOS as well. Suggestions for improvements resulting from
practical experience are welcome!

Thanks for your interest,
BG,oL.

langmack@inf.fu-berlin.de
-- 
Send compilers articles to compilers@iecc.cambridge.ma.us or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
Newsgroups: comp.lang.eiffel
From: fm@sigcomp.sub.org (Frieder Monninger)
Subject: Re: Search for PC-Eiffel (or -SATHER)
Organization: SIG Computer GmbH
Date: Fri, 11 Dec 1992 08:39:19 GMT

In <1992Dec08.153714.18089@th-ilmenau.RZ.TH-Ilmenau.DE> huebner@PrakInf.TH-Ilmenau.DE (Huebner) writes:


>Hi,

>Although EIFFEL is based on Unix, I would like to have it for MS-DOS.
>Is there such a system available?
Why do you not use Eiffel/S - you need a 386SX and 4 MByte (or more)

>Are there Eiffel systems for educational purposes (including size 
>reduced versions)?
Student License in Germany DM 150.- incl. Mwst 
-- 
Frieder Monninger	SIG Computer GmbH	fm@sigcomp.sub.org
			D 6333 Braunfels	++49 6472/2096
Newsgroups: comp.lang.eiffel
From: andrea@pX1.stfx.ca (John Andrea)
Subject: eiffel for DEC osf/1 ?
Summary: compiler for osf/1 ?
Keywords: dec osf1 eiffel axp
Organization: NSTN Network Operations Centre, Nova Scotia, Canada
Distribution: comp.lang.eiffel
Date: Sat, 12 Dec 1992 20:16:35 GMT


Does anyone have any info about Eiffel being available under OSF/1
on DEC AXP machines ?

Sig or ISA

John Andrea
andrea@essex.stfx.ca
From: ram@eiffel.com (Raphael Manfredi)
Newsgroups: comp.lang.eiffel
Subject: Re: Semantics of invariants
Date: 16 Dec 92 18:13:29 GMT
Organization: Interactive Software Engineering, Santa Barbara CA

Quoting cflatter@nrao.edu from comp.lang.eiffel:
>In article 16406@bony1.bony.com, richieb@bony1.bony.com (Richard Bielak) writes:
>>Is the invariant supposed to be true *ALL* the time, once the object is
>>created? 
>>
>You can invalidate a class invariant inside a function or procedure
>provided that it is true on exit.  In other words the class invariant
>is an implicit conjunct of both the precondition and the postcondition
>of a function or procedure.

Well, that's not completely true. The invariant is indeed added to the
preconditions and postconditions of a feature ONLY when called remotely,
i.e. when you write:

	a.f;

If you only call:

	f;

then the invariant is NOT checked. The reason behind this is that one class
(e.g. SORTED_TWO_WAY_LIST) may temporarily violate its invariant (typically
when sorting the list). The sorting algorithm may well rely on two or three
subroutines, and checking the invariant while in an inconsistent state would
be fatal... At the time the execution flow "exits" from the class (i.e. when
we return from the feature in SORTED_TWO_WAY_LIST which was called by a client),
then of course the invariant must be checked.

This makes the "invariant check" operation difficult, if not impossible, to
implement concurrently as Richard Bielak suggested it.
-- 
Raphael Manfredi <ram@eiffel.com>
Interactive Software Engineering Inc.
270 Storke Road, Suite #7                      / Tel +1 (805) 685-1006 \
Goleta, California 93117, USA                  \ Fax +1 (805) 685-6869 /
Newsgroups: comp.lang.eiffel
From: cflatter@nrao.edu (Chris Flatters)
Subject: Re: Semantics of invariants
Reply-To: cflatter@nrao.edu
Organization: NRAO
Date: Wed, 16 Dec 1992 16:38:47 GMT

In article 16406@bony1.bony.com, richieb@bony1.bony.com (Richard Bielak) writes:
>Is the invariant supposed to be true *ALL* the time, once the object is
>created? 
>
>If this is so, you can imagine each object having an "invariant-checker"
>running continously on another processor.
>
>Or is it OK to invalidate the invariant while inside the object's routines,
>as long as the invariant is true on exit.

You can invalidate a class invariant inside a function or procedure
provided that it is true on exit.  In other words the class invariant
is an implicit conjunct of both the precondition and the postcondition
of a function or procedure.  Suppose that the class invariant is I and
the P is the precondition of a procedure of the class as given in the
require clause and Q is the postcondition as given in the ensure clause:
then (P and I) is also a precondition of the procedure and (Q and I) is
also a postcondition of the procedure.

If the values of class attributes are not modified outside of the procedures
and functions of that class it is sufficient to check the class invariant
on exit from each function or procedure since the invarient will not
change between exit from one function/procedure and entry into the next.

	Chris Flatters
	cflatter@nrao.edu
Newsgroups: comp.lang.eiffel
From: fred@sobel.u-strasbg.fr (Frederic PIERRE)
Subject: [Q] PD-Eiffel
Date: Tue, 15 Dec 1992 16:37:56 +0000

	SIG-Computer GmbH (Germany) sells a public domain Eiffel compiler.
apropriately called PD-EIFFEL. Who knows if it is available for anonymous 
ftp and where?
	Thanks in advance.
	Fred.
 ===========================================================================
 Frederic PIERRE. ENSPS/LSIT 7 rue de l'universite F-67000 Strasbourg FRANCE 
 Tel: (33) 88 35 80 84 Fax: (33) 88 35 31 76 e-mail: fred@sobel.u-strasbg.fr
 ==========================HamRadio: FC1HFD=================================
From: bruce@plsparc.UUCP (Bruce D Mount)
Newsgroups: comp.lang.eiffel
Subject: Re: Semantics of invariants
Date: 16 Dec 92 15:17:27 GMT
Organization: Personal Library Software, Inc.

In article <1992Dec15.213603.16406@bony1.bony.com> richieb@bony1.bony.com (Richard Bielak) writes:
>Is the invariant supposed to be true *ALL* the time, once the object is
>created? 
>
>Or is it OK to invalidate the invariant while inside the object's routines,
>as long as the invariant is true on exit.
>

Well, I probably shouldn't do this from memory but...
I thought it was ok to violate the invarient inside a feature
as long as the invarient held upon feature-exit.  Given this
syncronys model, I don't think a coprocessor to check invarients
is needed IMHO.

(BTW Richie, I'm enjoying the series of articles you wrote for
the Sun amgazine I can't currently find :-).  Keep writing...)

Sorry for the poor spelling,

--Bruce
============================================================
Bruce Mount             "Another Member of the Eiffel Jihad!"
Personal Library Software
Voice:  (301) 990-1155
e-mail: bruce@pls.com    OR   ...uunet!plsparc!bruce
============================================================
Newsgroups: comp.lang.eiffel
From: richieb@bony1.bony.com (Richard Bielak)
Subject: Semantics of invariants
Organization: multi-cellular
Date: Tue, 15 Dec 92 21:36:03 GMT

Is the invariant supposed to be true *ALL* the time, once the object is
created? 

If this is so, you can imagine each object having an "invariant-checker"
running continously on another processor.

Or is it OK to invalidate the invariant while inside the object's routines,
as long as the invariant is true on exit.

What if one object routine calls another? What about recursive routines?


...richie
-- 
* Richie Bielak   (212)-815-3072   |                                          *
* Internet:       richieb@bony.com | Rule #1: Don't sweat the small stuff.    *
* Bang {uupsi,uunet}!bony1!richieb | Rule #2: It's all small stuff.           *
*    - Strictly my opinions -      |                                          *
Newsgroups: comp.lang.eiffel
From: nagle@netcom.com (John Nagle)
Subject: Re: Semantics of invariants
Organization: Netcom - Online Communication Services  (408 241-9760 guest) 
Date: Fri, 18 Dec 1992 03:38:11 GMT

cflatter@nrao.edu (Chris Flatters) writes:
>If the values of class attributes are not modified outside of the procedures
>and functions of that class it is sufficient to check the class invariant
>on exit from each function or procedure since the invarient (sic) will not
>change between exit from one function/procedure and entry into the next.

       This is not quite sufficient, unfortunately.  The usefulness of
class invariants is that one can assume them to be true at entry to
a procedure exported from a class.  Procedures in the class are coded
assuming the invariant is true (and, strictly, shouldn't assume anything
about the class variables that isn't expressed in the invariant).
After manipulating the class variables, the procedure must make the
invariant true before returning.  This is a good, sound way to program.

       There's a hole, though.  Class reentrancy is a problem.  If a
procedure exported from a class can, directly or indirectly, call
itself or some other exported procedure on the same object, the
object can be entered with the invariant in an invalid state.

       This comes up in some C++ programs which use "iterators".
If an iterator iterating over a list calls a function which, say,
calls the function which
deletes something from that list, the iterator may dereference a pointer
to a deleted object.

       The implication is that if an object has functions which could
potentially call something which reenters the object, the invariant must
be rechecked at object entrance, as well as at exit.  

       Many invariant checks can be optimized out by a good compiler.
How well are existing Eiffel compilers doing in this area?

					John Nagle
From: lef@plsparc.UUCP (Lawrence E. Fitzpatrick)
Newsgroups: comp.lang.eiffel
Subject: Re: Semantics of invariants
Date: 17 Dec 92 06:28:09 GMT
Organization: Personal Library Software, Inc.

In article <1992Dec15.213603.16406@bony1.bony.com> richieb@bony1.bony.com (Richard Bielak) writes:
>Is the invariant supposed to be true *ALL* the time, once the object is
>created? 
>

This is rather elegantly defined in the E3 book (p126):

	The invariant specifies properties which any instance of the
	class must satisfy at every instant at which the instance is
	observable by clients.

A simple reading would suggest that in a single threaded executable,
"observable" might be interpreted to mean "when the thread of control is
with the client."  On the other hand, that approach makes some assumptions
that may be invalidated sooner than one might like.  [Remember the 
Macintosh and "32-bit clean".  Apple did say, don't do this, but there
wasn't any penalty at the time!]  I would prefer a more abstract reading.

>If this is so, you can imagine each object having an "invariant-checker"
>running continously on another processor.

Interesting idea, depending on what it does.  Seems that the only time
you need to check invariants is when a state changes.  The cost of
checking it (in some cases) far exceeds the cost of signalling a checker
to check it.  (something about dependency lists springs to mind).  But
then there are the synchronization problems -- by the time the checker
determines a violation, the code being checked has executed another 3
million instructions!

What percentage of a program's operations are instance state changes?
I bet it's not as high as one might think (for most things).
-- 
Regards, lef

Lawrence Fitzpatrick                    Voice:(301)926-1402/Fax:(301)963-9738
Personal Library Software               lef@pls.com
Newsgroups: comp.lang.eiffel