HDTenEightyP/NetNews huggingface dataset:
From: James.MacGregor@ttlg.UUCP (James MacGregor)
Newsgroups: comp.lang.pascal
Subject: NO NUMBERS! (or even SHORT INTS!)
Date: 4 Oct 92 02:32:05 GMT


 > From: klaus@diku.dk (Klaus Ole Kristiansen)
 > Newsgroups: comp.programming,comp.lang.c,
 > comp.lang.pascal,comp.lang.objective-c
 > Subject: Re: NO NUMBERS! (or even SHORT INTS!)
 > Organization: Department of Computer Science, U of Copenhagen
 > Date: 29 Sep 92 09:35:16 GMT

 > A friend of mine once accused me of writing spaghetti
 > code, because had written

 > count := count + 1

 > He insisted that it should be

 > count := succ(count)

You can still do it one better (in Turbo Pascal, anyway); try:

Inc(count)

 > He is a physics major, BTW

That explains much.  :-)

---
 * Origin: {========[ *** Infinite Recursion *** ]========} (42:100/16)
From: abunaser@plains.NoDak.edu (Samy Abunaser)
Newsgroups: comp.lang.pascal
Subject: help needed
Date: 30 Sep 92 17:49:37 GMT
Article-I.D.: plains.20826
Distribution: usa
Organization: North Dakota Higher Education Computing Network



Hi 
 I wrote a Turbo Pascal Software and I would like to debug it.
 I have used tracing and breakpoints to do that; however, I do not think 
 that is enough. 

 My question: Is there any method for debugging Turbo Pascal programs 
 available?  I would appreciate it if someone gives me a reference where
 I can find it or if you can mail me the method.   

                                                Thanks.
                                              Samy Abunaser
Newsgroups: comp.lang.pascal
From: peter@psychnet.psychol.utas.edu.au (Peter R. Tattam)
Subject: Re: Turbo Pascal 7.0
Organization: Psychology Department, University of Tasmania
Date: Wed, 7 Oct 1992 02:46:53 GMT

In article <718329910.F00001@monly.wlink.nl.wlink.nl> Berend.de.Boer@p23.f112.n100.z60.wlink.nl (Berend de Boer) writes:
>From: Berend.de.Boer@p23.f112.n100.z60.wlink.nl (Berend de Boer)
>Subject: Turbo Pascal 7.0
>Date: 2 Oct 92 11:08:08 GMT
>Alf Christophersen wrote in a message to All:
>
> AC> What I would like to see in a new TP, is the Simula notion
> AC> of assigning values to a variable.
>
> AC> a :- b means that you assign the pointer of a to point to b,
> AC> but
> AC> a := b, means that you copy the info in the fields of b to
> AC> the variable a, without moving the pointer.
>
>You can write a := @b
>
>Greetings, ...... === Ent ===

From memory, I think that all type checking goes out the door if this method 
is used.  (I use it a lot to coerce data structures)  It would be 
nice if TP could either tighten up the @ operator, or perhaps allow the 
construct

	a := ^b;

to enforce the more strict type checking which makes pascal such a useful 
tool in a production environment.  I don't think there are any syntactical 
problems with doing this.

This kind of thing does however cause errors for the heap manager. What 
happens if one disposes a pointer which has been assigned using this 
method?  Maybe one should define two types of pointers.... ones which can 
be new/disposed, and ones which can't.  The compiler can then check that you 
don't assign a pointer from a non-heap reference to a heap pointer, 
but you are still allowed to copy the data the pointer points to.  Just some 
musing anyway...  it would probably open up too many cans of worms later 
on.  Still, it might be useful for operating systems programming.

One wonders if the whole area of pointers needs to be rethought...  the 
concept of a pointer is at least 20(?) years old now... and yet they seem to 
be used like the old goto statement sometimes.  Is there a way of 
formalizing pointer usage so that illegal operations on pointer types can be 
minimized.  I reckon that bad pointers would account for a large percentage 
of programming bugs.... especially so with object oriented programming with 
virtual methods.

Peter
----------------------------------------------------------------------------
P.Tattam                                    International Phone 61-02-202346
Programmer, Psychology Department           Australia     Phone   002-202346
University of Tasmania, Hobart, Tasmania, Australia
----------------------------------------------------------------------------
Newsgroups: comp.lang.pascal
Subject: Re: Turbo Pascal 7.0set profile
From: khill@vax1.umkc.edu
Date: Wed, 30 Sep 1992 13:12:36 GMT
Organization: University of Missouri - Kansas City

In article <1992Sep18.141433.12834@kth.se>, kjell@weber.e.kth.se (Kjell Rilbe) writes:
> I have seen a lot of good points on what should be in TP 7, but I find
> one thing missing:
> 
> I want to be able to return RECORD types from functions!!!!!!!
> 
> I know Think pascal for MAC can do this, why can't TURBO????
> 
> Please!
> 
> /Kjell

	Try doing this:
type
  tmyrec = record
		mystring  : string;
		myinteger : integer;
		myreal    : real;
	   end;

VAR
  myrec   : ^tmyrec
  yourrec : ^tmyrec

  function myfunction(myparams : integer) : pointer
    begin
      myrec^.mystring :='this is a test';
      myrec^.myinteger:=myparams
      myrec^.myreal   :=3.14159265;
   
      myfunction := myrec;
    end;

  begin
    new(myrec);
    new(yourrec);

    writeln('old value of myrec');
    writeln(myrec^.mystring);
    writeln(myrec^.myinteger);
    writeln(myrec^.myreal);
    writeln;
    
    yourrec^:=myfunction(100)^;
    writeln('new value of yourrec');
    writeln(yourrec^.mystring);
    writeln(yourrec^.myinteger);
    writeln(yourrec^.myreal);
  end.
From: BAKERRE@awc1.eglin.af.mil (Baker, Robert E.)
Newsgroups: comp.lang.pascal
Subject: OOP questions
Date: 6 Oct 92 13:22:39 GMT


	I have a few questions I need to ask about OOP, and from what I've
seen in this newgroup, this seems to be as good a place to start as any.
	While I am beginning to understand the basic concepts of OOP
(encapsulation, inheritance and ploymorphism), the thing that seems to be a
little hard for me right now is how do I determine what needs to be an object
and what doesn't?  How far should I break something down for a starting point?
	As an example, I have a file/directory maintenance program (PCWand)
that I've been working with for a few years now, and would like to convert it
to OOP.  The basic question I have to ask myself is how do I break down the
file objects?  Should I have one object for all files, or should I have a base
object with, say, the name and attributes, and then declare the different
types of files (directories, volume label, etc) from that base object?  That's
the concept I'm having a little problem with right now.
	I would appreciate ANY comments or suggestions at all on this - good 
and bad.  Thanks.

Bob Baker
BAKERRE@TAWC1.EGLIN.AF.MIL
From: grund@prosun.first.gmd.de (Stephan Grund)
Newsgroups: comp.lang.pascal
Subject: Re: Turbo Pascal 7.0
Date: 28 Sep 92 11:28:30 GMT
Organization: GMD-FIRST, D-1000 Berlin 10

<1992Sep24.153932.3666@ifi.uio.no> writes:

>My wishes for TP:

...

>   'Statements with values': allowing things like
>      x := if b then y+z else 0;
>      if (x := z*y) = 0 then ....

when b is a boolean variable You can do something like:

x := Ord(b) * (y+);

This works cause the ordinal behavior of boolean
expressions ( Ord(false)=0 ; Ord(true)=1 ).
Newsgroups: comp.lang.pascal
Newsgroups: comp.lang.pascal
Subject: flowchart program
Date: Tue, 29 Sep 1992 18:05:00

Does anybody have a good flowchart program?  Binaries would be nice
xx3401 ed if they were small.  Source code would be nice too.  If
anybody knows a BBS in the New England area with a good one please
tell
me too.  Thanks
  OLX 2.1 TD  A bug is a feature that didn't make it into the
manual.


 * Origin: Leo Technology (603)432-2517/432-0922 (HST/V32)
(1:132/189)
Newsgroups: comp.lang.pascal
Newsgroups: comp.lang.pascal
Subject: speaker too high to hear?
Date: Tue, 29 Sep 1992 20:07:00

I tried using the speaker at very high hertz (I didn't hear a thing).
Does this really make a sound on the standard PC speaker, or does the
software just "know" that it can't make a sound that high and ignore
it?
I was thinking of making a dog whistle TSR.
  OLX 2.1 TD  Fatal Error: Programmer executed


 * Origin: Leo Technology (603)432-2517/432-0922 (HST/V32)
(1:132/189)
From: samodena@csemail.cropsci.ncsu.edu (S. A. Modena)
Newsgroups: comp.lang.pascal
Subject: Re: TVision - Anything I should know?
Date: 4 Oct 92 11:05:34 GMT
Organization: Crop Science Dept., NCSU, Raleigh, NC 27695-7620

In article <1992Oct03.193705.7070@CS.ORST.EDU> tannerr@prism.cs.orst.edu writes:
>jonathan@nova.next.nd.edu (Jonathan Bradshaw) writes:
>
>>I am about to go delving into TurboVision. I have heard of some problems
>>with it (something about a keyboard problem with the built in keyboard
>>reader for some key?)  Anything I should know? Patches? Utilities?

>> Jonathan Bradshaw | jonathan@nova.decio.nd.edu -or- jbradsh2@darwin.cc.nd.edu
>
>First, the TV manual is messed up in my opinion.  Read chaps 1, 3, 4, and 5
>BEFORE reading chapter 2.  THEN read chap 2 (which is a detailed set of
>examples with minimal background information... you'll get lost for sure.)

Oh oh!  Jeff Duntemann is going to be disappointed to hear that....'cuz I
think he did the manual for Borland......

>
>Dr. Dobb's Journal did about 5 or so articles on TV starting with issure 183
>(I think).  You may want to look them up in your local university library.
>It has some good stuff on how to make new classes streamable.

To get more specific, these articles were under a regular column called:
"Structured Programming"  by...by Jeff Duntemann.  :^)

But, fortunately, they are not a rehash of the book...(eh) manuals, manuals.
The articles aren't bad at all.

>
>Ryan (tannerr@prism.cs.orst.edu)

Steve
---
+------------------------------------------------------------------+
|     In person:  Steve Modena     AB4EL                           |
|     On phone:   (919) 515-5328                                   |
|     At e-mail:  nmodena@unity.ncsu.edu                           | 
|                 samodena@csemail.cropsci.ncsu.edu                |
|                 [ either email address is read each day ]        |
|     By snail:   Crop Sci Dept, Box 7620, NCSU, Raleigh, NC 27695 |
+------------------------------------------------------------------+
         Lighten UP!  It's just a computer doing that to you.
OOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO
         
Xref: sparky comp.lang.pascal:5650 comp.os.msdos.misc:5378
From: exuptr@exu.ericsson.se (Patrick Taylor)
Newsgroups: comp.lang.pascal,comp.os.msdos.misc
Subject: Re: Zen 1.0
Date: 25 Sep 92 16:24:38 GMT
Organization: Ericsson Network Systems, Inc.
X-Disclaimer: This article was posted by a user at Ericsson in North America.
              The opinions expressed are strictly those of the user and
              not necessarily those of Ericsson.

In article <3722@hpwala.wal.hp.com> toml@hpwala.wal.hp.com (Tom Luteran) writes:
>From: toml@hpwala.wal.hp.com (Tom Luteran)
>Subject: Re: Zen 1.0
>Date: 23 Sep 92 13:13:00 GMT


>  From the Author:

>    _Zen and the Art of the Internet_

>    Brendan P. Kehoe

>    ISBN 0-13-010778-6

>    Prentice Hall, c. 1993 (yes, that's what it says!)

I wonder if that means that it is legal to rip it off until January ;-)

>  Tom
 ----------------------------------------------------------------------------
    "This must be Thursday.  I never could get the hang of Thursdays"
                                                       - Douglas Adams
  - Patrick Taylor                                       (Arthur Dent)
    Ericsson Network Systems
    exuptr@exu.ericsson.se                       "Don't let the .se fool you"
    or exuptr@ZGNews.Lonestar.Org, exu.exuptr@memo.ericsson.se
From: gt7803b@prism.gatech.EDU (Raving Mad Lunatic)
Newsgroups: comp.lang.pascal
Subject: Re: Turbo Pascal 7.0
Date: 29 Sep 92 20:28:07 GMT
Organization: Georgia Institute of Technology

>>IF YOU DON'T LIKE THE TURBO PASCAL VERSION x.x IDE,  WHY NOT USE A MORE
>>FLEXABLE (AND FREE) EDITOR LIKE MicroEMACS.
MicroEMACS? Eeeeeewwwww! Use QEdit!
A
>>* a procedure/function multi-tasking device
>Use Windows.
Windows is the only trojan horse you have to pay for. Use OS/2 2.0
It multi-tasks DOS programs much more effectively.
-- 
A bird in hand is easily crushed lifeless.
Newsgroups: comp.lang.pascal
From: dmurdoch@mast.queensu.ca (Duncan Murdoch)
Subject: Re: Turbo Pascal 7.0
Organization: Queen's University
Date: Fri, 2 Oct 1992 17:37:59 GMT

In article <1992Oct1.193910.17226@news.clarkson.edu> kooijman@sun.soe.clarkson.edu (Harry Kooijman,Peyt314a,3808) writes:
>> 
>> What does "*" mean in A*B, where A and B are matrices?  I'd like it to
>> mean matrix multiply.  In APL (where it's a cross, not a 
>> star) and S it means element by element multiply.  Who is right?
>> 
>Who's right depends on the way YOU want to use it. Define it anyway 
>YOU want, operator overloading does not fix which way you can use it!

The problem is that I want to use other people's libraries, I don't want to 
write all of my programs from scratch.  If two libraries overload * in 
different ways, it would be a nightmare to use both of them.  If they both 
define a "MMul" function that multiplies matrices in different ways, at least
"MMul" probably isn't used for multiplying integers, or reals, or complex 
numbers, so it would be a reasonable task to manually go through one 
library and change all MMul occurences to MMul2, or to 
define MMul2 in my program to mean Lib2.MMul.

>Another wish for TP7:
>If TP uses the same name for the constructors as for the object and for
>the destructors the same name with a ~, then it can be - just like in
>C++ - possible to automatically call the constructor at the
>declaration. Then when the declared variable goes out of scope, it calls
>its destructor automatically. That's real OOP-power!
>So many times I have vectors and matrices that are used only locally.
>I'd like to be able to declare a vector/matrix with a dimension passed
>on to a function, so that I can use it directly, and not have to worry
>about initializing and calling a destructor when I'm done. Like:

I think there is absolutely no chance that TP would adopt this convention.  
It would break too much old code.  

A reasonable alternative might be to add a declaration "auto" to a 
particular constructor, which would mean the constructor should be 
automatically called every time an object of that type came into scope.  
The same could be done for a destructor.

Another less convenient way to do this would be to allow a constructor and 
destructor to be specified in the variable's declaration.

Another thing which you can do now, is to declare your object to be a 
"typed constant".  This has lots of disadvantages though, and doesn't help 
with the destructor problem.

One rule which this would break is the long standing rule that in Pascal, a 
variable's contents are undefined until you make an assignment to it.  Is it 
worth complicating the language definition by making this statement only 
sometimes true?

Duncan Murdoch
dmurdoch@mast.queensu.ca
From: James.MacGregor@ttlg.UUCP (James MacGregor)
Sender: postmaster@ttlg.UUCP
Newsgroups: comp.lang.pascal
Subject: Bubble Sort Routine
Date: 03 Oct 92  19:27:25 mst

 > From: Dennis.Ayala@f23.n367.z1.FIDONET.ORG (Dennis Ayala)
 > Newsgroups: comp.lang.pascal
 > Subject: Bubble Sort Routine
 > Organization: FidoNet node 1:367/23 - The Wall 1,
 > Guaynabo PR
 > Date: Sun, 27 Sep 92 20:30:00 EDT

 > Hello All:

 >   If it is possible that somebody would be kind enough
 > to post a pretty good bubble sort routine I will appreciate
 > it. I kinda need one.

 > Greetings,

 > Dennis Ayala

Dennis, without intended offense, the only 'good' bubblesort is a *dead* bubblesort!  If you want a simple-to-code sorting algorithm that's ample for general use, look seriously at using a Shell or (preferably) Shell-Metzner.

Bubblesorts tend to have a processing time proportional to the *square* of the number of elements processed (IE: a 10 element list takes 100 time units, a 100 element list takes 10,000 time units!)

If you are only dealing with a very small number of elements, at least consider making the sorting an integral part of the input routine (IE: using something like an insertion sort); bubble-sorting is only useful as an example of what *not* to do!  :-)

---
 * Origin: {========[ *** Infinite Recursion *** ]========} (42:100/16)
From: tomc@siesoft.co.uk (Tom Crossland)
Newsgroups: comp.lang.pascal
Subject: Re: POW function in pascal
Date: 1 Oct 92 17:09:03 GMT
Reply-To: tomc@siesoft.co.uk
Organization: Siemens Nixdorf Information Systems Ltd.

clarke@winkle.bhpese.oz.au writes:
: I am currently working on my first pascal program and need to use a function
: that is the same as the POW function in "C".
 
: Can someone supply me with a copy of the pascal code that would do this please.

You can do this using exponents and logarithms (but not for negative powers!):

x^y=exp(y*log(x)). (log represents natural logarithm, base e)

so your pow function would be something like:

function pow(x,y: real):real
begin
	pow=exp(y*log(x));
end;
--
___ _ __   "Beep beep blip beep bibble beebeeep blip bibble beep" - Altern8
  ((_))))...  Tom Crossland, Sysop of DarcWorld IES, [+44] [0]8675 77724.
         Hi! I am a .signature virus. Copy me into your .signature to join in!
From: tannerr@CS.ORST.EDU (Ryan Tanner)
Newsgroups: comp.lang.pascal
Subject: Re: TVision - Anything I should know?
Date: 6 Oct 92 01:40:14 GMT
Reply-To: tannerr@prism.cs.orst.edu
Organization: Oregon State University, Computer Science Dept
Originator: tannerr@storm.CS.ORST.EDU

samodena@csemail.cropsci.ncsu.edu (S. A. Modena) writes:

>In article <1992Oct03.193705.7070@CS.ORST.EDU> tannerr@prism.cs.orst.edu writes:
>>jonathan@nova.next.nd.edu (Jonathan Bradshaw) writes:
>>
>>>I am about to go delving into TurboVision. I have heard of some problems
>>>with it (something about a keyboard problem with the built in keyboard
>>>reader for some key?)  Anything I should know? Patches? Utilities?

>>> Jonathan Bradshaw | jonathan@nova.decio.nd.edu -or- jbradsh2@darwin.cc.nd.edu
>>
>>First, the TV manual is messed up in my opinion.  Read chaps 1, 3, 4, and 5
>>BEFORE reading chapter 2.  THEN read chap 2 (which is a detailed set of
>>examples with minimal background information... you'll get lost for sure.)

>Oh oh!  Jeff Duntemann is going to be disappointed to hear that....'cuz I
>think he did the manual for Borland......

Nope, he only worked on part of the first chapter.  He said so in DDJ.

>>
>>Dr. Dobb's Journal did about 5 or so articles on TV starting with issure 183
>>(I think).  You may want to look them up in your local university library.
>>It has some good stuff on how to make new classes streamable.

>To get more specific, these articles were under a regular column called:
>"Structured Programming"  by...by Jeff Duntemann.  :^)

Yea, shoulda mentioned the name of the author and his column.  Thanks.

>But, fortunately, they are not a rehash of the book...(eh) manuals, manuals.
>The articles aren't bad at all.

>>
>>Ryan (tannerr@prism.cs.orst.edu)

>Steve
>---
>+------------------------------------------------------------------+
>|     In person:  Steve Modena     AB4EL                           |
>|     On phone:   (919) 515-5328                                   |
>|     At e-mail:  nmodena@unity.ncsu.edu                           | 
>|                 samodena@csemail.cropsci.ncsu.edu                |
>|                 [ either email address is read each day ]        |
>|     By snail:   Crop Sci Dept, Box 7620, NCSU, Raleigh, NC 27695 |
>+------------------------------------------------------------------+
>         Lighten UP!  It's just a computer doing that to you.
>OOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO
>         
-- 
-------------------------------------------------------------------------------
Ryan Tanner (tannerr@prism.cs.orst.edu)        Highlander III quote:
                                                   "There can be only FIVE!"
Disclaimer:  I don't even know the person!
From: bobb@vice.ICO.TEK.COM (Robert Beauchaine)
Newsgroups: comp.lang.pascal
Subject: Re: Turbo Pascal 7.0
Date: 28 Sep 92 19:24:30 GMT
Organization: Tektronix, Inc., Beaverton,  OR.

In article <dmurdoch.184.717449468@mast.queensu.ca> dmurdoch@mast.queensu.ca (Duncan Murdoch) writes:
>
>I won't change the reply I had last year to this same suggestion:  it would 
>be better to add type Complex as a basic supported type in TP.  Once you go 
>beyond complex numbers, there are very few applications where the meaning 
>of the arithmetic operators is clear.  
>

  I disagree.  The arithmetic operators are well enough defined to
  be usefule in the areas of vector and matrix operations, polar and 
  complex numbers, and boolean algebra.  Other areas that, while not
  so formally defined, would benefit from operators would be data
  structures (doesn't "+" and "-" make sense for a binary tree or a
  linked list?).  And wouldn't it be nice if you could add or
  subtract elements from a TCollection using "+" and "-" ?

  Even Wirth and the early Pascal extenders had an inkling of this when 
  they provided overloading of a subset of the mathematic operators
  for strings and sets.

/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ 

Bob Beauchaine bobb@vice.ICO.TEK.COM 

C: The language that combines the power of assembly language with the 
   flexibility of assembly language.

Real friends don't let friends use UNIX.
From: exuhag@exu.ericsson.se (James Hague)
Newsgroups: comp.lang.pascal
Subject: Re: Turbo Pascal 7.0 wishlist (LONG)
Date: 28 Sep 92 15:30:37 GMT
Reply-To: exuhag@exu.ericsson.se
Organization: Ericsson Network Systems, Richardson, TX
X-Disclaimer: This article was posted by a user at Ericsson in North America.
              The opinions expressed are strictly those of the user and
              not necessarily those of Ericsson.

Tom Swingle writes:
>
>4.  The ability to invoke procedures taking structured types as parameters
>with constant values.  For example, if you had a procedure declared like
>"procedure PlotPixel(P:Pixel; Color:Integer);" and type Pixel were 
>declared as a record with fields X and Y (Integers), this procedure could
>be invoked as: "PlotPixel((5,10),Red)" or something similar, maybe even
>requiring a type name be present as in "PlotPixel(Pixel(5,10),Red)" so
>that you can be sure that the user knows what type he/she is referring to.

As with any "simple" addition to a language, it brings up a lot of
little questions.  I agree that you'd need type information, as shown
in your latter example.  But now it looks like a type cast or
possibly a function call.  And it is a weird exception that
only constants can be used in such statements (if you don't just allow
constants then things will get really messy).

I know, it is up to the programmer to not do stupid things and to
write code in a clear manner.  But (1) lots of people will *not* do
this and I'll end up having to maintain their code, and (2) it is
*much* more important to have a solid and predictable set of tools
which handle most basic functions cleanly than to mire the whole
thing in complexity just to handle some special cases.

--
James Hague   
exuhag@exu.ericsson.se
Newsgroups: comp.lang.pascal,rec.games.programmer