HDTenEightyP/NetNews huggingface dataset:
From: jeff@aiai.edinburgh.ac.uk (Jeff Dalton)
Subject: Re: Beginner's Question - CLOS
Organization: The Ohio State University Department of Computer and Information Science
Date: Tue, 15 Sep 1992 17:53:47 GMT

Harley Davis writes in response to kanderso@BBN.COM (indented):

>    What would you leave out of CLOS and the MOP?

>                    It is not so much a
> question of what we have left out of CLOS and the MOP, but where we
> put various aspects.

Once you have a large language it's very hard to take things out.
People disagree.  What's an eyesore to one is especially prized
by another.  The very idea of changing the size of the language
is disputed.  And so on.

This sort of thing has, hostorically, made the idea of subsets
very controversial in Common Lisp circles.  The same problem
happens from the other side in Scheme: it's almost impossible
to get an agreement to _add_ something.

In EuLisp, we've followed languages such as C and put lots of things
in libraries.  

>   Lisp has fought an uphill battle in the conventional world
> because Lisp program development has been seen as incremental
> modification of the state of the Lisp image.

But not by everyone.  This is primarily a Lisp machine, Interlisp
way of looking at things.  (I think.)

-- jd
Newsgroups: comp.lang.clos
From: rpg%inferno@lucid.com (Richard P. Gabriel)
Subject: Beginner's Question - CLOS
Organization: The Ohio State University Department of Computer and Information Science
Date: Tue, 15 Sep 1992 21:59:55 GMT

What I'm getting at is that C and C++ are moving closer to Lisp in
lots of ways, also. For example, that community seems to like
incremental development for its speed, but they don't see a *need* to
reload a changed function and *proceed*. They see a need to reload it
and start afresh from main. I take this as being just one step away
from the pure Lisp model. Yet they - and I - prefer to be able to do a
fresh compile, mostly because there is then a baseline so that when
things get screwed up, I can start afresh without having to do a lot
to re-create where I was.

What I don't want to do is to superficially analyze what is different
between Lisp and C and then go off and implement that. 

			-rpg-
Newsgroups: comp.lang.clos
From: kramer@cs.toronto.edu (Bryan M Kramer)
Subject: using mop to remove instance variables
Date: 9 Sep 92 13:46:50 GMT

I have an application where it is redundant to store a value for an
instance variable in a specialization of a class. I'll use numbers as
as an analogy (not that one would do this with numbers in common lisp):

One might have a class called complex-number that has two instance
variables real-part and imaginary part. A second class real-number
would be a specialization of complex-number but doesn't need to store
a 0 in the imaginary part. One could simply write an accessor that
always returns 0.

Has anyone used the MOP to allow a class such as real-number to not
have to store the unwanted instance variables? I'd love to have
someone send me an example so that I can avoid doing the work myself.

Thanks

|Bryan M. Kramer, Ph.D.	      416-978-7330, fax 416-978-1455|
|Department of Computer Science, University of Toronto      |
|6 King's College Road, Room 283E			    |
|Toronto, Ontario, Canada      M5S 1A4                      |
Newsgroups: comp.lang.clos
From: kanderso@bbn.com
Subject: Re: Beginner's Question - CLOS
Organization: The Ohio State University Department of Computer and Information Science
Date: Mon, 14 Sep 1992 06:33:40 GMT

  
  ...

  A general philosophical point is in order, however: The traditional
  problem of Lisp systems has been creating minimal applications.
  Carrying around lots of extra baggage such as optimizing code,
  compilers, and interpreters just continues this negative aspect.  The
  problem that we should be attacking in designing modern Lisps is the
  ability to create small, efficient applications which do not require
  enormous complexity to implement.  I think this is the major general
  complaint against Common Lisp and CLOS + MOP.  (Of course, there are
  any number of problems with specific language aspects due to
  featurosity accretion.)
  
You can certainly blame Lisp for being big, but you can also blame your
operating system.  For example, a lot of your extra baggage could be shared
among all your applications.  While this happens on Lisp machines, it does
not happen, yet on UNIX machines.

What would you leave out of CLOS and the MOP?

  Scheme has solved the problem to some extent, but the price is a
  language which many Lisp users would consider lacking in utility.
  
  EuLisp and Le-Lisp version 16 try to solve this problem by adding
  module systems and eliminating the guaranteed runtime mapping of all
  symbols to functions/values, along with some other improvements.
  
     Also, I'm not sure how your point about functions is related to
     dispatch optimization, but many unwanted runtime bindings between
     names and functions could be eliminated with some combination of
     unintern and setf of fdefinition.  (Not so for common-lisp package
     functions, of course.)
  
  If you accept that I was talking about a different kind of
  optimization than you, it should be clear that the points are related:
  both the fully extensible MOP and the guaranteed runtime name/function
  binding make it difficult to create small applications.
  
Why?  I can imagine a delivery strategy where the MOP could be quite useful
in delivering smaller applications.  For example, once you are willing to
crystalize your application by doing a DISKSAVE or whatever, CLOS has as
much knowledge about your program as C++ does.  Simply by loading the
appropriate metaclasses, and recompiling your software, you could have a
more compact, efficient application.  This would be better than having a
bunch of compiler switches because it makes things more user accessable.

Now your application may still be big because of other Lisp baggage, but
not because of the MOP.  Lucid's Energize environment for C++ development
provides a clean separation betweeen powerful development tools, and
compact delivery.  If we had a Lisp that could make that same separations,
i don't see why it wouldn't fit quite well into the constraints of some "modern"
operating system. 

k
From: gdonlon@bbn.com (Gerard Donlon)
Newsgroups: comp.lang.clos
Subject: Re: Beginner's Question - CLOS
Date: 15 Sep 92 17:30:42 GMT
NNTP-Posting-Host: kirin.bbn.com

davis@ilog.ILog.FR (Harley Davis) writes:

>I also think there is something indicative in your statement that at a
>certain point you should "crystallize your application by doing a
>DISKSAVE or whatever".  This idea that the state of memory somehow is
>the best representation of your application is deadly in today's
>computing environments.  As I said, we must integrate Lisp into
>existing environments, and one of the fundamental principles of
>program development in traditional OS's is that your code (statically
>known) plus a static program description (eg a Makefile) constitutes
>your application.  If you stray too far from this simple (and
>admittedly frustratingly limited) model, you are bound to end up in
>trouble.  Lisp has fought an uphill battle in the conventional world
>because Lisp program development has been seen as incremental
>modification of the state of the Lisp image.

  Ken was a little to vague saying "DISKSAVE or whatever".  A good
example of the kind of facility that is needed did exist.  DEC had
a resonable commonlisp system (before DEC decided to disband the
lisp group and sell a third party system).  They provided a usefull
extension to common lisp.  Clearly not within the standard, but
very usefull.  They shiped the binaries for the lisp system code,
and included a function that was something between a make and disksave.
It allowed you to build a lisp image that included only the system
functionality you requested, plus your code.  You could leave out the
compiler, debugger; there were many parts that were optional.
It was very similar to Lucid's delivery tool kit but had one big
advantage.  In the resulting image, read-only space was shareable.
All compiled code, and constants, and any data the user explicitly
declared to be read-only, were shared.

  We were running a fairly large system in DECLisp.  It was five
years ago, and I am generating these numbers from memory, so I
could be wrong.  I think our image (with no special treatment)
was around 35 to 40 meg.  After dropping the development environment
(both system code and some of our code) it dropped down to about 25meg
About 80% of that was shareable.  We were running on a microvax II.
Without shareable code, a second user running lisp caused serious
performance problems.  With shareable code, two users could run
comfortably, a third would slow down the system, but not as much
as two non-shared users.

  It is this kind of practical tool that will help make lisp a
viable commercial language.


Gerard Donlon.   (gdonlon@bbn.com)
BBN Systems and Technologies
4015 Hancock St   San Diego, Ca 92110
From: lange@lanai.cs.ucla.edu (Trent Lange)
Newsgroups: comp.lang.clos
Subject: Re: Functional Interfaces and CLOS Metaobject Protocols
Date: 11 Sep 92 12:23:37 GMT
Organization: UCLA Artificial Intelligence Laboratory

In article <9209101712.AA27788@kuwait.lucid> jonl%kuwait@lucid.com (Jon L White) writes:
>
>re: Date: 8 Sep 92 01:09:40 GMT
>    From: lange@lanai.cs.ucla.edu (Trent Lange)
>    Subject: Alternative specializer types
>    . . . 
>    (defmethod foo ((self (and class1-mixin class2-mixin))) ...)
>
>As Danny Bobrow's reply indicated, there are some theoretically very
>interesting directions in which generic-function discrimination can
>be extended, including boolean combinations of classes.  However,
>research into the style suggested by these directions would probably
>have to make some more basic alterations to a Lisp/CLOS system than
>are envisioned in AMOP's published interfaces.
>
>-- JonL --

The interesting thing about this kind of example is that the AMOP
seems to come very close to supporting it, or at least allowing it.
For instance, an appropriate user method on compute-applicable-methods
and compute-applicable-methods-using-classes would seem to allow it.
(Actually writing those methods to allow full boolean combinations of
classes as specializers might be a bit tricky, but it certainly could
be done.)

The "problem" is that although the far-seeing and flexible published
interfaces of the AMOP allow the programmer to do extremely powerful
extensions of this nature, there are sometimes other parts that aren't so
open-ended and which rule out the extensions.  For example, the parts
of the AMOP that explicitly say that "method specializers are class
metaobjects or EQL specializers", thus ruling out alternative types
of method specializers (such as boolean combinations).  If instead the
AMOP said "the standard method specializers are class metaobjects or
EQL specializers, but can be anything the MOP programmer allows", or
something similarly open-ended, then it could be done.

I've noticed these kind of limitations to the standard provided
interfaces in a few different places in the AMOP.  Presumably they
were stated the way they were because nobody thought of alternative
possibilities at the time.  But hopefully the evolving protocol can
leave things more open-ended in general, and where possible say what
the standard implementation provides, rather than saying what things
must be.

- Trent Lange
Newsgroups: comp.lang.clos
From: keunen@nrb.UUCP (Vincent Keunen)
Subject: Re: Looking for information on CLOS based distributed object systems
Reply-To: nrb!keunen@relay.EU.net
Organization: The Ohio State University Department of Computer and Information Science
Date: Wed, 9 Sep 1992 14:38:00 GMT

    Date: Thu, 3 Sep 1992 05:04+0200
    From: barmar@think.com (Barry Margolin)

    In article <01050159.cgf6gc@devlab.IISA.COM> kpt@iisa.com writes:
    >I'm looking for information on CLOS based distributed object systems.
    >It seems, from what little information I have available, that every
    >O-O language except CLOS has been used to develop such systems.  Is
    >this true or have I missed something?  If it is true then what has
    >lead to this state of affairs?

    Symbolics has announced that they're converting their Statice OODBMS from
    Flavors to CLOS, and investigating porting it to CL on conventional
    architectures.
    -- 
    Barry Margolin
    System Manager, Thinking Machines Corp.

    barmar@think.com          {uunet,harvard}!think!barmar


I know Symbolics SystemHaus (Germany) have been working on a CL Statice
on conventional architectures for some time now.  They're supposed to
release a first version in the end of 92.

I suppose gt@sger.uucp can provide more info.  I can't.

vk
--

Keunen Vincent                  Network Research Belgium
R&D, Software Engineer          Parc Industriel des Hauts-Sarts
keunen@nrb.be                   2e Avenue, 65
tel: +32 41 407282              B-4040 Herstal
fax: +32 41 481170              BELGIUM
From: rr@world.std.com (Robert I Ransbottom)
Newsgroups: comp.lang.c++
Subject: setiosflags(ios::fixed)<<MINDOUBLE
Summary: dumps core
Keywords: cfront 3.0,  SysVr3.2
Date: 6 Sep 92 00:40:15 GMT
Followup-To: comp.lang.c++
Distribution: usa
Organization: The World Public Access UNIX, Brookline, MA

// This neophyte thinks "Not me, I didn't do it!"

// weedie.C 

#include <values.h>
#include <iostream.h>
#include <iomanip.h

main()
{
	cout << MINDOUBLE << endl;
	cout << setiosflags(ios::fixed) <<  MINDOUBLE + .00000001 << endl;
	cout << MINDOUBLE << endl;
}
//:r! ( CC t.C && a.out) 2>&1
//CC +OL weedie.C:
//   cc     weedie.c -lC30
//4.94066e-324
//0.000000
//sh: 16333 Bus error - core dumped

-- 
rr@world.std.com  Robert Ransbottom

"Maintaining correct attributions is extremely important." -- anonymous
Newsgroups: comp.lang.c++
From: eric@tfs.com (Eric Smith)
Subject: Re: initialization HELP structure of classes
Organization: TFS
Distribution: global
Date: Tue, 8 Sep 1992 00:13:33 GMT

In article <g89s9112.2.715860452@giraffe.ru.ac.za> g89s9112@giraffe.ru.ac.za (MR D STURZEBECHER) writes:
>ERROR : Objects of type 'A_DATA' cannot be initialized with {  }

You can't initialize normal classes that way, only "aggregates".
For normal classes, ou have to use class constructors.

"Aggregates" are C structs, etc., used mainly for compatibility with C.
For an exact definition, see page 151 of the ARM.
Newsgroups: comp.lang.c++
From: rmartin@thor.Rational.COM (Bob Martin)
Newsgroups: comp.lang.c++
Subject: Re: can I 'delete' without a 'new'?
Date: 5 Sep 92 17:31:47 GMT

peter@kentrox.uucp (Peter Uchytil) writes:

|class foo {
|  char *String;
|public:
|  foo();
|  foo( char * );
|  ~foo();
|  void set( char * );
|};

|foo:foo() { };

|foo:foo( char *inString ) {
|  String = new char[strlen( inString )];
|  strcpy( String, inString );
|}

|void foo:set( char *inString ) {
|  String = new char[strlen( inString )];
|  strcpy( String, inString );
|}

|foo:~foo() {
|  delete [] String;
|}

|The question is what will happen if I create a foo with the empty constructor
|and never call 'set'?  Since 'new' has never been called, what will 'delete'
|try to delete?  Looks like a real good way to frazzle the system.  Yes?  No?

It is, if the member variable String is non-zero.  But if your default
constructor sets this variable to zero, then the 'delete' in the
destructor will be safe.  Operator delete is well-behaved when passed
a 0 argument.

|Summary of questions:
|      1) What happens if I call 'delete' without having called 'new'?


If the pointer is zero, then nothing bad happens.  If the pointer is
non-zero then system frazzling is imminent.

|      2) What happens if I call 'new' twice in a row?  Sounds like I'm going
|         to make some memory become unrecoverable.  

The memory allocated by the first call to new would "leak" out of your
application.  You would never be able to put it back in the heap.


--
Robert Martin                        Training courses offered in:
R. C. M. Consulting                       Object Oriented Analysis
2080 Cranbrook Rd.                        Object Oriented Design
Green Oaks, Il 60048 (708) 918-1004       C++
Xref: sparky comp.lang.c++:13516 gnu.g++.help:1216
From: munroe@dmc.com (Dick Munroe)
Newsgroups: comp.lang.c++,gnu.g++.help
Subject: Re: Variable Declarations
Date: 10 Sep 92 12:35:02 GMT
Followup-To: comp.lang.c++,gnu.g++.help
Organization: Doyle, Munroe Consultants, Inc., Hudson, MA
To: gnu-g++-announce@uunet.uu.net

In article <u895217.716089910@bruny>, u895217@bruny.cc.utas.edu.au (Scott Marshall) writes:
> Hi.
> I need a little advice on using C++. When given the following code, would
> the variable being declared (and initialised) be re-initialised on every
> iteration?
> 
> 		String s = buf;

It will be reinitialized with each iteration of the loop.  This statement is
equivalent to (begging the issues of constructors):

        String s ;
        s = buf ;
-- 
Dick Munroe				Internet: munroe@dmc.com
Doyle Munroe Consultants, Inc.		UUCP: ...uunet!thehulk!munroe
267 Cox St.				Office: (508) 568-1618
Hudson, Ma.				FAX: (508) 562-1133

GET CONNECTED!!! Send mail to info@dmc.com to find out about DMConnection.
Newsgroups: comp.lang.c++
From: fjh@munta.cs.mu.OZ.AU (Fergus James HENDERSON)
Subject: Re: inline virtual functions
Organization: Computer Science, University of Melbourne, Australia
Date: Tue, 15 Sep 1992 14:31:30 GMT

sdm@cs.brown.edu (Scott Meyers) writes:

>For all the compilers with which I am familiar, inline virtual functions
>are oxymoronic:  the function bodies are never inlined, and the object file
>for each translation unit seeing the definition of the function receives a
>static copy of the function.  I tested this using cfront 3.0 and g++ 2.2.2,
>and both behaved as I have described, neither issuing a warning about not
>inlining a function.

I just tested cfront 1.2.1, cfront 2.0, g++ 1.37.2, and g++ 2.2.2.
All of these except cfront 1.2.1 can successfully inline "inline virtual"
functions. Perhaps you made some mistake?

Here's the code I used:

	extern void ggggg();	// "ggggg" easy to find in the assembly output

	class A {
	public:
		inline virtual void fffff() { ggggg(); }
	};

	void foo() {
		A a;
		A& b = a;
		a.fffff();	// this gets inlined
		b.fffff();	// this doesn't :-(
	}

>Many people have discovered this behavior in current compilers, and so the
>following rule is widely followed: "never define an inline virtual
>function."

Not by me!
That would not be a good rule to follow.

>This is a pity, because it's the kind of rule that is easy to
>remember, hence people will continue to follow it even when C++ compilers
>become agressive enough in their optimization to be able to generate
>inlined calls to virtual functions.

Compilers are already that aggressive.

-- 
Fergus Henderson             fjh@munta.cs.mu.OZ.AU      
This .signature virus is a self-referential statement that is true - but 
you will only be able to consistently believe it if you copy it to your own
.signature file!
Newsgroups: comp.lang.c++
From: lappala@cse.unl.edu (Kristopher Lappala)
Subject: fseek()
Summary: Need help with fseek() and binary files...
Keywords: fseek()
Organization: University of Nebraska - Lincoln
Distribution: global
Date: Tue, 15 Sep 1992 06:57:54 GMT

I need to somehow detect the size of a binary file so my
program will stop reading from it..
i.e.

while(i<=lastposition) {.......
				Thanks,
				K.L.

Newsgroups: comp.lang.c++
From: sjm@bcrki65.bnr.ca (Stuart MacMartin)
Subject: Re: Virtual methods
Keywords: interrupt handler virtual methods
Organization: Bell-Northern Research Ltd., Ottawa, Canada
Date: Tue, 15 Sep 1992 15:02:36 GMT

> feustel@netcom.com (David Feustel) writes:
> 
> |> Coplien's book "Advanced C++" makes the point that very little overhead
> |> would be incurred in most programe even if all functions were declared
> |> virtual and that some programs might even run faster than equivalent C
> |> programs using switch constructs to achieve the same effects.
> 
> This reminds me of a question which I've been meaning to ask for some
> time now. Ignoring performance issues, why would one not declare every
> method in a class virtual? What circumstances might preclude its use?

Also, sometimes the extra 4 bytes for a pointer to a virtual table is
not acceptable.  Some classes are instantiated hundreds of thousands of
times, and having extra bytes is significant.

Stuart
--
: Stuart MacMartin                                    email: sjm@bnr.ca      :
: Bell-Northern Research                              phone: (613) 763-5625  :
: PO Box 3511, Stn C, Ottawa, K1Y-4H7, CANADA    Standard disclaimers apply. :
Newsgroups: comp.lang.c++
From: adk@Warren.MENTORG.COM (Ajay Kamdar)
Subject: Re: inline virtual functions
Organization: Mentor Graphics Corp. - IC Group
Date: Tue, 15 Sep 1992 15:04:11 GMT

In article <1992Sep15.023336.1403@cs.brown.edu> sdm@cs.brown.edu (Scott Meyers) writes:
>For all the compilers with which I am familiar, inline virtual functions
>are oxymoronic:  the function bodies are never inlined, and the object file
>for each translation unit seeing the definition of the function receives a
>static copy of the function.  I tested this using cfront 3.0 and g++ 2.2.2,
>and both behaved as I have described, neither issuing a warning about not
>inlining a function.
>

Cfront based compilers will warn about noninlined virtual functions
if you use the +w switch.


- Ajay

-- 
I speak for none but myself.

Ajay Kamdar                               Email : ajay_kamdar@mentorg.com
Mentor Graphics, IC Group (Warren, NJ)    Phone : (908) 580-0102
From: tmb@arolla.idiap.ch (Thomas M. Breuel)
Newsgroups: comp.lang.c++
Subject: defining cast operators outside classes
Date: 7 Sep 92 20:23:24 GMT
Reply-To: tmb@idiap.ch
Organization: IDIAP (Institut Dalle Molle d'Intelligence Artificielle
	Perceptive)

Apparently, it is impossible to define a conversion operator for a
class without making the conversion operator a member function.

It would be very useful to be able to define something like the
following without having to modify either class MyMatrix or class
TheirMatrix:

	operator MyMatrix(TheirMatrix &m) {
		...
	}

Why was this seemingly arbitrary restriction made? Can it be
eliminated in the next version of C++?

					Thomas.
From: fjbielsik@beckman.com (Frank Bielsik)
Newsgroups: comp.lang.c++
Subject: Tom Plumm C++ Style Guide -- where?
Date: 10 Sep 92 10:43:22 PDT
Organization: Beckman Instruments, Fullerton, CA

Which public FTP sites have the Tom Plumm C++ style guide?

Thanks.
Newsgroups: comp.lang.c++
From: fromherz@parc.xerox.com (Markus Fromherz)
Subject: APIs across Sun, Mac, and PC?
Reply-To: fromherz@parc.xerox.com (Markus Fromherz)
Organization: Xerox PARC
Date: Thu, 10 Sep 1992 17:56:57 GMT


This should be a faq, but we didn't find a comprehensive set of answers:

What development environments, class libraries, application frameworks
or APIs exist that allow to write programs portable across Suns, Macs
and PCs?

- As an example, ParcPlace Smalltalk would be ideal as it guarantees
  100% portability across those platforms.
- We are primarily interested in environments or libraries for an
  object-oriented language, and we focus on C++.
- Naturally, we are especially interested in portable user interface code.
- The environment or library should be stable and supported.
- X would be a nice common basis.

Thanks for your help.
Please write e-mail; I will summarize.


Markus Fromherz


Xerox PARC, Systems and Practices Lab    |  Tel.:   +1 (415) 812-4273
3333 Coyote Hill Road                    |  Fax.:   +1 (415) 812-4334
Palo Alto, CA 94304                      |  E-Mail: fromherz@parc.xerox.com