HDTenEightyP/NetNews huggingface dataset:
From: doug@saturn.ads.com (Doug Morgan)
Subject: Re: O.M() versus M(O) notation
Organization: Advanced Decision Systems, Mountain View, CA 94043, +1 (415)
	960-7300
	<DOUG.92Aug16200024@monet.ads.com> <9+0mxzp.objsys@netcom.com>
Date: Tue, 18 Aug 1992 18:35:20 GMT

In article <9+0mxzp.objsys@netcom.com> Bob Hathaway <objsys@netcom.com> writes:
> In article <DOUG.92Aug16200024@monet.ads.com>, doug@monet.ads.com (Doug Morgan) writes:
> >This issue may finally boil down to genetic predispositions and
> >environment influences.  Some people just see M(O1,O2,...) as fitting
> >so beautifully into their notions of mathematics, symmetry, Occam's
> >razor, etc.  that no other notation makes an iota of sense.  Others
> >just see O1.M(O2,...) as the high point of the new OO-think of
> >encapsulation, message passing, classes, etc.  Neither group accepts
> >the the other's view and compromise is out of the question.  (Oh, by
> >the way, the TRUTH is that the first group is completely correct and
> >the second is completely misguided.)
>
> Ah, an old subject of interest of mine.  Why not simply examine the
> underlying grammar from which these constructs came (which is imperative)
> and then reevaluate them?  The true and quite natural origin from whence
> they came doesn't seem to be mentioned much anymore.
>
> bob
> objsys@netcom.com

I'll bite.  Did the O.M(...) notation come from simula?  Just why is
it imperative to examine the underlying grammar that suggests such an
emphasis on a single argument?

But first.  My strong suspicion is that grammar has little to do with
the current situation.  Rather, people who worry primarily about the
physical aspects of storing object data and methods just naturally
gravitate toward sticking everything on an object or its class.  Thus,
to them the 0.M(...) notation seems natural.  They have their own
strongly held reasons for not changing: hey, its simple and efficient,
everything has a place, and (most pernicious) "programming is not
mathematics."  However, the people that worry primarily about the
abstract values of objects (this would be "type" or "sort" in formal
mathematical specification) and abstract relations between these
values could care less about restricting polymorphism to one argument
and, in fact, find it extremely limiting and unnatural to do so.

All this wouldn't matter except the first group seems to dominate the
building and designing of languages that the second group then *tries*
to use (apologies for slighting CLOS designers, Chambers, and
certainly a few others).

doug

Newsgroups: comp.object
From: agesen@Xenon.Stanford.EDU (Ole Agesen)
Subject: Re: Self 2.0
Organization: CS Department, Stanford University, California, USA
Distribution: comp
Date: 17 Aug 92 15:40:53 GMT

smith@ctron.com (Larry Smith) writes:

>I downloaded Self 2.0 from self.stanford.edu and found no source code in
>this distribution.  I would very much like to have it, we are about to commit
>to an interpreter extension language for this project and I'd really like it
>to be Self.  Where can I get source???

>Larry Smith (smith@ctron.com) No, I don't speak for Cabletron.

The source is available from the same ftp server, but it is a rather big
chunk so we have packaged the stuff in several ways. Here is a selection
of files from the  /pub/Self-2.0/sun4  directory on self.stanford.edu:

README                    -- please always transfer and read this file
Self.tar.Z                -- the basic stuff, binaries and self source code
Optional.Snapshot.tar.Z   -- snapshot (image in Smalltalk terms)
Optional.Glue.tar.Z       -- stuff needed if you have to define new primitives
Optional.VM.tar.Z         -- source; this is probably what you were looking for

Good luck!
Ole
Newsgroups: comp.object
From: Zacharias J. Beckman <zac@dolphin.com>
Subject: Article Submissions for NeXT-Oriented Magazine Sought
Reply-To: zac@dolphin.com
Organization: Dolphin Software
Distribution: usa
Date: Wed, 12 Aug 1992 22:55:11 GMT

BANGup Magazine (An Excellent NeXT Magazine) Seeks Authors

We are rapidly approaching the publication deadline for the October issue  
of BANGup Magazine, and we need more articles!  If you are interested in  
writing about NeXT, whether the topic be fiction or fact, experience or  
desire, please get in touch with us!

Send us you postal address, electronic mail address, voice and fax  
telephone numbers (if you don't have one of these, don't worry).  We are  
looking for ideas, articles, and authors who wish to contribute.  Include  
what it is you would like to do for the magazine, and we'll get in touch  
with you right away!

	Zacharias J. Beckman <zac@dolphin.com>
	Editor in Chief, BANGup Magazine
	900 High School Way, Number 2106
	Mountain View, CA 94041
	415.966.8919
-- 
 Zacharias J. Beckman - Dolphin Software - zac@dolphin.com (NeXTMail welcome!)
         900 High School Way - Suite 2106 - Mountain View - CA - 94041
 To be "matter of fact" about the world is to blunder into fantasy... and dull
 fantasy at that, as the real world is strange and wonderful. -- R. A. Heinlen
Newsgroups: comp.object
From: naren@cs.UAlberta.CA (Narendra Ravi)
Subject: Re: A Graph Theory Newsgroup, Perhaps?
Organization: University of Alberta, Edmonton, Canada
Date: Fri, 21 Aug 1992 19:36:00 GMT

jbone@splat.dell.com (Jeff Bone) writes:

: thinman@netcom.com (Technically Sweet) writes:
: >
: >If you're interested in computing with graph theory,
: >get the LEDA toolkit from sbsvax.cs.uni-sb.de:/pub/LEDA/LEDA...tar.Z.
: >It's in C++ and pretty spiffy.  Has lots of graph theoretical
: >and other operations in various class libraries.
: > 

: Well, if you've tried to suck this puppy over the Big Pond you'll have
: noticed that (a) it takes forever and (b) the connection never stays
: up long enough to get the whole thing (at least from my corner of the
: Net).  AND archie doesn't reveal any domestic sites.

: Well...  just by accident I stumbled across an older copy of this thing
: on xcf.berkeley.edu:/src/programming/c++/LEDA-2.2.0.tar.Z...  NOTE that
: this isn't the newest version (the German site has a 2.2.2), but I guess
: that's better than nothing.

: FYI, use this information at your own risk. ;)


: jb


: PS - if anybody successfully retrieves the version from across the water,
: could you stick it up for ftp somewhere domestically and post the location
: to this group?  Thanks....

I have managed to retrieve this from the original site. One can copy this
from

    menaik.cs.ualberta.ca:pub/naren/LEDA

: --
: -- Jeff Bone ------------------------------------------------------------
:       "Imagination is more important than knowledge."  - A. Einstein
: ------------------------------------------------------- jbone@dell.com --
:                                                                        --
-- 

 -- Naren
    Narendra Ra[a]vi     Email : naren@cs.ualberta.ca
--

 -- Naren
    Narendra Ra[a]vi     Email : naren@cs.ualberta.ca
From: pcg@aber.ac.uk (Piercarlo Grandi)
Newsgroups: comp.object
Subject: Re: O.M() versus M(O) notation
Date: 18 Aug 92 13:33:56 GMT
	<1992Aug15.124149.28538@m.cs.uiuc.edu> <c+0m6cl.objsys@netcom.com>
Reply-To: pcg@aber.ac.uk (Piercarlo Grandi)
Organization: Prifysgol Cymru, Aberystwyth

On 18 Aug 92 03:02:46 GMT, objsys@netcom.com (Bob Hathaway) said:

objsys> Not really.  Types and type systems are clearly defined in
objsys> almost all compiler texts (ASU), several modern languages
objsys> (Emerald, Trellis/Owl),

And all these definitions refer to *different* things. Too bad.

objsys> several texts (Booch, Won Kim), and etc.

Models of clarity and coherence, indeed! I would have great fun quoting
at length from certain popular books, to let the reader compare how
things change from one page to the next, or what kind of sense can be
made of the phrases used therein.

objsys> ***I could make up terms to my liking too***

You have been doing this all along... Not that this is bad; most cs and
math textbooks do this (some speak of protocol, some of signature, some
of interface, and it's always nearly the same thing), and this is
acceptable as long as definitions are clear and coherent.

objsys> but it is better to use standard computer science terminology

I was just reading yesterday some report on an OO workshop, in which
there was a summary of discussion on types. It said that most of the
discussion had been severely hobbled by problems with terminology
problems.  It does not look like a standard computer science terminology
exists in this field.

You seem to insist that *yours* is the standard computer terminology,
which I hope it is not, because it is hopelessly fuzzy and incoherent.

objsys> if for no other reason than to be able to communicate well with
objsys> colleagues.

I am starting to think that if you are a computer scientist, I am not,
so we are not colleagues. :-)
--
Piercarlo Grandi                   | JNET: pcg@uk.ac.aber
Dept of CS, University of Wales    | UUCP: ...!mcsun!ukc!aber-cs!pcg
Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg@aber.ac.uk
Newsgroups: comp.object
From: santas@inf.ethz.ch (Philip Santas)
Subject: Re: O.M() versus M(O) notation
Organization: Dept. Informatik, Swiss Federal Institute of Technology (ETH), Zurich, CH
Date: Mon, 17 Aug 1992 21:34:10 GMT



In article <graham.714051874@galois> graham@maths.su.oz.au (Graham Matthews) writes:
>(Ralph Johnson) writes:
>>First, I agree completely that it is a good idea to separate interface
>>from implementation and from specification. 
>
>Could someone provide a concrete example of where seperating interface
>and implementation buys one a whole lot, or where you want to inherit
>part of an interface. I am not saying that it can't be done or isn't
>useful, I am merely interested in an illustrative example.

One of the best examples is type inference. In such case you need
only the interface of types and functions (BTW, isn't this called 
signature?) and not their implementation.

Philip Santas

  "In an evolving universe those who stand still are really moving backwards"
--------------------------------------------------------------------------------
email: santas@inf.ethz.ch				 Philip Santas
Mail: Dept. Informatik				Department of Computer Science
      ETH-Zentrum			  Swiss Federal Institute of Technology
      CH-8092 Zurich				       Zurich, Switzerland
      Switzerland
Phone: +41-1-2547391
 






    
Newsgroups: comp.object
From: djohnson@mtc.ti.com (Doug Johnson)
Subject: Re: Beginner's Question - CLOS
Reply-To: johnson@mycroft.mtc.ti.com (Doug Johnson)
Organization: Texas Instruments
	<16u2tpINN9ad@early-bird.think.com> <1992Aug19.213818.21709@tfs.com>
Date: Thu, 20 Aug 1992 00:38:47 GMT



 >But doesn't that make method dispatch very time consuming?  It seems like
 >it would involve searching for the method in tables, and that the amount
 >of time consumed would depend on how many methods were in those tables and
 >how many class arguments each method had.

Naive implementations are slow, sophisticated ones can be quite fast
(by Lisp standards).  Techniques like caching methods are used to
speed up dispatch.

 >In C++, method dispatch is trivial to the CPU, such that on most modern
 >CPU's it would take a fraction of a microsecond.  I can see the advantages
 >of dispatching according to the types of multiple arguments, but I'm just
 >wondering how much of a speed impact it has.  In C++ the same functionality
 >requires more code, but it seems like it would still be faster. 

Lisp has always tended to buy richness of expression with speed.  "In
C++ the same functionality requires more code, but it seems like it
would still be faster" implies that programmer time is cheaper than
CPU time.  It varies from case to case, but it is often a poor
trade to increase code to increase speed.

 >For
 >example, a terminal object's display function would take a base class of data
 >as its argument, and then it would get the data converted to its requirement
 >by invoking a conversion method on the data object.  That conversion method
 >would be known to the terminal object at compile time, so the resulting code
 >would involve no lookups other than the initial sub-microsecond dispatch to
 >the terminal object's display function, followed by the sub-microsecond
 >dispatch to the data objects's conversion function for that terminal object's
 >data format.

In general, EVERYTHING in Lisp is deferred to runtime.  Richer
expression at the cost of performance.  CLOS is entirely consistent
with Lisp philosophy.  C++ is entirely consistent with C.   Both have
their virtues.  Neither solves all the world's problems, no matter
what the bigots say.  

Doug Johnson
Lisp Bigot (retired)
From: mod@cs.man.ac.uk (Michael O'Docherty (CAG ra))
Newsgroups: comp.lang.eiffel
Subject: system-level validity
Summary: system-level-validity
Keywords: system-level validity
Date: 21 Aug 92 15:35:18 GMT

In an earlier posting, I gave a type hole example and asked a few
questions. Perhaps I was too subtle, for I received no answers. I'll
try to be more concise and more direct about the most important issue.

   "Does ISE Eiffel 3.0 perform system-level validity checking?"

I only ask because I strongly believe that 3.0 vendors should be up
front about this very important issue; after all, is a compiler that
only performs 99% of the possible static checking any long term use,
especially when Eiffel is trumpeted as robust? (Oops, slipped a second
question in there ;-).

If the answer to the first question is "no" then we'll still buy
EiffelBench but I would be disappointed if future versions don't do the
checking either, (there's a third question in there if you look
carefully :-).  Shortcomings are fine as long as they're temporary and
we know what they are.

Yours eagerly awaiting the release,

	Mike.

ps. I know the people at ISE are doing a very difficult job, no
criticism is intended.

Internet: mod@cs.man.ac.uk, wet string: (+44) 061 223 1301 ext. 2343
From: sommar@enea.se (Erland Sommarskog)
Newsgroups: comp.lang.eiffel
Subject: Re: Questions on libraries and conformance
Date: 15 Aug 92 21:00:01 GMT
Organization: Enea Data AB

Glenn Maughan (gmaughan@monu6.cc.monash.edu.au) writes in response to me:
>Yes but if you needed to inherit an existing class to reuse its functionallity
>You would generally need to know how it the class works.  That means at least
>browsing the source code.

Please notice that there is no contradiction with what I wrote. Just
because you ship the source code with the library, doesn't mean that
the compiler should compile all over and over again. Or do global
reference analysis. That is, remove the source code and the compiler
won't notice. Only the programmer but that's another issue.
-- 
Erland Sommarskog - ENEA Data, Stockholm - sommar@enea.se
Life is wonderful when the wonderlife is full
Newsgroups: comp.lang.eiffel
From: gmaughan@monu6.cc.monash.edu.au (Glenn Maughan)
Subject: How to check for state changed in objects?
Organization: Monash University, Caulfield Campus
Date: Sun, 16 Aug 1992 04:39:24 GMT

Does anyone know if there is a mechanism for checking if an object
has changed state?  I am trying to implement incremental persistence and
need to know if an object has changed state when compared to the same object
on disk.

Is there a way to do it in Eiffel code.  If there is a way
in version 3 I would like to know also.

I located the definition for OBJECT in the C code of Eiffel 2.3
(finding it wasn't a pleasant experience).

typedef struct OBJECT {
	INFO info;
	...
	long date;       <-- can this be used?
} OBJECT, *OBJPTR;


Does the date item hold information about the creation date?  Would I be able
to use it?

I would prefer to stay away from writing low level C to do check this.
I have also thought of checking state changed by making a copy of all
attributes in an object, but that defeats the purpose of making efficient
persistent mechanisms.

Any ideas?

Glenn Maughan
Software Development Honours
Monash University
gmaughan@monu6.cc.monash.edu.au


-- 
--------------------------------------------------------
Glenn Maughan
Software Development Honours
email: gmaughan@monu6.cc.monash.edu.au
Newsgroups: comp.lang.eiffel
From: langmack@inf.fu-berlin.de (Olaf Langmack)
Subject: Eiffel-3 Parser Test
Organization: Free University of Berlin, Germany
Date: Sat, 15 Aug 1992 11:06:34 GMT

We are looking for - "dirty" - data to test our Eiffel-3 Parser:

  1 - Does NICE already provide reference test data for Eiffel-3 
      compilers? 

  2 - Could anyone provide Eiffel-3 programs with a better grammar 
      coverage than the sources of the SIG (and ISE in 9/92?) Eiffel-3 
      implementations?
  
 (3 - Does anyone know if there exist test data generators which 
      operate on LL(1)-grammars?)

Thanks,
  Burghardt Groeber & Olaf Langmack.

FU Informatik
Nestorstrasse 8-9
W-1000 Berlin 31

+49-30-89691-{108,116}

{groeber,langmack}@inf.fu-berlin.de
From: seanb@cs.man.ac.uk (Sean Bechhofer)
Newsgroups: comp.lang.eiffel
Subject: CECIL and garbage collection
Date: 19 Aug 92 14:31:59 GMT

Here's an interesting problem I've come up against in Eiffel 2.3, when
using garbage collection and external C functions which create objects. As
it says in the Environment manual, p.108:
 
        "What keeps the garbage collector from collecting Eiffel
        objects that are only referenced in C code? Nothing. If
        garbage collection is enabled, you must keep a reference
        on the Eiffel side to prevent an object from being collected."
 
[Minor gripe: It would be nice to have this mentioned in the chapter on the
CECIL interface. It took a while to find out quite why the code was
behaving in a strange manner.]
 
In my code, an external C function is passed an Eiffel reference. The C
builds an Eiffel tree (using eif_create, eif_rout, etc), then passes
control back to Eiffel. The problem is that while the tree is being built,
some of the nodes lower down the tree get garbage collected by Eiffel, with
the effect that the result returned isn't what you'd expect.
 
I'd imagine there's a similar problem if you've got an Eiffel C archive
compiled with garbage collection on, and some C wrapped around it. Calling
into the Eiffel could cause objects created in the C code to be trashed. 


So,

        o Any suggestions for a solution, other than simply turning
	  garbage collection off (via feature collection_off of class
	  MEMORY) while you're in the C world?  
 
        o Is this "feature" likely to change in Eiffel 3?
 
Cheers,
 
                Sean Bechhofer
                seanb@cs.man.ac.uk
 
 
 
 
 
 
 
Newsgroups: comp.lang.eiffel
From: youngm@magma.Colorado.EDU (Matthew Young)
Subject: Current Version of Eiffel, Sather
Originator: youngm@magma
Reply-To: youngm@magma.Colorado.EDU (Matthew Young)
Organization: Center for Study of Earth from Space, U of Colorado, Boulder
Distribution: usa
Date: Sat, 22 Aug 1992 17:32:16 GMT


Could someone please tell me the current release version of Eiffel, and
whether or not the Meyers text covers this version?  Also wondering if 
the Meyers text is the best/most current source for information on Sather.
Is Sather truly a subset of Eiffel?

Thanks.

Sorry for the FAQ.

mY
Newsgroups: comp.lang.eiffel
From: bernie@resntl.bhp.com.au (Bernard Orenstein)
Newsgroups: comp.lang.eiffel
Subject: Examples of Eiffel used for large applications?
Date: 20 Aug 92 23:34:28 GMT
Organization: BHP Research (Newcastle Laboratories)
X-Useragent: Nuntius v1.1

I am currently evaluating tools for serious application development
for the next few years.  To date we have only used the Eiffel language
as an OO specification tool.

Are there any examples of large applications developed with Eiffel
tools.  We are particularly interested in those applications requiring
the use of prototyping, (portable) GUIs and (portables) databases.

Thanks - Bernie
Newsgroups: comp.lang.eiffel
From: jcm@hgc.edu (James McKim)
Subject: Re: TOOLS Conference Report (?)
Organization: The Hartford Graduate Center
Date: Fri, 14 Aug 1992 15:34:13 GMT

In article <1992Aug12.090606.12@corning.com> kruger_rc@corning.com writes:
>
>I understand that ISE was planning on unveiling Eiffel 3.0
>(and other goodies(?)) at the TOOLS conference last week in Santa Barbara. 
>If any one reading this newsgroup attended the conference, maybe they 
>could post a brief summary for the benefit of those of us who could
>not attend. (?)
>
>Thanks in advance.


OK, I'll take a first cut at this and then maybe others will join in.

First, the bad news. We still didn't hear a firm shipping date.
There appears to be one last problem with the "melting ice"
technology (this is what allows mixing of compiled and interpreted
code for a fast compile-edit cycle during development).

The good news is that everything we saw looks _really_ good.

EiffelBench is the basic development environment designed for use
in a windowing system (motif is supported now with openlook soon
to follow). Through a very intuitive "drag and drop" mechanism, one 
can quickly compile, edit and examine source code, view short and 
flat forms of classes, find ancestors, descendants, clients, suppliers, etc.
What we did see of the melting ice technology looked very fast.

EiffelBuild is an application builder. Again using the drag and drop 
mechanism one can quickly build and experiment with graphical user
interfaces, for example. You build the interface on the screen and
the system generates most of the code. If your interface
includes a command button, the code for putting the button on the
screen, with text and colors of your choice will be automatically
generated. At the appropriate time, the system will provide a
template for the code _you_ have to fill in. Namely, what happens
when somebody clicks on the button. Perhaps someone with experience
with other GUI builders could comment further (Dave Q?). 

EiffelBuild came together in a remarkably short time. It uses
the EiffelVision graphics library extensively (as does EiffelBench,
I think), so there is some empirical evidence that this library
is easy to use and provides some solid development power.

EiffelCase was also demonstrated, but I missed it! :-(

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: kruger_rc@corning.com
Newsgroups: comp.lang.eiffel
Subject: TOOLS Conference Report (?)
Date: 12 Aug 92 09:06:06 -0500
Organization: Corning Incorporated


I understand that ISE was planning on unveiling Eiffel 3.0
(and other goodies(?)) at the TOOLS conference last week in Santa Barbara. 
If any one reading this newsgroup attended the conference, maybe they 
could post a brief summary for the benefit of those of us who could
not attend. (?)

Thanks in advance.
Newsgroups: comp.lang.eiffel
From: tcn@holon.demon.co.uk (Trevor Nash)