HDTenEightyP/NetNews huggingface dataset:
From: msm@mse.cmu.edu (Mark S McWhinney)
Newsgroups: comp.lang.lisp
Subject: Re: Allegro CL and C code
Date: 29 Sep 92 22:44:27 GMT
Article-I.D.: cs.BvD364.CAs.2
Organization: CMU/SEI Master of Software Engineering Program


FYI - 

Nick (nick@cs.washington.edu) sent the following answer which I have
tested.  I works great.


Here's what I did when I wanted to pass AND get back a string.  
The key is to have a :fixnum get returned, and then use
ff:char*-to-string.

        (ff:defforeign 'espresso-interface
            :arguments '(string)
            :return-type :fixnum
            :entry-point *espresso-interface-entry-point*)

and the function call

        (ff:char*-to-string (espresso-interface <argument>))
From: stolcke@ICSI.Berkeley.EDU (Andreas Stolcke)
Newsgroups: comp.lang.lisp
Subject: infix -> lisp package sought
Date: 6 Oct 1992 19:03:20 GMT
Organization: International Computer Science Institute, Berkeley, CA, U.S.A.
Distribution: world
NNTP-Posting-Host: icsib30.icsi.berkeley.edu

I am wondering whether someone out there has or knows of a tool that converts
arithmetic expressions in infix notation (e.g. (3 + 4)) into standard
Lisp expressions (+ 3 4).  Ideally this could be hooked up to a read macro
so code containing huge arithmetic expressions could be made more readable.

It would nice if this tool were extensible, along the lines of Prolog's 
operator definitions.

Please reply via email, I'll summarize to the net.

-- 
Andreas Stolcke					stolcke@icsi.berkeley.edu
International Computer Science Institute	stolcke@ucbicsi.bitnet
1947 Center St., Suite 600, Berkeley, CA 94704	(510) 642-4274 ext. 126
From: KMP@stony-brook.scrc.symbolics.com (Kent M Pitman)
Newsgroups: comp.lang.lisp
Subject: string search and assignment
Date: 30 Sep 92 04:01:47 GMT
Organization: LCS news/mail gateway
X-Unparseable-Date: Tue


    Date: Tue, 29 Sep 1992 20:11 EDT
    From: Robert L Pack <rlpst@cislabs.pitt.edu>

    ... What i want to do is start at the beginning of the file( which I can do)
    and search for the word "entity". Once I find this, I want to assign the
    next word to a variable.  ...

Use WITH-OPEN-FILE to open the stream.  It will let you specify a variable
to which the stream is bound.  The I/O routines all take a stream as argument. e.g.,

(defun find-word-association-in-file (word file)
  (with-open-file (stream file :direction :input)
    (loop
      (let ((line (read-line stream nil nil)))
	(declare (type string line))
	(unless line (return nil))
	(let ((pos1 (position #\Space line :test #'char-equal)))
	  (when (and pos1 (string-equal word line :end2 pos1))
	    (let ((pos2 (position #\Space line
				  :test (complement #'char-equal)
				  :start pos1)))
	      (when pos2
		(return (subseq line pos2
				(position #\Space line
					  :test #'char-equal
					  :start pos2)))))))))))

Given a data file "delete-me.text" containing:

FOO OOF
BAR RAB XYZZY
BAZ ZAB PLOVER PLUGH 
NUL NIL

I find that:

 (find-word-association-in-file "FOO" "delete-me.text")  => "OOF"
 (find-word-association-in-file "BAZ" "delete-me.text")  => "ZAB"
 (find-word-association-in-file "NUL" "delete-me.text")  => "NIL"
 (find-word-association-in-file "GEE" "delete-me.text")  => NIL

So you'd do 

 (setq my-var (find-word-association-in-file ...))
Newsgroups: comp.lang.ada
From: solomond@ajpo.sei.cmu.edu (John Solomond)
Subject: ASISWG Technical Meeting
Keywords: ASIS
Organization: Ada Joint Program Office
Date: Tue, 6 Oct 1992 16:57:20 GMT

	The Ada Semantic Information Specification (ASIS) Working Group
will hold ASISWG Technical Meetings on Wednesday and Thursday, 14-15
October at:

		Institute for Defense Analyses
		2001 N. Beauregard Street
		Alexandria, VA 22311

	A short plenary meeting will be held on Wednesday morning
beginning at 8:30 AM.  These technical meetings will continue through
Thursday afternoon, ending about 4:30 PM.

	If you would like to attend, please send an email message
and/or call Clyde Roby with your name, company, and phone number.

		Clyde Roby
		roby@Ida.org
		(703) 845-6666
		FAX: (703) 845-6848

Newsgroups: comp.lang.ada
From: goodsenj@ajpo.sei.cmu.edu (John Goodsen)
Subject: Re: Ada's (in)visibility in the engineering community
Organization: Ada Joint Program Office
Date: Fri, 2 Oct 1992 06:24:11 GMT

>
>dag@control.lth.se (Dag Bruck) writes:
>
>I think that to some extent it depends on how precise you want to be.
>I usually simplify matters and tell people that exception handling in
>C++ is "just like Ada."  There are of course important differences,
>and I know them.  If you want to be more precise you must also mention
>influences from other languages, e.g., Clu, Mesa, ML and PL/I.  In
>that situation it is easy to answer "absolutely not" if someone asks
>if EH in C++ is like EH in Ada.
>

See a recent post by Bjarne Stroustrup in comp.lang.c++ for his explicit
addressing of what was and was not inspired by Ada in C++.
Exception handling was not really inspired by Ada.  C++
templates were greatly inspired by Ada generics however.

John Goodsen
goodsenj@ajpo.sei.cmu.edu

Newsgroups: comp.lang.ada
From: mab@wdl39.wdl.loral.com (Mark A Biggar)
Subject: Re: Declaring Arrays of Bits (how)?
Organization: Loral Western Development Labs
Distribution: comp
Date: Tue, 29 Sep 1992 17:07:54 GMT

In article <YOUNG.92Sep29101112@kuwait.gdfwc3> young@gdfwc3 (Mark Young) writes:
>I am trying to declare arrays of bits in Ada.  Here's my attempt:
>type Array_Range_Type is range 1..128;
>type Bit_Type is (OFF, ON);
>for  Bit_Type use (OFF => 0, ON => 1);
>for  Bit_Type'size use 1;
>type Bit_Array_Type is array (Array_Range_Type) of Bit_Type;
>Bit_Array : Bit_Array_Type;
>
>This looks right to me.  I would expect Bit_Array to be represented
>as an array of 128 bits (128 contiguous bits).  This is not the case,
>however.  My compiler (XDADA) is representing Bit_Array as an array
>of 128 bytes.  As an added note, I have been using representation clauses
>for records without any problems.  
>Am I missing something?  
>Is there a special representation clause for arrays that I am overlooking? 
>Is my compiler at fault?

For most compilers you probably need to throw a:

pragma PACKED(Bit_Array_Type);

in the mix somewhere as well.  Otherwise according to the LRM the compiler is
under no obligation to put the array element in anything smaller then a byte
each unless you add the pragma PACKED.

--
Mark Biggar
mab@wdl1.wdl.loral.com
From: lwelton@a (Lou Welton)
Newsgroups: comp.lang.ada
Subject: info-ada digest newlstters
Date: 28 Sep 92 16:04:01 GMT
Organization: The Internet


 Please send the most recent issues of Info-Ada Digest to my new
e-mail address:  lwelton@asv3.wvnet.edu.  This will insure that the
issues are not received by our old host.  If you could mail all September 
issues to the new address, I think we'll be in sync.  Thank you very much
for your attention to this and please note that our clients greatly 
appreciate reading through this publication--we've received several favorable
comments.  Thanks again.  Lou Welton

Newsgroups: comp.lang.ada
From: rlk@VisiCom.COM (Bob Kitzberger)
Newsgroups: comp.lang.ada
Subject: Re: TASKS
Date: 6 Oct 92 19:47:23 GMT
Distribution: usa

mperez@ringer.cs.utsa.edu (Michael Perez) writes:

>TASK body Name IS
>begin
>    Accept filename(...);
>         ...........
>         statements
>         ...........
>    End filename;
>end Name;

>It seems like the TASK is executed one time then I always get a
>TASKING_ERROR. 

You need to put a loop..end loop pair around the accept statement in the task,
otherwise your task Name will accept a single entry call, and then terminate.

	.Bob.
----------------
Bob Kitzberger          VisiCom Laboratories, Inc.
rlk@visicom.com         10052 Mesa Ridge Court, San Diego CA 92121 USA
                        +1 619 457 2111    FAX +1 619 457 0888
Newsgroups: comp.lang.ada
From: eachus@Dr_No.mitre.org (Robert I. Eachus)
Subject: Re: conditional compiles ?
Organization: The Mitre Corp., Bedford, MA.
Date: Tue, 29 Sep 1992 16:37:36 GMT


    The other replies to this message are barking up the wrong tree.
We all know that in Ada it is almost always possible to code in an
implementation independant manner so a first order answer is that you
don't use anything like #ifdef.  (Or #include, a lot of early Ada
compilers implemented pragma INCLUDE, but no one ever used it.)  If
you do have to have hardware specific code, the usual approach is to
put all that code in one or two packages and if necessary maintain
several versions of it.

--

					Robert I. Eachus

with STANDARD_DISCLAIMER;
use  STANDARD_DISCLAIMER;
function MESSAGE (TEXT: in CLEVER_IDEAS) return BETTER_IDEAS is...
Newsgroups: comp.lang.ada
From: sakkinen@jyu.fi (Markku Sakkinen)
Subject: Re: Ada's (in)visibility in the engineering community
Organization: University of Jyvaskyla, Finland
Date: Tue, 6 Oct 1992 07:27:22 GMT

In article <1992Oct5.195015.128@fcom.cc.utah.edu> val@news.ccutah.edu (Val Kartchner) writes:
>sakkinen@jyu.fi (Markku Sakkinen) writes:
>: In article <1992Sep25.210409.23219@fcom.cc.utah.edu> val@news.ccutah.edu (Val Kartchner) writes:
>: > ...
>: >A major superiority claim can be made on behalf of C's real-time ability over
>: >Ada's real-time ability in that families of commerically viable (meaning
>: >actually FAST) operating systems have been written using C.  While it may be
>: > ...
>: 
>: Please, tell us even _one_ real-time feature of C !
>
> [long rambling about dictionary definitions etc. deleted)]
>Note: none of the above definitions specifies any requirements for "real-time".
>However, they all heavily imply that speed is VERY important in "real-time".
>In "Ada Versus C++: A Business Case Analysis" (this should be an acceptably
>biased souce of information for this group), says that C and C++ both
>score higher (are faster) in run-time speed.
>
>However, contrary to common English usage, the same report says that Ada has
>a better real-time score.  This apparent contradiction can most easily be
>resolved by concluding that Ada has a definition for "real-time" which differs
>from common English usage.

So, according to your reasoning, "speed" is the _only_ real-time characteristic
that matters (and be it just 1% faster).  You will not find many supporters.

>sakkinen@jyu.fi (Markku Sakkinen) writes:
>: Please, tell us even _one_ real-time feature of C !
>Please, first explain these three things to me:
>
>   1 - What is the definition of "real-time" which Ada uses?
> ...

No, it was you who originally touted "the superior real-time capabilities
of C".  I don't even force a definition of 'real-time' upon you.
If _you_ have any definition of 'real-time' which is not totally
ridiculous (like "speed"), please tell us one real-time feature of C
according to that definition.  To support your original claim,
that feature should be better than what Ada has, although I originally
didn't demand even that.
(You are free to look in appropriate books, of course.)

>Now that that has been addressed, my original point is that C and (by
>inheritance) C++ are commercial real-time successes.  If you doubt this
> [rambling totally beside the point deleted]

----------------------------------------------------------------------
Markku Sakkinen (sakkinen@jytko.jyu.fi)
       SAKKINEN@FINJYU.bitnet (alternative network address)
Department of Computer Science and Information Systems
University of Jyvaskyla (a's with umlauts)
PL 35
SF-40351 Jyvaskyla (umlauts again)
Finland
----------------------------------------------------------------------
Newsgroups: comp.lang.ada
From: mperez@ringer.cs.utsa.edu (Michael Perez)
Subject: TASKS
Organization: University of Texas at San Antonio
Distribution: usa
Date: Tue, 6 Oct 1992 02:24:50 GMT

I am learning ada and I was having trouble with TASK. My code looks
something like this
 
PROCEDURE joe IS
   ......
   ......
   declarations
   .....

TASK Name IS
     entry filename(...);
END;

TASK body Name IS
begin
    Accept filename(...);
         ...........
         statements
         ...........
    End filename;
end Name;

Begin
   while (....) Loop
       Name.filename(....);
   end loop;
end joe;

It seems like the TASK is executed one time then I always get a
TASKING_ERROR. I tried putting an exception to handle this error but
it didn't work. I think there is something about TASK that I don't understand
if anyone has any comments please let me know.
                                                    Thanks.
Newsgroups: comp.lang.ada
Subject: Derived types and portability
From: mmangieri@vitro.com (M. J. Mangieri)
Date: 25 Sep 92 11:20:00 -0500
Distribution: world
Organization: Vitro Corporation

I have always achieved portability by using user-defined types such as:

     type MY_INTEGER is range 0 .. 2**32-1;

However, I recently came across a document that suggested using derived types
in combination with length representation clauses to achieve portability:

     type MY_INTEGER is new INTEGER;
     for MY_INTEGER'SIZE use 32;

Are these two methods equivalent? I understand the second case to simply
reserve more storage. For example, if the platform is a PC, where INTEGER is 16
bits, I would think the run-time would still enforce a range of values that are
limited to 16 bits, but give you a word size of 32 bits.
Is this correct, or am I missing something?
         __________________________________________________________________
        / Michael J. Mangieri                 Internet: mmangieri@vitro.com
__     /  Vitro Corporation                      Voice:      (301) 231-3016
  \   /   MX-SP 4-2311                             FAX:      (301) 231-1233
   \ /    14000 Georgia Ave.              
    *     Silver Spring, MD 20906-2972    

         "Everything should be made as simple as possible, but not simpler."
                                                       - A. Einstein
From: eachus@Dr_No.mitre.org (Robert I. Eachus)
Newsgroups: comp.lang.ada
Subject: Re: Difference between a function and an operation
Date: 29 Sep 92 18:57:08 GMT
Organization: The Mitre Corp., Bedford, MA.

In article <PDB7L1R@math.fu-berlin.de> weberwu@inf.fu-berlin.de (Debora Weber-Wulff) writes:

   Could someone either explain the distinction between an operation
   and a function in Ada or quote chapter and versein the LMR? I
   understand that '+' and '*' and such are operations, and when I
   define a function hugo to return a value, then that is a function.

   Hmmm... Tall order, I'll try to answer in a way that is consistant
with the current ARG position.  There are a number of overlapping
terms involved, and Venn diagrams would be pretty useless.

   Let's start with 3.3(1):

   "A type is characterized by a set of values and a set of operations."

   Then go to 3.3.3(whole section):

   "The set of operations of a type includes the explicitly declared
subprograms...The remaining operations are each implicitly
declared...These implicitly declared operations comprise the basic
operations, the predefined operators and enumeration literals."

   "A basic operation is...An assignment...selected component...
qualification...type conversion...literal...aggregate...or an
attribute."  [Very heavily edited, and I intentionally ignored derived
types.]

   Finally in 6.7(1):

   "The declaration of a function whose designator is an operator
symbol is used to overload an operator."
   
   So there is a + for, say, integer which is a predefined operation.
You may also declare:

	   function "+" (L,R: Integer) return Integer;

   to overload the addition operator.  What is the difference?  The
predefined operations of a type are always in scope, but they may be
hidden, as above.  In a generic only the predefined operations of a
formal type parameter are visible, unless the operator is also passed
as a formal parameter:

	generic
	  type Int is range <>; -- a generic formal integer type.
	  with function "+"(L,R: Int) return Int is <>;
	  -- use the "+" for the actual parameter corresponding to Int
	  -- and visible at the point of instantiation.  This may be
	  -- the predefined operation.
        package...

     Also if you derive from a type, any subprograms (with a parameter
or result of the type) declared in the same package specification as
the parent type are derivable, and are available for the derived type
also.  In this there is no distinction between predefined and other
operations.

      Summary:

    A type has basic operations, predefined operators, and explicitly
declared operations (possibly including enumeration literals).
Derived types also have derived operations.  (In the case of a derived
enumeration type, the enumeration literals are derived operations.)
The predefined operations include the basic operations and the
predefined operations.

--

					Robert I. Eachus

with STANDARD_DISCLAIMER;
use  STANDARD_DISCLAIMER;
function MESSAGE (TEXT: in CLEVER_IDEAS) return BETTER_IDEAS is...
From: crispen@efftoo.boeing.com (crispen)
Newsgroups: comp.lang.ada
Subject: Re: Using Global Variables
Date: 25 Sep 92 14:01:56 GMT
Organization: The Internet

sampson@cod.nosc.mil  (Charles H. Sampson) says:

>     Several of the entries in this thread have raised the spectre of shared
>memory.  Without addressing whether shared memory is good or bad, let's clar-
>ify that it's not the point of this thread.

Mea culpa, inter alia.  I keep thinking of the way that global visibility
is implemented (as memory).  And if you've got any sort of tasking or 
multiprocess considerations you have at least the possibility of
shared memory.  So I apologize for going from point A to point Q
without touching the bases in between, and for my part in broadening
the topic.

You are certainly right that communication between elements within a
process and communication between processes are two separate things.
I do think, though, that there are global visibility issues for both.
And I think that people writing on this topic were addressing both.

For example:

Larry Howard  (lph@sei.cmu.edu) says:

>There may also be considerable power in other forms of coordination, even if
>these same forms have been misused in the past.  I think we should only insist
>that whatever is used be understandable and predictable.

Right on!  I'm not sure I completely accept your notion of "decoupling
communication from invocation or synchronization" but I agree that
"previous offenders" should be given a chance to rehabilitate themselves.

I know that you believe that there are software architectures that
can standardize and template-ize the use of global variables to such an
extent that the practice becomes safe.  I think I do, too.  What I
do wonder about is the non-abstract use of memory (potentially
shared memory in a multiprocess system) to implement global variables.
That's the part I have concerns about.

It feels to me like we've taken our "previous offender", locked him
in a room with only a couple of doors in and out (which we can watch)
but he's (potentially) using the phone to commit crimes.
 
>I guess what I really objected to in this thread was the odor of orthodoxy
>when (IMHO) we still seem to be on a fairly steep learning curve.
 
Double right on!  And another mea culpa if my pedantic style was
mistaken for assurance about my views.  I am presently only sure that
I have doubts.
+-------------------------------+--------------------------------------+
| Bob Crispen                   |     Down with orthodoxy, or DIE!     |
| crispen@foxy.boeing.com       +--------------------------------------+
| (205) 461-3296                |Opinions expressed here are mine alone|
+-------------------------------+--------------------------------------+
Newsgroups: comp.lang.ada
From: erskine@cs.dal.ca (Neil Erskine)
Subject: Is there a FAQ for this newsgroup
Organization: Math, Stats & CS, Dalhousie University, Halifax, NS, Canada
Distribution: na
Date: Tue, 29 Sep 1992 17:31:06 GMT

][b
Is there a Frequently Asked Questions (FAQ) list for this newsgroup?
If so, would someone mail it, or a location from whence it can be FTPed
please?

My immediate question is what Pascal to Ada translators are available.

	Thanks,
	    Neil Erskine
||!][b
-- 
Neil Erskine		erskine@cs.dal.ca
			uunet!dalcs!erskine
From: pelakh@convex.com (Boris Pelakh)
Newsgroups: comp.lang.ada
Subject: Re: TASKS
Date: 6 Oct 92 11:23:04 GMT
Distribution: usa
Organization: Engineering, CONVEX Computer Corp., Richardson, Tx., USA
X-Disclaimer: This message was written by a user at CONVEX Computer
              Corp. The opinions expressed are those of the user and
              not necessarily those of CONVEX.

In article <1992Oct6.022450.9087@ringer.cs.utsa.edu> mperez@ringer.cs.utsa.edu (Michael Perez) writes:
>I am learning ada and I was having trouble with TASK. My code looks
>something like this
> 
Your task body performs the accept only once, after that the task becomes 
terminated, and you get a TASKING_ERROR when calling the entry a second time.
Modify your task as follows:

>
>TASK body Name IS
>begin
  loop
   select
>    Accept filename(...);
>         ...........
>         statements
>         ...........
>    End filename;
   or
     terminate;
   end select;
  end loop;
>end Name;



-- 
Boris Pelakh		Ada Project Leader          pelakh@convex.com
		     Convex Computer Corporation
"If winning isn't important, why keep score ?"	-- Lt. Worf, Star Trek TNG.
From: eachus@Dr_No.mitre.org (Robert I. Eachus)
Subject: Re: The trouble with Ada... (60 lines)
Organization: The Mitre Corp., Bedford, MA.
	<92Sep22.205921edt.47893@neat.cs.toronto.edu>
	<1992Sep24.150801.20492@mksol.dseg.ti.com>
Date: Tue, 29 Sep 1992 21:47:28 GMT

In article <1992Sep24.150801.20492@mksol.dseg.ti.com> mccall@mksol.dseg.ti.com (fred j mccall 575-3539) writes:

   Anyway, I don't think the 'superhacker' mentality is any less
   prevalent in Ada -- it is just justified differently.  After all,
   how many people have you heard assert that SIMPLY BECAUSE THEY ARE
   USING ADA they will not have this or that error?  Sounds like an
   unreaasonable faith in a 'magic bullet' to me; just another way to
   justify the 'superhacker' syndrome.

   Yes, language will somewhat impact your approach to a problem, but
   this should happen only insofar as taking into account SHORTCOMINGS of
   the language is an impact.  This is another one of those
   mythology-breaking things...

   Sorry Fred, but anyone who has done much Ada development knows
that developing in Ada IS different.  Back in 1983-1985 the Greek
chorus at AdaTEC (later SIGAda) meetings was that "Ada is not just
another programming language."  Learning to program in Ada meant
learning software engineering.

   A few years later, many people had discovered that development in
Ada meant something like 60% design, 20% code, 10% integration and test.
Much different from the old 40% design, 50% code, 90% integration and
test.  It is now becoming apparent WHY this is, which is why I started
preaching to the converted.  (Anyone who has seen the magic of the
integration phase of a large Ada project knows that things are
different.  Anyone who hasn't doesn't believe it.)

   My experience has been that in over a million lines of Ada code,
ALL of the problems I have encountered in system integration involved
script files and pathnames.  All of the parameter mismatches and name
conflicts were long gone by then, as well as most of the bugs.  One
system had one bug report in the first six months after it was
released--an error message was misspelled, most others had none.
(This of course does not include internal and beta testing.)

   Why does it work out this way?  Because it is very easy to express
ANY workable system design in Ada.  So if you can't express the
design, you know you are in trouble.  And you find out early.  Of
course, many times the design is expressable in Ada but won't work.  I
have always found it fairly easy to reconfigure the design in these
cases, with even major reorganizations requiring only a couple of
days.  Minor fixes like add another parameter to an interface or
another field to a record usually takes less than an hour, including
recompiles.
--

					Robert I. Eachus

with STANDARD_DISCLAIMER;
use  STANDARD_DISCLAIMER;
function MESSAGE (TEXT: in CLEVER_IDEAS) return BETTER_IDEAS is...