HDTenEightyP/NetNews huggingface dataset:
From: barmar@think.com (Barry Margolin)
Newsgroups: comp.lang.lisp
Subject: CAR and CDR (was Re: Why Isn't Lisp a Mainstream Language?)
Date: 23 Jan 1993 19:28:39 GMT
Organization: Thinking Machines Corporation, Cambridge MA, USA
NNTP-Posting-Host: gandalf.think.com

In article <19930122162651.0.SWM@SUMMER.SCRC.Symbolics.COM> SWM@stony-brook.scrc.symbolics.com (Scott McKay) writes:
>I personally think CAR and CDR could have been flushed from the
>language, since FIRST and REST do the exact same thing.  

FIRST and REST only make sense when a cons is being used as a chain in a
list.  CAR and CDR make much more sense for conses being used as pairs.
Their lack of preexisting semantics fits in with the abstract nature of
conses: calling them CONS-PART1 and CONS-PART2, for instance, would imply
an ordering to the components that doesn't necessarily exist.  Flushing CAR
and CDR would make almost as little sense as flushing NOT because it's
equivalent to NULL.

Perhaps conses as fundamental data types should have been removed when
DEFSTRUCT was included in the standard.  CONS could be defined as:

(defstruct (cons (:conc-name ""))
  car cdr)

>  What machines
>directly execute mapping operators?  Reduction operators?  

Connection Machines!

>							    What machines
>directly execute generic arithmetic, including integers, large integers,
>floating point, and ratios?  

Lisp Machines?
-- 
Barry Margolin
System Manager, Thinking Machines Corp.

barmar@think.com          {uunet,harvard}!think!barmar
From: jeff@aiai.ed.ac.uk (Jeff Dalton)
Newsgroups: comp.lang.lisp
Subject: Re: SETF vs. SETQ
Date: 21 Jan 93 19:45:54 GMT
Organization: AIAI, University of Edinburgh, Scotland

In article <HAL.93Jan13083812@monsun.si.no> hal@si.no (Hallvard Tretteberg) writes:
>In article <1iupurINNih2@early-bird.think.com> barmar@think.com (Barry Margolin) writes:
>   No, there's only a MULTIPLE-VALUE-SETQ.
>
>   In hindsight, having separate SETQ and SETF was a bad design, IMHO.
>
>I agree. In a Lisp style guide I wrote the general rule was to use the
>most specific construct when choosing among several alternative ways
>of doing the same thing. But, when it came to SETF vs. SETQ I
>recommended using SETF all the time.

I disagree with the most-specific rule in general, and I don't see
anything wrong with using SETQ.  Does anyone seriously want to argue
that SETQ is unclear, for instance?

>One argument for using SETQ could be that it is easier to spot which
>uses are fast-simple-variable access, compared to
>slow-complicated-slot access where SETF should be used. But with
>SYMBOL-MACROLET you can be fooled by an innocent SETQ, because it, as
>I understand, is treated like a SETF.

You can be fooled by an innocent (SETF <symbol> ...) as well.

>One thing that annoys me is that one can't use #'(setf
>struct-slot-reader) because struct-slot setters can be implemented as
>setf-macros and not as methods. 

That annoys me too, but struct-slot setters should be functions
(not methods) just like struct-slot readers are.

-- jd
Newsgroups: comp.lang.lisp
From: emcoop@bnr.ca (hume smith)
Subject: Re: Lisp syntax beauty? (was Re: Why Isn't Lisp a Mainstream Language?)
Organization: Bell-Northern Research, Ottawa, Canada
	<19930122162651.0.SWM@SUMMER.SCRC.Symbolics.COM>
	<dfs.727723285@noonian> <C1GEsq.94@stl.dk>
Date: Tue, 26 Jan 1993 20:14:15 GMT

In article <C1GEsq.94@stl.dk> flv@stl.dk (Flemming Vestergaard) writes:

   In <dfs.727723285@noonian> dfs@doe.carleton.ca (David F. Skoll) writes:

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

   Well, it is fun. But from this corner of the world I suppose that it is
   a more serious problem (if not a disaster) that Common Lisp provides 
   input and output functions that are suited only for English/American.

   (format t "~R" 4) -> four really doesn't help very much in most of the world.
   And yes-or-no-p cannot be used either.

   I do think it is a mistake to include natural language specific functions
   in a language standard.

well it IS the AMERICAN standard.  ISO may (should) make a different one.
i personally think there should be something way, from system locale
resources, to figure out local customs.  it shouldn't be too hard to
have hooks of some sort for ~R, so local number-spelling functions
can be slipped in.
--
Hume Smith                                Honour sick and davey cris-cross
hume.smith@acadiau.ca                     McTruloff sentimie
emcoop@bnr.ca                             A parsnip inner pair threes.
Newsgroups: comp.lang.lisp
From: jturley@netcom.com (Jim Turley)
Subject: CONTRACTOR WANTED: LISP --> OS/2 Port
Organization: Netcom - Online Communication Services  (408 241-9760 guest) 
Date: Wed, 27 Jan 1993 19:32:53 GMT



-----------CALIFORNIA CONTRACT JOB POSTING--------------
----
---------San Francisco South Bay Area---------

NOTE THAT I CANNOT RESPOND TO YOUR RESUME SUBMISSION UNTIL 2/2/93, but
please feel free to FAX before then.  


Please FAX Resume to (408) 741-0512 or email (RTF or plain text, no troff) 
 
Artificial Intelligence CONTRACTOR WANTED:  South Bay Area, 3-6 Months

Experience AI consultant with knowledge of LISP (preferably on Symbolics
processor) required for port of LISP application to OS/2 in "C"or C++. OS/2 
Presentation Manager GUI design a plus.
 
Immediate requirement 
 
Respond to Jim Turley, XAI (Contract Broker)
              by EMAIL or FAX

Thanks!

Jim Turley,  jturley@netcom.com

   
Newsgroups: comp.lang.lisp
From: news@cs.mu.OZ.AU
Subject: HELP ! Pearl Lisp on Mac IIci.
Organization: Computer Science, University of Melbourne, Australia
Date: Tue, 26 Jan 1993 23:36:20 GMT

PLEASE HELP MY PEARL LISP ON Mac IIci.

I have an original Pearl Lisp version 1.01 and it ran comfortably on 
mac Plus and SE.  The trouble happened when I install it on my new
IIci.

The problem is when I open listener window, insertion mark changed into
scattered dots inside the listener window.  Outside it, the mark changed
back to normal arrow.  Why this kind of things happen?

The system software is 6.0.7, and IIci has a cache card.  I doubt this
cache card.

If you have any information about this "insertion mark --> dots" problem,
would you please post it or email me ?

Thanks in advance.

Noriaki Onodera (noriaki@mullian.ee.mu.oz.au)
( I am a extremely beginner of Lisp )


Newsgroups: comp.lang.lisp
From: zdhm06@trc.amoco.com (Donald H. Mitchell)
Subject: Re: Why Isn't Lisp a Mainstream Language?
Originator: zdhm06@scholar
Organization: Amoco Production Company, Tulsa Research
Date: Wed, 27 Jan 1993 19:25:08 GMT



> 
> As a final note, then, I would say, yes, in the beginning, my attitude
> toward LISP was influenced by a professor whom I respected, and who spoke
> positively regarding the language. 
> 

IMHO, Priscilla's hit the nail on the head.  Most purchasing decisions
or choices of how to go about doing something are based first on
personal experience and second on recommendations from friends and
colleagues.  You may violate this characterization by going out and
researching every purchase that you do; however, I doubt it.  Your
choice of store to shop in, refrigerator model, *restaurant*, church,
etc starts with personal recommendations (or sometimes
advertisements).  We've got to evangelize and perhaps stoop to 
teaching introductory programming courses :-)

Note, IBM and MicroSoft don't corner their markets by quality,
price, or features but by familiarity, trustworthiness, and
marketing agressiveness.  They've defined the battle: we must
fight it on their grounds.  The same goes for languages.

>     
> -- 
> Priscilla Walther

Don Mitchell			dmitchell@trc.amoco.com
Amoco Production Company	(918) 660-4270
Tulsa Research Center
P.O. Box 3385, Tulsa, OK 74102
-- 
Don Mitchell			dmitchell@trc.amoco.com
Amoco Production Company	(918) 660-4270
Tulsa Research Center
P.O. Box 3385, Tulsa, OK 74102
Xref: sparky comp.lang.lisp:3352 comp.lang.lisp.mcl:2086
From: joungwoo@mensa.usc.edu (John Kim)
Newsgroups: comp.lang.lisp,comp.lang.lisp.mcl
Subject: Re: Measuring elapsed CPU time
Date: 24 Jan 1993 18:47:34 -0800
Organization: University of Southern California, Los Angeles, CA
NNTP-Posting-Host: mensa.usc.edu
Keywords: CPU time

I would like to thank everyone who emailed me or posted an answer on this BB
for an elementary question. (I knew lisp function's args are evaled first,
but the fact just slipped out when I was doing my coding.:-]) I could have
guessed using defmacro. But many of your alternative answers were extensive
and beyond just using macros.

Frankly I have received ENOUGH answers by now. I'll post a summary soon.

Thank you all again. Netters are wonderful.

John



joungwoo@mensa.usc.edu (John Kim) writes:


>I'm trying to measure teh elasped CPU time during a lisp form has been run.
>The problem with the Common Lisp's builtin function TIME is that it does not
>return the various elapsed times but returns the return value of the form
>(ie, TIME's arg) plus I don't know if I am getting accurate elapsed CPU time
>either. 
>	So I tried using builtin function GET-INTERNAL-RUN-TIME as follows,
>but the following function defined by me usually it gives me either 0 or 1 no
>matter how time-consuming task I give it. 

>(defun CPU-time (form)
>  "returns the actual elapsed CPU(?) time not including I/O processing 
>in msecs.
>"
>  (let ((start-time nil)
>        (end-time nil)
>        )
>    (setq start-time (get-internal-run-time))
>    form
>    (setq end-time (get-internal-run-time))
>    (print start-time)
>    (print end-time)
>    (- end-time start-time)
>    ))

>Am I doing something wrong in the above function definition or is there a
>better way to do this? Or are most tasks heavily I/O bound but so lightly
>CPU-bound that the internal clock for GET-INTERNAL-RUN-TIME hardly ticks?

>Thank you in advance. (Please email me.)

>John

>P.S. I tried both Lucid Common Lisp/Sparc on Sun and Macintosh Common Lisp
>(MCL 2.0) and the result is the same.

>P.P.S. In the worst case, is there a way to print the msg (not the return
>value) of TIME which goes to *TRACE-OUTPUT* to a string (so I can parse teh
>string later)?
>-- 
>Joung-woo John Kim				joungwoo@mensa.usc.edu
>Computer Science Dept.
>University of Southern California, Los Angeles, CA 90089-0781

-- 
Joung-woo John Kim				joungwoo@mensa.usc.edu
Computer Science Dept.
University of Southern California, Los Angeles, CA 90089-0781

Newsgroups: comp.lang.lisp
From: fy@lucid.com (Frank Yellin)
Subject: Re: (SETF VALUES)
Organization: Lucid, Inc., Menlo Park, CA
	<1imgf4INNmf@early-bird.think.com> <8204@skye.ed.ac.uk>
Date: 21 Jan 93 10:03:18


In article <8204@skye.ed.ac.uk> jeff@aiai.ed.ac.uk (Jeff Dalton) writes:
>
>> The normal multiple-value assignment operators only allow you to assign to
>> variables, but you might want to assign to a set of generalized references.
>> Here's a simple, contrived example:
>>
>> (defstruct (q-and-r (:conc-name qr-))
>>  quotient
>>  remainder)
>>
>> (defvar *qr* (make-q-and-r))
>> ...
>> (setf (values (qr-quotient *qr*) (qr-remainder *qr*))
>>      (floor numerator denominator))
>>  So a multiple-value-setf would have worked as well?


Yes, it is true that
    (setf (values <x> <y> <z>) <something>)
Would be equivalent to 
    (multiple-value-setf (<x> <y> <z>) <something>)

The advantage of having a setf method for values is that it allows you to
use #'values in macros.

Let me give a slightly contrived example.  Imagine you have some sort of
data type PAIR for holding two values.

You might want to do operations like:

   > (setq x (make-pair 3 5))
   #<Pair>
   > (pair-value x)
   3
   5
   (setf (pair-value x) (truncate 10 3))
   3
   1
   
A trivial implementation would be:

   (defun make-pair (x y) (cons x y))

   (defmacro pair-value (x) `(values (car ,x) (cdr ,x)))

[Yes, this is a contrived example.  Yes, I realise that x is evaluated
twice in the definition of pair-value.]

-- Frank Yellin
Newsgroups: comp.lang.lisp
From: jmm@contra-aid.lucid.com (Jay Mellman)
Subject: Any Common Lisp under Solaris 2.1
Organization: Lucid, Inc.
Distribution: comp.lang.lisp, comp.lang.clos
Date: 26 Jan 93 15:59:21


As everyone should be well aware, the change from SunOS to Solaris is
a major change requiring a large rewriting of underlying systems to
make Common Lisp run.  The good news is that Lucid has just shipped a
beta version of Lucid Common Lisp for Solaris 2.1 to a number of our
test sites.  As our QA manager said, "this is the strongest piece of
software I have seen."  I expect beta to go very smoothly.  In
general, you can expect formal release of the software in 3 months.

Please contact me or "sales@lucid.com" for more information.

Jay Mellman				jmm@lucid.com
Product Marketing Manager		(415) 329-8400
Lucid, Inc.
From: matomira@di.epfl.ch (Fernando Mato Mira)
Newsgroups: comp.lang.lisp
Subject: Re: Lisp syntax beauty? (was Re: Why Isn't Lisp a Mainstream Language?)
Date: 26 Jan 93 18:09:59 GMT
Organization: Ecole Polytechnique Federale de Lausanne

In article <C1GEsq.94@stl.dk>, flv@stl.dk (Flemming Vestergaard) writes:
> 
> Well, it is fun. But from this corner of the world I suppose that it is
> a more serious problem (if not a disaster) that Common Lisp provides 
> input and output functions that are suited only for English/American.
> 
> (format t "~R" 4) -> four really doesn't help very much in most of the world.
> And yes-or-no-p cannot be used either.
> 
> I do think it is a mistake to include natural language specific functions
> in a language standard.

Maybe some hooks should be provided to internationalize these functions. Then if 
somebody needs to print checks in Spanish they can write their own routine to handle the ~R directive.
But even if the standard specifies the behaviour only for english, I think that thinking only "american" with respect to
the "billion thing" is quite irritating.
For yes-or-no-p it would be very easy (and extremely useful) to specify in the standard some system variables which you
could modify to hold the string appropriate for the local language.

And yes, I think CL is "a nice PL/1". And in the same way everybody around here seems to want everybody else to program in
LISP, I will be happy only when most LISPers program in SCHEME (with a good MOP, of course). Then I could get a lot of
public domain tools for it and abandon CL. If C++ is the black hole of OO programming, I must say that CL is the neutron star of list
processing.

-- 
Fernando D. Mato Mira
Computer Graphics Lab			   "Only CLOS is good enough"
Swiss Federal Institute of Technology	  		      ^^^^^^
matomira@di.epfl.ch

NeXTMail : matomira@lignext.epfl.ch
FAX 	 : +41 (21) 693 - 5328

Disclaimer:

disclaim([],[]).
disclaim([H|T],[DH,DT]) :- fixed-point-disclaimer(H,DH),
			   disclaim(T,DT).
fixed-point-disclaimer(Text,fixed-point-disclaimer(Text,_)).
From: secrist@msdsws.enet.dec.com (Strong datatypes for weak minds.)
Newsgroups: comp.lang.lisp
Subject: Re: Why Isn't Lisp a Mainstream Language?
Date: 21 Jan 93 02:42:04 GMT
Organization: Digital Equipment Corporation


In <1993Jan14.093640.20306@ads.com>, bvrotney@ADS.COM (Bill Vrotney) writes...

	; I used to think the answer to you question was complex, but now I
	; think that it is simple. I call it "C sickness". For Lisp to
	; become mainstream it has to be small, fast and hardened.

Not.  The mainstream is not controlled by computer scientists, but by
mass market dweebs.  C compilers are becoming a fat, bloated miasmas 
much like the 80x86-seeking public (go install a Borland product), and 
mutants like C++ aren't even ANSI/ISO standards.  

Today form is more important than function, marketing is king, and 
vendors are catering to that mass market.

Perhaps Scheme and Dylan are the last, best hope to dent the mainstream.

Regards,
rcs
From: Michael.Fleming@f2206.n124.z1.fidonet.org (Michael Fleming)
Newsgroups: comp.lang.lisp
Subject: Why Isn't Lisp a Mainstream Language?
Date: 26 Jan 93 14:36:00 GMT

Don't most languages use prefix notation? For example puts("type 
your name."); seems quite similar to (print "type your name"). Why 
is one prefix and the other something else? Prefix notation is also 
common in English. We say "Put the letter in the slot" not "letter 
put slot." Or "the letter put in the slot". I am puzzled by the 
complaint that a drawback of Lisp is its use of prefix notation.
I agree that a complex math expression can be difficult in prefix, 
but the same expression is usually difficult in infix as well.
 * Origin: The Interocitor*AI/Robotics*214-258-1832 (1:124/2206)
From: dyer@airplane.sharebase.com (Scot Dyer)
Newsgroups: comp.lang.lisp
Subject: Re: Lisp syntax beauty? (was Re: Why Isn't Lisp a Mainstream Language?)
Date: 28 Jan 93 17:03:47 GMT
Reply-To: dyer@airplane.sharebase.com (Scot Dyer)
Organization: NCR/ShareBase Corporation

;;; Maybe some hooks should be provided to internationalize these
;;; functions. Then if somebody needs to print checks in Spanish they can
;;; write their own routine to ha ndle the ~R directive.  But even if the
;;; standard specifies the behaviour only for english, I think that
;;; thinking only "american" with respect to the "billion thing" is quite
;;; irritating.  For yes-or-no-p it would be very easy (and extremely
;;; useful) to specify in the s tandard some system variables which you
;;; could modify to hold the string appropriate for the local language.

Actually, yes-or-no-p would be very hard to internationalize correctly.  There
exist languages with no direct translations of the English "Yes" and "No," and
languages where the semmantics of "Yes" and "No" are quite different for
questions posed in the negative.  Examples are Welsh (with no direct 1-to-1
translation for either 'Yes' or 'No'), Japanese (where the semmantics of saying
'Yes' to a negative question are different than those of English), and French
(where a 3rd word is added for disambiguating answers to questions in the
negative)

As for format's ~R, it could be internationalized, but personally I'd rather
see format dropped from the CL specification and replaced with several
functions, maybe one for the actual output and others that do formatting.
The current format defies most conventional tree-shaking algorithms.  This
wouldn't be so bad if it weren't so mammoth to begin with...  IMHO, of course.

I don't want to get rid of ~R, just make it its own function.

;;; And yes, I think CL is "a nice PL/1". And in the same way everybody
;;; around here seems to want everybody else to program in LISP, I will be
;;; happy only when most LISPers program in SCHEME (with a good MOP,
;;;  of course). Then I could get a lot of public domain tools for it and
;;; abandon CL. If C++ is the black hole of OO programming, I must say
;;; that CL is the neutron star of list processing.

I agree that CL/CLOS/CLIM is probably too big to run as anything other than
an OS, and the design really isn't that compiler friendly.  A nice, small,
OO lisp (maybe Scheme + OO or Dylan) with _libraries_ would be much more
practical.

And before everyone starts shouting that I want to remove all dynamicism from
Lisp let me assure you: I only want to remove that dynamicism that isn't
necessary for the semmantics of a given program.  The compiler technology
exists for this kind of thing, but the language spec needs to be more compiler
friendly if we're ever going to see compact binaries coming from Lisp source.

	-- Scot
From: gandalf@sabrina.dei.unipd.it (ROBERTO AVANZI)
Subject: Re: Lisp syntax beauty? (was Re: Why Isn't Lisp a Mainstream Language?)
Organization: D.E.I. Universita' di Padova, Italia
Date: Sat, 23 Jan 1993 08:19:00 GMT

In article <dfs.727729181@crusher> dfs@doe.carleton.ca (David F. Skoll) writes:
>In <1jpe0qINNnf1@tamsun.tamu.edu> hmueller@orca.tamu.edu (Hal Mueller)
>writes:
>
[things omitted]
>
>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.
>
>--
>David F. Skoll
I like Lisp too, while sometimes i HAVE to resort to C or 68020 asm
for my daily programming. but time passes and i use C less and Lisp
more. I am writing "LIsp" and not "Common Lisp" here because i prefer Scheme.
It is not a mere matter of taste. Scheme is more powerful for building
constructs, due to more powerful continuations, while CL has a much larger
library and a standard Object system. anyway,  a lisp language can be used
also for very small projects... MacGambit runs on 2 meg macintoshes, as
well on powerful Quadras, while PC Scheme manages to fit in the ridiculous
less-than-640-k-or-change-os amount of memory of MesSy DOS.
If you need more powerful libraries, just look around . MIT CScheme for
example already has them built-in, with good systems such as Elk or
Gambit having no trouble in growing and growing with the user.

My 2 cents about "Why is not lisp a mainstream language" are as follow.
i)   people think lisp <=> AI . it's false we know, but most people think so.
     a friend of mine (and and intelligent person) asked me: why do you
     use Lisp, AI has failed in its objectives...
ii)  people hate parentheses. But still I do not understand why do they not
     use forth instead then ...
iii) Lisp has been since recent times a resource hog. now its a false
     statement, we have light lisps. but when allegro on a sparc gives you
     a 11meg image, well, I believe something is wrong with allegro...
iv)  a lack to a good interface to C routines. NOT OS interface, but generic
     C code. I mean a STANDARD way. CMUCL, Lucid, Allegro all offer such
     facilities but they are incompatible. That's bad.

Cheers
Roberto

Newsgroups: comp.lang.lisp,comp.lang.lisp.mcl
From: emcoop@bnr.ca (hume smith)
Subject: Re: Measuring elapsed CPU time
Organization: Bell-Northern Research, Ottawa, Canada
Date: Thu, 21 Jan 1993 14:18:40 GMT

In article <1jlr7cINNep1@mensa.usc.edu> joungwoo@mensa.usc.edu (John Kim) writes:

	   So I tried using builtin function GET-INTERNAL-RUN-TIME as follows,
   but the following function defined by me usually it gives me either 0 or 1 no
   matter how time-consuming task I give it. 

   (defun CPU-time (form)
     "returns the actual elapsed CPU(?) time not including I/O processing 
   in msecs.
   "
     (let ((start-time nil)
	   (end-time nil)
	   )
       (setq start-time (get-internal-run-time))
       form
       (setq end-time (get-internal-run-time))
       (print start-time)
       (print end-time)
       (- end-time start-time)
       ))

   Am I doing something wrong in the above function definition or is there a
   better way to do this?

this sort of thing needs a macro.  in your construct, the form has been evaled by the time
the function starts, and all your timer ends up timing is how long it takes the
evaluator to find the value of the symbol "form".  try this:

(defmacro CPU-time (form)
  `(let (start-time end-time)
     (setq start-time (get-internal-run-time))
     ,form
     (setq end-time (get-internal-run-time))
     (print start-time)
     (print end-time)
     (- end-time start-time)))
--
Hume Smith                                Honour sick and davey cris-cross
hume.smith@acadiau.ca                     McTruloff sentimie
emcoop@bnr.ca                             A parsnip inner pair threes.
Newsgroups: comp.lang.lisp,comp.lang.scheme