HDTenEightyP/NetNews huggingface dataset:
Newsgroups: comp.lang.lisp
Date: Sun, 22 Nov 1992 10:54:53 -0500 
From: William.Lott@cs.cmu.edu
Subject: Re: Release Info. on CMU Common Lisp

Andrew Joseph Kompanek <ak10+@andrew.cmu.edu> writes:
> Can anyone supply me with the following info. on CMU Common Lisp:
> 
> 1.  Version and date of most recent version.  Is the version 16e?

The ``omega'' release is 15e dated Feb 25, 1992.
The ``beta'' release is 16e dated Aug 5, 1992.
[We also have an internal alpha release, but you don't to know about
that.  Some days I wish I didn't. :-) ]

For details as to what is in each release, pick up the files:

	omega-release-notes.txt
	beta-release-notes.txt

from our release area:

	/afs/cs/project/clisp/release/

For those without access to AFS, you can use anonymous ftp to one of
the following machines:

	lisp-rt1.slisp.cs.cmu.edu [128.2.217.9]
	lisp-rt2.slisp.cs.cmu.edu [128.2.217.10]
	ftp.cs.cmu.edu [128.2.206.173]

> 2.  Should non-Sun users update from 16d to 16e?

Depends on whether or not you want/need the bug fixes/improvements to
be found in 16e.  Check out the beta-release-notes for details as to
what they are.

> 3.  When is the newest version due?  Major Revisions?

Currently, we don't have any hard plans for the next release.  We are
trying to get some of the PCL problems worked out, and when we do we
will probably put out a 16f that includes them and whatever other
random bug fixes we think are stable enough.

It will probably be a while before a version 17 based release sees the
light of day.

> Will the info. to this board?  Is there are a mailing list that anyone
> is aware of?

We post information about new releases to this newgroup.  Queries and
bug reports can be sent to cmucl-bugs@cs.cmu.edu.

-William Lott
CMU Common Lisp Group
From: charest@Aig.Jpl.Nasa.Gov (Len Charest)
Subject: Re: Elegant control structure wanted
Reply-To: charest@aig.jpl.nasa.gov
Organization: NASA/Jet Propulsion Laboratory
Date: Thu, 19 Nov 1992 22:31:54 GMT

In article <98373@netnews.upenn.edu>, zaidel@muzungu.cis.upenn.edu (Martin J. Zaidel) writes:
|> I've written an equality predicate to test two structures.  My
|> predicate is of the form:

|> (defun node-equal (node1 node2)
|>    (and (if (slot1-equal slot1 slot2) 
|> 	    t
|> 	    (format t "Slot 1 not equal"))
|> 	(if (slot2-equal slot1 slot2)
|> 	    t
|> 	    (format t "Slot 2 not equal"))
|> 	(if (slot3-equal slot1 slot2)
|> 	    t
|> 	    (format t "Slot 3 not equal"))))
|> 
|> This explicit use of T for the value of the IF strikes me as rather
|> inelegant.  I'd appreciate suggestions for a nicer solution.

Did you mean to write 'node1' and 'node2' instead of 'slot1' and 'slot2'?
Relying on the fact that FORMAT returns NIL:

(defun node-equal (node1 node2)
  (and (or (slot1-equal node1 node2)
           (format t "..."))
       ...and so on ))
..................................................
                                  Len Charest, Jr.
                 JPL Artificial Intelligence Group
                          charest@aig.jpl.nasa.gov
From: barmar@think.com (Barry Margolin)
Newsgroups: comp.lang.lisp
Subject: Re: *READ-SUPPRESS* and #P syntax
Date: 16 Nov 1992 21:17:06 GMT
Organization: Thinking Machines Corporation, Cambridge MA, USA
NNTP-Posting-Host: telecaster.think.com

In article <1992Nov15.210151.1062@wstar.mixcom.com> jpf@wstar.mixcom.com (John P. Flanagan) writes:
>Consider Steele's comments from section 22.1.4, p.537 in CLtL2 with
>regard to `#P"..." is equivalent to #.(parse-namestring "...")':
>["I interpret the intent of the vote to be that #p reads a following form,
> which should be a string, that is then converted to a pathname as if by
> application of the standard function parse-namestring."]

Those comments are just what you said they are: Steele's comments.  They
are not part of the standard, nor are they binding on implementors.  If we
want to require that all implementors perform similarly in this respect, we
must make them official by changing the draft accordingly.

I'll submit a review comment to this effect.

>Similar reasoning should also apply to the #C, #(, and #' macros although
>an example involving the #( reader macro on p.23-22, section 23.2 of the
>dpANS appears to suggest otherwise, i.e., #(a b c) becomes #(nil nil nil) 
>rather than nil.  The last paragraph before the examples says, "#( notation
>continues to delimit vectors"; it doesn't say, "#( notation continues to
>delimit [and construct] vectors" as is true with parentheses.

My interpretation of *READ-SUPPRESS* is that when it doesn't say something
operates differently from normal, it should operate the normal way.  Thus,
#( continues to construct vectors because it doesn't say that it doesn't.
Notice that when it's describing (, the words "and construct" are in
parentheses.  I interpret this to mean that it's just stating the obvious;
it wasn't repeated in the following sentence because it's even more obvious
because it was stated explicitly but parenthetically in the previous
sentence.
-- 
Barry Margolin
System Manager, Thinking Machines Corp.

barmar@think.com          {uunet,harvard}!think!barmar
From: barmar@think.com (Barry Margolin)
Newsgroups: comp.lang.lisp
Subject: Re: Lucid bug in delete-if?
Date: 18 Nov 1992 08:44:43 GMT
Organization: Thinking Machines Corporation, Cambridge MA, USA
NNTP-Posting-Host: gandalf.think.com

In article <KRULWICH.92Nov16104949@zowie.ils.nwu.edu> krulwich@zowie.ils.nwu.edu (Bruce Krulwich) writes:
>Have any implementations ever tried to handle destructive modification of the
>first element of a list by RPLACA'ing the first cons cell to the first element
>of the desired list?

I've never heard of anyone doing it, although it's allowed.

>(Not that this would completely obviate the need to SETF the result of a
>destructive operation, but I was just curious.)

Since it doesn't solve the problem (you still have to do the assignment if
the result of the modification is NIL), there's not much point in doing it
this way.  It's less efficient, because you have to do a RPLACA *and* a
RPLACD whenever the CAR matches; and unless you're extra tricky, you'll
also end up doing an extra CDDR to get the value to RPLACD.  This also
requires the CAR to be handled as a special case, otherwise you'll get this
expense for every matching element.


-- 
Barry Margolin
System Manager, Thinking Machines Corp.

barmar@think.com          {uunet,harvard}!think!barmar
Newsgroups: comp.lang.lisp
From: krulwich@zowie.ils.nwu.edu (Bruce Krulwich)
Subject: Re: Lucid bug in delete-if?
Organization: The Institute for the Learning Sciences, Evanston, IL
	<1992Nov14.205620.11328@news2.cis.umn.edu>
Date: Mon, 16 Nov 1992 16:49:49 GMT


Have any implementations ever tried to handle destructive modification of the
first element of a list by RPLACA'ing the first cons cell to the first element
of the desired list?

(Not that this would completely obviate the need to SETF the result of a
destructive operation, but I was just curious.)

Bruce
From: cthomas@cs.washington.edu (Christopher Thomas)
Newsgroups: comp.lang.lisp
Subject: Evaluating in given environment?
Date: 23 Nov 92 02:59:31 GMT
Article-I.D.: beaver.1992Nov23.025931.27024
Distribution: usa
Organization: University of Washington Computer Science


I have a problem to solve in Common Lisp, and a solution that seems to work.
I am posting this to get feedback on the solution.

Problem: I have a macro that takes a form as an argument, and the expansion
passes that form to a function.  I want the function to evaluate the form,
but in the lexical environment of the macro expansion.  Here is a simplified
example of my problem:

  (defmacro eval-it (form &environment env)
    `(function-eval-it ',form ',env))

   ... Meanwhile, in another lexical environment...

  (defun function-eval-it (form &rest env)
    (evalhook form nil nil env))

  (setf x 40)
  (let ((x 10))
    (eval-it (print x)))

   10
   => 10

As I said, this seems to do the right thing, but, I am wondering
if there is a more elegant way to do this, such as a better way to
evaluate the form, rather than EVALHOOK.  Am I using EVALHOOK properly?

Thanks in advance,

**************************************************************************
* Christopher Thomas             * What do you mean, an African swallow, *
* Univ. of WA Computer Science   *    or a European swallow?             *
* cthomas@cs.washington.edu      *       - King Arthur                   *
**************************************************************************


-- 
**************************************************************************
* Christopher Thomas             * What do you mean, an African swallow, *
* Univ. of WA Computer Science   *    or a European swallow?             *
* cthomas@cs.washington.edu      *       - King Arthur                   *
Newsgroups: comp.lang.lisp,comp.ai
From: barmar@think.com (Barry Margolin)
Newsgroups: comp.lang.lisp
Subject: Re: How to pronounce CAR and CDR ?
Date: 18 Nov 1992 22:29:01 GMT
Organization: Thinking Machines Corporation, Cambridge MA, USA
Distribution: usa
NNTP-Posting-Host: telecaster.think.com

In article <1992Nov18.180337.26400@eng.ufl.edu> zzang@stat.ufl.edu (zzang) writes:
>I dont know how to pronounce the CAR and CDR?

>CAR: /si://ei//a:/ or /ka:/ ?

/ka:/, just like the English word with the same spelling.

>CDR: /si://di://a:/  ??

I don't know the ASCII phonetic alphabet, so I'll describe it.

CDR is pronounced in two syllables.  The first rhymes with "wood" and
"good", and the second rhymes with the second syllable of "butter" (just an
"r" sound).
-- 
Barry Margolin
System Manager, Thinking Machines Corp.

barmar@think.com          {uunet,harvard}!think!barmar
From: jas@ISI.EDU (Jeff Sullivan)
Newsgroups: comp.lang.lisp
Subject: CLIM 1.0 source for displaying bitmapped images in a window?
Date: 17 Nov 92 00:53:29 GMT
Distribution: comp
Organization: USC-ISI


It would seem like such an obvious thing, yet CLIM 1 can't do it.
Does anyone have some code that does do it?  I've heard that you can
hack the INK to work...

jas
--
--------------------------------------------------------------------------
Jeffrey A. Sullivan             | Research Scientist et al.
jas@isi.edu (Internet)          | Information Sciences Institute
72511,402    (Compuserve)       | University of Southern California
Xref: sparky comp.lang.lisp:2928 comp.lang.lisp.x:275
From: br762@cleveland.Freenet.Edu (Tim Werner)
Newsgroups: comp.lang.lisp,comp.lang.lisp.x
Subject: Re: xlisp on unix, or any lisp on unix
Date: 21 Nov 1992 00:24:32 GMT
Organization: Case Western Reserve University, Cleveland, OH (USA)
Distribution: inet
Reply-To: br762@cleveland.Freenet.Edu
NNTP-Posting-Host: hela.ins.cwru.edu


In a previous article, br762@cleveland.Freenet.Edu (Tim Werner) says:

>
>I got the source code for xlisp from an ftp site, but it's got msdos-
>specific code in it.
>
My account has been messed up, and I have been unable to post for the last
week or so, but I wanted to post a follow-up to this, since I got the
answer via e-mail and a couple of people asked me to forward any replies
to them.

The archie search for xlisp turned up a package that had a file called
"uxstuff.c" in it. The readme file said that uxstuff could be used as a
guide. Turns out this has already been done, along with a lot of other
work on a package called "winterp" which has xlisp underneath it.

The key file is now called "unixstuff.c", and I was able to build xlisp
with only a small edit to the makefile. This package is bundled with winterp
under the X11 contrib hierarchy at giza.cis.ohio-state.edu, for instance.

I want to thank everyone who wrote. By the way, the hint in another article
about ESC-x run-lisp from GNU emacs was also very helpful.

(good-bye from tim-werner)
-- 
Xref: sparky comp.lang.lisp:2938 comp.lang.lisp.mcl:1658
From: rkf@INEL.GOV (Raymond K. Fink)
Subject: Re: Elegant control structure wanted
Reply-To: rkf@inel.gov
Organization: Idaho National Engineering Laboratory
Date: Thu, 19 Nov 92 20:08:50 GMT

zaidel@muzungu.cis.upenn.edu (Martin J. Zaidel) writes:
>I've written an equality predicate to test two structures.  My
>predicate is of the form:
>
>(defun node-equal (node1 node2)
>   (and (slot1-equal slot1 slot2)
>	(slot2-equal slot1 slot2)
>	(slot3-equal slot1 slot2)))
>
>I wanted to add format statements so that when NODE-EQUAL returned nil,
>I'd know which slot caused the failure.  So I tried UNLESS:
...
>inelegant.  I'd appreciate suggestions for a nicer solution.

My suggestion, using the fact that (format ....) returns nil

(defparameter *node-equality-tests*
  '(slot1-equal slot2-equal slot3-equal))

(defun node-equal (node1 node2)
  ;; apply test functions in sequence, returning t if completed ok
  (dolist (fn *node-equality-tests* t)
    (unless (funcall fn node1 node2)
       ;; up and out if a test fails, returning nil and logging message
       (return (format t "Failed on ~A" fn)))))

Pro: easy to modify the list of tests without changing the test function
Con: may be slower and cons'ier than desirable

--
Ray Fink -- Idaho National Engineering Laboratory -- Idaho Falls ID 
	rkf@inel.gov			208-525-5431
Hit 'n' now to skip the obnoxious legal disclaimer......
========== long legal disclaimer follows, press n to skip ===========

Neither the United States Government or the Idaho National Engineering
Laboratory or any of their employees, makes any warranty, whatsoever,
implied, or assumes any legal liability or responsibility regarding any
information, disclosed, or represents that its use would not infringe
privately owned rights.  No specific reference constitutes or implies
endorsement, recommendation, or favoring by the United States
Government or the Idaho National Engineering Laboratory.  The views and
opinions expressed herein do not necessarily reflect those of the
United States Government or the Idaho National Engineering Laboratory,
and shall not be used for advertising or product endorsement purposes.
Newsgroups: comp.lang.lisp,comp.lang.lisp.mcl
From: espen@coli.uni-sb.de (Espen J. Vestre)
Subject: Re: remove
Organization: Computerlinguistik, Universitaet des Saarlandes
Distribution: co
Date: 23 Nov 92 16:59:34 GMT
X-Note1: mail msgid was <1er2lmINNl0a@coli-gate.coli.uni-sb.de>
X-Note2: message-id generated by recnews

In article <SIMON.92Nov23130108@liasg2.epfl.ch> Simon Leinen,
simon@lia.di.epfl.ch writes:
>Espen is correct in that Hallvard's REMOVE variant isn't
>tail-recursive and may therefore cause problems with long lists.  One
>could code an iterative tail-preserving version (which might be slower).
>
>But I did some benchmarking on Sun-4s under Allegro and CMU CL, and even
>on longish lists (like 1000 elements or so), Hallvard's FASTER-REMOVE
>performed better on the whole than the system-provided REMOVE versions.
>I would bet that at least 90% of the uses of REMOVE would benefit from
>using FASTER-REMOVE.

Yes, especially if you take into account that if you're using very long
lists as your data structures, you are probably using the wrong kind of
data structure.
I guess a lot of programs might benefit even more from _memoizing_ the
remove function, i.e. if the program is using remove to filter the same
list again and again, it would benefit from knowing that, e.g., a given
value isn't present in that list at all.
--------------------------------------------------------------
Espen J. Vestre,                          espen@coli.uni-sb.de
Universitaet des Saarlandes,        
Computerlinguistik, Gebaeude 17.2 
Im Stadtwald,                          tel. +49 (681) 302 4501
D-6600 SAARBRUECKEN, Germany           fax. +49 (681) 302 4351
--------------------------------------------------------------
From: zaidel@muzungu.cis.upenn.edu (Martin J. Zaidel)
Newsgroups: comp.lang.lisp
Subject: Elegant control structure wanted
Date: 19 Nov 92 16:31:05 GMT
Organization: University of Pennsylvania

I've written an equality predicate to test two structures.  My
predicate is of the form:

(defun node-equal (node1 node2)
   (and (slot1-equal slot1 slot2)
	(slot2-equal slot1 slot2)
	(slot3-equal slot1 slot2)))

(Actually, the two node arguments have vastly different structures, but 
that's not the issue here.)

I wanted to add format statements so that when NODE-EQUAL returned nil,
I'd know which slot caused the failure.  So I tried UNLESS:

(defun node-equal (node1 node2)
   (and (unless (slot1-equal slot1 slot2)
	   (format t "Slot 1 not equal"))
	(unless (slot2-equal slot1 slot2)
	   (format t "Slot 2 not equal"))
	(unless (slot3-equal slot1 slot2)
	   (format t "Slot 3 not equal"))))

This won't work, since UNLESS will return NIL, regardless of the 
value of the slot-equal test.  Now, CLtL2 p.158 advises that, when the 
value of the unless is relevant (as it is here), to use IF instead.

That means my code is:

(defun node-equal (node1 node2)
   (and (if (slot1-equal slot1 slot2) 
	    t
	    (format t "Slot 1 not equal"))
	(if (slot2-equal slot1 slot2)
	    t
	    (format t "Slot 2 not equal"))
	(if (slot3-equal slot1 slot2)
	    t
	    (format t "Slot 3 not equal"))))

This explicit use of T for the value of the IF strikes me as rather
inelegant.  I'd appreciate suggestions for a nicer solution.

Thanks in advance.
Newsgroups: comp.lang.lisp
From: jpf@wstar.mixcom.com (John P. Flanagan)
Subject: Re: *READ-SUPPRESS* and #P syntax
Date: Thu, 19 Nov 1992 17:02:12 GMT
Organization: WaveStar Technology

barmar@think.com (Barry Margolin) writes:

>In article <1992Nov18.000646.1180@wstar.mixcom.com> jpf@wstar.mixcom.com (John P. Flanagan) writes:
>>barmar@think.com (Barry Margolin) writes:
>>>My interpretation of *READ-SUPPRESS* is that when it doesn't say something
>>>operates differently from normal, it should operate the normal way.  Thus,
>>
>>Maybe it's the cloudy weather affecting my judgement, but since nearly
>>all sharp reader macros behave a certain way when *read-suppress* is
>>non-nil, why then would you assume that a sharp reader macro that slipped
>>through the specification net wouldn't behave in a similar manner?

>I based my assumption on the fact that CLtL and the dpANS specifically list
>only a small number of sharpsign macros in the the description of
>*READ-SUPPRESS*, and make no mention of a general default effect of setting
>this variable.  When interpreting a language standard (AKA "language
>lawyering"), it's generally not appropriate to extrapolate from specific
>instances to general cases.

According to my copy only three sharp reader macros, #C, #(, and #',
were left out of the description for *READ-SUPPRESS*, that's hardly a
small number!  We have twelve *specific* reader macro examples to ponder
in that description of *READ-SUPPRESS*; excluding #=, all produce nil when
*READ-SUPPRESS* is non-nil.  How much extrapolation is required to properly
reconcile the behavior of #C, #(, or #' given this kind of evidence?

>>Normally these two expressions produce a vector of two elements, the symbols
>>foo and bar, but when *read-suppress* is non-nil we get this instead?
>>
>>	#1A(foo bar)
>>	=> nil
>>
>>	#(foo bar)
>>	=> #(nil nil)
>>
>>Isn't this a bit inconsistent (if not confusing)?

>I agree that it's inconsistent and confusing, but I also believe it's
>implied by CLtL.

One man's implication is another man's extrapolation?  ;-)

>Actually, I'm considering suggesting a more general change:

>    When *READ-SUPPRESS* is true, READ, READ-PRESERVING-WHITESPACE, and
>    READ-DELIMITED-LIST all return NIL; however, they continue to parse the
>    representation of an object in the normal way, in order to skip over
>    the object.  Any standard read macro that is defined to read an object
>    or token will do so, but not signal an error if the object read is not
>    of an appropriate type or syntax.

>Sound reasonable?

Yes, very much so, but you're already tempting fate (**EXTRAPOLATION**)
by not mentioning READ-FROM-STRING!

-jpf.
-- 
   __________________________________________________________________________
   WaveStar Technology           WaveStar Common Lisp        John P. Flanagan
   W344 N6855 Bayberry Court     ANSI-12.24, X3J13/92          (414) 367-5014
   Oconomowoc, WI  53066         HPUX-800/700/400/300    jpf@wstar.mixcom.com
Newsgroups: comp.lang.lisp,comp.lang.scheme
From: chucko@kronos.arc.nasa.gov (Chuck Fry)
Subject: Use of Lisp in education
Followup-To: poster
Reply-To: Chucko@westmark.stanford.edu
Organization: Recom Technologies, NASA Ames Research Center, Moffett Field, CA
Date: Thu, 19 Nov 1992 18:18:32 GMT


I'd like to ask the academics on the net about the use of Lisp in
their institutions.  Apologies in advance; I know some of this
information has been posted before, but I failed to save it.

What schools (high schools, colleges and universities) use Lisp or
Scheme in introductory computer science courses?  How has the use of
Lisp over more "conventional" languages affected the way in which
students learn the basic concepts of computer science?

And which institutions use Lisp as the primary language throughout the
core computer science curriculum, and what effect has it had on the
program?

Please reply to me only.  Thanks.

 -- Chuck Fry  
    Chucko@westmark.stanford.edu [despite what the header says]
From: William.Lott@cs.cmu.edu
Newsgroups: comp.lang.lisp
Subject: Re: CMU-Lisp on 486 running Mach ?
Date: 16 Nov 92 22:58:59 GMT
Article-I.D.: cs.0f2=FHG00jeiMrS8UM
Organization: Carnegie Mellon, Pittsburgh, PA

cracauer@wavehh.hanse.de (Martin Cracauer) writes:
> I wonder, if one can bring up the CMU Common Lisp from the sources on
> a PC running Mach.
> 
> Anybody there, who knows ?
> 
> An e-mail address of someone at CMU, who likes to respond, would be
> good, too.
> 
> Thanks
>         Martin
> -- 
> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
> Martin Cracauer,    cracauer@wavehh.hanse.de
> Waldstrasse 200, W-2000 Norderstedt, Germany
> Tel.: +49 / 522 18 29, Fax.: +49 / 522 85 36

Random queries about CMUCL can be sent to cmucl-bugs@cs.cmu.edu.

A port to the 386/486 running MACH is currently in progress but is
much more involved then a port to Yet Another Risc Machine would be
because of the limited number of registers.  The biggest problem is
that the garbage collector assumes that the register file can be
partitioned into two sets, one that only over holds valid lisp
descriptors that can be identified by the garbage collector and one
that holds raw binary values that would confuse the garbage collector.
Given that the x86 only has 8 registers, artificially constraining
their use would result in horrible performance if not a total
implementation nightmare.

We have figured out how to solve this problem, but it requires a
rather significant change: the compiler is going to have to annotate
the object code with information about what registers hold valid lisp
objects (i.e. the liveness info) at various points in the code and
then the garbage collector has to be taught that it can only GC at
those points.

We've been planning to move to a generational garbage collector, and
it seemed like a good idea to merge these two tasks together given
that they both involve bashing on the garbage collector.  But other
higher priority tasks keep pushing this one back.  I plan on resuming
active work on the 386/486 port Real Soon Now, and should have an
alpha system Soon After That.  In other words, don't expect anything
before early next year, and that is even rather optimistic.  (Of
course, if someone were to donate money and/or machines to our
project, that would of course cause us to re-prioritize the various
tasks at hand. :-)

-William Lott
CMU Common Lisp Group
Newsgroups: comp.lang.lisp