🚀 go-pugleaf

Well after a short conversation today I'm back on the "warpath" trying
to 'better' (slight bias to my views here :-) the language.

First: ADD OPERATOR OVERLOADING.  Despite recent well written notes on
the subject (which I basically disagree with), operator overloading
would be a great benefit to the language.  This feature would not
require run-time checking or much compiler overhead, if implemented
correctly.  Consider adding unary and binary operator overloading,
via a preprocessor step (this is to support my claim of no run-time
checking and limited compiler overhead).
Example syntax: (normal preprocessor special id symbols omitted)
TYPE  UserType = REAL;
      OtherUserType = INTEGER;

PROCEDURE EquateMyTypes(x: OtherUserType): UserType;
BEGIN
   RETURN ConvertInteger2Real(x);
END EquateMyTypes;

UNARY OPERATOR UserType ':=' OtherUserType USES EquateMyTypes;

Calls such as
  userType:= otherUserType;
would then be converted to
  userType:= EquateMyTypes(otherUserType);

Binary operators can be handled in much the same way and could encompass
precedence.
Consider:
BINARY OPERATOR Type1 '+' Type2 Type3 USES AddTypes23 PRECEDENCE 10;
BINARY OPERATOR Type1 '+' Type3 Type2 USES AddTypes32 PRECEDENCE 10;
BINARY OPERATOR Type1 '*' Type2 Type3 USES MulTypes23 PRECEDENCE 20;
BINARY OPERATOR Type1 '*' Type3 Type2 USES MulTypes32 PRECEDENCE 20;
BINARY OPERATOR Type1 '**' Type2 Type3 USES RaiseTypes23 PRECEDENCE 30;
BINARY OPERATOR Type1 '**' Type3 Type2 USES RaiseTypes32 PRECEDENCE 30;

Or Perhaps just:

BINARY OPERATOR Type1 '+' Type2 Type3 USES AddTypes PRECEDENCE 10
COMMUTES; (* hope I got that right, long time out of math :-) *)
BINARY OPERATOR Type1 '*' Type2 Type3 USES MulTypes PRECEDENCE 20
COMMUTES;
BINARY OPERATOR Type1 '**' Type2 Type3 USES RaiseTypes PRECEDENCE 30
COMMUTES;

Let a, b, c be Type1, Type2 and Type3, respectively.
Then the expression
   a:= b + c * b ** c;
would be converted to
   a:= AddTypes(b, MulTypes(c, RaiseTypes(b, c)));

I see no reason that this couldn't be written as a preprocessor,
and/or built into the language/compiler.  Readability and abuse are
valid concerns, but not sufficient to discard consideration of such
a valuable feature.  (BTW, nowhere did I say I wanted to write such
a preprocessor ;-)
-----------------------

Second: MODIFY PARAMETER PASSING FOR GENERIC PARAMETERS.
This one has to be done at the compiler level.  Basically, add at
GENERIC parameter and LIST modifier to the formal parameters.
Consider a built-in language type GENERIC defined as follows:
GENERIC = RECORD
   type: AtomicTypes; (* Set of AtomicTypes *);
   variable: BOOLEAN;
   addr: ADDRESS;
   length: CARDINAL;
   next: POINTER to AnotherGenericRecord; (* Used to decompose array and
                                             record types *)
   END;

The above would likely need some 'tweaking' for such things as pointers
and perhaps some additional info for arrays.

The LIST modifier would allow a procedure to accept an arbitrary number
of parameters (in the form of a list).

So the procedure:
PROCEDURE Test(LIST OF GENERIC);
would accept anything given it (and still retain knowledge of it's type).
Likely this feature would have to restricted in certain ways to
guarantee that all type arbitration would be performed at compile time.

Lots of room for abuse with this feature and considerable overhead
would likely be associated with it's use, but it would give
considerable power to toolmakers, prototypes and OOP folks.
-----------------------

Pet Peeve: Consistency across systems.
I wish that INTEGERs and CARDINALs were defined by default to be 32bits,
basically I'd like to see all atomic types defined at the bit level.
Further (u didn't think I would stop there did u :-), I'd like to see
the ability to 'build a variable' at the bit level.
Example
   littleCard: BITFIELD RANGE 0..15; (* 4 bits *)
   bigCard: BITFIELD BITS 96; (* 96 bits *)
   largeInt: BITFIELD BITS 64 SIGNED; (* 64 bit signed number *)
Of course arrays of these should only take up the minimum bits needed
for storage.  This type and the ability to overload operators (as
outlined above) should provide a rather rich low-level type structure.
Overhead on this one would likely be pretty bad, but could be bypassed
by staying with default types.
-----------------------

Well that should be enough to firmly establish me on racial lunatic
outer fringe.

Oh, and before it's mentioned, yes I can spell Ada <grin>.

What'a think?

Greg