HDTenEightyP/NetNews huggingface dataset:
From: geoff@flash.bellcore.com (Geoffrey Clemm)
Subject: Re: Assertions for programming design
Followup-To: comp.lang.eiffel
Organization: Bellcore
	<1992Apr6.143103.6335@merlin.hgc.edu>
	<1992Apr15.160124.29431@cis.ohio-state.edu>
Date: 17 Apr 92 10:03:05

In article <1992Apr15.160124.29431@cis.ohio-state.edu> heym@cis.ohio-state.edu (Wayne Heym) writes:
> We can take advantage of existing model-based or axiom-based
> specification languages to provide a complete, abstract specification
> of program behavior.  And we can encourage efforts to establish a
> combination of (1) programming language, (2) specification language,
> (3) sound and complete rules for proving the correctness of a program
> with respect to its specification, and (4) tools for developing and
> machine-checking formal proofs of correctness.

So now you want me to solve every problem three times, once in the programming
language, once in the specification language (this includes every
enhancement made during maintenance), and once in the proof that the
program satisfies the specification.  Even supposing that you are willing
and able to produce all three of these objects, you still need to

- worry about incorrect specifications,
(for many specification lanaguages, it is more likely that there is a bug
in the specification than that there is a bug in the original program)

- and worry about incorrect proofs
(fully "machine-generated" proofs are still a fantasy for large or complex
software.  If you think debugging a program is hard, try debugging a program
proof).

My "return on investment" for this extra effort had better be very high.

And even if you manage to generate and maintain a correct specification and
proof that the program satisfies it, you *still* have to test for violation
of the "assumptions" of the specification and for "usability" (i.e. does
this solution really satisfy the user).

Let me emphasize that I am not arguing against specification technology.
Effective specification technology will gradually increase the power of
executable specifications in programs.  But the "two language/with human-
aided proof of consistency" will always fail the cost/benefit test except
for an extremely small percentage of applications.

Cheers,

Geoff
--
geoff@bellcore.com
Newsgroups: comp.lang.eiffel
From: bouguett@milkbones.cs.colorado.edu (Athman Bouguettaya)
Subject: Eiffel Library and Documentation
Reply-To: bouguett@milkbones.cs.colorado.edu (Athman Bouguettaya)
Organization: University of Colorado, Boulder
Date: Fri, 10 Apr 1992 17:13:23 GMT

I have been using Eiffel for the past year or so.  While I feel it
provides some of the best of object-oriented programming and 
software engineering, I feel the library documentation
is one of the louziest I have ever seen.  It looks like the documentation
process has not carefully been conducted.  I noticed numerous and
numerous discrepancies between the library and its documentation.   One
has to take a look at the lexical and syntactic analyzers to see how
extensive is the discrepancy.  I used these libraries to develop 
an interpreter.  What seemed to be a job that would take at most a week
turned up to take weeks.  The louzy and incorrect documentation was the
primary cause.   I had to check every class in these libraries to make
sure what documentation was correct.  This is unacceptable!!!  I also
had some students use the graphics library to develop a graphical user 
interface.   The problem was the same.   I would like to have your fedback
about other parts that you had a problem with.   BTW, I used Eiffel 2.3.
I hope Eiffel 3.0 corrects these problems.   We ordered this version and we
are still waiting....


-Athman
From: geoff@flash.bellcore.com (Geoffrey Clemm)
Newsgroups: comp.lang.eiffel
Subject: Re: views and dynamic binding
Date: 8 Apr 92 13:21:56 GMT
Organization: Bellcore

In article <Apr.7.18.06.34.1992.29333@aramis.rutgers.edu> partha@aramis.rutgers.edu (a_zombie) writes:
> This is related to the example given in the book (OOS/W Construction, p272).
> The example talks about how to create different 'views' ( in database sense)
> of the same data structure using exports and inheritance:
> It defines a class bank_account with all the procedures but without exporting 
> any, different views like clerk_view,customer_view etc are direct children 
> of the class bank_account with different exports.
> Now suppose in one top level class ( like session) i need to have different
> views of the a same account:
> I am confused about how to do it:
> first of all when i create a new account: should i create a bank_account entity
> or a manager_view entity  or  a customer_view entity? Basically it is not clear
> to me how different views could be refered to the same account object.
> Perhaps reverse assignment attempt will be useful here: create the account as 
> bank_account type and reverse assign to different views.
> Then the routines in session has to  be written in terms of the class 
> type  to which it dynamically binds after the reverse assignment to satisfay 
> static type checking of eiffel.  Is this the correct
> way to do it?  Am I missing some simple things?

I believe the confusion is Meyer's, not yours.  The reverse assignment
operation is not relevant here, since it only provides the ability to assign
an entity with static BANK_ACCOUNT to an entity of static type CLERK_VIEW
if the dynamic type of the object bound to the entity is actually CLERK_VIEW.

I also believe the solution is straightforward: create another type called
INTERNAL_BANK_ACCOUNT, which is a descendent of all the xxx_VIEW classes,
in which a feature is exported if it is exported in *any* of its ancestors.
Then instantiate your bank account as INTERNAL_BANK_ACCOUNT, and everything
should work as desired.

Cheers,

Geoff
--
geoff@bellcore.com
From: partha@lgs.rutgers.edu (a_zombie)
Newsgroups: comp.lang.eiffel
Subject: views,dynamic binding, addendum to my previous posting
Keywords: dynamic binding
Date: 8 Apr 92 01:25:33 GMT
Organization: Rutgers Univ., New Brunswick, N.J.


Continuing on my previous posting, here is the problem that I am facing now,
hope this will be more precise than the other one:

suppose i have a class named ACCOUNT which does not export anything but defines
the following attributes: 
                id:INTEGER
                amt:REAL
  and the routines :
                   set_id(id:INTEGER)
                   set_amt(amt:REAL)
with obvious meaninig.

classes  READ_V and WRITE_V are defined as follows:

class READ_V
  export
         id{READER},amt{READER}
  inherit 
         ACCOUNT
  end


class WRITE_V
  export
         set_id{WRITER},set_amt{WRITER}
  inherit 
          ACCOUNT
  end

-- intention is that 'reading' and 'writing' on ACCOUNT s are to be done by
-- classes READER and WRITER respectively.

Example of a routine is WRITER is as follows:

  set_balance(ac:WRITE_V,amt:REAL) is
        do
           ac.set_amt(amt);
           io.putstring("some message etc ")
        end

Example of a routine in READER is similarly:
  
   read_balance(ac:READ_V):REAL is
         do
            result := ac.amt
          end

Now on the top level class, say  ACCOUNTING, i define the routine 
deposit as follows

class ACCOUNTING
     .....
 feature 
      ....
     deposit(ac:ACCOUNT,amt:REAL) is
         local
              a1:READ_V;
              a2:WRITE_V;
              x,y : REAL;
              r: READER;
              w:WRITER
          -- foreget about efficiency and optimization on some local 
          -- entities
         do
            r.create;
            w.create;
             a1 ?= ac;
             a2 ?= ac;
             x := r.read_balance(a1);
             y:= x+amt;
             w.set_balance(a2,y)
         end
 ....


Now from the static type checking point of view this whole thing should
compile okay. What i want to know here whether read_balance and set_balance 
will work properly on the objects pointed to by a1 and a2 after successful
(suppose deposit will be called with a nonvoid ACCOUNT  actual)reverse
assignment attempt...



There must be other ways to 'view' the same account by the readers and the 
writers... any help? different design of class structures ?





thanks for bearing with me..


--partha
From: fiffi@cs.tu-berlin.de (Carsten Hoehne)
Newsgroups: comp.lang.eiffel
Subject: To Frieder Monninger (SIG)
Date: 13 Apr 92 10:23:04 GMT
Reply-To: fiffi@cs.tu-berlin.de
Distribution: comp
Organization: Technical University of Berlin, Germany

It seems that i have trouble to reach Frieder Monninger by EMAIL. So i
try it this way round. This posting is not of any interest for the rest
of the world.

Hallo Frieder Monniger

Nach der CEBIT in Hannover habe ich mehrmals versucht ueber email
Kontakt aufzunehmen. Bis jetzt habe ich noch kein Anzeichen dafuer
bekommen das meine mails ueberhaupt die TU-Berlin verlassen haben. Daher
bitte ich darum mir doch einmal via Email zu antworten und mir
mitzuteilen ob etwas von mir angekommen ist.

Carsten

-- 
Carsten Hoehne     |  e-mail: fiffi@opal.cs.tu-berlin.de
Hallesches Ufer 28 |          fiffi@tubopal.UUCP
1000 Berlin 61     |            ...!{unido,pyramid}!tub!opal!fiffi
-------Germany     |          fiffi%tubopal@DB0TUI11.BITNET
From: boelhouw@wsooti06.info.win.tue.nl (Erik Boelhouwer)
Newsgroups: comp.lang.eiffel
Subject: Message to Interactive Software Engeneering
Date: 13 Apr 92 13:26:13 GMT
Reply-To: boelhouw@info.win.tue.nl

Hello,

I have some problems with the Eiffel-compiler (version 2.3).
Sometimes, pass 2 does not terminate for certain classes. When I restart the
compiler, the system continues compilation with pass 3.

The second problem, which might have something to do with the first, allthough
I'm sure it is not the only cause, occurs in pass 4 of the compilation process.
The compiler tells me the following :

  pass 4 : space_alloc : size > BLOCK_SIZE
           please contact Interactive Software Engeneering 

Well,....  I would like to know what might have caused this errors :

- Are there to many features in my classes ?
- Are there to many nested object references in my classes ?
- What exactly does "pass 2"


Please contact me , in order to prevent decrement in the progress of my
graduation project ,

Erik Boelhouwer
T.U. Eindhoven
The Netherlands
e-mail : boelhouw@info.win.tue.nl
Newsgroups: comp.lang.eiffel
From: ogden@seal.cis.ohio-state.edu (William F Ogden)
Subject: Re: LISTS and CURSORS - a design question
Organization: The Ohio State University, Department of Computer and Information Science
Date: Mon, 13 Apr 1992 15:50:12 GMT

In article <1992Apr10.161652.22797@jarvis.csri.toronto.edu> tarvydas@turing.toronto.edu (Paul Tarvydas) writes:

>Here's another possible way to think about your CURSORS problem.
   ...
>Smalltalk conquers the CURSOR problem by defining little cursor
>barnacles called "streams".  Streams are stand-alone, encapsulated
>cursors which know how to walk through a given data structure while
>returning each successive item.  Each container data structure is
>capable of (creating and) returning a stream on itself.  Stream
>objects are independent of the container objects which they can
>traverse, hence, you can have as many concurrent streams on a
>particular object as you wish.
   ...

The STREAM does seem like an improvement over the CURSOR, but it too
has its problems. They become clear if you try to pin down precisely
what the generic stream is supposed to do. Should, for example, the
structure and content of the underlying data structure be frozen when a 
stream is created so that the stream produces a predictable fixed sequence
of items? Alternatively, should the results returned by the stream attempt
to track the changes induced in the content and form of the underlying data
structure by its other operators? (E.g. Do you want to concoct an elaborate
enough description of a stream attached to a tree to explain what happens
when say a subtree which it is in the midst of traversing gets grafted onto
another tree? Or even when the subtree gets moved to a different place in
the same tree?) The first choice here entails a serious copying cost, while
the second involves a truely hairy semantics for streams.

Also, you still have a messy problem when the Item and Replace commands
from different concurrent streams collide (just as you do for cursors). 

/Bill
-- 

/Bill

Newsgroups: comp.lang.eiffel
From: geoff@flash.bellcore.com (Geoffrey Clemm)
Subject: Re: Formatting strings (was: Bad interaction between Eiffel 3 strings and SCCS)
Organization: Bellcore
	<TYNOR.92Mar20100242@hydra.gatech.edu> <65@eiffel.eiffel.com>
	<GEOFF.92Mar24091844@wodehouse.flash.bellcore.com> <363@alfrat.uucp>
	<1992Mar27.090938.3147@cs.rug.nl> <364@alfrat.uucp>
Date: 6 Apr 92 11:35:05

In article <364@alfrat.uucp> roy@alfrat.uucp (Roy Phillips) writes:
    Au contraire: I think the compiler should keep it's hands off the content
    of strings *completely*, and just pass them on to classes that contain
    knowledge of what to do with the contents, in Eiffel that should be class
    STRING.  This would leave the system open to any possible future extensions,
    such as Internationalisation Standards.

Let me try this one more time (I noticed Roy chose not to respond to an earlier
posting indicating the inherent fallacy in his reasoning :-).

*WHAT* is the compiler going to pass to the classes ?

my_routine("arg1\", arg2, \"arg3");

Is it passing one constant string argument, or <a constant string, the value
associated with arg2, and another constant string> ?

Attempting to ignore the distinction between character escapes in strings
and format control characters in strings is absurd.

Cheers,

Geoff
--
geoff@bellcore.com
Newsgroups: comp.lang.eiffel
From: ian@syacus.acus.oz.au (Ian Joyner)
Subject: C++ Critique in comp.lang.c++
Organization: ACUS Australian Centre for Unisys Software, Sydney
Date: Wed, 8 Apr 1992 12:00:57 GMT

Thank you to those who replied to my please reply. It proved that the other
message I sent with default distribution did not get through, and hence my
C++ critique had not reached a wide audience. I have now posted this in
comp.lang.c++. This should give a good basis for the comparison of
Eiffel and C++.
-- 
Ian Joyner                                     ACSNet: ian@syacus.acus.oz
ACUS (Australian Centre for Unisys Software)   Internet: ian@syacus.acus.oz.au
Tel 61-2-390 1328      Fax 61-2-390 1391       UUCP: ...uunet!munnari!syacus.oz
Newsgroups: comp.lang.eiffel
From: geoff@flash.bellcore.com (Geoffrey Clemm)
Subject: Re: Bad interaction between Eiffel 3 strings and SCCS.
Organization: Bellcore
	<GEOFF.92Mar24091844@wodehouse.flash.bellcore.com>
	<1992Mar26.230507.1598@enea.se>
Date: 6 Apr 92 11:25:22

In article <1992Mar26.230507.1598@enea.se> sommar@enea.se (Erland Sommarskog) writes:

> But I can agree that it is not a very good idea of having percent
> as an escape character. But it's not the percent sign which is
> wrong, it's the notion of an escape character. All you really
> need is a mechanism to include the string delimiter in the string,
> and there is an easy way out: double the string delimiter. That's
> the way the vast majority of languages do.

Ah, finally the "real" reason for voting against '\'.

So what is your proposal for including non-printing characters in strings ?
Surely you are aware that including the string delimiter is the least
significant reason for introducing an escape character.

So far, the only reasons I have seen against using '\' are:

* it doesn't print nicely on my terminal
* I don't like it

These reasons are to be weighed against the need for a common escape
character, the existence of a large number
of language processing tools that currently understand '\', and the 
non-existence of a significant number of language processing tools that
understand a non-`\' escape character.

I'll post the results of the vote for and against '\' by the
eiffel newsgroup community at the end of this week.

Cheers,

Geoff
--
geoff@bellcore.com
From: deutsch@SMLI.Eng.Sun.COM (L. Peter Deutsch)
Newsgroups: comp.lang.eiffel
Subject: Re: LISTS and CURSORS - a design question
Date: 13 Apr 92 21:49:03 GMT
	<1992Apr13.155012.28046@cis.ohio-state.edu>
Organization: Sun Microsystems Laboratories Inc.
NNTP-Posting-Host: luxembourg.eng.sun.com
In-reply-to: ogden@seal.cis.ohio-state.edu's message of 13 Apr 92 15:50:12 GMT

> Should, for example, the structure and content of the underlying data
> structure be frozen when a stream is created so that the stream produces a
> predictable fixed sequence of items?
> ... [this] choice here entails a serious copying cost ...

The bookkeeping for doing copy-on-write is much less than the actual cost
of the copy, so if there aren't any read/write collisions, you never make
the copy; if there *is* a read/write collision, it may still be possible to
copy incrementally.  I, for one, would rather pay the cost to have
well-defined semantics than implementation-dependent happenstance.

> Also, you still have a messy problem when the Item and Replace commands
> from different concurrent streams collide (just as you do for cursors). 

Taking a leaf from data bases: reading should create a virtual copy, but
writing should be exclusive.
From: steven@monu6.cc.monash.edu.au (Steve Stergakis)
Newsgroups: comp.lang.eiffel
Subject: INFO NEEDED on OOA Methodologies
Date: 8 Apr 92 09:37:18 GMT
Organization: Monash University, Caulfield Campus


NOTE: this message has been posted for persons that either use, teach 
or have some opinion regarding current OOA methodologies being 
used...

THIS MESSAGE HAS BEEN CROSS POSTED TO MANY NEWS GROUPS.  PLEASE 
DISREGARD IT IF HAS BEEN POSTED TO AN INCORRECT AREA.

i am a postgraduate student who is currently studying OOA and 
would greatly appreciate any information regarding experience
you have had with object oriented methodologies

as i am about to write a critical review of the current OO methodologies i 
would appreciate if you could tell me which approach you prefer.. or if
you know of any article that have compared current OOA methods, that would
also be greatly appreciated...

i am especially interested in persons who use such methodologies 
in practice.. their extent of their use in your work area.. 
the type of work you do.... and your opinion!

PLEASE feel free to comment on any of the above questions.. if you do
not wish to relate specific information pertaining to your work /
work environment, then leave it out

NOTE: if possible please reply directly to me 

thanks in advance

+------------------------------------------------------------+
| Steven Stergakis      steven@monu6.monash.cc.edu.au        |
|                                                            |
|                       (Post Graduate)                      |
|                       Faculty of Computing and Information |
|                       Technology                           |
|                                                            |
|                       Monash University - Australia        | 
+------------------------------------------------------------+
Newsgroups: comp.lang.eiffel
Subject: Recompiling clients
From: Chris_Sullivan@kcbbs.gen.nz (Chris Sullivan)
Date: 17 Apr 92 12:54:51 GMT
Organization: Kappa Crucis Unix BBS, Auckland, New Zealand

I'm interested in the recompilation requirements of Eiffel.
Can anyone answer two questions I have :-
 
Say I write a class library in Eiffel and release it to customers.
Customers write client classes using classes in my class library.
At a later date I make some changes to the class library and release a
new version.  Does the new version require recompilation of customers'
existing client code?
 
(1)  If I only change the (private) implementation inside classes
of my class library, I expect Eiffel client classes won't require
recompilation.  Am I correct?
 
(2)  If I add some new exported methods to some classes in my class 
library, does Eiffel require recompialtion of client code, even 
though the interface is otherwise unchanged?  IE the interface has 
had new methods added to it without changing anything in the 
original interface.
 
Thanks.
From: gmaughan@monu6.cc.monash.edu.au (Glenn Maughan)
Newsgroups: comp.lang.eiffel
Subject: LaTeX style for Eiffel code
Date: 8 Apr 92 01:13:46 GMT
Organization: Monash University, Caulfield Campus

Does anyone know of a LaTeX style sheet for formatting Eiffel code.

I would like it to adhere to the standards set out in OOSC (Meyer). 
That is, keywords highlighted, comments lighlighted with arguments in
italics, etc.

If anyone finds one could you email it me?

Thanks,

Glenn Maughan
email: gmaughan@monu6.monash.edu.au

-- 
Glenn Maughan
Software Development Honours
email: gmaughan@monu6.monash.edu.au
From: gmaughan@monu6.cc.monash.edu.au (Glenn Maughan)
Newsgroups: comp.lang.eiffel
Subject: persistence
Date: 8 Apr 92 01:10:09 GMT
Organization: Monash University, Caulfield Campus

I am currently researching Persistence programming for an Honours
degree at Monash University.  My thesis will be examining persistent
environments and their implementations.  

The implementations I have looked at at this stage are compiler based
such as E and PS-Algol.  Any information/experience you may have on 
persistence would be greatly appreciated.

I aim to implement a complete orthogonal persistent environment in Eiffel
(Version 3...when it arrives!).  The environment will be an extension and 
possibly generalisation of STORABLE and ENVIRONMENT.  Any comments on the
use of these classes would be appreciated also.

Regards,
Glenn Maughan
email: gmaughan@monu6.monash.edu.au

-- 
Glenn Maughan
Software Development Honours
email: gmaughan@monu6.monash.edu.au
Newsgroups: comp.lang.eiffel
From: partha@living.rutgers.edu (stranger in a strange land)
Newsgroups: comp.lang.eiffel
Subject: Re: views,dynamic binding, addendum to my previous posting
Keywords: dynamic binding
Date: 8 Apr 92 14:04:19 GMT
Organization: Rutgers Univ., New Brunswick, N.J.

sorry folks,please ignore my previous posting, my understanding of
reverse assignment attempt was incorrect and the example i tried to
build with read_v write_v and reverse assignments are simply WRONG.

However I would like to know the answer to the question i asked in the
first posting ( different views of same BANK_ACCOUNT as posed in Dr.
Meyer's book)... 

How about the following class structure:
 
                      BANK_ACCOUNT {no export, only definition}



CLERK_VIEW                 CUSTOMER_VIEW       MANAGER_VIEW

     
                    
                                   COMMON_VIEW



3 classes in 2nd row are each child of BANK_ACCOUNT,
COMMON_VIEW is child of all the three views above it, and in the top
level class like a session, accounts are created and passed around as 
common_view objects..


sorry about my previous posting and thanks for your helps..

--partha
Newsgroups: comp.lang.eiffel
From: ian@syacus.acus.oz.au (Ian Joyner)
Subject: Please reply II
Organization: ACUS Australian Centre for Unisys Software, Sydney
Date: Tue, 7 Apr 1992 03:35:20 GMT

I am sending this message to our 'world' distribution list. Please reply,
if you can see this outside of Australia. Thanks

-- 
Ian Joyner                                     ACSNet: ian@syacus.acus.oz
ACUS (Australian Centre for Unisys Software)   Internet: ian@syacus.acus.oz.au
Tel 61-2-390 1328      Fax 61-2-390 1391       UUCP: ...uunet!munnari!syacus.oz