HDTenEightyP/NetNews huggingface dataset:
From: will@aristotle.ils.nwu.edu (William Fitzgerald)
Newsgroups: comp.lang.lisp
Subject: Re: Use of format or pprint
Date: 21 Dec 92 22:44:57 GMT
Distribution: usa
Organization: The Institute for the Learning Sciences
X-Newsreader: Tin 1.1 PL5

Barry Margolin (barmar@think.com) wrote:
: 
: You'll have to write your own routine to convert the single-string form
: into a list of strings.  Common Lisp has nothing that will parse the string
: into words and treat them separately for this purpose (the only thing in CL
: that deals with words is STRING-CAPITALIZE).
: 

Here are some functions I've written to convert strings into lists of
various sorts. Examples follow at the end.

(defun list-from-string (string
                         &key 
                         (start 0) 
                         (char-bag '(#\Space))
                         (test #'(lambda (ch)
                                   (not (member ch char-bag 
                                                :test 'char=))))
                         (post-process 'identity))
  (let ((pos (position-if test string :start start)))
    (if pos 
      (list-from-string* string :start  pos :char-bag char-bag
                         :test test :post-process post-process)
      nil)))

(defun list-from-string* (string
                          &key 
                          (start 0) 
                          (char-bag '(#\Space))
                          (test #'(lambda (ch)
                                    (not (member ch char-bag :test 'char=))))
                          (post-process 'identity))
  (let* ((pos (position-if-not test string :start start))
         (new-pos (if pos (position-if test string :start pos) nil)))
    (cond
     ((and pos new-pos)
      (cons (funcall post-process (subseq string start pos))
            (list-from-string* string :start new-pos :char-bag char-bag
                               :test test :post-process post-process)))
     (pos (list (funcall post-process (subseq string start pos))))
     
     (t (list (funcall post-process (subseq string start)))))))


(defmethod string->symbol-list ((s string) &optional (package *package*))
  (list-from-string s :post-process
                    #'(lambda (str) 
                        (intern (nstring-upcase str) package))
                    :test 'alphanumericp))



#|


(list-from-string  "chris dan ski elaine nick") --> 
  ("chris" "dan" "ski" "elaine" "nick")

(list-from-string  "chris dan ski elaine nick" 
                   :post-process 'nstring-capitalize) -->
  ("Chris" "Dan" "Ski" "Elaine" "Nick")

(list-from-string "chris! dan! ski! elaine! nick!"
                  :char-bag '(#\Space #\!)) -->
  ("chris" "dan" "ski" "elaine" "nick")

(string->symbol-list "chris dan ski elaine nick")-->
 (CHRIS DAN SKI ELAINE NICK)


|#
Newsgroups: comp.lang.lisp
From: rs69@cunixb.cc.columbia.edu (Rong Shen)
Subject: a problem with reading a stream
Organization: Columbia University
Date: Sun, 27 Dec 1992 01:45:28 GMT

Hi experts:

	I am trying to write a function that asks a path to a file
from the user and opens the file to read. There is no problem with
opening the file, but when it tries to read, the interpreter
complains.

	Can anyone tell me why?

	Thanks very much.

--
rs69@cunixb.cc.columbia.edu

(defun read-path ()
  (format t "Enter the path to the file to read, e.g. /tmp/foo/faq.txt")
  (setf file-path-name (read-line))
  (setf what-stream (open file-path-name :direction :input)) ; ok

  (read what-stream nil 'This-is-the-end-of-the-world)) ; This line has error;
Newsgroups: comp.lang.lisp
From: fy@lucid.com (Frank Yellin)
Subject: Re: Origins of LISP and relation with Fortran
Organization: Lucid, Inc., Menlo Park, CA
Date: 23 Dec 92 10:50:03


In article <1992Dec23.111821.201165@circe.fr> girou@circe.fr (Denis Girou)
writes: 

> Some years ago, one of my teacher says during a lesson that when John
> McCarthy, around 1956, think to that will become LISP, he only want to write
> an extension to the Fortran language (Fortran I or Fortran II at this time)
> to manipulate lists structures. It would be only later that he thought to a
> real new language, completely independant of Fortran.

> Is there somebody who can confirm or infirm this fact, and can give me a
> bibliographic reference? (it's for an article about Fortran that I have to
> write...) 

I'm sure John McCarthy will know the answer to this.  Email to 
jmc@cs.stanford.edu should reach him.

-- Frank Yellin
From: rv@erix.ericsson.se (Robert Virding)
Newsgroups: comp.lang.lisp
Subject: Re: Reference counting (was Re: Yet another Lisp Interpreter Available (RefLisp) Long)
Date: 22 Dec 92 14:10:11 GMT
Organization: Ellemtel Telecom Systems Labs, Stockholm, Sweden
Nntp-Posting-User: rv

In article <1gr5ejINN3k5@early-bird.think.com>, barmar@think.com (Barry Margolin) writes:
>In article <1992Dec17.200901.20942@uk03.bull.co.uk> bbirch@hemel.bull.co.uk (Bill Birch) writes:
>>	- RefLisp has reference counting garbage collection, that means
>>	  memory is reclaimed as soon as it is un-used. It is a "non-stop"
>>	  system, in that there is never any halt for garbage collection (GC).
>
>This is a frequent claim that is simply not true.  A reference counting
>system simply changes the time and distribution of the GC delays, but it
>doesn't eliminate it.  For instance, if you allocate a million-element
>list, and then lose the pointer to the first element, that operation will
>take a million times longer than losing a pointer to the head of a
>one-element list, as it has to recursively deallocate all the objects in
>the list (assuming there are no other pointers into the list).  No matter
>how fast your reference counting scheme is, I can always construct a data
>structure that takes a noticeable amount of time to deallocate it when the
>last pointer to the first element is dropped (assuming there's enough
>memory).

There are reference counting schemes in which the GC delays can be
made arbitarily small, even real-time. It is not my scheme but I know
because I have made a real-time implementation using it. See

Glaser, H.W., and Thompson, P., "Lazy Garbage Collection". Software -
Practice and Experience, 17(1), 1-4, January 1987.


		Robert Virding  @ Ellemtel Utvecklings AB, Stockholm
		EMAIL: rv@erix.ericsson.se
From: girou@circe.fr (Denis Girou)
Newsgroups: comp.lang.lisp
Subject: Origins of LISP and relation with Fortran
Keywords: history, fortran
Date: 22 Dec 92 13:44:46 GMT
Reply-To: girou@circe.fr
Organization: CNRS/CIRCE


  Dear friends,


  I want to ask you a confirmation about an history point concerning the
origins of LISP (the section 2-13 of the FAQ doesn't say something about that).

  Some years ago, one of my teacher says during a lesson that when John
McCarthy, around 1956, think to that will become LISP, he only want to write
an extension to the Fortran language (Fortran I or Fortran II at this time)
to manipulate lists structures. It would be only later that he thought to a
real new language, completely independant of Fortran.

  Is there somebody who can confirm or infirm this fact, and can give me a
bibliographic reference? (it's for an article about Fortran that I have to
write...) 

  Thanks for answer.

  Best regards,

------------------------------------------------------
Denis Girou (C.N.R.S./C.I.R.C.E.)                    |
Batiment 506 - B.P. 167 - 91403 Orsay Cedex - France |
E-mail : girou@circe.fr - Tel.  : 33. 1. 69.82.41.52 |
------------------------------------------------------
Newsgroups: comp.lang.ada
From: mfeldman@seas.gwu.edu (Michael Feldman)
Subject: Re: Ada Readability, Book Reference
Organization: George Washington University
Date: Wed, 30 Dec 1992 03:51:43 GMT

In article <9212281507.AA20416@ajpo.sei.cmu.edu> SAHARBAUGH@ROO.FIT.EDU writes:
>I received one request for a pointer to Bryan & Mendal's
>book so I may as well post it (same amount of keystrokes).
>
[stuff deleted]
>
>For many examples the book asks, "What will this
>program print?"  For example 7.3.12 the answer is
>"The answer to the question is indeterminate."
>
>So I ask "Is Ada readable if you can express an indeterminate
>program using it?".
>
The particular example depends on the evaluation order of the sides
of the expression, but more fundamentally, speaks to the approximations
inherent in floating point. Ada's readability has little to do with it -
it's characteristic of digital computers that floating-point arithmetic
has indeterminate results sometimes, so that (A*B)/C may yield a different 
result than A*(B/C). 

In the specific case, (6.0 * 1.0)/3.0 can yield a different result from 
6.0 * (1.0 / 3.0) because 1.0/3.0 cannot be exactly represented.
Therefore an expression like
  6.0 * (1.0 / 3.0) = (6.0 * 1.0) / 3.0
may not evaluate to True. Traditional floating-point gotcha.

You chose an example that doesn't make your point very well, because a
programming language can't fix problems inherent in trying to approximate
the real numbers in a finite number of bits.

Mike Feldman
------------------------------------------------------------------------
Michael B. Feldman
co-chair, SIGAda Education Committee

Professor, Dept. of Electrical Engineering and Computer Science
School of Engineering and Applied Science
The George Washington University
Washington, DC 20052 USA
(202) 994-5253 (voice)
(202) 994-5296 (fax)
mfeldman@seas.gwu.edu (Internet)

"Americans want the fruits of patience -- and they want them now."
------------------------------------------------------------------------
Newsgroups: comp.lang.ada
From: burr@seas.gwu.edu (Timothy J. Burr)
Subject: DOS/Windows Ada compilers - recommendations wanted
Organization: George Washington University
Distribution: na
Date: Mon, 28 Dec 1992 23:50:03 GMT

I need to get an Ada compiler.  I'm a student so cost is a factor but
I would appreciate recommendations.  I would prefer a Windows version
but a DOS implementation would be OK if the price was right.

Tim

burr@seas.gwu.edu 
Newsgroups: comp.lang.ada
From: psm@nosc.mil (Scot Mcintosh)
Subject: Can this data be represented in Ada?
Organization: Naval Ocean Systems Center, San Diego
Date: Thu, 31 Dec 1992 01:47:19 GMT

I'm implementing a data communications protocol that has some data
structural features that don't look possible to implement in Ada.
Perhaps someone more experienced can suggest a way to accomplish
what I'm trying to do (changing the protocol is not an option).

A Transmission Unit looks like:

+---------+----------+-----------+------+
| Packet  |  Packet1 |  Packet2  | etc  |
| Length  |          |           |  ... |
+---------+----------+-----------+------+
    |     |<-------->|<--------->|
    |          ^          ^
    |          |          |
    |__________|__________+


Each Packet looks like:

+---------+----------+--------------+
| Data    |  Data    |  Padding     | 
| Length  |          |(i.e. nothing)| 
+---------+----------+--------------+
|   |     |<-------->               |
|   |          ^                    |
|   |          |                    |
|   |__________|                    |
|                                   |
|<--------------------------------->|
        Packet Length

For a given transmission, the Packet Length is fixed, but can be
different in the next transmission. The Data Length within each
Packet can be different for each Packet. I've tried to figure out how
to define Ada types for the Transmission Unit and Packet that
allow for the variability of the field sizes and haven't succeeded.
Any ideas? Thanks in advance.


-- 
----
Scot McIntosh
Internet: psm%helios.nosc.mil@nosc.mil
UUCP:     I have no idea
Newsgroups: comp.lang.ada
From: BERRYMAN@orca.drep.dnd.ca (DON BERRYMAN)
Subject: Visibility
Organization: Defence Research Establishment Pacific
Date: Wed, 23 Dec 1992 23:35:19 GMT
X-News-Reader: VMS NEWS 1.20



I have a quesiton on Visiblity. The following Ada code
generates the following error.


     package datatypes is
         subtype widget is integer;
     end datatypes;

     with datatypes;
     package testvisibility is
         function widget (a: integer) return datatypes.widget;
     end testvisibility;



     $ ada testviz
         7       function widget (a: integer) return datatypes.widget;
     .........................................................1
     %ADAC-E-NOTDECLALLHIDER, (1) All declarations with designator widget are
             globally hidden by function specification widget at line 7 [LRM 8.3(16)]
     %ADAC-E-ERRPROCESS, Errors compiling package specification testvisibility in
             file FLD$CENTRAL:[BERRYMAN.MFP.MOTIF]TESTVIZ.ADA;4
     %ADAC-E-ENDDIAGS, Ada compilation completed with 1 diagnostic



I can see why this would have happened if I'd coded:

     with datatypes; USE DATATYPES;
     package testvisibility is
         function widget (a: integer) return widget;
     end testvisibility;


But since I have a full specification for DATATYPES.WIDGET
why is there a problem???


Don Berryman
Defence Research Establishment Pacific
Canadian Forces Base Esquimalt
Victoria, BC, CANADA, V0S-1B0
604-363-2731    604-363-2856fax
berryman@orca.drep.dnd.ca

Newsgroups: comp.lang.ada
From: yow@sweetpea.jsc.nasa.gov (Bill Yow)
Subject: PHIGS Ada Binding - Location or Text
Keywords: PHIGS Ada Binding 
Organization: MDSSC
Date: Mon, 28 Dec 1992 22:49:53 GMT

Does anyone know where or if there is a PHIGS Ada Binding?

Thanks,

						Later,
						Bill Yow
						(713) 283-4051
						yow@sweetpea.jsc.nasa.gov
						byow@mcimail.com

My opinions are my own!
From: alex@cs.umd.edu (Alex Blakemore)
Newsgroups: comp.lang.ada
Subject: Re: Ada Readability, Book Reference
Date: 29 Dec 92 19:35:14 GMT
Organization: U of Maryland, Dept. of Computer Science, Coll. Pk., MD 20742

In article <9212281507.AA20416@ajpo.sei.cmu.edu> SAHARBAUGH@ROO.FIT.EDU writes:
> "Is Ada readable if you can express an indeterminate program using it?".

Any language that supports concurrency must allow indeterminate programs
to be expressed in that language.  Indeterminate order of execution of specific tasks
is a necessary consequence of concurrency.  The most that a language can do
is provide robust and efficient mechanisms for keeping (mostly) independent
tasks (mostly) independent - so that programmers can reason effectively about
the program's possible behavior.  Ada does this fairly well, and Ada9X is even better.
Ada9X also tightens the rules in several areas not involving concurrency so that
program behavior is more uniformly specified (bounded) in several previous grey areas.

Nonetheless, IMHO you can write readable or unreadable code in any language.
Ada encourages readable software, especially with the strong division between
package interface and implementation.  Some Ada programmers actually hurt readability 
by equating verbosity 100% with readability.  So a program is readable or not, a language
can only influence readability to a degree.  Ada excels at this, but the standard that
"readability = inability to express an indeterminate program" is the wrong approach.

Finally, I've recently looked at some C code that was hand translated line by line
into Ada.  The C code was pretty readable and better than most - the Ada was appalling.
I think these are the reasons.

  1. The C standard for readability is lower.  The difference between module specs and
     implementation is much fuzzier.  Global variables are considered normal.
     So things that looked normal in C, looked appalling in Ada where I am used
     to a much more careful statement of what's an interface, what's visible etc.

  2. The languages are different - and though some aspects of readability are
     fairly independent (use descriptive names), other idioms depend in subtle ways
     on the language and its culture.  Good LISP style may be bad Ada style.

  3. The human translator did not seem to know Ada well, so even when doing
     line by line translation - did not choose the best Ada constructs for doing
     the little things (loops instead of slice assignments for example) irregardless
     of being stuck with the previous decomposition into modules.

Bottom line - readability depends on many things.
-- 
---------------------------------------------------
Alex Blakemore alex@cs.umd.edu   NeXT mail accepted
From: nebbe@lglsun.epfl.ch (Robb Nebbe)
Newsgroups: comp.lang.ada
Subject: Re: Visibility
Date: 24 Dec 92 11:48:52 GMT
Organization: Ecole Polytechnique Federale de Lausanne

In article <1992Dec24.021655.22555@beaver.cs.washington.edu>, pattis@cs.washington.edu (Richard Pattis) writes:
|> In article <1992Dec23.233519.21523@netfs.dnd.ca> BERRYMAN@orca.drep.dnd.ca (DON BERRYMAN) writes:
|> >
|> >
|> >I have a quesiton on Visiblity. The following Ada code
|> >generates the following error.
|> >
|> >
|> >     package datatypes is
|> >         subtype widget is integer;
|> >     end datatypes;
|> >
|> >     with datatypes;
|> >     package testvisibility is
|> >         function widget (a: integer) return datatypes.widget;
|> >     end testvisibility;
|> >
|> 
|> The LRM says in 8.3(16) "every declaration with the same designator" is
|> hidden. And designators are only identifiers or operator symbols. So it looks
|> like your designator widget, even when declared in another package and
|> selected, is still hidden.  There are two notes on this, but both involve
|> generics
|> 
|> Now, can anyone say why this interpretation "is a good thing".
|> 
|> Rich Pattis
|> 

I think the rule is intended as the simplest way of preventing someone
from writing the following:

function widget (A : integer := widget) return integer;

This prevents the compiler from having to figure out what the designator
corresponds to and whether or not it should be legal. The above code
obviously won't work but how about:

function widget (A : integer := widget(1)) return integer;

I think they wanted to avoid all these legalistic problems and so they
just came up with the simplest rule possible that eliminated the problem.
If people think that Ada is hairy now they should just imagine if it had
rules like:

Within the specification of a function, every declaration with the same 
designator as the function that is found as a default value in the
parameter list is hidden; ...

I would think rules like this would be a compiler writers nightmare.

Robb Nebbe
nebbe@lglsun.epfl.ch
Newsgroups: comp.lang.ada
From: mfeldman@seas.gwu.edu (Michael Feldman)
Subject: Re: C++ vs. Ada -- Is Ada loosing?
Organization: George Washington University
Date: Wed, 23 Dec 1992 22:18:17 GMT

In article <15@mlb.win.net> mbayern@mlb.win.net (Mark Bayern) writes:
>
>I'm afraid you're absolutely correct! But you don't have to look
>into the update cycle to see Ada's commercial problems.  Look at the
>original cost of getting the language.  Want to use C in your
>embedded 80x86? Both MSC and TurboC list for (much) less than
>$1000.  That and a little work and you're up and running.  Ada? How
>about $25,000 for a license, and $5,000 for the _required_ first
>year 'support'! 
>
Huh? I'm curious. Whose 80x86 target compiler is $25,000? RR, AETech, 
Meridian and Alsys' DOS extended-mode compilers are all in the $1-2k range,
commercial prices (maybe less). Who else is there?

Are you thinking of the commercial prices for Unix-server-host compilers?
I'll admit that those are too high, but not the DOS-host ones. Is your
information up to date? Meridian? Alsys? You awake out there?

If this post's information is correct, we are all in BIG trouble. If not,
this is a great example of the lousy job we are doing in the Ada
community in getting the facts out into the street, guys.

Mike Feldman
------------------------------------------------------------------------
Michael B. Feldman
co-chair, SIGAda Education Committee

Professor, Dept. of Electrical Engineering and Computer Science
School of Engineering and Applied Science
The George Washington University
Washington, DC 20052 USA
(202) 994-5253 (voice)
(202) 994-5296 (fax)
mfeldman@seas.gwu.edu (Internet)

"Americans want the fruits of patience -- and they want them now."
------------------------------------------------------------------------
Newsgroups: comp.lang.ada
From: dtl8v@holmes.acc.Virginia.EDU (Heracleitus)
Subject: Ada RTE/F.A.A.-certified?
Originator: dtl8v@holmes.acc.Virginia.EDU
Organization: University of Virginia
Date: Thu, 31 Dec 1992 02:01:20 GMT


  I recently came across a reference in the AIAA/IEEE 8th Digital
Avionics Systems Conference to an Ada RTE bassed on a U.S.
F.A.A.-certified executive in one or more commercial Ada compiler
systems.  I was hoping someone out there would be able to give me a
lead on this, as the article in the proceedings did not provide
specific detail, and there may be more than the author mentioned.

Doug Lamb
University of Virginia
dtl8v@Virginia.EDU
Newsgroups: comp.lang.ada
From: srctran@world.std.com (Gregory Aharonian)
Subject: Re: Cost of Ada (was - Re: C++ vs. Ada -- Is Ada loosing?)
Organization: The World
	<1992Dec29.161150.23301@nosc.mil> <1992Dec30.040140.10412@seas.gwu.edu>
	<1992Dec30.160803.2211@mksol.dseg.ti.com>
Date: Thu, 31 Dec 1992 04:25:26 GMT

>Consider.  Most of the current customers for such systems are doing
>Defense work, where Ada is mandated.  They are, in effect, consumers
>in a captive market.  This artificially pushes the demand curve to a
>position where demand is artificially high at each market price and
>the elasticity of demand is quite low.  Hence, the supplier in such a
>market will exercise what is, after all, only good business sense, and
>will price their product artificially high in that market.
>Arbitrarily lowering their price in that kind of captive market
>situation leads to lower profits (since they make less on each of the
>'mandated' purchases).  This is why you will likely never see anything
>like a 'Turbo Ada' while the Mandate is in force, unless the
>government funds the thing itself (trying to correct market
>distortions caused by government intervention through the use of more
>intervention). 

This suggestion and others dealing with DoD Ada software policies pose very
interesting microeconomic conditions that have been totally ignored by the
DoD over the past ten years.  Many free market concepts - competition,
marketing, supply and demand, cost curves, etc - are for the most part no
reflected anywhere in DoD software policy planning.  There are no accounting
data sets to assess such questions, no microeconomic models to apply such
data to, and no interest inside the DoD, in particular the STARS effort,
to care or be concerned about such questions.  At least the Russian central
planners had economic models of what they were trying to do, even if the
models were lousy economics.

The problem with the Mandate is that it is part of the big Lie: that anyone
can claim anything about DoD software policies, knowing that no one downstream
will be able to veryify or disprove such claims, or remember what the original
claims were.  The STARS program, with its endless reorganizations and new
sets of claims, is a classic example.  Ada is just a side issue to the DoD
brass (my face is still blue holding my breath waiting for Strassman to
publicly mention Ada in one of his interviews).

Greg Aharonian
Source Translation & Optimization
-- 
**************************************************************************
Greg Aharonian
Source Translation & Optimiztion
P.O. Box 404, Belmont, MA 02178
Newsgroups: comp.lang.ada