Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU
Path: utzoo!watmath!clyde!burl!ulysses!ucbvax!nosc.arpa!broman%bugs
From: broman%bugs@NOSC.ARPA (Vincent Broman)
Newsgroups: net.lang.mod2
Subject: Re:  scrap INC/DEC vs Overloading
Message-ID: <8603111522.AA08818@bugs.ARPA>
Date: Tue, 11-Mar-86 10:22:10 EST
Article-I.D.: bugs.8603111522.AA08818
Posted: Tue Mar 11 10:22:10 1986
Date-Received: Fri, 14-Mar-86 03:44:18 EST
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The ARPA Internet
Lines: 26

<price $0.02>

I would like to jump in and defend most of the standard predefined functions
Rob wants external to the compiler.

ABS, ODD, FLOAT, TRUNC are computations defineable in M2, but not always well.
When my vax has cvtfl & cvtlf instructions, I don't want to muck about with a
procedure call that tries to simulate the bit-twiddling by hand. Many machines
have a single instruction for ODD, much preferable to divide-multiply-subtract
then test. ABS is borderline.

CHR, ORD could be programmed as no-op functions that just coerce and copy,
but their being implemented in the compiler means that no
computation/invocation need be generated in the object code.

CAP is probably there for portability's sake. I would like LOWER also.

INCL, EXCL, INC, DEC, (SUCC), (PRED) have distinct advantages for use with
enumerated types, as has been pointed out recently, but the first four
are fine mental time-savers, just as the C-language op= syntax is.
INC(list^.arr[nbr].otherlist^.counter) is much nicer than you-know-what.
Just make sure it checks the upper bound of the type.

vincent broman, code 632, naval ocean systems center, san diego, ca 92152, usa
phone: +1 619 225 2365    starship: 32d 42m 22s n/ 117d 14m 13s w
arpa: broman@nosc.mil     uucp: {sdcsvax,gould9,bonnie,hp-sdd}!noscvax!broman