HDTenEightyP/NetNews huggingface dataset:
From: moon@cambridge.apple.com (David A. Moon)
Newsgroups: comp.lang.clos
Subject: Re: CLOS With-Accessors
Date: 10 Apr 92 18:50:15 GMT
Article-I.D.: cambridg.9204101844.AA08001
Organization: The Ohio State University Department of Computer and Information Science

> Date: Wed, 8 Apr 1992 13:09-0400
> From: barmar@Think.COM (Barry Margolin)
> ....
> P.777 of CLtL2 contains the restriction "Any accessors specified by
> WITH-ACCESSORS must already have been defined before they are used";
> this line comes direct from the CLOS spec.  And the ANSI draft's
> description of WITH-ACCESSORS says, "The consequences are undefined if
> any accessor-name is not the name of an accessor for the instance."
> 
> In the case of the first quote, I'm not sure what it means by "used";
> does it mean "called" (i.e. at runtime), or does it mean "seen by the
> compiler"?  I'd like to think that the former was intended, but that's
> true of *all* functions so I don't think the designers would have made a
> special point of it.
> 
> The second quote has me even more confused.  It may be intended just to
> restate the restriction in the first quote.  This sense of the term
> "accessor" is never defined precisely in the standard (there's a
> definition of "accessor" that refers to generalized references -- e.g.
> CAR is this kind of accessor).  Nowhere is it ever stated that :ACCESSOR
> defines this kind of accessor; it is just a shorthand for defining the
> appropriate methods yourself (it might also make use of
> implementation-specific optimizations, but those should be transparent
> unless you're timing or using the metaobject protocol).
> 
> Finally, these restrictions appear to contradict other parts of the CLOS
> spec, which say that WITH-ACCESSORS is equivalent to a use of
> SYMBOL-MACROLET that replaces the "variable" references with calls to
> the specified accessor.  Why should this SYMBOL-MACROLET expansion be
> dependent on how the accessor is defined?

Don't look at me, I never understood what this sentence is trying to say.

However, if I was forced to guess, I would guess that the sentence from
CLtL2 means that with-accessors is only a syntactic transformation: it
will generate calls to some functions but it won't define the functions
if they aren't already defined.  You still have to use :accessor or
:reader or :writer in your defclass, even if you never directly write
calls to the functions defined there in your program, but only use
them indirectly via with-accessors.

I'm completely clueless about the quote from the ANSI CL draft.  Do you
think it's a garbled paraphrase of the quote from CLtL2?  Or did it come
from someplace else?
From: hohmann@zug.csmil.umich.edu
Subject: Re: redefining keys
Organization: The Ohio State University Department of Computer and Information Science
Date: Mon, 6 Apr 1992 05:24:46 GMT


If you want something that works for all windows and all dialog
items specialize 'window-key-event-handler, or write your own
event-hook routine.

  -- Luke
Newsgroups: comp.lang.clos
From: barmar@think.com (Barry Margolin)
Subject: Re: no-applicable-method
Organization: The Ohio State University Department of Computer and Information Science
Date: Thu, 16 Apr 1992 13:47:00 GMT

    Date: Thu, 16 Apr 1992 15:53 EDT
    From: Thomas Kirk <tk@HUNNY.research.att.com>

	From: Barry Margolin <barmar@Think.COM>
	Subject: Re: no-applicable-method
	To: tk@research.att.com
	Cc: mh5l+@andrew.cmu.edu, comp.lang.clos@cis.ohio-state.edu
	In-Reply-To: <19920416170513.9.TK@PETZL.research.att.com>
	Message-Id: <19920416182843.6.BARMAR@occam.think.com>

	    Date: Thu, 16 Apr 1992 13:05 EDT
	    From: Thomas Kirk <tk@HUNNY.research.att.com>

	    this will work fine. assuming that you can get at the generic functions,
	    just change the class of the generic function object, like so:

	Sorry, this isn't permitted.  According to p.197 of "The Art of the
	Metaobject Protocol", third paragraph, "the class of a generic function
	metaobject may not be changed...".

    true enough. however, given that (a) this is a useful thing to do,
    and (b) many extant CLOS implementations allow it, it may be worthwhile 
    to relax this restriction. it's in the spirit of the specification in 
    the AMOP to consider such improvements, unless there's some convincing 
    rationale for leaving it alone (perhaps there is, but i can think of 
    no reason myself).

I can't find where AMOP specifically states this restriction (the place
I quoted actually says, "*since* the class of a generic function may not
be changed").  But I believe the intent is to permit implementations to
make compile-time optimizations of calls to standard generic functions
and other implementation-defined generic function classes.  Changing the
class of a generic function would invalidate these optimizations.

                                                barmar
Newsgroups: comp.lang.clos
From: barmar@think.com (Barry Margolin)
Subject: Re: no-applicable-method
Organization: The Ohio State University Department of Computer and Information Science
Date: Thu, 16 Apr 1992 10:28:00 GMT

    Date: Thu, 16 Apr 1992 13:05 EDT
    From: Thomas Kirk <tk@HUNNY.research.att.com>

	From: barmar@think.com (Barry Margolin)

	However, this won't work if you're trying to do this to generic functions
	that you don't define yourself, since you can't override their metaclasses.

    this will work fine. assuming that you can get at the generic functions,
    just change the class of the generic function object, like so:

Sorry, this isn't permitted.  According to p.197 of "The Art of the
Metaobject Protocol", third paragraph, "the class of a generic function
metaobject may not be changed...".

                                                barmar
Newsgroups: comp.lang.clos
From: tk@HUNNY.research.ATt.COM (Thomas Kirk)
Subject: Re: no-applicable-method
Reply-To: tk@research.att.com
Organization: The Ohio State University Department of Computer and Information Science
Date: Thu, 16 Apr 1992 15:10:00 GMT

    From: Barry Margolin <barmar@Think.COM>
    Subject: Re: no-applicable-method

	Date: Thu, 16 Apr 1992 15:53 EDT
	From: Thomas Kirk <tk@HUNNY.research.att.com>

	    From: Barry Margolin <barmar@Think.COM>
	    Subject: Re: no-applicable-method
	    To: tk@research.att.com
	    Cc: mh5l+@andrew.cmu.edu, comp.lang.clos@cis.ohio-state.edu
	    In-Reply-To: <19920416170513.9.TK@PETZL.research.att.com>
	    Message-Id: <19920416182843.6.BARMAR@occam.think.com>

		Date: Thu, 16 Apr 1992 13:05 EDT
		From: Thomas Kirk <tk@HUNNY.research.att.com>

		this will work fine. assuming that you can get at the generic functions,
		just change the class of the generic function object, like so:

	    Sorry, this isn't permitted.  According to p.197 of "The Art of the
	    Metaobject Protocol", third paragraph, "the class of a generic function
	    metaobject may not be changed...".

	true enough. however, given that (a) this is a useful thing to do,
	and (b) many extant CLOS implementations allow it, it may be worthwhile 
	to relax this restriction. it's in the spirit of the specification in 
	the AMOP to consider such improvements, unless there's some convincing 
	rationale for leaving it alone (perhaps there is, but i can think of 
	no reason myself).

    I can't find where AMOP specifically states this restriction (the place
    I quoted actually says, "*since* the class of a generic function may not
    be changed").  But I believe the intent is to permit implementations to
    make compile-time optimizations of calls to standard generic functions
    and other implementation-defined generic function classes.  Changing the
    class of a generic function would invalidate these optimizations.

						    barmar

it's explicit in the paragraph previous to the one you cited. you're 
undoubtedly correct about the supposed intent, which is why one wouldn't 
want to remove all restrictions on changing gf objects. a reasonable 
compromise, instead of prohibiting this outright, would be to put 
restrictions on the new generic function class, and constraints 
on what behavior can change as a result (e.g. out-of-band behavior
that depends on the gf class, like no-applicable-method). 

that several CLOS implementations already allow this is suggestive, 
but only CLOS implementors are likely to know for sure what the 
tradeoffs are.
Newsgroups: comp.lang.clos
From: imai@sakura.bpe.osaka-u.ac.jp (Katsunobu Imai)
Subject: Re:  redefining keys
Organization: The Ohio State University Department of Computer and Information Science
Date: Mon, 6 Apr 1992 12:38:26 GMT

I don't have Extended-keyboard, so I can't test your situation.

I think, you should post this article to comp.lang.lisp.mcl.

The newsgroup comp.lang.lisp.mcl and info-mcl mailing list 
have the same contents.
If you can't access internet news, send your request mail to
info-mcl-request@cambridge.apple.com

-----------
Katsunobu Imai
imai@bpe.osaka-u.ac.jp
Newsgroups: comp.lang.clos
From: dsr@chickpea.mitre.org (Douglas S. Rand)
Subject: Re: CLOS With-Accessors
Organization: The MITRE Corporation
	<19920410191337.6.BARMAR@occam.think.com>
Date: Fri, 10 Apr 1992 20:59:32 GMT

In article <19920410191337.6.BARMAR@occam.think.com> barmar@think.com (Barry Margolin) writes:

       ...
       > spec, which say that WITH-ACCESSORS is equivalent to a use of
       > SYMBOL-MACROLET that replaces the "variable" references with calls to
       > the specified accessor.  Why should this SYMBOL-MACROLET expansion be
       > dependent on how the accessor is defined?

       Don't look at me, I never understood what this sentence is trying to say.

       However, if I was forced to guess, I would guess that the sentence from
       CLtL2 means that with-accessors is only a syntactic transformation: it
       will generate calls to some functions but it won't define the functions
       if they aren't already defined.  You still have to use :accessor or
       :reader or :writer in your defclass, even if you never directly write
       calls to the functions defined there in your program, but only use
       them indirectly via with-accessors.

   That's a possible interpretation.  That's certainly what I *thought* we
   intended to require.

There is a problem with that interpretation though.  with-slots allows
the access (read and write) to slots regardless of the definition
of appropriate access methods,  I can easily imagine that
with-accessors should do the same except with a functional style
in place of a variable style.

IMHO,  orthogonal design should hold excepting cases where it breaks
existing code,  so either with-slots should require :reader, :writer,
:accessor definitions or with-accessors should not require :r, :w, :a.
--
Douglas S. Rand 
Internet:   <dsrand@mitre.org>
Snail:	    MITRE, Burlington Road, Bedford, MA 
Disclaimer: MITRE might agree with me - then again...
Amateur Radio: KC1KJ
Newsgroups: comp.lang.clos
From: Gregor@parc.xerox.COM (Gregor Kiczales)
Subject: Re: Attempting to circumvent Symbolics' Reader Method
	 optimization
Organization: The Ohio State University Department of Computer and Information Science
Date: Wed, 8 Apr 1992 17:58:01 GMT


   Date:	Tue, 7 Apr 1992 17:56:40 -0700
   From:	kab@cambridge.apple.com (Kim Barrett)

   I don't believe there is anything in the specification that requires (or even 
   implies) that the methods defined by DEFCLASS actually call SLOT-VALUE, and I 
   believe this is intentional, as it permits some significant optimizations.

Just to clarify which specification you are talking about here, I assume
you mean the AMOP text, and not the draft ANSI standard.  This problem
seems to be far enough into MOP land that the ANSI standard just doesn't
cover it.

I have just looked through the relevant parts of the AMOP, and indeed it
doesn't seem to explicitly require automatically generated methods to
call SLOT-VALUE (and hence SLOT-VALUE-USING-CLASS).  That is a shame,
because it was certainly our intention that it should do so.  This seems
to have fallen in the crack between the CLOS standard and the AMOP.

The idea is that by defining a method on SLOT-VALUE-USING-CLASS you
should be able to affect all accesses to the slots.  If the
automatically generated methods don't call SLOT-VALUE this won't work.
In fact, the only reason I know of for SLOT-VALUE being in the language
is to support this.  Note that other CLOS-like languages without MOPs
don't have SLOT-VALUE and seem to get along without it.


   The 
   whole point of the class STANDARD-READER-METHOD is that it permits the 
   effective method computation to notice that the only applicable method is one 
   whose definition is understood by the implementation, thereby allowing the 
   access to be inlined in the effective method or even "hoisted" up into the 
   generic function dispatcher.

Its still possible to do the significant optimization, you just have to
be a little bit more careful.  You must notice both that the only
applicable method on the reader generic function is one that is
understood by the implementation and then notice further that the only
applicable method on SLOT-VALUE-USING-CLASS is one that is known to the
implementation.  Then you can do the same optimization.

Gregor
From: hogg@rossem.trl.OZ.AU (Stephanie Hogg)
Newsgroups: comp.lang.c++
Subject: Task Library: AT&T port for sun4s
Keywords: Task, AT&T, sun4
Date: 7 Apr 92 03:57:08 GMT
Followup-To: comp.lang.c++
Organization: TRL

Hi,

Does anyone out there know of a port of AT&T's task library
to sun4s (sparc1) preferrably for the version 2.1 C++ compiler?  
At the moment we have a AT&T task library for sun3s, but have 
been told AT&T's version has not been ported to sun4s.

Any help greatly appreciated.

STephanie.

PS.  Could any replies please be e-mailed: for those for 
whom e-mailed replies are anathema I plead a flakey news 
feed which is currently running a week behind.  If there are
any others interested I will post a summary to this group.

-- 
________________________________________________________________________
Stephanie Hogg				Internet:	s.hogg@trl.oz.au
Telecom Research Laboratories
 PO Box 249 Clayton 3168		Phone:	+61 3 253 6102
 Victoria, Australia			Fax:	+61 3 253 6144
________________________________________________________________________
Newsgroups: comp.lang.c++
From: kdontas@gmuvax2.gmu.edu (Kejitan Dontas)
Subject: Help needed with Linking
Organization: George Mason University, Fairfax, Va.
Date: Wed, 8 Apr 1992 17:08:27 GMT

	Hi,
	    I'm currently trying to link CLIPS 5.0 with my own C source
code, and am having difficulties.  I am using Borland C++ 2.0, but
writing regular C. I have one C source file, and the CLIPS library which
consists of 68 C object files.  Everything compiles, but during linking,
I get 47 error messages of the form:

	'Linker Error : SEGMENT _TEXT exceeds 64K' 

	    This line appears for 47 of the 68 object files in the
library.  I don't believe this is a problem in the library as the files
in it were written by the government (hmm.....) not me.  Am I just
missing an option when linking or compiling ?  Any help will be much
appreciated.  Also, if this is the wrong group for this message, could
someone E-Mail me and suggest a better choice.

			Many thanks in advance,

					Chris

Newsgroups: comp.lang.c++
From: mittle@watson.ibm.com (Josh Mittleman)
Subject: Re: implementing [][] for a 2-D array
Date: Tue, 14 Apr 1992 20:58:13 GMT
Disclaimer: This posting represents the poster's views, not necessarily those of IBM
Organization: IBM T.J. Watson Research Center

The only way to implement [][] is to use two levels of objects.  [][] is
_not_ an operator in C or in C++; it is the application of operator [] to
the results of the first use of [].  Thus:

	object[i][j]

really means:

	object.operator[](i).operator[](j)

Thus, Object::operator[] has to return either an object for which
operator[] is defined or an array (or pointer to an array).  If you want
boundary checking in the second dimension, then the first access must
return a class object.

===========================================================================
Josh Mittleman (mittle@watson.ibm.com)
J2-C28 T.J. Watson Research Center, PO Box 704, Yorktown Heights, NY  10598
From: rmartin@dirac.Rational.COM (Bob Martin)
Newsgroups: comp.lang.c++
Subject: Re: Best C++ Books -- Need Opinions!!!
Date: 9 Apr 92 14:18:29 GMT

scott@swindle.Berkeley.EDU (Scott Silvey) writes:


>% These are my favorite books on C++ and OOD.  I refer to them often.
>% 
>% Object Oriented Design with Applications
>% 	Grady Booch

>How is this book?  Is this the same guy who designed the Booch library?

The book is excellent.  And, yes, it is the "same guy".  Although,
Mike Vilot is very involved as well. 

>Is the book C++ oriented?  Does it have code for working applications?
>Does it emphasize the engineering and algorithmic aspects of OO design or 
>is it just another "this is how you might design a shape library" kind of 
>book?  

The code has examples in C++, Smalltalk, Object Pascal, CLOS and Ada.
But these exammples are not really the thrust of the book.  The book
is a virtual lexicon of OOD information.  It describes the fudemental
principles of OOD in exhaustive detail.  It introduces a very powerful
notation for describing OO design decisions.  It talks about the
"method" of OOD.  And it presents a set of case studies in the
languages I mentioned above.   The book is not to be missed by anyone
who is serious about learning OOD.

>I am looking for something that covers how to "THINK object oriented" as 
>oposed to thinking procedurally (as one would with plain C).

I don't really think you are going to find that in any one book.
Learning to THINK OO is like learning a new language.  First you learn
the basic vocabulary, then some of the grammar rules, then you read
and write it.  Eventually you find you can THINK in it.

Grady's book is an excellent place to start that education.  But to
acheive your goal, you should continue on with the other excellent
works on the subject, and do a lot of OOD experimentation yourself.

>Scott Silvey
>scott@xcf.berkeley.edu
--
+---Robert C. Martin---+-RRR---CCC-M-----M-| R.C.M. Consulting         |
| rmartin@rational.com |-R--R-C----M-M-M-M-| C++/C/Unix Engineering    |
|     (Uncle Bob.)     |-RRR--C----M--M--M-| OOA/OOD/OOP Training      |
+----------------------+-R--R--CCC-M-----M-| Product Design & Devel.   |
Newsgroups: comp.lang.c++
From: jimad@microsoft.com (Jim ADCOCK)
Subject: Re: Assigning values from an object's private data
Date: 13 Apr 92 20:38:57 GMT
Organization: Microsoft Corp.

In article <11975@tamsun.tamu.edu> chetl@donald.tamu.edu (Chet Laughlin) writes:
|WARNING: Potential Newbie question.
|
|I am having trouble getting data held inside a C++ Class available
|to simple variables using the equals operator.  During compilation,
|the compiler does not complain about my class, but does complain
|about my assignment statements.  What am I doing wrong?

You seem to be confused about assignment operators.  Within a class X,
declaring a: 

r operator=(y);

*always* assigns some object y to the class X "this" object, returning
as a side effect the value r.  r is typically "almost always" defined 
to be type "const X&" -- so that the assignment operator returns a
reference to the LHS, as expected for built-in types, except a const,
so that the compiler will not generate a temporary in some situations.

If X can be thought of as analogous to some built-in type [let's say an
"int"], then one might also want to declare a conversion operator for class
X as follows:

	operator int();

The compiler will then automatically apply this conversion whenever an X
appears where context demands an int.  An example being an assignment
to int:

	X x;
	int i = x; 	// X::operator int() applied to x "automagically"

-- which seems to be what you were trying to do.

A common mistake is to take this idea further, and create a bunch of
conversion functions from an X to some other class Y.  This is almost
always a mistake.  If such a conversion makes sense, then what you should
probably do is create a constructor in Y that takes a const X& as a 
parameter.

A further common mistake is to apply one or another of these conversion
techniques in situations where there isn't a strong analogy between the
various types we've been talking about.  In which case an explicitly-called 
access member function is probably a much better choice.
Newsgroups: comp.lang.c++
From: jimad@microsoft.com (Jim ADCOCK)
Subject: Re: Use of SmartPointers
Date: 08 Apr 92 23:51:33 GMT
Organization: Microsoft Corp.

In article <1992Apr2.090559.5358@lth.se> dag@control.lth.se (Dag Bruck) writes:
|In article <1992Mar31.041443.25950@microsoft.com> jimad@microsoft.com (Jim ADCOCK) writes:
|>....  For example, I was told that unless I
|>defended my proposal by physically being present at a meeting my proposal
|>would be considered dead.
|
|Unless you can adequately answer the questions raised in the analysis
|paper (see below), I would agree that that your proposal is dead.
|Being physically present makes it easier to answer questions, but it
|can be done on paper.

I answered the questions raised in Koenig's and Stroustrup's "Analysis..."
paper in email conversations with them.  [Note that about one
paragraph of their paper covers what I proposed]  If other members of
the committee have questions or comments about my proposal, I would be
happy to answer their questions and comments too.

Newsgroups: comp.lang.c++
From: schrod@iti.informatik.th-darmstadt.de (Joachim Schrod)
Subject: Re: Looking for version of 'indent' utility for C++
Date: Tue, 07 Apr 1992 15:10:14 GMT
Organization: TU Darmstadt

In article <1992Apr7.053337.7438@dumbcat.sf.ca.us>, marc@dumbcat.sf.ca.us (Marco S Hyman) writes:
> In article <9204021440.AA07393@vonneumann.ny.jpmorgan.com> chan@vonneumann.UUCP (Milo A. Chan) writes:
>  > I am looking for a version of the unix 'indent' utility which supports the
>  > extended syntax of C++, like //-style comments, "::" scope qualifier, etc.
> 
> You may already have it. [...]
> 
> I'm willing to shar and mail this to anyone who will make it available via
> anonymous FTP.  Any takers?

It's available from

	ftp.th-darmstadt.de
	directory pub/languages/C++
	files indent-C++.6.5.*

In this directory there are also some of the PD class libraries and
other goodies.

--
Joachim

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod			Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany
Newsgroups: comp.lang.c++