HDTenEightyP/NetNews huggingface dataset:
From: knight@mrco.carleton.ca (Alan Knight)
Newsgroups: comp.object
Subject: Re: Passing functions as parameters in an OO environment
Date: 30 Sep 92 15:13:19 GMT
Reply-To: knight@mrco.carleton.ca (Alan Knight)
Organization: Carleton University

In <1992Sep29.090923.13282@jyu.fi> sakkinen@jyu.fi (Markku Sakkinen) writes:

>In article <knight.717521079@cunews> knight@mrco.carleton.ca (Alan Knight) writes:
>>In <1992Sep23.080013.19249@jyu.fi> sakkinen@jyu.fi (Markku Sakkinen) writes:
>>
>>>But C++ is a highly hybrid language.  It also has things like
>>>pointer arithmetic, which is extremely contrary to object orientation.
>>>In more purely OO languages, procedures typically cannot be used as
>>> ...

>All right, since Smalltalk is the best-known purely OO language,
>'typically' was perhaps out of place! (*)
>CLOS obviously is a hybrid language if any, and so is Simula
>(which does allow procedures as parameters, like Algol 60 on which
>it was based).  Eiffel certainly does not allow it;  I don't remember
>about Trellis/Owl (tm), DEC's strongly typed, purely OO language.
>The other DEC language, Modula-3, allows procedures as parameters,
>but its main goal was not object orientation in the first place.

>(*) However, I don't count passing a method _name_ as at all equivalent
>to passing a procedure, because method binding is always fully dynamic
>in Smalltalk.  Even the "pointers to member functions" in C++ are not
>exactly equivalent to procedure values (or pointers) if the member function
>(method) pointed to is virtual.

Passing a method name or a member function pointer isn't exactly the
same as passing a function pointer in C, but I would argue that it's
what you usually want in an OO language. As I see it, the purpose of
function arguments is higher-order programming, and it doesn't seem to
be inhibited by having the appropriate method automatically looked up
for you. In Smalltalk, even though the block itself is fixed,
everything that is done in the block relies on dynamic lookup, just
like everything else in the language.
  The advantage of blocks over method names is that you can construct
blocks on the fly, like anonymous functions in LISP or other
functional languages.
-- 
 Alan Knight  knight@mrco.carleton.ca  +1 613 788 2600x5783   Join
 Dept. of Mechanical and Aerospace Engineering                the
 Carleton University, Ottawa, Ontario, Canada, K1S 5B6        LPF
Xref: sparky comp.object:3784 comp.lang.smalltalk:1977 comp.lang.eiffel:1199
From: Bob Hathaway <objsys@netcom.com>
Subject: Re: FAQ list
Date: Sun, 27 Sep 92 07:03:54 GMT
Organization: Object Systems

In article <1992Sep25.172042.13247@msuinfo.cl.msu.edu> czerny@doberman.cps.msu.edu (Barbara Czerny Dr. Ni) writes:
>Where is the FAQ list for this group found?
>I have not seen it on news.answers or at pit-manager.mit.edu.

I'm working on one with a little help but I wish I had more time to devote
to it.  So, sorry, it may be a while.

bob
objsys@netcom.com
Newsgroups: comp.object
From: burchard@horizon.math.utah.edu (Paul Burchard)
Subject: Re: comparing object-oriented platforms
Organization: University of Minnesota
Date: Tue, 6 Oct 1992 10:11:57 GMT

In article <TMB.92Oct5225510@arolla.idiap.ch> tmb@arolla.idiap.ch (Thomas M.  
Breuel) writes:
> Milner-style polymorphism is roughly what you get with C++ templates.
> That is, you can write code that works with any consistent combination
> of types, values, functions, and "methods".
> 
> [rest of explanation deleted...]

Thank you for the explanation....

The useful part of this style of polymorphism would seem to be the ability to add functionality to classes, with type checking, independent of the hierachy (rather than just declaring the existence of functionality, as protocols do).

This sort of "parametric polymorphism" would be implemented in Objective-C using another one of its simple but versatile constructs---namely by adding absolutely identical "categories" of methods to the base classes desiring the extra functionality.  (A "category" is nothing but a set of implemented methods for a class; the point though is that a category may be compiled separately from the class itself; the source code for the original class is not required.  Category methods are inherented just like ordi

nary methods.)

On a slightly different note, one thing that seems to concern a lot of the proponents of strong compile-time type-checking is the mysterious, elusive nature of the errors which can occur with incorrectly typed data.  While this is true of languages like C++ which merely provide a front for structure pointers whose type cannot be verified at run time, it is not true of OOP languages with run-time binding which by necessity maintain type info at run time (e.g. in Obj-C, the first instance var of every object

 is its class).  If I go wild and send messages to the wrong types of objects, I don't get a memory violation or corrupted data, but rather the helpful message

	Button does not respond to selector -wowCheckThis:outMan:

Of course, this still aborts the program, but at least there's some belated type checking going on here.

--
--------------------------------------------------------------------
Paul Burchard	<burchard@geom.umn.edu>
``I'm still learning how to count backwards from infinity...''
--------------------------------------------------------------------
From: schramm@bigfoot.first.gmd.de (Andreas Schramm)
Newsgroups: comp.lang.eiffel
Subject: Re: Re: What about allowing "old" expressions in "rescue" clauses?
Date: 6 Oct 92 12:22:37 GMT
Organization: GMD-FIRST, Berlin


In article <2037@snap> paj@uk.co.gec-mrc (Paul Johnson) suggested to
extend the semantics of "old" over entire expressions and to allow
"old" expressions also in routine bodies:

>                           [...]  .  I can see where it could make the
> bodies of some routines clearer as well, saving the programmer from
> having to declare a local variable such as `old_foo'.  It also removes
> an ugly special case operator from the language, giving it the same
> validity as any other unary operator.

I take a different point of view:

An "old foo" expression is just a shortcut for the use of a local
variable "old_foo" plus its proper declaration and initialization at
the beginning of the routine body.
This leads to the following criteria w.r.t. "old" expressions:

* Does one want the expression of axiomatic specifications (e.g. postconditions)
  --and possibly of other stuff like e.g. exceptions--
  to be dependent on routine bodies?
* Does one want to clutter up a routine body with statements like
  "old_foo := foo" for purposes which are not the routine body's?

As for postconditions, the answer is obvious:  Axiomatic specification
should be possible without recourse to the routine body, whose purpose
after all is to obey the specification and not to define it.
Therefore, "old" expressions are appropriate in postconditions.

As for routine bodies themselves, the situation is different.  Allowing
"old" expressions here would only provide a shortcut for a special
case, thus it would actually complicate the language.  Such a decision
would have to be carefully weighed.

As for exceptions, their role is somewhat unclear, at least to me.
Should they be considered as a part of the algorithm, so that routine
bodies can be burdened with preparatory work for them, or are they
something different?

Also take into account that exceptions and the retry instruction
add something like a backtracking concept to the language.
Thus, the question may also be stated as:  Should preparatory work for
backtracking have to be expressed explicitly?

BTW, was the expression of genuine backtracking among the intended uses
of exceptions and retry?

Andreas Schramm
(schramm@first.gmd.de)
From: schramm@bigfoot.first.gmd.de (Andreas Schramm)
Newsgroups: comp.lang.eiffel
Subject: What about allowing "old" expressions in "rescue" clauses?
Date: 28 Sep 92 14:10:16 GMT
Organization: GMD-FIRST, Berlin

The subject line already says it all.

To my knowledge, "old" expressions are currently restricted to
postconditions ("ensure" clauses).

As the purpose of a "rescue" clause is to re-establish a consistent
state (viz. class invariant) from a potential mess, it seems to be
natural to provide a convenient facility to access the values of
attributes they had at the entry of the failing routine.

Just an idea.

Andreas Schramm
(schramm@first.gmd.de)
Newsgroups: comp.lang.eiffel
From: sakkinen@jyu.fi (Markku Sakkinen)
Subject: Re: What about allowing "old" expressions in "rescue" clauses?
Organization: University of Jyvaskyla, Finland
Date: Tue, 29 Sep 1992 08:42:44 GMT

In article <2400@bigfoot.first.gmd.de> schramm@bigfoot.first.gmd.de (Andreas Schramm) writes:
> ...
>To my knowledge, "old" expressions are currently restricted to
>postconditions ("ensure" clauses).
>
>As the purpose of a "rescue" clause is to re-establish a consistent
>state (viz. class invariant) from a potential mess, it seems to be
>natural to provide a convenient facility to access the values of
>attributes they had at the entry of the failing routine.
> ...

Unfortunately, this looks completely unfeasible in the general case.
Simply think about the case where the object originally pointed to by
an attribute is deleted before the exception happens --
the "old" value would be garbage.
The suggestion could be applied to attributes having expanded types
(which contain no references).

How is the above kind of problem situation actually handled in a
postcondition?  I would suppose that trying to access a no more
extant object through an "old" attribute causes a postcondition
violation.

----------------------------------------------------------------------
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: rick@tetra.co.uk (Rick Jones)
Newsgroups: comp.lang.eiffel
Subject: Re: What about allowing "old" expressions in "rescue" clauses?
Date: 30 Sep 92 11:58:59 GMT
Organization: Tetra Ltd., Maidenhead, UK

In article <1992Sep29.084244.11675@jyu.fi> sakkinen@jyu.fi (Markku Sakkinen) writes:
>In article <2400@bigfoot.first.gmd.de> schramm@bigfoot.first.gmd.de (Andreas Schramm) writes:
>> ...
>>As the purpose of a "rescue" clause is to re-establish a consistent
>>state (viz. class invariant) from a potential mess, it seems to be
>>natural to provide a convenient facility to access the values of
>>attributes they had at the entry of the failing routine.
>> ...
>
>Unfortunately, this looks completely unfeasible in the general case.
>Simply think about the case where the object originally pointed to by
>an attribute is deleted before the exception happens --
>the "old" value would be garbage.

In Eiffel objects are never "deleted", they are simply detected as
unreferenced by the GC and reclaimed.  To implement "old" the run-time
code merely has to keep a copy of the relevant attribute values at
entry to a routine.  If such an attribute is a reference, and the real
attribute drops the reference in the routine code, the copy still holds
the reference preventing it being garbaged.  At routine exit the copy
attribute is removed from scope, so it no longer holds the referenced
object.

The main practical problem I see of implementing this in a rescue clause
would be the need to make a copy object on every routine entry, since
the compiler would not know when the rescue clause would be needed.
With postconditions only the attributes named as "old" in the relevant
postcondition need to be copied.

-- 
Rick Jones, Tetra Ltd.  Maidenhead, Berks, UK		rick@tetra.co.uk

Any fool can provide a solution - the problem is to understand the problem
From: jcm@hgc.edu (James McKim)
Subject: Re: Eiffel Quickie!
Organization: The Hartford Graduate Center
Date: Fri, 25 Sep 1992 13:06:19 GMT

In article <6450@otc.otca.oz> alexk@otc.otca.oz.au (Alex Kowalenko) writes:
>How do you make an INTEGER into a STRING?
>
>-- 
>
>    Alex Kowalenko                 ACSnet: alexk@otc.otca.oz
>    R&D Contractor                   UUCP: {uunet,mcvax}!otc.otca.oz!alexk
>    |||| OTC ||                       Fax: +6 2 287 3299
>                                    Phone: +6 2 287 3131
>                                    Snail: GPO Box 7000, Sydney 2001, Australia


Assuming you're working with the ISE version, you call the to_string
routine from class BASIC.

Hope this helps,

-- Jim
-- 

*------------------------------------------------------------------------------*
Jim McKim  (203)-548-2458     In exactly 3.2 seconds it will be a few 
Internet:  jcm@hgc.edu   minutes to 5:00.
Newsgroups: comp.lang.eiffel
From: ctaylor@sparc7.cs.uiuc.edu (Conrad W Taylor)
Subject: Eiffel 3.0 for the PC...?
Organization: University of Illinois at Urbana-Champaign
Date: Sun, 27 Sep 1992 00:01:43 GMT

         Is there an Eiffel 3.0 compiler implemented for the PC?  If so,
could someone e-mail all the important info for purchasing the compiler?

Thanks in advance to all that reply to this post.

-Conrad

ps: My e-mail is ctaylor@silver.lcs.mit.edu or
    u21749@uicvm.uic.edu.
Newsgroups: comp.lang.eiffel
Subject: Re: Eiffel 3.0 for the PC...?
From: Des.Kenny@bbs.actrix.gen.nz
Date: Tue, 29 Sep 1992 10:51:40 GMT
Organization: Actrix Information Exchange

In article <1992Sep27.000143.16378@sunb10.cs.uiuc.edu> ctaylor@sparc7.cs.uiuc.edu (Conrad W Taylor) writes:
>          Is there an Eiffel 3.0 compiler implemented for the PC?  If so,
> could someone e-mail all the important info for purchasing the compiler?
> 
> Thanks in advance to all that reply to this post.
> 
> -Conrad
> 
> ps: My e-mail is ctaylor@silver.lcs.mit.edu or
>     u21749@uicvm.uic.edu.
> 
 
In the US contact Interactive Software : Darcy@eiffel.com
in Europe contact SIG : fm@sigcomp.sub.org

 



Newsgroups: comp.lang.eiffel
From: hoelzle@Xenon.Stanford.EDU (Urs Hoelzle)
Subject: Re: Self for Windows 3.x and PC...?
Organization: CS Department, Stanford University, California, USA
Date: 28 Sep 92 22:12:19 GMT

ctaylor@sparc7.cs.uiuc.edu (Conrad W Taylor) writes:

>         Are there any implementations of the Self programming
>language for Windows 3.x and PC?  Also, are there any books/intro
>for the language?  Thanks in advance for all that reply to this
>post.

Unfortunately, there's no x86 version of Self, and no book.  However,
you can get lots of information (including papers about the language
and the current system incl. manuals) via anonymous ftp from
self.stanford.edu.

-Urs

----------------------------------------------------------------------------
Urs Hoelzle                                              urs@cs.stanford.EDU
Computer Systems Laboratory, CIS 57, Stanford University, Stanford, CA 94305
From: Roger_Alexander@rock.intersolv.com
Newsgroups: comp.lang.eiffel
Subject: Grammar for Eiffel 3
Date: 30 Sep 92 19:01:00 GMT


          Does anyone know if there is there a grammar available
          (preferably via ftp) for Eiffel version 3 ?  If not 3, then
          perhaps 2.3 ?

          Please respond to roger_alexander@intersolv.com

          Thanks,

          Roger Alexander
          INTERSOLV
From: fm@irau36.ira.uka.de (GI-member Fm)
Newsgroups: comp.lang.eiffel
Subject: Re: eiffel ported to PC
Date: 2 Oct 1992 12:09:44 GMT
Organization: University of Karlsruhe, FRG
Distribution: comp
NNTP-Posting-Host: irau36.ira.uka.de

why do you not use Eiffel/S on your PC ?
150 classes - you will need the development license for
US$ 398 and a good 32 bit c compiler (zortech, watcom or gnu)

frieder monninger  fm @sigcomp.sub.org
Newsgroups: comp.lang.eiffel
From: sakkinen@jyu.fi (Markku Sakkinen)
Subject: Re: What about allowing "old" expressions in "rescue" clauses?
Organization: University of Jyvaskyla, Finland
Date: Thu, 1 Oct 1992 14:22:14 GMT

In article <1552@tetra.co.uk> rick@tetra.co.uk (Rick Jones) writes:
>In article <1992Sep29.084244.11675@jyu.fi> sakkinen@jyu.fi (Markku Sakkinen) writes:
>>In article <2400@bigfoot.first.gmd.de> schramm@bigfoot.first.gmd.de (Andreas Schramm) writes:
>>> ...
>>>As the purpose of a "rescue" clause is to re-establish a consistent
>>>state (viz. class invariant) from a potential mess, it seems to be
>>>natural to provide a convenient facility to access the values of
>>>attributes they had at the entry of the failing routine.
>>> ...
>>
>>Unfortunately, this looks completely unfeasible in the general case.
>>Simply think about the case where the object originally pointed to by
>>an attribute is deleted before the exception happens --
>>the "old" value would be garbage.
>
>In Eiffel objects are never "deleted", they are simply detected as
>unreferenced by the GC and reclaimed.  To implement "old" the run-time
>code merely has to keep a copy of the relevant attribute values at
> ...

Well, of course!  The total absence of explicit deletion has its
advantages, although on the other hand it makes it more difficult
to simulate real-world objects.

A similar problem remains, however:  objects pointed to by the old attributes
may have been _modified_, and there is no way to restore all relevant state
to what it was at entrance.
Perhaps the suggested feature would be nice in many situations
in spite of this restriction.

----------------------------------------------------------------------
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: ctaylor@sparc7.cs.uiuc.edu (Conrad W Taylor)
Subject: Self for Windows 3.x and PC...?
Organization: University of Illinois at Urbana-Champaign
Date: Sun, 27 Sep 1992 00:34:12 GMT

         Are there any implementations of the Self programming
language for Windows 3.x and PC?  Also, are there any books/intro
for the language?  Thanks in advance for all that reply to this
post.

-Conrad

ps: My e-mail is ctaylor@silver.lcs.mit.edu or
    u21749@uicvm.uic.edu.
From: arleth@iesd.auc.dk (Tom Arleth)
Newsgroups: comp.lang.eiffel
Subject: eiffel ported to PC
Date: 29 Sep 92 10:26:16 GMT
Distribution: comp
Organization: Mathematics and Computer Science, Aalborg University

Does anyone have experience with porting the C-package to a DOS-PC, or alternativly knowlege about a PC-version of eiffel capable of handling app. 150+ classes? If so i would very mutch like to hear from you.

e-mail address:arleth@iesd.auc.dk
From: Markus_Klingspor@wue.maus.de (Markus Klingspor)
Newsgroups: comp.lang.eiffel
Subject: like current
Date: 4 Oct 92 12:09:00 GMT
Article-I.D.: WUe.A2083
Organization: MausNet
X-Gateway: MausGate/News 1.13

Provided I have a class tA defined as:
class tA
creation
        make
feature
        io: BASIC_IO;
        x: integer;
        make is
          do
            !!io;
            x := 1;
          end; -- make
        print is
          do
            io.put_string("x="); io.put_int(x); io.put_newline;
          end; -- print
        tst(t: tA): like current is
          do
            result := t;
          end; -- tst
end; -- class tA

and a class tB which inherits from tA defined as:
class tB
inherit tA
?redefine make, print;
?end;
creation
        make
feature
        y: integer;
        make is
          do
            !!io;
            x := 11; y := 12;
          end; -- make
        print is
          do
            io.put_string("x="); io.put_int(x); io.put_newline;
            io.put_string("y="); io.put_int(y); io.put_newline;
          end; -- print
end; -- class tB

What will be the output of the following:
        !!A; -- of type tA
        !!B; -- of type tB
        B.tst(A).print;

With SIG/Eiffel (which is the only compiler I have) I get erroneous output.
Is this a compiler bug or a problem of the language specification.

- Markus
------------------------------------------------------------------------------
Markus Klingspor Internet: mk@wue.maus.de
Gerbrunn                or klingspo@informatik.uni-wuerzburg.dbp.de
Germany          UUCP:backbone_that_knows_domains!wue.maus.de!mk
                 Fido: Markus_Klingspor%maus wue, 2:242/2.6
From: paj@uk.co.gec-mrc (Paul Johnson)
Newsgroups: comp.lang.eiffel
Subject: Re: What about allowing "old" expressions in "rescue" clauses?
Date: 2 Oct 92 11:17:21 GMT
Reply-To: paj@uk.co.gec-mrc (Paul Johnson)
Organization: GEC-Marconi Research Centre, Great Baddow, UK

In article <1552@tetra.co.uk> rick@tetra.co.uk (Rick Jones) writes:

[Commenting on the use of `old' in rescue clauses]

>The main practical problem I see of implementing this in a rescue clause
>would be the need to make a copy object on every routine entry, since
>the compiler would not know when the rescue clause would be needed.
>With postconditions only the attributes named as "old" in the relevant
>postcondition need to be copied.

I don't see the problem here.  If you have an expression in the code
such as

	old (foo.bar.baz(5))

then that refers to the value of the expression when the routine is
entered.  Hence the compiler should include code to compute this at
the routine entry point (rather than at the position where the
expression is used).  Doing a deep clone of `foo' in the example above
would be one way, but it would be inefficient.  Also the following
expression:

	(old (foo.bar.baz(5))).boing

should return the current value of the `boing' feature of the object
referred to by the old value of `foo.bar.baz(5)'.  A deep clone would
return the wrong value in this case.

I think that giving the `old' operator such generalised semantics is
the Right Thing.  At present programmers are banned from using it
outside postconditions.  Now it has been pointed out that there are
legitimate uses in rescue clauses.  I can see where it could make the
bodies of some routines clearer as well, saving the programmer from
having to declare a local variable such as `old_foo'.  It also removes
an ugly special case operator from the language, giving it the same
validity as any other unary operator.

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
From: johnr@ee.uts.edu.au (John Reekie)
Newsgroups: comp.lang.eiffel
Subject: Eiffel and Transputers (was: RT GC Should use Better Hardware)
Date: 1 Oct 92 15:18:16 GMT
Organization: University of Technology, Sydney
NNTP-Posting-Host: schutz.ee.uts.edu.au

Des.Kenny@bbs.actrix.gen.nz writes:

>  
>  For example at Advanced Robotics Research Limited in U.K. they
>  are building this mobile Robot , weighing 1/3 of a ton.

>  The response time has to be of the order of 20 ms.
>  
>  Clearly it is safety critical.

>  So they are not using the general run of the mill hardware
>  or even OS.

>  They are using  Transputers and fast data paths ( 200 MB/S).

>  The application programming is being done in Eiffel.

I'm curious about how exactly Eiffel fits into the transputer
environment. Since Eiffel does not (yet) support concurrency
directly in the language, is multi-tasking achieved by using
explicit process creation and communications calls to the underlying
hardware? Is there a Transputer-specific Eiffel, or is the output
from a UNIX or PC implementation compiled on a Transputer
C compiler?


Regards

John Reekie

Newsgroups: comp.lang.forth