tomr@DECWRL.DEC.COM (Tom Rodeheffer) (03/11/86)
Rob Nagler argues that INC and DEC don't need to be in the language, rather they should be optimized by the compiler or provided by an Assembly language module. Well, not that I particularly like INC and DEC, but they have the property that you can feed them a variable of any discrete type. Modula-2 doesn't have the facilities to allow you to declare a procedure that does the same thing. Hence you can't banish INC and DEC from the language into a standard library module without changing their meaning. Now you can say 1) Let's add features to Modula-2 to allow us to write our own procedures such as INC and DEC, then INC and DEC won't be special any more; this leads down the path toward overloading. Or you can say 2) Because we can't write procedures such as INC and DEC let's chip a wart off the language by eliminating them. Or you can say 3) Overloading looks like a real tarpit but we sure would like to be able to do INC and DEC on enumerated types, let's just stick a hack into the language and be done with it. State 3) is where we're currently at. Tom Rodeheffer P.S. By the way, does anybody have an idea why Wirth dumped SUCC and PRED when he went from Pascal to Modula? I really hate writing VAL(SomeModule.SomeType,ORD(expression)+1) instead of SUCC(expression), and it's even more disgusting to cons up a new variable in order to use INC. -Tom R
nagler%orb@SUN.ARPA (Rob Nagler) (03/11/86)
Well, not that I particularly like INC and DEC, but they have the
property that you can feed them a variable of any discrete type.
Modula-2 doesn't have the facilities to allow you to declare a
procedure that does the same thing.
DEFINITION MODULE Shorthands;
IMPORT
SYSTEM;
EXPORT QUALIFIED
INC, DEC;
PROCEDURE INC( VAR ordinal : ARRAY OF SYSTEM.BYTE );
PROCEDURE DEC( VAR ordinal : ARRAY OF SYSTEM.BYTE );
END Shorthands.
PROCEDURE INC( VAR ordinal : ARRAY OF SYSTEM.BYTE );
VAR
i : POINTER TO LONGCARD; (* longest ordinal in the machine *)
BEGIN (* INC *)
i := SYSTEM.ADR( ordinal );
(*$R-*)
i^ := i^ + 1;
(*$R=*)
END INC;
If your system doesn't have assembler modules, SYSTEM.CODE,
in-line code procedures, or C, then you'll have to use the above hack.
No type checking, how the heck are you going to pass the description
of the type to an overloaded type, without tons of baggage. Besides,
every implementation I have seen did not type check the result of
INC or DEC, because it would slow it down! Why can't compilers
be smarter?
Personally, I think this type of shorthand is not all that
useful, but I can see the need. Don't know how to add your
SUCC and PRED without coercion in the client. I personally
treat enumerated types as opaques with generator functions
and use FOR loops (I know there isn't an EXIT from a FOR loop,
but I didn't design the language, I just hack in it).
1) Let's add features to Modula-2 ...
Why not? Everyone else seems to want to. Now, if we all wanted to add the
same features, we might have something. Remember, there are two types of
language designers in the world: anarchists and facists. Take your pick
as to which one I am.
2) Because we can't write procedures...
Yep, get rid of them. Only put in things that the programmer can't write.
We can write INC, DEC, ABS, ODD, CHR, ORD, EXCL, INCL, FLOAT, TRUNC,
and CAP. Can't write HIGH, HALT, and VAL. How about LOW?!? A feature
that was left out that we can't write, but because there was so much
rubbish out there, Wirth didn't add it. How many people out there
would like LOW instead of CAP?
3) Overloading looks like a real tarpit
You said it, not me. I like languages with overloading done correctly,
e.g. SmallTalk, but I imagine that they wouldn't define it correctly
and we would be stuck half-loaded. I think we have to consider what
it would do to the size of the implementations and what other
features we would really like. For example, limited private and private
as well as opaque types, real strings with real built-in operations,
garbage collection, termination bodies as well as initialization for
modules, exceptions, ... The problem is that the machines of yesterday
can't accomodate all of these features and run in 64K. Sounds stupid,
but there a way too many 6502s, 8080s, and Z80s out there to ignore.
The problem with Ada isn't that it has too many features, it is just
that KAPSE doesn't fit in less than 32K (implemented correctly).
P.S. does anybody have an idea why Wirth dumped SUCC and PRED
when he went from Pascal to Modula?
I haven't noticed the loss. I imagine identifier pollution is the
reason. He doesn't seem to like excessive features. However, this
is one you can't implement nicely, you are correct.
Sorry to ramble, but I believe that M2 is an OK language with some
goofy features. It works and provides a much cleaner interface to
the system level stuff than C, BLISS, BCPL, or your favorite Pascal
hacks. Mesa isn't bad either, but proprietary languages are quite
difficult to popularize. My biggest concern is reusable software
and having a modular language which is fairly clean, can possibly
improve the chance of my software porting. C is my only alternative
at this point and it is far from clean and modular.
Sigh,
Robbroman%bugs@NOSC.ARPA (Vincent Broman) (03/11/86)
<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