HDTenEightyP/NetNews huggingface dataset:
From: mouli@iris4irit.fr (Richard MOULI)
Newsgroups: comp.lang.eiffel
Subject: Re: repeated inheritance and renaming
Date: 18 Nov 92 22:35:16 GMT

--------------------------------------------------------------------------------
From: ambuj@ucsb.edu (Singh)


I have the following question regarding repeated 
inheritance and renaming in Eiffel.

Suppose I have the following classes:

			class R

			feature
  			  x:integer;
  			  f is do
    			    x := x+1;
  			  end;
			end


class A			class B			class C
inherit			inherit			inherit 
  R redefine f;		  R rename x as xB	  R
feature			end			end
  f is do
    x := x + 2;
  end;
end

			class S
			inherit 
  			  A rename f as fA;
  			  B rename f as fB;
  			  C;
			feature
  			  Create is
    			    do
      			      fB;
      			      io.putint(xB); io.new_line;
    			    end;
			end

Assume that class S is the ``root'' class of the system.
Upon activation of S.create,
I would have expected procedure fB to update xB and
the subsequent print statement to print 1.
However, it seems that fB updates x instead of xB
and 0 is the value printed.
I also find that if S does not inherit from A then the
expected happens and 1 gets printed.
What am I missing?  Is this a problem with the installation
of Eiffel?

Thanks.

Ambuj Singh
Dept. of Computer Science
University of California
Santa Barbara, CA 93106
ambuj@cs.ucsb.edu

--------------------------------------------------------------------------------


I am PhD student and I do all my work whith Eiffel. I have already met some problems with repeated inheritance and renaming. I know this : in the actual implementation of the Eiffel compiler, an object is like an array of fields. That's mean when you reference a field by its name, the compiler translates by the access to the field-number item in the array. In your problem, the field named `x' in the class R is the i_th item of the array and the routine f of the same class uses this number to update the fie




ld `x'.

The renaming and the repeating inheritance of class R through the class A, B and C introduce the duplication of the field `x' of R as fields `x' (from A) and `xB' (from B) and the duplication of the routine `f' of R as routines fA (from A), fB (from B) and f (from R through C). Now you have two fields (`x' and `xB' - two elements in the array) but the routines f, fA, fB which use the field `x' still acces to the same i_th element in the array.

I think if you reverse the inheritance clauses of class A and B, you will have the expected result but the routines f and fA will update also the field `xB'.

May be, you will have what you want by renaming the field `x' of the class B in the inheritance clause of this class in the class S because the compiler will change the number of the item used by the routine fB.

Richard MOULI IRIT-UPS Toulouse (FRANCE)

mouli@irit.fr
Newsgroups: comp.lang.eiffel
From: sakkinen@jyu.fi (Markku Sakkinen)
Subject: Re: Eiffel internals
Keywords: id of the caller..
Organization: University of Jyvaskyla, Finland
Date: Wed, 18 Nov 1992 14:09:05 GMT

In article <Nov.17.18.57.56.1992.26484@paul.rutgers.edu> partha@paul.rutgers.edu (nowhere_man) writes:
>
>I might need this for my work.Suppose class C declares x of class type
>D, creates it and invokes x.m, where m is a method properly defined in
>class D. Now is there any way to find out at the callee (ie in class
>D) the (pointer to the) object of type C that calls the method m?
> ...

Sorry, I am not actually helping you ...

This is not such a bad idea in principle.  At least I myself have
sometimes thought that a facility for the supplier object to know
the identity of its client could be useful at times.
Somebody may even have suggested some mechanism for that in public
(perhaps Mario Wolczko from Manchester University?).

An official client-identification facility would suit Eiffel
particularly well, given that the language already has selective
export declarations (a class may restrict the allowed client classes
for each feature separately).  It should be declared in the feature
declaration, and the routine would then have available an identifier
'Client', similarly to 'Current'.

If the client's identity were automatically available to all features,
it might make sense to have also another identifier, 'External_client',
for the uppermost feature call on the call stack that was made through
a variable, not simply to Current.

Well, a rather loose idea.  Please develop further or shoot it down
(the latter being my own favourite hobby, of course).

----------------------------------------------------------------------
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
----------------------------------------------------------------------
From: paj@uk.co.gec-mrc (Paul Johnson)
Newsgroups: comp.lang.eiffel
Subject: Re: Eiffel internals
Date: 19 Nov 92 09:51:11 GMT
Reply-To: paj@uk.co.gec-mrc (Paul Johnson)
Organization: GEC-Marconi Research Centre, Great Baddow, UK

In article <1992Nov18.140905.23486@jyu.fi> sakkinen@jyu.fi (Markku Sakkinen) writes:

>In article <Nov.17.18.57.56.1992.26484@paul.rutgers.edu> partha@paul.rutgers.edu (nowhere_man) writes:

>>I might need this for my work.Suppose class C declares x of class type
>>D, creates it and invokes x.m, where m is a method properly defined in
>>class D. Now is there any way to find out at the callee (ie in class
>>D) the (pointer to the) object of type C that calls the method m?
>> ...

Whenever I need to do something like this, I make the client an
argument to `m', so the call looks something like

    x.m (Current, foo, bar);

As to how to do it without the extra argument, I think the only way
would be to take a look at the machine stack.  This will involve some
assembly code.  A change to either your Eiffel compiler, your C
compiler or your hardware would break it.

>This is not such a bad idea in principle.

I rather disagree.  If you want an object to know something then you
should tell it explicitly.


Paul.
-- 
Paul Johnson (paj@gec-mrc.co.uk).	    | Tel: +44 245 73331 ext 3245
--------------------------------------------+----------------------------------
These ideas and others like them can be had | GEC-Marconi Research is not
for $0.02 each from any reputable idealist. | responsible for my opinions
Newsgroups: comp.lang.eiffel
From: huebner@PrakInf.TH-Ilmenau.DE (Huebner)
Subject: Re: FAQ ... Eiffel lang description?
Reply-To: huebner@PrakInf.TH-Ilmenau.DE (Huebner)
Organization: Technische Hochschule Ilmenau
Date: Tue, 17 Nov 92 16:27:47 GMT

In article <1992Nov11.073446.13722@Informatik.TU-Muenchen.DE>, behrenss@Informatik.TU-Muenchen.DE (Soenke Behrens) writes:
|> Foo,
|> 
|> apologies for posting a FAQ, but I waited for quite a while and didn't see
|> "answers to FAQ" coming up, and they were not archived here, either. *shrug*
|> 
|> So, question: Where can one get information about the Eiffel language suitable
|> to help in writing a compiler? Are there:
|> - yacc/lex grammars?
|> - test suites?
|> - already-built free compilers?
|> 
|> Etc.
|> 
|> Yours
|> 
|> Soenke

To make it a FAQ-"list" I add another search for:
- a formal syntax description ( or formal specification) of Eiffel

Thanks, Michael


Newsgroups: comp.lang.eiffel
From: butte_ms@pascal.uwlax.edu (Mike S. Butterbrodt S92)
Subject: if then else  strange things..
Organization: University of Wisconsin - La Crosse Computer Science Department
Date: Tue, 17 Nov 1992 16:47:13 GMT

 Gotta neat problem......
 
 For a class we are creating a logic gate simulator.  In one of the gates, we  
toggle the color with
 a mouse down event.  (From Black to Light_gray).  
 
 We are using Postscript commands on a NeXT enviroment, but that should be  
irrelevant for this problem.   
 
 
 My first attempt was ::::
       -- When the gates are initially created      status_color :=  Black;
       
    the mouse_down event method contains this (among other non-related things)
    
               if  status_color = Light_gray then
	           status_color := Black;
	      else
	            status_color := Light_gray;
	        end;	 
	        display;
 This changed the color to Light_gray, but would not change it back on  
successive mouse downs.
 However, this worked.....
 
                if  status_color = Black then
	           status_color := Light_gray;
	      else
	            status_color := Black;
	        end;	 
	        display;

It works now, so I am happy.  But this is very curious.  Any answers???

                                         Mike Butterbrodt,  UW_La Crosse Comp.  
Sci.
From: partha@paul.rutgers.edu (nowhere_man)
Newsgroups: comp.lang.eiffel
Subject: Eiffel internals
Keywords: id of the caller..
Date: 17 Nov 92 23:57:56 GMT
Organization: Rutgers Univ., New Brunswick, N.J.


I might need this for my work.Suppose class C declares x of class type
D, creates it and invokes x.m, where m is a method properly defined in
class D. Now is there any way to find out at the callee (ie in class
D) the (pointer to the) object of type C that calls the method m?

I dont mind calling C routines from eiffel, so it doesn't have to be
an eiffel solution using some exotic(!) library class, all i need is a
handle on the caller at the callee end. It has to be there somewhere
in some stack that keeps the run time state of the eiffel system.. is
it possible at all to sneak around an access that?


Any help is much appreciated.
From: hiran@ee.uts.edu.au (Hiran Wijetilaka)
Newsgroups: comp.lang.eiffel
Subject: Eiffel/s examples wanted
Date: 23 Nov 92 03:38:28 GMT
Organization: University of Technology, Sydney
NNTP-Posting-Host: vivaldi.ee.uts.edu.au

Hi,
Does anyone out there have eiffel/s (eiffel 3) examples, other than those supplied by the manufacturers ??
BTW: eiffel/s is the PC DOS version.

Any help would be appreciated. email is best. I will post  articles to this group if there is sufficient interest.

thanks in advance,
--
hiran

hiran@ee.uts.edu.au
From: Ted.W.Lawson@cm.cf.ac.uk (Ted Lawson)
Newsgroups: comp.lang.eiffel
Subject: Re: "Rename" considered hazardous
Date: 23 Nov 92 21:05:03 GMT
Organization: University of Wales College of Cardiff

In article <1992Nov23.135527.7035@th-ilmenau.RZ.TH-Ilmenau.DE> huebner@PrakInf.TH-Ilmenau.DE (Huebner) writes:
>
>Handling the problem of name conflicts arising from multiple inheritance 
>by renaming could be a nice solution. But it seems that there should be
>some restrictions to ensure the reliability of the produced software.

	(original example omitted for brevity)

>	z.foo(x);   -- o.k.
>	z.foo(y);   -- Error: message "f" not understood by object of Typ B

"It is important to understand that renaming does not change any of the
inherited features, but simply changes the names under which those features
will be known by the _clients_ and _descendents_ of a class." [ETL p 83]

The above error doesn't happen because C is neither a client nor a descendant
of B.

Ted
From: a7657@mindlink.bc.ca (Stephen H. Kawamoto)
Newsgroups: comp.lang.forth
Subject: Re: Hench4th
Date: 15 Nov 92 20:01:09 GMT
Organization: MIND LINK! - British Columbia, Canada

thanks kevin.
 have it upload to mindlink now. am waiting for a unix user to un-tar the
tar.z UUDecode decrypted.

--
Stephen Kawamoto <a7657@mindlink.bc.ca>
    "It is the very mind itself
     That leads the mind astray;
     Of the mind,
     Do not be mindless."
     (an old Japanese folk song)
From: ForthNet@willett.pgh.pa.us (ForthNet articles from GEnie)
Newsgroups: comp.lang.forth
Subject: Searching For Connections
Date: 22 Nov 92 21:04:56 GMT
Organization: EIEI-U

Category 14,  Topic 12
Message 25        Sat Nov 21, 1992
ELLIOTT.C                    at 10:23 EST
 
 -----via CRS Premium Bulletin Board - U
 SR 16.8K Dual Standard  (416) 629-7000

 Date: 11-19-92 (14:00)
   To: RAY DUNCAN
 From: TOM RUST
 Subj: INTERNET

 Do you have an internet address for the BBS? It would be cheaper
 for me to call via internet. Thanks. ---

  * The GrapeVine/Ferret Face BBS * NLR,ARK * 501-753-8121 DS *
  * PostLink(tm) v1.03  GRAPEVINE (#318) : RelayNet(tm) Hub

 CRS Premium Bulletin Board -
 USR 16.8K Dual Standard  (416) 629-7000

 Date: 11-20-92 (00:00)
   To: TOM RUST
 From: RAY DUNCAN
 Subj: INTERNET

 No - we don't have an Internet address at this point, although we
 are thinking about getting an Internet feed.

 NET/Mail : LMI Forth Board, Los Angeles, CA (310) 306-3530
 ---
  * The GrapeVine/Ferret Face BBS * NLR,ARK * 501-753-8121 DS *
  * PostLink(tm) v1.03  GRAPEVINE (#318) : RelayNet(tm) Hub

-----
This message came from GEnie via willett.  You *cannot* reply to the author
using e-mail.  Please post a follow-up article, or use any instructions
the author may have included (USMail addresses, telephone #, etc.).
Report problems to: dwp@willett.pgh.pa.us
From: ForthNet@willett.pgh.pa.us (ForthNet articles from GEnie)
Newsgroups: comp.lang.forth
Subject: Forth based products
Date: 22 Nov 92 21:04:36 GMT
Organization: EIEI-U

Category 4,  Topic 9
Message 52        Fri Nov 20, 1992
ELLIOTT.C                    at 16:02 EST
 
 -----via CRS Premium Bulletin Board -
 USR 16.8K Dual Standard  (416) 629-7000
 Date: 11-18-92 (23:00)
   To: ALL
 From: DON GOLDING
 Subj: WHISKERS

 Whiskers is Forthbot I created that can play songs, hear sounds,
 control both motors similtaneously with different speeds, has
 forth on board ( New Micros), does collision avoidance and has
 whiskers of course.
 Contact : Don Golding Angelus Research 6344
 Sugar Pine Circle #98
 Angelus Oaks, Ca.  92305.
 A fun way to learn Forth.  Only $395.
 ---
    CNet 1.20 25 #15   MetroLink   ROBOT Dawn BBS   (714)538-0614
 V32b
  * The DC Information Exchange (703)836-0748
  * PostLink(tm) v1.03  DCINFO (#16) : MetroLink(tm)

-----
This message came from GEnie via willett.  You *cannot* reply to the author
using e-mail.  Please post a follow-up article, or use any instructions
the author may have included (USMail addresses, telephone #, etc.).
Report problems to: dwp@willett.pgh.pa.us
From: bevan@cs.man.ac.uk (Stephen J Bevan)
Newsgroups: comp.lang.forth
Subject: Re: Experimental Ideas
Date: 18 Nov 92 15:37:12 GMT
Organization: Department of Computer Science, University of Manchester
In-reply-to: ForthNet@willett.pgh.pa.us's message of 14 Nov 92 13:25:43 GMT

In article <4148.UUL1.3#5129@willett.pgh.pa.us> ForthNet@willett.pgh.pa.us (ForthNet articles from GEnie) writes:

    At EuroForth '92 Christophe Lavarenne (`FreeForth') proposed to
    get rid of the Forth interpreter altogether and use a "compile
    buffer" (my interpretation). The idea, which has also been
    proposed by Mitch Bradley and John Hayes (among others), is to
    compile each line typed by the user into a nameless colon
    definition, execute that code and forget it again.

Doesn't this, in essence, describe how STOIC works?
It always _seemed_ a better model to me, but I have to admit I've
never actually tried it.  I keep meaning to hunt around some of the
CP/M archives for it but never seem to get round to it :-<
Of course if somebody has a portable UNIX implementation, that would
be a different matter altogether ...

bevan
From: ForthNet@willett.pgh.pa.us (ForthNet articles from GEnie)
Newsgroups: comp.lang.forth
Subject: From the xCFB's / ForthNet
Date: 17 Nov 92 11:31:53 GMT
Organization: EIEI-U

Category 14,  Topic 2
Message 62        Mon Nov 16, 1992
ELLIOTT.C                    at 16:41 EST
 
 -----via CRS Premium Bulletin Board - USR 16.8K Dual Standard
 (416) 629-7000

 Date: 11-14-92 (21:00)
   To: JACK WOEHR From: JERRY SHIFRIN Subj: XCFB'S

 JW>        ECFB is now Monument BBS in Monument, Colorado. Has
 Forth files, JW>is not listed as a "Forth-oriented" BBS anymore.
 J. Shifrin still in JW>charge.

 And The Monument Board does carry Forthnet!

 JW>        NCFB gone.

 but Don Madson drops by every now and then.

 JW>        BCFB on and off, not sure of current status.

 Jack went off on sabbatical a year or so ago.  He may return one
 day.

 JW>        WCFB is gone, Ray runs the LMI Forth Board exclusively
 now.

 Ray ran the LMI board way before ECFB got started and, to some
 extent, inspired the whole xCFB network

 JW>        RCFB 4 years, 20,000 calls and going strong!

 Congrats, one more year to catch up to ECFB! ---

 Date: 11-15-92 (11:00)
   To: JERRY SHIFRIN From: JACK WOEHR Subj: XCFB'S

 -> JW>        RCFB 4 years, 20,000 calls and going strong! -> ->
 Congrats, one more year to catch up to ECFB!

  The ECFB was a bit different from the RCFB. I suspect that in
 Forth files RCFB has caught up and possibly surpassed the ECFB
 (largely with your help Jerry, thanx!). But in general "stuff"
 and in PCBoard-related features, e.g., DOORs, graphic menus,
 etc., we never went as far in the direction of "full-service" BBS
 as ECFB did. I never wanted to spend the time setting all that
 stuff up!

         Lately we have added two new emphases to the RCFB.

                 1) We have a directory of MS-Windows files. The
                 selection criterion is, "Does it interest SYSOP"
 :-)

                 2) We have a Smalltalk directory and are
 considering a
                 Smalltalk conference.


2
 Incidentally, Ray may have started the xCFB net but it was Jerry
 who taught me, Don, Jack and others how to set up and use the
 software!

                 =jax=

 NET/Mail : RCFB Golden, CO (303) 278-0364 VESTA & Denver FIG for
 Forth! ---
  * The GrapeVine/Ferret Face BBS * NLR,ARK * 501-753-8121 DS *
  * PostLink(tm) v1.03  GRAPEVINE (#318) : RelayNet(tm) Hub  

-----
This message came from GEnie via willett.  You *cannot* reply to the author
using e-mail.  Please post a follow-up article, or use any instructions
the author may have included (USMail addresses, telephone #, etc.).
Report problems to: dwp@willett.pgh.pa.us
From: ForthNet@willett.pgh.pa.us (ForthNet articles from GEnie)
Newsgroups: comp.lang.forth
Subject: Forth on-line resources
Date: 22 Nov 92 21:04:53 GMT
Organization: EIEI-U

Category 14,  Topic 4
Message 160       Sat Nov 21, 1992
ELLIOTT.C                    at 10:23 EST
 
 -----via CRS Premium Bulletin Board -
 USR 16.8K Dual Standard  (416) 629-7000

 Date: 11-20-92 (04:00)
   To: B-LEE [B0B]
 From: RAY DUNCAN
 Subj: FORTH IN PRINT

 Michael Ham's book will be available in a slightly different form
 with the system FIRST/FORTH.  FIRST/FORTH is a shareware version
 of UR/FORTH that is distributed with a subset of the normal
 UR/FORTH files, Mike Ham's teaching files, and the first chapter
 of his book in text file form.  The filename is FIRST4TH.ZIP and
 it is available on the LMI Forth Board, BIX, and several other
 places.

 Those people who register FIRST/FORTH and pay the (small)
 shareware fee receive a spiral-bound copy of Mike Ham's book and
 a discount certificate toward the full UR/FORTH system.

 I am hoping that Mike will modify his book slightly so that it
 will be usable with our new WinForth system but I don't know
 whether he will have time for this in the near future.
 ---
  * The GrapeVine/Ferret Face BBS * NLR,ARK * 501-753-8121 DS *
  * PostLink(tm) v1.03  GRAPEVINE (#318) : RelayNet(tm) Hub

-----
This message came from GEnie via willett.  You *cannot* reply to the author
using e-mail.  Please post a follow-up article, or use any instructions
the author may have included (USMail addresses, telephone #, etc.).
Report problems to: dwp@willett.pgh.pa.us
From: ForthNet@willett.pgh.pa.us (ForthNet articles from GEnie)
Newsgroups: comp.lang.forth
Subject: Graphics, GUIs, and Events
Date: 22 Nov 92 21:04:58 GMT
Organization: EIEI-U

Category 18,  Topic 2
Message 52        Sat Nov 21, 1992
ELLIOTT.C                    at 10:24 EST
 
 -----via CRS Premium Bulletin Board -
 USR 16.8K Dual Standard  (416) 629-7000

 Date: 11-14-92 (21:00)
   To: MIKE HAAS
 From: MARCEL HENDRIX
 Subj: GRAPHICS

 Mike Haas wrote, about Graphics

 mh> As an aside, I think it is interesting that Forth has no mh>
 standard graphics interface, perhaps never will, and one mh> of
 the most popular existing graphics languages is an interactive
 mh> Forth-cousin called PostScript.

 If Postscript weren't so slow, we could run it as a secondary
 process and send ASCII text commands to it.

 Our tForth graphics are handled by a ``library'' sort of
 extension called GRAPHICS.FRT that relies on a driver file for
 physical output. The default driver sends remote calls to our C-
 server via the transputer host link, but it was not very
 difficult to write a driver that translates the calls to
 Postscript and writes that to a diskfile. So I did that(*). It
 depends on the complexity of GRAPHICS.FRT of course, but our
 driver fits into a 5775 byte text file. (I use very short lines
 to plot pixels, because my knowledge of PS is, well, limited.
 Also, I do not know how to handle color yet).

   (*) The slowness is due to the fact that I use GOSCRIPT to
   convert the file to a binary for a HP LaserJet, which I then
   display on my screen with a another Forth program that
   interprets HP LaserJet files and writes them directly to screen
   memory (using very dirty tricks).  What's clearly needed is a
   fast Display Postscript program. Any volunteers :-)


 The only point I want to make is that it is relatively easy to
 have very nice, very high-quality graphics and text in Forth, and
 using existing technology should not be that difficult. The only
 thing needed is a group of knowledgeable people that can write a
 specification of what is needed, preferably layered (must_have,
 low_res, mid_res, high_res, full-ps). I know that some people in
 this newsgroup were working on that a few months ago, but I do
 not know what they finally came up with.

 Marcel Hendrix,          "Wisdom has never been known to enter
      the head through an open mouth"
 Dutch Forth Workshop     -- overheard somewhere.

 NET/Mail : FS FORTH Systeme BBS West Germany ++49 7667 556
 ---
  * The GrapeVine/Ferret Face BBS * NLR,ARK * 501-753-8121 DS *
  * PostLink(tm) v1.03  GRAPEVINE (#318) : RelayNet(tm) Hub

-----
This message came from GEnie via willett.  You *cannot* reply to the author
using e-mail.  Please post a follow-up article, or use any instructions
the author may have included (USMail addresses, telephone #, etc.).
Report problems to: dwp@willett.pgh.pa.us
From: ForthNet@willett.pgh.pa.us (ForthNet articles from GEnie)
Newsgroups: comp.lang.forth
Subject: eForth
Date: 20 Nov 92 11:34:39 GMT
Organization: EIEI-U

Category 7,  Topic 17
Message 60        Thu Nov 19, 1992
ELLIOTT.C                    at 10:07 EST
 
 -----via CRS Premium Bulletin Board -
 USR Dual Standard 16.8K  (416) 629-7000

 Date: 11-16-92 (16:00)
   To: ALL
 From: ROSS BARNES
 Subj: EFORTH

 I downloaded eForth and compiled a definition, but cannot figure
 out how to "FORGET" the definition.  Could someone enlighten me?
 Thank you.

 NET/Mail : RCFB Golden, CO (303) 278-0364 VESTA & Denver FIG for
 Forth! ---
  * The GrapeVine/Ferret Face BBS * NLR,ARK * 501-753-8121 DS *
  * PostLink(tm) v1.03  GRAPEVINE (#318) : RelayNet(tm) Hub


-----
This message came from GEnie via willett.  You *cannot* reply to the author
using e-mail.  Please post a follow-up article, or use any instructions
the author may have included (USMail addresses, telephone #, etc.).
Report problems to: dwp@willett.pgh.pa.us