HDTenEightyP/NetNews huggingface dataset:
From: hrubin@pop.stat.purdue.edu (Herman Rubin)
Subject: Re: languages which allow the introduction of new operators
Organization: Purdue University Statistics Department
Date: Thu, 12 Nov 1992 20:00:45 GMT

In article <KERS.92Nov12085629@cdollin.hpl.hp.com> kers@hplb.hpl.hp.com (Chris Dollin) writes:
>In article ... veit@du9ds3.uni-duisburg.de (Holger Veit) writes:

			......................

>But Herman might not think of those things as ``operators''. Consider the Pop11
>definition:

>    define 5 ++( x, y ); lvars x, y; x + y + 1 enddefine;

>The ``5'' is the precedence (it happens to be the same as ``+'') and makes
>``++'' a (nominally infix) operator, so expressions such as

>    x ++ y, f(x) ++ g(h(y), z)

>work. But (in Pop) an operator is *just* a procedure with a pleasant calling
>syntax; writing ``x ++ y'' just means ``push x, push y, call ++'' (Pop is an
>open-stack language), ``x * y'' means ``push x, push y, call -'', and ``f(x)''
>means ``push x, call f''. *Some* procedure calls are coded in-line, but this is
>not a property of being (syntactically) operators; it is a property of being a
>particular procedure, such as fast_front, or fi_+.

If you could write 

define	(x ++ y) x+y+1

I would accept that as the insertion of the ++ operator.  I would definitely
allow far more complicated versions, as defining the power operator differently
depending on the types of the arguments.  But I would object to any language
which insists that we use a strictly stack machine.  Pushing, popping, and
calling are to be avoided unless necessary.  Otherwise things just run too
slowly to be of more than theoretical use.

But there are operators I would not want to consider defining in terms of the
usual language primitives, because they essentially cannot be sensibly done 
that way.  SOME of these may get into libraries where the user cannot use
them himself, like add with carry, or simultaneous results of an operation.
One should strive for semiportability, but not full portability, and in many
cases the use of them would be portable, but the code would be machine.

Getting any speed out of machines requires that we think of speed in coding,
rather than the fact that it is possible in principle to operate with a 
stack machine with no registers.  This also ignores hardware, such as vector
machines, where the use of a control register or control stream introduces
basic bit operations which did not exist before, and which are utterly stupid
as a means of efficient computation on a stack machine.
-- 
Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907-1399
Phone: (317)494-6054
hrubin@snap.stat.purdue.edu (Internet, bitnet)  
{purdue,pur-ee}!snap.stat!hrubin(UUCP)
Newsgroups: comp.lang.misc
From: howesb@monashee.sfu.ca (Charles Howes)
Subject: List of languages - 10,000 did you say?
Organization: Simon Fraser University, Burnaby, B.C., Canada
Date: Mon, 9 Nov 1992 21:06:55 GMT

A friend told me there are at least 10,000 computer languages in existance.
He said he got this number from this newsgroup, and that I should look here
for the full list.

Well, I've taken the time to read most of the articles that were still at
our site, and I couldn't find a FAQ or the list in question.

If you have a copy, could you forward it to me?

Thank you.

Charles Howes -- howesb@sfu.ca
Newsgroups: comp.lang.misc
From: hrubin@pop.stat.purdue.edu (Herman Rubin)
Subject: Re: Pointers
Organization: Purdue University Statistics Department
Date: Tue, 10 Nov 1992 20:17:54 GMT

In article <92Nov10.125426est.47525@neat.cs.toronto.edu> tlai@cs.toronto.edu (Tony Wen Hsun Lai) writes:
>In article <1992Nov10.024021.8724@linus.mitre.org> crawford@boole.mitre.org (Randy Crawford) writes:
>[stuff deleted]
>>Remember too, that when C was born in 1969, most programmers were still 
>>fighting with 300 baud modems, paper tape, and columnar punch cards.  A terse 
>>powerful programming language like C, with user-defined types, dynamic memory 
>>and free-form syntax was a huge step forward.  In a lot of ways, more modern 
>>languages are still trying to catch up.  It was 1992 before Ada 9X offered us 
>>pointers to functions.  But two decades ago they were available in C.

>ALGOL 68 and SIMULA 67 have user-defined types, dynamic memory, and
>free-form syntax, no?  And why do you need explicit pointers to functions
>when you can have procedure types, like Modula-2?

You need explicit pointers to functions when the caller does not know
the name of the function being called, but the caller has received a
pointer to the function.  The same holds for pointers to arrays of
pointers, and to array descriptors.  If several parts of a program
are using the same double buffer, and are even compiled separately,
using a pointer to the active buffer, and another one to the refill
buffer, would be an excellent way to do things.

-- 
Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907-1399
Phone: (317)494-6054
hrubin@snap.stat.purdue.edu (Internet, bitnet)  
{purdue,pur-ee}!snap.stat!hrubin(UUCP)
Newsgroups: comp.lang.misc
From: torh@syma.sussex.ac.uk (Tor Houghton)
Subject: POPLOG for IBM compatibles?
Organization: University of Sussex
X-Newsreader: Tin 1.1 PL4
Date: Mon, 9 Nov 1992 16:17:46 GMT

Does Standard ML or PML (part of the POPLOG suite) exist for the IBM & 
compatibles?

Please reply through mail to: patrickt@cogs.susx.ac.uk

Cheers,

Tor
-- 

----------------------------------------------------------------------
email: torh@cogs.susx.ac.uk           "Then we will wonder if machines
                                       will steal each others dreams."
Newsgroups: comp.lang.misc
From: lsc1047@dlscg3.dlsc.dla.mil (Daniel Helmer)
Newsgroups: comp.lang.misc
Subject: HELP: key trapping in gwbasic
Date: 4 Nov 92 20:06:53 GMT
Organization: Defense Logistics Service Center, Battle Creek, MI

Does anybody know how to trap the CRTL and BREAK keys in GWBASIC?

If you do please pass it on to me.


	Thanks,



----------------------------------------------------------------------------
Daniel Jay Helmer DLSC-EIE        | E-mail: lsc1047@dlscg3.dlsc.dla.mil
Defense Logistics Services Center |
74 North Washington Avenue        |
Battle Creek, MI 49017-3084       |
Newsgroups: comp.lang.misc
From: barmar@think.com (Barry Margolin)
Newsgroups: comp.lang.misc
Subject: Re: Pointers
Date: 5 Nov 1992 18:58:16 GMT
Organization: Thinking Machines Corporation, Cambridge MA, USA
NNTP-Posting-Host: telecaster.think.com

In article <1992Nov5.014143.15635@newshost.lanl.gov> jlg@cochiti.lanl.gov (J. Giles) writes:
>   Second: in both, you should avoid aliasing.  In the case of GO TO,
>   you should avoid branching to the same label for many disparate
>   reasons.  In the case of pointers, you should try to avoid have
>   two pointers to the same thing *at all*.

That's a silly guideline.  The most common reason to use pointers is
precisely *because* you need multiple references to the same data.  In
object-based programming, an object may be in different relationships with
other objects, and relationships are usually implemented as pointers
between objects.  For instance, in a family tree model, a person might have
pointers to its parents, children, and siblings; any particular person is
likely to be referenced by the children array of two parents and a parent
pointer of some children.

Your guideline suggests that the main reason for using pointers is to avoid
copying data (e.g. passing arguments by reference by passing a pointer).
While pointers are certainly useful for this (in languages that don't
provide better mechanisms, such as C++'s references), I hardly consider it
the raison d'etre of pointers.

In another article, someone pointed out that the most spaghetti structured
code tends to be Lisp, which doesn't have pointers.  While it's true that
Lisp doesn't have distinct pointer values, in some sense every value is
conceptually a pointer value, because of Lisp's object-based nature (most
Lisp dialects allow optimizations for numeric values that that allow them
to be treated as non-objects, though).  The only difference between Lisp
and other languages in this regard is that Lisp doesn't have an explicit
dereference operator, as dereferencing happens automatically.  The Lisp
expression (car a) is analogous to the C expression (cons *)a->car.
-- 
Barry Margolin
System Manager, Thinking Machines Corp.

barmar@think.com          {uunet,harvard}!think!barmar
Newsgroups: comp.lang.misc
From: throopw@sheol.UUCP (Wayne Throop)
Newsgroups: comp.lang.misc
Subject: Re: languages which allow the introduction of new operators
Date: 13 Nov 92 01:08:22 GMT

: From: wb@arb-phys.uni-dortmund.de (Wilhelm B. Kloke)
: Message-ID: <1992Nov12.082643.8415@arb-phys.uni-dortmund.de>
::: Lisp.  Forth.  Postscript.  Smalltalk. 
:: You forgot Prolog.
: Add Ada, Algol68, TeX as well.

Hmmmm?  I knew that Ada, C++, and others had the ability to coin new
meanings for *existing* operators, but (other than functional notation)
I thought they could not introduce completely *new* operators.  That is,
the parse and expression syntax is constant.
Was I wrong?

( As I said, it seems to depend to a certain extent what one allows
  as an "operator" (and the meaning of "new" also... ) )
--
Wayne Throop  ...!mcnc!dg-rtp!sheol!throopw
Newsgroups: comp.lang.misc
From: anw@maths.nott.ac.uk (Dr A. N. Walker)
Subject: Re: Pointers
Reply-To: anw@maths.nott.ac.uk (Dr A. N. Walker)
Organization: Maths Dept., Nott'm Univ., UK.
Date: Thu, 5 Nov 1992 15:34:59 GMT

In article <1992Nov4.031026.23624@linus.mitre.org>
crawford@boole.mitre.org (Randy Crawford) writes:
>The nice thing about C's low level programming support is that you
>don't have to tolerate the imposition and girth of a garbage collector
>(something that belongs in a library anyway).  If you really want one,
>once again, C will let you roll your own.

	No it won't.  There is no way [provided by C -- an individual
compiler or system may add one, of course] of finding out whether some
object is being pointed at, so there is no way of determining which
objects are "dead".  There is no way of "compacting" live storage, and
shifting all pointers to correspond.  For specific applications, you can
rig up versions of "malloc" and "free" to do this, but not in general.

	In languages that *do* provide proper garbage collection, it
is usually included only if your program includes constructs that
might cause it to be invoked -- in C terms, it might be a library
procedure that was called by "malloc" -- which gets round your objection
to its "imposition and girth" [whatever that means!].

>If you want run-time error checking, then C is the wrong choice of
>programming language for a lot of better reasons than array bounds
>checking.

	Why?  I quite like C, and it wouldn't make it any worse as a
language if there was at least a compiler option [as indeed there is
for *some* compilers] for array bound checking, pointer validity
checking, etc.

-- 
Andy Walker, Maths Dept., Nott'm Univ., UK.
anw@maths.nott.ac.uk
Newsgroups: comp.lang.misc
From: ian@syacus.acus.oz.au (Ian Joyner)
Subject: Re: Pointers
Organization: ACUS Australian Centre for Unisys Software, Sydney
Date: Mon, 9 Nov 1992 12:13:17 GMT

hrubin@pop.stat.purdue.edu (Herman Rubin) writes:

>Computer hardware quite properly uses pointers, and any software that
>does not is just making life difficult for the users.

Firstly, computer hardware does not necessarily use pointers.

Secondly, where different architectures do use pointers, the definition
of them can be quite different. As I have already said, Unisys A Series
have quite a different kind of pointer to that which C likes. In fact
the hardware defines a higher level more problem oriented kind of pointer
than C.

Thirdly, if you want direct access to hardware capabilities, then you may
as well use assembler. The disadvantages should be well known. Such languages
are solutions or 'how' oriented, not problem and 'what' oriented. This means
that you are not implementation independent, which makes portability difficult.
This also makes maintainability difficult. This style of programming locks
you into certain ways of doing things, instead of giving you the freedom
that higher level languages give you.

Customers are becoming more sophisticated, and do not like to be locked
into closed systems (proprietary systems are not necessarily closed), or
into Unix for that matter. 

-- 
Ian Joyner  ACUS (Australian Centre for Unisys Software)    ian@syacus.acus.oz
"Where is the man with all the great directions?...You can't imagine it,
 how hard it is to grow, Can you imagine the order of the universe?" ABWH
Disclaimer:Opinions and comments are personal.
Newsgroups: comp.lang.icon
Date: Mon, 9 Nov 1992 15:02:35 MST
From: "Kenneth Walker" <kwalker@cs.arizona.edu>
Subject: Re: file scanning

> Date: 5 Nov 92 04:55:57 GMT
>
> Ken, Ralph, Clint, etc.:  How hard would it really be to implement
> file scanning?

Kelvin Nilsen's Conicon has a stream data type the subsumes files and
supports a type of scanning. His scanning doesn't have tab() and move()
instead it has probe() and advance() which aslo replace read(). While
you can backtrack during scanning, I think there are limitations on
explicitly scanning backwards. He allows for infinite streams along the
lines of Unix pipes. I know he does some careful buffering to make
things work.

For files that support seek(), it should be possible to do scanning
with buffering as you suggested. It means that every file must be
buffered within the Icon run-time system and all string analysis
functions have to be changed to work on files and extend the buffer
when needed. Note that seeking backwards in a file using translation
mode on systems that have multi-character line termination (like
MS-DOS) may be a little tricky.

There is the question of where you put the buffer. Putting it in the
string region makes some string handling operations easier; portions
of the input are normal strings. However, it may be necessary to copy
the buffer to the end of the region to extent it. How do you decide how
much to copy? Suppose you backtrack past a point where you did a read-ahead
to extend the buffer; you probably don't want to loose the read-ahead.
How do you handle that? I haven't look closely at Kelvin's work in
several years, so I don't recall how he does these things. But it doesn't
sound trivial.

  Ken Walker  kwalker@cs.arizona.edu   uunet!arizona!kwalker

Newsgroups: comp.lang.icon
Date: Thu, 12 Nov 92 18:36:19 -0500
From: isidev!nowlin@uunet.uu.net
Subject: Re rationale for sortf()

 > The sortf() function in Icon V8.7 is defined as:
 > 
 >      sortf(X,i)  Produces a sorted list of the elements of X. The
 >                  results are similar to those of sort(X,i),
 >                  except that among lists and among records,
 >                  structure values are ordered by comparing their
 >                  ith fields.
 > 
 > Can someone explain to me why the second argument to the sortf() function is
 > an integer index of the field in the record to sort on, instead of a string
 > containing the field name?

The sortf() function works on lists in addition to records.  It remains
flexible enough to do both by using an integer index.  If you specified
field names with a string you would lose the ability to sort lists of
lists.  I suppose you could overload the second argument so that integers
worked for both types of structures but a string in the context of a list
would generate a run-time error.  Not worth it.

You can define tables with field names as key and the record index as value
and just use that in place of field name arguments to sortf().  When you
change record definitions you would have to change tables values.  This
won't help with Idol unfortunately.  Maybe Idol could put extra fields at
the end of records to avoid obscuring known index values?

Jerry Nowlin


Newsgroups: comp.lang.icon
From: goer@ellis.uchicago.edu (Richard L. Goerwitz)
Subject: Re: file scanning
Reply-To: goer@midway.uchicago.edu
Organization: University of Chicago Computing Organizations
Date: Tue, 10 Nov 1992 16:10:57 GMT

Several folks questioned whether what I really wanted was file scanning.
The answer is "yes."  Icon is good for text and language processing, but
to do this everything has to go through a tokenizing stage.  Icon's string
scanning mechanism relies heavily on strings as chunks taken from files,
broken up by newlines.  Sadly, we typically can't break up a file when
tokenizing.  We have to treat it as a stream of characters.  If that stream
could be scanned, then Icon would be quite useful for all stages of text
and natural langauge processing.  Right now, it's okay, but you have to
do one of two things:  a) use it like a poor man's C, or b) try to con-
struct input so that it can be snipped off at each newline for the purposes
of tokenizing.  Ironically, Icon itself cannot be tokenized in this way.

Incidentally, I'm not the first to suggest that scanning be generalized to
files.  I recall reading this suggestion in an old Arizona tech report.

The real crux with file scanning, it would seem, is what to do when the
file in question doesn't support backwards seeks.  Also, how in Icon could
the stream be buffered in such a way as to store backtracking points? 
Actually, I'd tend to say, "Don't buffer anything other than a few chars."
After all, when tokenizing, normally nobody uses more than a few characters
of pushback, and we normally use only one lookahead character.  If people
want to seek back and forth through large files, then let them.  For things
like pipes and other non-backwards-seekable objects, I would not care par-
ticularly if there were simply an error message.

-- 

   -Richard L. Goerwitz              goer%midway@uchicago.bitnet
   goer@midway.uchicago.edu          rutgers!oddjob!ellis!goer
From: goer@ellis.uchicago.edu (Richard L. Goerwitz)
Newsgroups: comp.lang.icon
Subject: Re: Character manipulation
Date: 5 Nov 92 04:45:27 GMT
Reply-To: goer@midway.uchicago.edu
Organization: University of Chicago Computing Organizations

skagos@hercules.cs.uregina.ca (P. Takis Skagos) writes:

>>>Well ... my character manipulation problems concerned parsing out
>>>lines and performing all sorts of substitutions and stuff (pre-processing
>>>a file).
>
>>Give us some examples!
>
>I cannot give examples ... part of this is for a class assignment ...

Hint:  Look back in your news history a few weeks (if it goes back that
far).  Just recently we talked about stripping out /* C-style comments */.
It's a classic problem.
-- 

   -Richard L. Goerwitz              goer%midway@uchicago.bitnet
   goer@midway.uchicago.edu          rutgers!oddjob!ellis!goer
Newsgroups: comp.lang.icon
Date: Thu, 12 Nov 1992 22:19:21 MST
From: "President Clinton Jeffery" <cjeffery@cs.arizona.edu>
Subject: Re rationale for sortf()


   Jerry Nowlin writes:
>   You can define tables with field names as key and the record index as value
>   and just use that in place of field name arguments to sortf().  When you
>   change record definitions you would have to change tables values.  This
>   won't help with Idol unfortunately.  Maybe Idol could put extra fields at
>   the end of records to avoid obscuring known index values?

An interesting thought.  There is no reason the two "extra fields" could not
be put at the back.  But current default behavior notwithstanding, objects
are not supposed to be transparent and allow any old function to access
their internal fields; a sortf() that would be technically correct for Idol
would call a procedure (method, really) to access the key, and there are real
technical reasons why sortf() doesn't call back out to an Icon procedure (or
Idol method) in the present implementation -- none of Icon's built-in
functions do that, in fact.  Writing a built-in Icon function that calls
procedures is our user-grailquest for the week; in the meantime sorters of
lists of objects would do well to consider adapting Bob Alexander's elegant
isort procedure from the Icon program library.

Newsgroups: comp.lang.icon
From: ron@syacus.acus.oz.au (Ron Williams)
Subject: icon program examples
Organization: ACUS Australian Centre for Unisys Software, Sydney
X-Newsreader: TIN [version 1.1 PL6]
Date: Mon, 9 Nov 1992 08:14:04 GMT

I recently acquired the icon executables, and source, but apart from the
test suite, there appears to be little in the way of examples. I wonder if
I simply missed seeing what is there? Could someone please direct me to 
any source written in icon that is freely available? I desperately need
examples.

thanks in advance...

--
Ron Williams                  ACSnet : ron@syacus.acus.oz
Ph : +61 2 390-1366         Internet : ron@syacus.acus.OZ.AU
Fax: +61 2 390-1391             UUCP : uunet!munnari!syacus.acus.oz.au!ron
Standard Disclaimers Apply
Newsgroups: comp.lang.icon
From: srt@cs.arizona.edu (Scott R. Trappe)
Newsgroups: comp.lang.icon
Subject: Rationale for sortf() second argument?
Date: 6 Nov 92 04:40:10 GMT

The sortf() function in Icon V8.7 is defined as:

     sortf(X,i)  Produces a sorted list of the elements of X. The
                 results are similar to those of sort(X,i),
                 except that among lists and among records,
                 structure values are ordered by comparing their
                 ith fields.

Can someone explain to me why the second argument to the sortf() function is
an integer index of the field in the record to sort on, instead of a string
containing the field name?  As defined, this function seems to be very
dangerous, since adding, deleting, or re-ordering fields in a record could
change which field is used as the key.  The programmer must manually inspect
each use of sortf() and verify that either it is not being used on data
structures containing the affected record type, or that the field index is
unaffected by the change.

It would seem that specifying the field name as a string is far safer; it makes
it obvious which field is used as the key, makes the program insensitive to
adding or re-ordering fields in the record, and should the field be deleted,
could result in a run-time error.  It would seem to also improve program
readability, since in the typical case the field name would be a literal string
in the sortf() function.  As it stands now, one has to go find the record
declaration and count the fields to find out which field is the key.

This is even more problematical if one is using an Icon pre-processor such as
Idol that adds extra fields to the BEGINNING of the record: without knowledge
of the transformations that the preprocessor makes, it is impossible to use the
sortf() function.  Worse, changes to the pre-processor could silently break
"correct" code.

There seems to me to be precedent in Icon for supplying language identifiers
in strings; witness the proc() and args() functions.  Indeed, in the very same
report where the sortf() function is described, there is a description of a
new feature whereby field selection can be done with a string operand, for
example:

    record.["field1"]

can be used to mean:

    record.field1

Scott Trappe
Newsgroups: comp.lang.icon