HDTenEightyP/NetNews huggingface dataset:
From: cantwell@vuse.vanderbilt.edu (Jeff Cantwell)
Subject: PPR4 on Powerbook 140??
Keywords: FPU 68881 68882
Organization: Vanderbilt University School of Engineering, Nashville, TN, USA
Date: Tue, 14 Apr 1992 18:43:25 GMT

I'd like to use PPR4 on a Powerbook 140. One obvious problem is the
lack of an FPU.  Does SoftwareFPU (a shareware program) allow one to
use PPR4 on the Powerbook 140?  Someone please say "yes"!
-- 
Jeff Cantwell, Vanderbilt U. CIS Box 1804, Sta. B Nashville, TN 37235 
  Internet: cantwell@vuse.vanderbilt.edu Bitnet: CANTWEJR@VUCTRVAX
	Phone: (615) 322-0110  Fax: (615) 343-6449
       2 Cor. 12:9 "Power is perfected in weakness."
Newsgroups: comp.lang.lisp,comp.lang.postscript
From: mkant+@CS.CMU.EDU (Mark Kantrowitz)
Subject: Re: Lisp dialect as front end to PostScript
Date: Fri, 10 Apr 92 01:02:46 GMT
Organization: Carnegie Mellon University

In article <1992Apr6.220502.12960@adobe.com>, yost@adobe.COM (David Yost)
writes:
|> Imagine PostScript, but with lisp syntax and lisp macros.
|> I.e. a lisp dialect that translates more or less directly
|> to PostScript.
|> 
|> Has anyone done such a thing?

See "PLisp, A Lisp to Postscript Compiler", by John C. Peterson, University of
Arizona, TR 86-29, December 1986.

--mark
From: barmar@think.com (Barry Margolin)
Newsgroups: comp.lang.lisp
Subject: Re: ``unwind-protect'' eval
Date: 6 Apr 1992 16:16:20 GMT
Organization: Thinking Machines Corporation, Cambridge MA, USA
NNTP-Posting-Host: telecaster.think.com
Keywords: error handler

In article <18342@ector.cs.purdue.edu> yeh@cs.purdue.EDU (Wei Jen Yeh) writes:
>  Is it possible to recover after you're thrown out to the top-level?

Not *after*, but you can provide a way to intercept and/or allow the user
to throw to your own routine instead of the Lisp top-level.

>I need to implement something like

[his own read-eval-print loop]

>How does one recover from the eval call when error occurs?  The
>book says that no standard way of error handling is defined, since they
>have not found a satisfactory one.  Hm...

That book (CLtL, I presume you're referring to) is out of date.

>What are the error-handling mechanisms of
>current CL dialects?  BTW, the particular code is to run under akcl/TopCL.

Most current dialects implement the condition system described in Chapter
29 of CLtL, 2nd Edition.  I'm not directly familiar with TopCL, but I'll
bet it does.  However, I'm not so sure about AKCL; if (macro-function
'handler-bind) returns NIL then it doesn't implement it.

If you want to provide your own restart option in the debugger, so that the
user can go back to your loop, use RESTART-BIND or one of its derivatives,
RESTART-CASE or WITH-SIMPLE-RESTART.  For instance, your r-e-p loop might
look like this:

(let ((cmd NIL))
  (loop (restart-case
	    (progn
	      (setq cmd (getline))
	      (if (registered_service cmd)
		  (myapply (symbol-function (1st cmd)) (rest cmd))
		  (eval cmd)))
	  (abort () :report "Return to registered-service top-level."))))

This won't *prevent* someone from choosing the restart that exits your
program and goes out to the normal Lisp top-level, but it will force him to
do so consciously.  Most systems provide a shortcut for choosing the most
recent ABORT restart, so the above code will cause your restart to be
chosen when that's done.

If the above doesn't meet your needs, other things you may find relevant
may be *DEBUGGER-HOOK* and HANDLER-CASE or HANDLER-BIND.
-- 
Barry Margolin
System Manager, Thinking Machines Corp.

barmar@think.com          {uunet,harvard}!think!barmar
Newsgroups: comp.lang.lisp
From: u3428aa@unx.ucc.okstate.edu (Jayaram Ramanathan)
Subject: OPS5 in the public domain?
Organization: Oklahoma State University Computer Center
Date: Tue, 7 Apr 1992 17:03:53 GMT

I'm interested in finding out if there's a version of OPS5 available
for PCs.  Also, is OPS5 available in the public domain, that can be
ftp'ed?

Any info would be appreciated.

Jay Ramanathan
u3428aa@unx.ucc.okstate.edu
From: gaynor@blaze.rutgers.edu (Silver)
Newsgroups: comp.lang.lisp
Subject: scheme parameter frames
Date: 14 Apr 92 04:53:22 GMT
Reply-To: gaynor@paul.rutgers.edu
Organization: Rutgers Univ., New Brunswick, N.J.

Peace-of-mind request.  I get the impression that the frame for associating
parameters for a function call remains accessable after the call completes.
("Off the stack", if you will.)  For example,

    (define (foo a)
      (define (bar b)
        (write a)
        (newline)
        (set! a b)
        a)
      bar)
    foo

    (define bar (foo 1))
    bar

    (bar 2)
    1
    2

    (define baz (foo 100))
    baz

    (bar 3)
    2
    3

I do have this right, don't I?  I think so...

Anyone care to comment on semantic and efficiency issues?

I'm a little uncomfortable with the notion of a physical attribute of a
function call persisting beyond the invocation.  What do you think are
reasonable alternatives in resolving the reference?  Make it unbound or voided
in some way?  This is kind of inefficient, heap-intensive, no?  Well, seems
that this cost can be written off under the assumption that most functions
don't provide access to their invocation frames after invocation, and that this
condition can be detected statically and subject to relatively easy
optimization.

Regards, [Ag]
Xref: sparky comp.lang.lisp:1369 comp.lang.misc:1654 comp.lang.objective-c:254
From: stephen@estragon.uchicago.edu (Stephen P Spackman)
Newsgroups: comp.lang.lisp,comp.lang.misc,comp.lang.objective-c
Subject: Re: Survey on future of Object Oriented Programming
Date: 12 Apr 92 01:07:12 GMT
Organization: University of Chicago CILS

While I don't doubt that the OO fad will result in some excesses, has
it never occurred to you that as a paradigm it is about as balanced as
logic programming, and is doomed from the start? It's certainly FAR
from what you want for serious engineering purposes.

OO is just scheme with - if you are very lucky - type checking in the
wrong places. Expect it to be superceded within the decade, possibly
by a debugged and mutated Haskelloid - maybe this will take 20 years
for the marketplace as a whole, but I think that's grossly
pessimistic.

In any event, I see no way of fitting this view into your survey,
since you seem to REQUIRE us to answer that by 2050 you will need to
use an OO language to own a dog.

You'll note that a background in C never reached a requirement for 50%
of hires, and C had a much better run at the slope.
----------------------------------------------------------------------
stephen p spackman         Center for Information and Language Studies
stephen@estragon.uchicago.edu                    University of Chicago
----------------------------------------------------------------------
Newsgroups: comp.lang.lisp
From: SWM@sapsucker.scrc.symbolics.com (Scott McKay)
Subject: Ideas for new LISP Machines
X-Unparseable-Date: Fri
Organization: LCS news/mail gateway
Date: Fri, 10 Apr 1992 21:03:48 GMT

    Date: Tue, 7 Apr 1992 17:07 EDT
    From: "David V. Wallace" <gumby@cygnus.com>

       Date: 7 Apr 92 19:54:48 GMT
       From: wilson@cs.utexas.edu (Paul Wilson)
							     (I think most
       of the costs of floats are the compiler's problem, not the hardware's;
       with good inlining, dataflow analysis, etc., most floats can be raw
       untagged values on the stack or in registers.

I disagree that this is the compiler's problem.  In addition to
providing incredibly useful hints for robust garbage collectors, tags
also provide the same sort of hints for better debuggers.  Furthermore,
with manifest data types in memory, the common C/C++ problem of tracking
down wild pointers becomes a thing of the past.  Is a pair of tag bits
on every memory word too high a price to pay for a giant step forward in
robust software?

    This makes scavenging the stack painful if you're doing realtime gc in
    another execution thread.
From: davis@madeleine.ilog.fr (Harley Davis)
Newsgroups: comp.lang.lisp
Subject: Re: Lelisp -> Common Lisp
Date: 6 Apr 92 12:23:38 GMT
	<1992Apr2.091242.3285@cenaath.cena.dgac.fr>
Organization: ILOG S.A., Gentilly, France
In-reply-to: mertz@cenaath.cena.dgac.fr's message of 2 Apr 92 09:12:42 GMT


In article <1992Apr2.091242.3285@cenaath.cena.dgac.fr> mertz@cenaath.cena.dgac.fr (Christophe MERTZ (CR2A)) writes:

   (Gilles Fouque) writes: 
 
     I am looking for information in order to translate Lelisp
     programs (lisp implementation created by the INRIA and
     commercialized by ILOG company, France) into Common-Lisp
     programs. I do not think that any translator exists but maybe
     someone knows something about the difficulties and the traps of
     this translation.

   I know that ILOG is working on a translator from le_lisp V15 to
   Le_lisp V16.  Le_lisp V16 will be very near from common lisp.

   For more informations e-mail to sennechael@ilog.fr

I am the author of the above-mentioned translator.  It does a fairly
good job on Le-Lisp v.15 to v.16, but would not help someone
translating to CommonLisp for a variety of reasons, not least of which
is that it is bundled with sales of Le-Lisp v. 16.

Le-Lisp v.16 is close to CommonLisp in the following ways:

 * It is lexically scoped with closures.
 * It is special-form based, and the set of special forms has a large
   intersection with those of CommonLisp.
 * It has a CLOS-like object system with a metaobject protocol.
 * The lambda-list syntax is like CommonLisp's.

However, Le-Lisp v.16's package system is rather different.  Instead
of using packages for both namespace division and modularity, Le-Lisp
v.16 uses packages purely for namespaces, and has modules for
modularity.  Also, the libraries are largely those of Le-Lisp v.15
rather than those of CommonLisp.

In general, the biggest problems in true source-to-source translations
of Lisp dialects arise from macros.

-- 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
From: barmar@think.com (Barry Margolin)
Newsgroups: comp.lang.lisp
Subject: Re: (typep foo 'type) ??
Date: 14 Apr 1992 23:32:11 GMT
Organization: Thinking Machines Corporation, Cambridge MA, USA
NNTP-Posting-Host: telecaster.think.com

In article <1992Apr14.181729.25402@walter.bellcore.com> Ralph Hill <rdh@thumper.bellcore.com> writes:
>Given a variable that claims to name a type, is there a way to find out
>that it really names a type?

No, there isn't.  X3J13 considered adding a TYPE-SPECIFIER-P function, but
we couldn't agree on its requirements.  In particular, how much syntax and
validity checking would it have to do?  Would (type-specifier-p '(integer
n)) return T (because it has the correct format for an INTEGER type
specifier) or NIL (because the argument to the INTEGER type specifier isn't
an integer or *)?  Should (type-specifier-p '(satisfies foo)) check whether
FOO currently names a function?

It gets even harder when user-defined type specifiers are involved.  If we
decide that TYPE-SPECIFIER-P must detect invalid type specifier arguments,
then there must be a way for it to determine this for types defined with
DEFTYPE, so it must catch errors that they signal.  This then leads to
strange cases like this:

(deftype random-type ()
  (if (zerop (random 2))
      'integer
      (error "No such type")))

(type-specifier-p 'random-type) would randomly return T or NIL.  If the
intent were to do

(when (type-specifier-p foo)
  (typep object foo))

in order to prevent errors from the TYPEP, it wouldn't work.

But if TYPE-SPECIFIER-P doesn't try to detect invalid arguments to type
specifiers then it isn't much use.

We eventually punted.  If you're calling TYPEP or SUBTYPEP with a
caller-supplied type specifier and you're not sure whether it's valid, put
a condition handler around the call.  This isn't guaranteed to work (for
some reason TYPEP is specified as having undefined consequences, rather
than signalling an error, if the type specifier argument isn't a type
specifier), but it will probably work in most implementations.
-- 
Barry Margolin
System Manager, Thinking Machines Corp.

barmar@think.com          {uunet,harvard}!think!barmar
From: lenting@cs.rulimburg.nl (Jacques Lenting)
Newsgroups: comp.lang.lisp
Subject: Beggar's plea: free/cheap Common Lisp
Date: 10 Apr 92 12:43:12 GMT
Reply-To: lenting@cs.rulimburg.nl (Jacques Lenting)
Organization: University of Limburg, Maastricht

I need a Common Lisp environment to run the MICE testbed on. Unfortunately,
there is hardly any budget available. Somebody told me that there is a public
domain version of Common-Lisp "at some Japanese university". Does anyone know
of an ftp (or email or postal) address of this or another site where Common
Lisp is obtainable without charge or at low cost?

Thank you!

Jacques Lenting
Newsgroups: comp.lang.lisp
From: SWM@sapsucker.scrc.symbolics.com (Scott McKay)
Subject: Re: features from Icon Language in lisp
X-Unparseable-Date: Thu
Organization: LCS news/mail gateway
Date: Thu, 16 Apr 1992 15:39:34 GMT

    Date: Wed, 15 Apr 1992 12:43 EDT
    From: "Richard L. Goerwitz" <goer@ellis.uchicago.edu>

		       LISP, of course, isn't object-oriented (yes, another
    level of indirection that seems to be the rage these days).  LISP
    people are always quick to point out that you can do object-oriented pro-
    gramming in LISP, but this is also true of C, Pascal, or even assembler.

This will come as a real surprise to the people who have been using CLOS
(Common Lisp Object System, a part of the X3J13 Common Lisp standard,
and supported by all major Lisp vendors) for the past several years, and
Flavors, New Flavor, Loops, etc., some of which have been around since
about 1980.
From: yeh@cs.purdue.EDU (Wei Jen Yeh)
Newsgroups: comp.lang.lisp
Subject: ``unwind-protect'' eval
Keywords: error handler
Date: 6 Apr 92 06:23:21 GMT
Organization: Department of Computer Science, Purdue University

Hello,
  Is it possible to recover after you're thrown out to the top-level?
I need to implement something like
  (let ((cmd NIL))
       (loop (setq cmd (getline))
             (if (registered_service cmd)
                 (myapply (symbol-function (1st cmd)) (rest cmd))
                 (eval cmd))))

How does one recover from the eval call when error occurs?  The
book says that no standard way of error handling is defined, since they
have not found a satisfactory one.  Hm...

I guess I can use the brute-force way of intercepting the "Error:" keyword
and re-invoking the main loop.  What are the error-handling mechanisms of
current CL dialects?  BTW, the particular code is to run under akcl/TopCL.

Thanks.

Wei Jen Yeh                      yeh@cs.purdue.edu
                                 Department of Computer Science
                                 Purdue University
                                 West Lafayette, Indiana
From: sam@staypuffed (Sam Griffith)
Newsgroups: comp.lang.lisp
Subject: How does one get a lisp job?
Keywords: Lisp, CLOS
Date: 13 Apr 92 20:57:37 GMT
Reply-To: sam@pencom.com
Distribution: usa
Organization: Pencom Software

I am a accomplished OOP programmer, and I've been interested in getting a job  
involving Lisp/CLOS.  I was wondering how to go about it, since I'm just  
learning Lisp, but have a strong OOP background.

--
Sam Griffith Jr.
Pencom Software
sam@pencom.com
From: kuroda@msi.co.jp (Hisao Kuroda)
Newsgroups: comp.lang.lisp
Subject: Re: More informative prompt from Lucid CL
Date: 14 Apr 92 12:08:23 GMT
	<EB.92Apr3115152@watergate.lucid.com>
Organization: Mathematical System institute Inc, Japan
In-reply-to: eb@lucid.com's message of 3 Apr 92 19:51:52 GMT

In article <EB.92Apr3115152@watergate.lucid.com> eb@lucid.com (Eric Benson) writes:

 ;
 ;In article <1992Apr3.012528.6344@cs.cornell.edu> raman@cs.cornell.edu (T. V. Raman) writes:
 ;
 ;
 ;   How do I set up things so lucid shows the current package as part of
 ;   the prompt?
 ;
 ;This is unofficial, of course, but is likely to work in all Lucid
 ;Common Lisp products available now and in the near future:
 ;
 ;(defun lucid::prompt ()
 ;  (format nil "~A> " (package-name *package*)))

Is there similer way for CMU-CL ?

thank you
--

Mathmatical Systems Institute Inc.			Hisao Kuroda
6F AM BLDG. 2-5-3 Shinjuku, Shinjuku-Ku			301, 1-22-2 Kyonan-cho
Tokyo, Japan 160					Musashino-shi,
E-mail : kuroda@msi.co.jp (Kuroda,Hisao)		Tokyo, Japan 180

    Everybody's got something to hide exept me and my //GS.
From: lafourca@imag.fr (Lafourcade Mathieu)
Newsgroups: comp.lang.lisp
Subject: LISP Cards on Macintosh
Date: 15 Apr 92 12:54:18 GMT
Organization: IMAG-GETA, Universite de Grenoble, France

I would like to buy a LISP card (Machine ?) for the Macintosh.
Where can I find inoformation about performances, compatibility and ... price.
I am currently using Common Lisp (MCL on the Mac) and CLOS.

- Mathieu
From: sweeney@husc3.harvard.edu
Newsgroups: comp.lang.lisp
Subject: Re: Dictionary of Spellings
Date: 16 Apr 92 17:09:24 GMT
Organization: Harvard University Science Center

We need a dictionary of spellings to test some linguistic learning 
algorithms. In particular, we are seeking an ASCII file of several 
thousand unique words, with or without affixes. 

Attempts to produce such a file from random documents fails to produce a 
high number of unique words. The DEC PDP-10 (about 10 years ago) used 
such an ASCII file of spellings. Does anyone have an ASCII file of 
words?

If anyone can provide such a file or have any pointers, please contact
me. Thank you for your assistance.

-Latanya Sweeney
email: sweeney@husc3.harvard.edu
From: barmar@think.com (Barry Margolin)
Newsgroups: comp.lang.lisp
Subject: Re: packages
Date: 13 Apr 1992 00:44:26 GMT
Organization: Thinking Machines Corporation, Cambridge MA, USA
NNTP-Posting-Host: gandalf.think.com

In article <MROSE.92Apr12120716@kali.stsci.edu> mrose@stsci.edu writes:
>I don't want to replace common-lisp:reduce, but it's not clear if I
>would be better off putting
>  (shadow 'reduce)
>  (export 'reduce)
>in my file, or if it's better to put those in the defpackage.
>What are the trade-offs here?

In general, it's better to do all your package setup with DEFPACKAGE, and
compile/load this before anything that uses the package.  It guarantees to
do everything in the write order.

>Also, CLtL2 pp269, discussing SHADOW, has the cryptic sentence
>   Shadow should be used with caution.  It changes the state of the
>   package system in such a way that the consistency rules do not hold
>   across the change.
>What does this mean?

It's referring to things like the print-read consistency rules that are
described a few pages earlier (sorry, I don't have my copy here, so I can't
give the page reference).  Normally, if you print a symbol and later read
that printed representation, you will get back the same symbol.  But if the
symbol was inherited, and you shadow it between the print and read, the
printed representation will be read as the shadowing symbol rather than the
symbol that was originally printed.

This is why it's generally best to do all your package manipulations before
you use the package.
-- 
Barry Margolin
System Manager, Thinking Machines Corp.

barmar@think.com          {uunet,harvard}!think!barmar
From: delacour@waxwing.parc.xerox.com (Vincent Delacour)
Newsgroups: comp.lang.lisp
Subject: Re: Ideas for new LISP Machines
Date: 10 Apr 92 22:33:48 GMT
Distribution: comp.lang.lisp
Organization: Xerox PARC, Palo Alto, CA


In article <19920410210242.2.SWM@SUMMER.SCRC.Symbolics.COM> SWM@sapsucker.scrc.symbolics.com (Scott McKay) writes:

>   [...]
>   down wild pointers becomes a thing of the past.  Is a pair of tag bits
>   on every memory word too high a price to pay for a giant step forward in
                         ^^^^^^^^^^^^^^^^
>   robust software?


Well, it depends on your notion of price. Are you telling that it's a
pity the constructors of cheap machines don't include tagged memory in
it ? go and tell'em. If my memory serves me right, Symbolics also
makes machines, no ? 

As a constructor, you can not express your regrets that the OTHER
constructors take the wrong approach, as well as the OTHER software
makers, etc. Since you are in the arena, just show the way by selling
popular, cheap machines with a tagged architecture, much software,
less idiosyncrasy than the current Symbolics, decent multitasking,
etc. I'd buy it I promise you.

I really don't understand your insistence on this point. Do you intend
to say that only because Symbolics exists (and has the market's share
it has), everybody else is wrong ?

	Vincent
Newsgroups: comp.lang.lisp
From: hall@aplcen.apl.jhu.edu (Marty Hall)
Subject: Re: Ideas for new LISP Machines [pricing]
Reply-To: hall@aplcen (Marty Hall)
Organization: AAI Corp AI Lab, JHU P/T CS Faculty
Date: Mon, 6 Apr 92 14:07:02 GMT


rpg@cs.tulane.edu (Robert Goldman) writes:
[Re Symbolics pricing]

>2.  you have to buy symbolics + unix boxes, if you buy symbolics as
>opposed to just buying unix boxes.

Very true. Still do. We use our Symbolics for LISP and the 
Suns for everything else (FrameMaker, C, etc.), so a Symbolics 
is clearly not  useful unless you do a *lot* of LISP.

>3.  Sun gave a much bigger academic discount

No longer true, however. We have purchased both Symbolics and
Suns this year for the program I work at the Johns Hopkins
Applied Physics Lab, and Symbolics discounts have been
much better. They give 45% off all hardware and hardware
maintenance, and usually charge a flat rate of $500 for
any of their unbundled software, no matter the original
price.

This pricing policy is only a couple of years old.

					- Marty
------------------------------------------------------
hall@aplcen.apl.jhu.edu, hall%aplcen@jhunix.bitnet, ..uunet!aplcen!hall
Artificial Intelligence Lab, AAI Corp, PO Box 126, Hunt Valley, MD 21030

(setf (need-p 'disclaimer) NIL)