Re. Rick's musings

[phw <P.H.Welch@xxxxxxxxx>]

Rick Beton put up a number of ideas for discussion about developing the
occam language.  At WoTUG-19, some of us thought that the language ought
to be kicked along a little, having moved forward from occam2 (1987 ?)
to occam2.1 (a small part-implementation of the occam3 proposal) in 1996.

Given that language extensions have to be implemented (we don't want
another occam3 paper language) and that INMOS are no longer around to
do this and that nobody else is funded to do this, these extensions
will have to be implemented in our lunch-times (already pretty committed
to work anyway).  So, the strategy ought to be: do things that are EASY
and USEFUL.  Call the result occam2.2.  Implement this in both KRoC and
SPoC.  Announce and release simultaenously with lots of noise.

Things that are HARD and USEFUL, leave to another day.  Start writing
proposals now to get the necessary manpower!

For completeness, things that are EASY and USELESS and things that are
HARD and USELESS, just leave.

Things that break basic occam security, label USELESS ... no matter how
temptingly `useful' they may seem.

Classifying (rather quickly) Rick's suggestions and some other ones worried
about at WoTUG-19:


       IDEA                :           EASY                 USEFUL
       ----                -           ----                 ------

DYNAMIC MEMORY             :            no               (may be dangerous?)
OPERATOR OVERLOADING       :           yes                    yes
POLYMORPHISM               :          dunno                probably
ENUMERATED TYPES           :           yes                    yes
ARRAY INDICES              :          dunno                   yes
DOTS --> UNDERSCORES       :         very easy           (only for politics)
RECORD SELECTORS --> DOTS  :         very easy           (only for politics)
INDENTATION --> {}         :        pretty easy            very dangerous

This classification is open for challenge!  Any other views + reasons?
I haven't time to justify my classification now ... except to say
something about OPERATOR OVERLOADING ...

We had reached the same conclusion as Rick regarding using operator
overloading for structures like COMPLEX32, rather than introducing
them as new primitive types.  occam2.1 does almost the whole job of
introducing such user-defined structures, giving us constructors and
field selection and their use for variables, parameters and record
fields.  The only thing missing is the infix operator (to be used instead
of a prefix function).  It would be silly not to build on this support
already in the language.

All we need do is extend the parser to cope with operator declarations,
which Rick suggests borrowing from Ada:

  COMPLEX64 FUNCTION "+" (VAL COMPLEX64 a, b)
    ...
  :

The parser would build a table for each operator, recording the operand
and result signature and the (secret occam2.1) function it would generate
as though it had been declared:

  COMPLEX64 FUNCTION unique.name (VAL COMPLEX64 a, b)
    ...
  :

where `unique.name' is generated by the parser.  If the signature already
exists for that operator, this is an error.

No change is needed in the expression parser.  The semantic checker of
expressions gets modified so that, when it finds an operator without
the standard overloadings for its parameters (e.g. REAL64 and REAL64),
it searches the user-operator table for a signature that matches its
operands.  If it finds one, it simply transforms the parse tree at that
node into the relevant `unique.name' function call with two arguments
and sets the result type for that node.  The magic of this is that no
change is now needed in the code-generator.

This would allow a library for complex arithmetic to be set up (either
accessed via #USE or, if we want to use INLINE, via #INCLUDE).  Different
versions offering different trade-offs between speed and completeness
could be made availiable (to do complex division or modulus "properly"
requires some care).  Type castings (e.g. between COMPLEX64 and COMPLEX32)
would need to be done as monadic functions ... but:

  a := COMPLEX32.ROUND (x)

doesn't seem too onerous compared to:

  a := COMPLEX32 ROUND x

which we could write if COMPLEX32/COMPLEX64 were built-in types.

Allowing user-defined infix operators between user-defined types seems
very natural.  A whole bunch of matrix arithmetic would really benefit
from this as well.

Estimated time to do this for the SGS-Thomson compiler (i.e. KRoC) is
two(ish) days ;-) ... trouble is finding the two(ish) days ...

Peter.