HDTenEightyP/NetNews huggingface dataset:
From: knight@mrco.carleton.ca (Alan Knight)
Subject: Re: get/set behaviour (was: >>Voluntary method typing)
Reply-To: knight@mrco.carleton.ca (Alan Knight)
Organization: Carleton University
Date: Wed, 27 Jan 1993 14:25:58 GMT

In <1993Jan27.132905.3865@heeg.de> hasko@heeg.de (Hasko Heinecke) writes:

>In article <1993Jan27.001832.10017@cs.uow.edu.au> humm@cs.uow.edu.au (Bernhard G Humm) writes:
>>
>>hasko@heeg.de writes:
>>
>>In article <1993Jan25.070651.2105@cs.uow.edu.au> humm@cs.uow.edu.au (Bernhard G >Humm) writes:
>>>>>>Of course, this only applies to database-type objects which just have
>>>>>>get/set behaviour, but this seems quite a significant subset.
>>>>
>>>>Are there really any other cases in a pure OO language?
>>>

<Various arguments about the distinction deleted>

The distinction is quite clear from the original post.  It says
"database-type objects which _just_ have get/set behaviour". Clearly
objects have a record structure internally, but they also may provide
a great deal of additional behaviour beyond just setting and getting
the state of instance variables. I believe the original author was
referring to objects which do not provide any additional behaviour and
are thus very much like objects n a database or a "normal" language.

There is also the issue that in an OO language it is not necessary to
provide these get/set methods, so the internal state of an object may
not be (entirely) visible to code not part of that object. e.g.
streams in V/Windows (and probably others) where it is not possible
(withou;t cheating) to directly access the collection over which you
are streaming.  One can only get a copy.


-- 
 Alan Knight  knight@mrco.carleton.ca  +1 613 225 8812
 The Object People, 885 Meadowlands Dr., Suite 509
 Ottawa, Ontario, Canada, K2C 3N2

Newsgroups: comp.lang.smalltalk
From: izzo@enuxha.eas.asu.edu (Donna Marie Izzo)
Subject: Availability of Presentation Objects?
Keywords: smalltalk, presentation objects, graphics
Organization: Arizona State University
Date: Sat, 23 Jan 1993 00:52:03 GMT

I am currently working on my Master's thesis at ASU.  As part
of its implementation, I need to "obtain" some interesting
presentation objects.  I have chosen to develop the prototype
in Smalltalk V using MS Windows.

Does anyone have any information on where I may be able to
obtain some "interesting presentation objects"?  By "interesting
presentation objects", I am referring to objects which display
X-Y plots, pie charts, gantt charts, spreadsheets, etc...  For
those familiar with Motif, something similar to the Widgets
available in the "ICS Widget Databook".

Any information would be appreciated.

Thanks,

Donna Izzo
ASU
"izzo@enuxha.eas.asu.edu"
From: thies@phi-sol.dfki.uni-sb.de (Markus Thies)
Newsgroups: comp.lang.smalltalk
Subject: ST/V PM 1.4 under OS/2 2.0 ? Problem !!
Date: 25 Jan 1993 09:53:48 GMT
Organization: DFKI Saarbruecken GmbH, D-W 6600 Saarbruecken
Distribution: comp
NNTP-Posting-Host: phi-sol.dfki.uni-sb.de


I installed two Smallktalk/V PM 1.4 images under 
OS/2 2.0 (GA German + German SP).

Both run fine under OS/2 1.3, but under OS/2 2.0 they crash with access 
violations within the module PMMLE.DDL. 
They always crash at the same location, as far as can 
interpret from the register information from OS/2 2.0.

Both images extensively use DDE to communicate with each other.

Any hints ?

           Markus.
--
------------------------------------------------------------
Markus Andreas Thies                 thies@dfki.uni-sb.de

DFKI                                 voice: xx49-681-3025253
Stuhlsatzenhausweg 3                 fax:   xx49-681-3025341
6600 Saarbruecken 11
Germany
Newsgroups: comp.lang.smalltalk
Subject: Re: WindowBuilder 2.0 - Bug fixes
From: dugerdil@uni2a.unige.ch
Date: 26 Jan 93 09:17:17 +0200
Organization: University of Geneva, Switzerland

In article <ALOIS.4.0@edvz.uni-linz.ac.at>, ALOIS@edvz.uni-linz.ac.at (Gillhofer Alois) writes:
> Lately I bought Cooper + Peters WindowBuilder 2.0 with Subpans/V for
> Windows. But this product has some bugs.
> 
> So is there anyone who has a list of bug fixes cause I'm not very
> experienced in programming Smalltalk/V.
> 
> Thank you in advance!
> 
> Alois

The fixes are on Compuserve. But C&P distribute a disk with the bug fixes
free of charge to the registered users of WB 2.0. Just send them a fax
or call them directly.

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Philippe Dugerdil
Geneva/Switzerland
dugerdil@uni2a.unige.ch
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Newsgroups: comp.lang.smalltalk
From: konnbt@eua.ericsson.se (Niklas Bjornerstedt)
Subject: ExternalInterface in ST80 
Reply-To: konnbt@eua.ericsson.se
Organization: Enator Functional Systems, Stockholm, Sweden
Date: Fri, 22 Jan 1993 08:06:26 GMT

In working with the C interface in Smalltalk-80 on a SUN I've stumbled on 
a very subtle bug (feature?). This bug applies to Smalltalk on UNIX platforms.

When you create an interface to a C-library you have to supply the name
of the library and a list of paths to where the library should be sought.
This would not work if you ship an image to a site that has its libraries
in a different place. To solve this ObjectMemory sends the update aspect #earlySystemInstallation to the ExternalInterface class on system startup.

The ExternalInterface in turn sends (among other things) 
installLibraryDirectoriesOn: to itself. At this point it would be possible
on a UNIX platform to get an environment variable from the CEnvironment class.
On a SUN the environment variable LD_LIBRARY_PATH stores the path names to
a number of library directories.

But this wouldn't work! 

The reason is that CEnvironment also updates itself on system startup. It 
regenerates its dictionary of environment variables when it receives the
update aspect #returnFromSnapshot. The problem is that ExternalInterface
receives #earlySystemInstallation before CEnvironment receives 
#returnFromSnapshot. 

The result of this is that ExternalInterface would end up getting an old
value for LD_LIBRARY_PATH from CEnvironment. 

The following code fixes this problem. The reason I use Smalltalk at: is 
that I don't want a dependancy between ExternalInterface and CEnvironment.

'From Objectworks\Smalltalk(R), Release 4.1 of 15 April 1992
ENVY/Developer R1.40 of 21 August 1992 on 22 January 1993 at 8:59:54 am'!



!ExternalInterface class methodsFor: 'initialize-release'!

install
        "Inform all dependent classes of a return from snapshot."
        "ExternalInterface install"

        | platformString platformArray platformID cEnv |

        "21 January 1993 - Added initialization of CEnvironment since some of the receiver's subclasses need environment variables that might have changed since the last snapshot. Remove CEnvironment from ObjectMemory since we don't want CEnvironment to initialize itself a second time"
        cEnv := Smalltalk at: #CEnvironment ifAbsent: [].
        cEnv = nil
                ifFalse: 
                        [cEnv install.
                        cEnv checkEnvironment.
                        (ObjectMemory dependents includes: cEnv)
                                ifTrue: [ObjectMemory removeDependent: cEnv]].

        platformString := OSHandle informVM.
        platformID := (platformString copyUpTo: Character space) asSymbol.
        platformArray := Array with: platformID with: platformString.
        self dependentClasses do: [:dependentClass | dependentClass installOn: platformArray].
        self installLibraryDirectoriesOn: platformArray.
        self installSubclassesOn: platformArray.
        CurrentPlatform := platformArray! !


_____________________________

Niklas Bjornerstedt
Enator Functional Systems
Email: konnbt@eua.ericsson.se
From: dvines@syl.dl.nec.com (Don Vines)
Newsgroups: comp.lang.smalltalk
Subject: pure vs hybrid OOPLs
Date: 23 Jan 93 03:28:51 GMT
Organization: NEC Systems Lab., C&C Software Technology Center (Dallas, TX)


Could someone point out a reference or identify some of the design
rationale (benefits) of having a pure OOPL like Smalltalk as opposed
to a hybrid OOPL like C++.

I did not want to start any language wars so I just posted to
comp.lang.smalltalk.  If possible please email the responses
to me.

Thanks

Don
-- 
Donald H Vines, Jr.
NEC Systems Laboratory, Inc.                  Phone: (214)518-3486             
1901 Gateway Dr.                              Fax  : (214)518-3552             
Irving, Texas 75038                           Email: dvines@syl.dl.nec.com   
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Via:        UK.AC.OPEN; 27 JAN 93  9:40:38 GMT
Newsgroups: comp.lang.smalltalk
Date:         Wed, 27 Jan 1993 09:39:11 GMT
From:         J.G.B.Heal@OPEN.AC.UK
Subject:      Re: Voluntary method typing in ST80

>

>
>Faced with a similar problem, I defined a method Class>>accessMethods which
>ran through all the instance variables of a class and defined get and
>set methods for those instance names. Much simpler and much more
>performant. There is a reason for compilers, after all. If you do this,
>Make sure that the generated text contains comments indicating that it is
>mechanically generated, so that later you (or others) won't modifiy the
>method and then lose the modification when accessMethods is rerun.


thanks - I agree your solution is neater/faster etc.  I suppose I just have
a bete-noire about compilation and freezing the type information.  The only
merit of my scheme (as with all interpreted ones) is that I can dynamically
extend the range of 'instance variables'.  e.g. if from time t3 I need to
have a variable 'x' I just send it a setX:99 message.  I don't need to
recompile.  You could recompile, but I'm not sure how to preserve existing
instances (say compiled with 3 instance variables) into a world of 4
instance variables.  Any thoughts about this?


------
Benedict Heal                          tel: (0908) 652695
Faculty of Mathematics                 e-mail: j.g.b.heal@open.ac.uk
The Open University
Milton Keynes
MK7 6AA U.K.
Newsgroups: comp.lang.smalltalk
From: hasko@heeg.de (Hasko Heinecke)
Subject: Re: Inheritance of Smalltalk
Organization: Georg Heeg Objektorientierte Systeme, Dortmund, FRG
Date: Wed, 27 Jan 1993 13:31:58 GMT

In article <1993Jan26.150808.62839@qut.edu.au> bub@qut.edu.au writes:
>Is any one there can tell me if Smalltalk/v windows has the capacity of
>multiple inheritance? What about ParcPlace's Smalltalk in windows?

I know of at least one site, where people implemented multiple inheritance
in ParcPlace Smalltalk. This was quite somme time ago, version 2.3 or so.
Anyway, I don't remember the details, but if you're interested, I can ask
and mail them.

Hasko

-- 
+-------------------------------------------------------+
| Hasko Heinecke @ Georg Heeg Objektorientierte Systeme |
| I _never_ mean what I say - and nobody else does...   |
+-------------------------------------------------------+
Newsgroups: comp.lang.lisp
From: kpc@pluto.arc.nasa.gov (k p c)
Subject: Re: Why Isn't Lisp a Mainstream Language?
Originator: kpc@zog.arc.nasa.gov
Reply-To: kpc@ptolemy.arc.nasa.gov
Organization: NASA Ames Research Center AI Research and Aero Branches;
	Sterling.
	<KPC.93Jan20162253@zog.arc.nasa.gov>
	<1993Jan21.160033.9883@st-andrews.ac.uk>
Date: Thu, 21 Jan 1993 19:22:20 GMT

i like lisp's simple syntax also.

but if adding one or two functions, each less complicated than loop
and format, answers 90% of joe programmer's objections, and if that
will help lisp survive, imho it's worth the cost.  it's not as if we'd
be changing the syntax of the language itself.
-- 
i'm open to comparing research career notes with other cogsci/cogneuro people.
From: davis@passy.ilog.fr (Harley Davis)
Newsgroups: comp.lang.lisp
Subject: Re: Why Isn't Lisp a Mainstream Language?
Date: 28 Jan 93 17:41:44 GMT
Organization: ILOG S.A., Gentilly, France
In-reply-to: bvrotney@ADS.COM's message of 27 Jan 93 07:01:06 GMT


In article <1993Jan27.070106.28425@ads.com> bvrotney@ADS.COM (Bill Vrotney) writes:

   (Arun Welch) writes:

   >   I think an associated question we should be asking is "How can we
   >   increase Lisp's popularity"? Knowing why it isn't popular is a good
   >   thing to discuss, but it would also be good to know where to go from
   >   here. Another question is "Should Lisp be a mainstream language?" I'm
   >   not sure the answer to that is yes. A lot of neat ideas have risen out
   >   of Lisp not having been standardised to death early on. CLOS is a case
   >   in point. If we'd standardised on Interlisp and LOOPS or Zetalisp and
   >   Flavors I think we'd be a lot poorer today. 

   Yes "Where to go from here?" I am disappointed that the Lisp leadership is
   not addressing this question. This begs for something like the Common Lisp
   project but aimed at making Lisp smaller and faster in an organized way.  I
   was reading about a KERNEL lisp specification in Lisp and Symbolic
   Computation. Perhaps something along these lines should be hit with force.
   Lisp leadership where are you? Give us something to be hopeful for.

I suggest you look at EuLisp and Dylan as steps in this direction.  I
would also like to humbly offer Ilog's Le-Lisp version 16 as another
member of this set of modern Lisps which attempt to address the
deficiencies and excesses of previous Lisps, although I have a certain
commercial stake in it.  Also, the emerging ISO Lisp standard is much
smaller than Common Lisp while retaining the most useful features such
as a small, CLOS-like object system.

-- Harley Davis
--

------------------------------------------------------------------------------
nom: Harley Davis			ILOG S.A.
net: davis@ilog.fr			2 Avenue Gallie'ni, BP 85
tel: (33 1) 46 63 66 66			94253 Gentilly Cedex, France
Newsgroups: comp.lang.lisp
From: bvrotney@ADS.COM (Bill Vrotney)
Subject: Re: Why Isn't Lisp a Mainstream Language?
Organization: Advanced Decision Systems, Mtn. View, CA (415) 960-7300
Date: Wed, 27 Jan 1993 07:01:06 GMT


In article <WELCH.93Jan26205611@sacral.cis.ohio-state.edu>
welch@sacral.cis.ohio-state.edu (Arun Welch) writes:

>   I think an associated question we should be asking is "How can we
>   increase Lisp's popularity"? Knowing why it isn't popular is a good
>   thing to discuss, but it would also be good to know where to go from
>   here. Another question is "Should Lisp be a mainstream language?" I'm
>   not sure the answer to that is yes. A lot of neat ideas have risen out
>   of Lisp not having been standardised to death early on. CLOS is a case
>   in point. If we'd standardised on Interlisp and LOOPS or Zetalisp and
>   Flavors I think we'd be a lot poorer today. 

Yes "Where to go from here?" I am disappointed that the Lisp leadership is
not addressing this question. This begs for something like the Common Lisp
project but aimed at making Lisp smaller and faster in an organized way.  I
was reading about a KERNEL lisp specification in Lisp and Symbolic
Computation. Perhaps something along these lines should be hit with force.
Lisp leadership where are you? Give us something to be hopeful for.

As far as Lisp's popularity. When Arabic numerals were first introduced to
people using Roman numerals it took them 400 years to convert to Arabic.
What's new? Forget the Lisp haters. Dwelling on why Lisp is not popular can
lead to no useful activity. If Lisp is a good idea it will still be here
after C++ is gone. Even if Lisp was "perfect" the Lisp haters would not want
to use it, so why try to make them happy. Let's make the people who like
Lisp happy for now, the rest will take its course.

If this thread is going to lead to anything useful I would hope it be to
expose Lisp's weak points and instigate a new Lisp direction to fix them.
For sure, most of those that worked on the Common Lisp project would delight
in an opportunity for another major refinement. Perhaps Clinton's new
technology direction will provide the money to do it.
--
Bill Vrotney
BAH/Advanced Decision Systems
Newsgroups: comp.lang.lisp,comp.unix.solaris
From: dvorak@cscs.ch (Jiri Dvorak)
Subject: Any Common Lisp under Solaris 2.1?
Organization: Centro Svizzero di Calcolo Scientifico / CH-6928 Manno
Date: Tue, 26 Jan 1993 08:48:18 GMT


The title says it all...

I'd like to install Solaris 2.1 on new HW we will get soon. However, 
I need to have a Common Lisp running. Any suggestions? How about the 
binary compatibility mode of Solaris? Will Lisp interpreters, e.g. Allegro 
or Lucid, run under this mode?

Thanks,
Jiri Dvorak                      dvorak@cscs.ch
From: york@oakland-hills.lucid.com (Bill York)
Newsgroups: comp.lang.lisp
Subject: Re: Lisp syntax beauty? (was Re: Why Isn't Lisp a Mainstream Language?)
Date: 25 Jan 93 19:36:47 GMT
	<dfs.727732459@kehleyr> <1jqgecINNjbf@elroy.jpl.nasa.gov>
Reply-To: York@Lucid.COM
Organization: Lucid, Inc.

In article <1jqgecINNjbf@elroy.jpl.nasa.gov> gat@forsight2.jpl.nasa.gov (Erann Gat) writes:

   There is an ongoing discussion on comp.lang.lisp.mcl which might be of
   interest to followers of this thread.  The discussion centers on the issue
   of how to produce small applications using Lisp.  The suggestion has been
   made that Common Lisp should be considered an operating system and not
   an application.  In that case, having a zillion obscure functions is no
   more unreasonable than having a large C library.  (BTW - MCL (Macintosh
   Common Lisp) implements all of CLTL2 and is 1.5 Megabytes, about a tenth
   the size of Allegro.)

Actually, the true beauty of the suggestion was the part where you
take the entire Lisp application, call it an extension (apologies to
the non-Mac-fluent) and have people drop it in the System Folder.
After all, it isn't much bigger than Quicktime.  Then you disguise the
fasl files as "applications" and sit back while everyone marvels at
the compact-but-powerful programs!  And they can inter-operate, too!
Newsgroups: comp.lang.lisp
From: glp@fig.citib.com (Greg Parkinson)
Subject: Franz Allegro vs. Lucid
Originator: glp@merlin
Organization: Citibank IBISM
Date: Wed, 27 Jan 1993 18:31:52 GMT


We're trying to decide whether to go with Allegro
or Lucid for our Sparcs.

What I've heard so far tends to favor Allegro - 
its development interface and Franz's customer
service are mentioned as being superior.

Any comments by other people who had to make the
same decision would be appreciated.

-- 
Greg Parkinson                  Phone: 212-657-7814  Fax: 212-825-8607
Citibank,111 Wall Street        E-Mail: glp@fig.citib.com
New York, New York  10043
The opinions expressed are my own and not those of the big 'ol bank.
Newsgroups: comp.lang.lisp
From: glp@fig.citib.com (Greg Parkinson)
Subject: Re: Lisp syntax beauty? (was Re: Why Isn't Lisp a Mainstream Language?)
Originator: glp@merlin
Organization: Citibank IBISM
Date: Wed, 27 Jan 1993 17:58:15 GMT


In article <dfs.727981585@kehleyr>, dfs@doe.carleton.ca (David F. Skoll) writes:

|>  And Lisp is not cheap - if you want to distribute Lisp
|> applications, you usually have to pay $$$ to the Lisp vendor to
|> distribute Lisp run-time licenses.  Also, the good Common Lisp
|> compilers are not free - are quite expensive, in fact.

It depends on what you think is "quite expensive".
I wouldn't call $7500 outrageously expensive,
considering what you get.  Compared to payroll
and hardware costs, it's negligible.

|>  Compare this
|> to C, for example, which has no run-time royalties, and has a free
|> ANSI-standard compiler.

The run-time is a difference, but Franz will charge
you a one-time fee of $2500 for all the run-times
you want ($5000 if you're going to sell them.)
Again, not a whole lot of money.

Of course, it depends on your environment.  I can
pay back the cost of a two-person-year project 
including hardware and software by preventing
*one* mistake.  

And fine, you can get a free C compiler.  How much are
you going to pay for a development environment to match
what your $7500 for Lisp includes?  

-- 
Greg Parkinson                  Phone: 212-657-7814  Fax: 212-825-8607
Citibank,111 Wall Street        E-Mail: glp@fig.citib.com
New York, New York  10043
The opinions expressed are my own and not those of the big 'ol bank.
Newsgroups: comp.lang.lisp
From: john@thelonius.mitre.org (John D. Burger)
Subject: Lisp vs English (was Re: Why Isn't Lisp a Mainstream Language?)
Organization: Artificial Intelligence Center, MITRE Corporation, Bedford, MA
Date: Wed, 27 Jan 1993 00:02:53 GMT

Randy Crawford (crawford@boole.mitre.org writes:

  Not only is english an unstructured language (as compared with programming
  languages) ...

Well, any grammar for English would be far larger and more complex than for any
programming language (except maybe CommonLisp :), but I don't think I'd call
English unstructured.

  ... but parsing english is legendary for its difficulty.

Hmm, I have very little difficulty.  :)

  Without punctuation and semantic context, it's trivial to write correct english
  which is effectively illegible; that's illegible to man _or_ machine.

You must make a distinction between syntactic correctness and understanding.  I'm
not sure which you mean by "illegible", but if I can't parse your trivially
written sentence, and few other English speakers can either, then it ain't
English, by definition.

On the other hand, maybe you meant "understand-ability"; you're correct in that
it's easy to construct syntactically valid English sentences that I can't
understand, but that's true for programming languages as well.  I submit that the
C code for the phone system is not understandable "to man _or_ machine".  It's
EXECUTABLE, but so what?  Very little code is understandable, as in "what does
this do, in all circumstances", to machine.  Witness all the research on program
verification.

Of course, none of this distinguishes Lisp from any other programming language,
but I just wanted to suggest that as far as "legibility" (which I read as
"understand-ability") is concerned, natural and programming languages are perhaps
not that different.

John Burger                                               john@mitre.org
From: cgay@sisters.cs.uoregon.edu (Carl L. Gay)
Newsgroups: comp.lang.lisp
Subject: Re: Lisp syntax beauty? (was Re: Why Isn't Lisp a Mainstream Language?)
Date: 22 Jan 93 23:51:21 GMT
	<19930122162651.0.SWM@SUMMER.SCRC.Symbolics.COM>
	<dfs.727723285@noonian> <1jpe0qINNnf1@tamsun.tamu.edu>
	<dfs.727729181@crusher>
Reply-To: cgay@cs.uoregon.edu
Organization: Amalgamated Consolidated, Incorporated
X-Headline: DISTRAUGHT UO UNDERGRAD LOOKS UNDER SKIRT OF FORMER AI HIGH FLYER!!!


   Newsgroups: comp.lang.lisp
   From: dfs@doe.carleton.ca (David F. Skoll)
   Date: Fri, 22 Jan 1993 18:59:41 GMT

   >>who really needs the number 394829348234982435 formatted in English words??
   >>Just try (format t "~R~%" 394829348234982435) for fun!

   Actually, it wouldn't be too bad in C (if you can ignore the
   fixnum/bignum problems :-)) I agree that Lisp has many built-in
   conveniences.  Maybe too many - we have Allegro Common Lisp on our Sun
   network, and the image is 11MB long.  That's a huge overhead, and
   anyone supporting the full Common Lisp spec probably couldn't do it in
   much less.

I couldn't just let this one go by.  The image for Macintosh Common
Lisp is ~1.5 MB, which includes the programming environment.  (I have
no idea why the Allegro image is so big...)

   I like Lisp.  I've worked on a large CAD program, and for that, Lisp
   was great.  But for small-to-medium programs, I find the overhead of
   Common Lisp way too high.