[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

occam wish list

In message <32AE8012.164B@xxxxxxxxxx> Richard Beton wrote:

 > ...  Stuff gently rebutting non-pc-ness of <whisper> 'o','c','c','a','m'

I seem to remember that an obscure language called 'C' spent time in the
wilderness too.

 > Well that's more than two-pen'orth for now.
 > Rick
 > PS To recap., here are some musings from earlier in the year, with some
 > new ones:

These are interesting, in the current climate, with the T9000 long time
a-dying and KRoC forging ahead. We can't complacently blame *everything* on
the fact that occam historically only worked on transputers.

  --{{{  aside
  I use it for robotics, and in the lower-level distributed control
  stuff it has saved my life times without number, but when I get to
  the stage of building a sufficiently flexible task sequencer I find
  it hard to avoid lapseing into C. Incidentally, in what I do I never
  felt a need for the T9000; I learned C *after* occam (assemblers &
  forth before) and it always struck me as too coarse-grained; I, too,
  lusted after a 16-pin DIP T225 "TRAMchip".

Here are some comments on Rick's list. They're just based on experience as
I've no comp.sci background except what I've picked up (My degree was in
Aero-eng) but I'd like to hear other people's opinions on what would actually
get used, and what not, if it was implemented. I'm not applying the razor here,
(though it's always in the back of my mind, I promise) just pragmatically
trying to prioritize things...

 >         IDEA                :        EFFORT              USEFUL
 >         ----                -        ------              ------
 >  ENUMERATED TYPES           :         low                 yes

Surely these are an irreproachably *good thing* (in the 1066 & all
that sense) ?

 >  DISCRETE RANGED TYPES      :         high                yes
 >  OPERATOR OVERLOADING       :         low                 yes
 >  CONVERSION OPERATORS       :         low                 yes

I personally don't need any of these (I think)

 >  BASIC DYNAMIC MEMORY       :       moderate              yes
 >  FULLY DYNAMIC MEMORY       :         high              probably

see fold marked "#####" below.

 >  POLYMORPHISM               :         dunno              maybe

I've always considered variant protocols and case inputs to be the 'methods'
of a process 'object'. If you mean polymorphism in this context, is this not
an aspect of the old argument for nested protocols? presumably you would want
to interface to a child using something like this, to get inheritance, but
how would you override? Have I got the wrong end of the stick here?:

        child.int; INT
        child.byte; BYTE

 >  TYPED ARRAY INDICES        :       moderate              yes
 >  BIT PRIMITIVE TYPE         :       moderate             dunno
 >  MAS CONSTRUCTIONS          :         high               dunno

I can live without them, but the people who want to port KRoC to PIC micros
will no doubt vote for the bit types...

 >  INITIALISED DECLARATIONS   :       moderate              yes

Useful, because they collect together two of the components of the state
machine, or unfortunately more frequently multiple merged, yet only minimally
interacting state machines in the construct:

          ...  globals
            ...  initialise
            WHILE alive
                ...  nightmare boolean flag sphagetti

(In my experience once you've grasped occam the above is gotcha #1)

 >  RESULT DECLARATIONS        :       moderate             dunno

I don't understand this.

 >  UNION TYPES                :         high              probably

I don't miss these at all.

 >  RECORDS OF CHANNELS        :         high               dunno
 >  CALL CHANNELS              :         high                yes
 >  SHARED CALL CHANNELS       :         high                yes

Yes please, but I agree with that triply reinforced "high", so I'm not
holding my breath...

 >  MODULES                    :       v. high              dunno
 >  LIBRARIES                  :         high                yes


 >  DOTS --> UNDERSCORES,      :       moderate      (only for politics)
 >  RECORD SELECTORS --> DOTS                             > 
 >  INDENTATION --> {}         :       moderate      (only for politics)
 >  U.SCORES IN IDENTIFIERS    :         low               probably

If you like...

 >  SEMAPHORES                 :       v. low                no

This is what compilers are for, please hide them!

 >  SHARED CHANNELS            :         low                 yes

Yes please! <pretty please, grovel, scrape> but I have no opinoin on who
should know they're shared (client or server, see RESOURCE debate on this
reflector). I'd be very interested to be told why either is best...

 >  BARRIER SYNCS              :       moderate            probably

Please explain why these are needeed, execpt for implementing...

 >  BUCKETS                    :       moderate             dunno

... which I can see the need for in the context of DES, John.

 >               Richard Beton BSc MInstP CPhys
 >       Roke Manor Research, Romsey, Hampshire SO51 0ZN
 > -------  Standard disclaimer about my own views etc  -------
 >            See http://www1.roke.co.uk/WHR/WHR.html

--{{{  ##### dynamic memory

OK, dynamic memory. I don't need recursion since I can always un-roll it.
That said, and even though I'm used to operating with just IRAM and a ROM
on a T2 I would like to do lists, trees, graphs &c. when I have to and I'll
accept responsibility for ensuring that I don't choke any heap I'm given.
I don't want pointer variables but a 'const <type> *' ( VAL DYNAMIC <TYPE> ?)
would be nice. I promise to be sparing with them.

It seems to me that, if we want dynamic memory:

0) An extension of the abreviation mechanism is the way to implement it,
   and with pointers solely controlled by the compiler run-time bounds
   checking of indexed array accesses confers the necessary safety,
   RETYPES notwithstanding. Run-time slices should be permitted but
   range checking code should be planted automaticaly.

1) Given this, it might be useful to implement a minimum allocation parameter
   of the form:

   ALLOCATE [A,B]<type> <name>:
   SEQ i = 0 FOR SIZE <name>
     ...  initialise <name>[i]

   which would be equivalent to:

   ALLOCATE [B]<type> <name>:
         SIZE <name> < A
           SEQ i = 0 FOR SIZE <name>
           ...   initialise <name>[i]

2) Within the scope of the allocating process a dynamic name can be passed as
   a VAL parameter; once it's scope ends it is eligable for garbage collection
   if it's reference count reaches zero. whether this happens immediately
   should be implementation dependent, but subject to control with a #PRAGMA
   so folk can implement lo-pri heap "tidying" if they wish.

3) Given that all pointers are 'const' (ie: VAL Aptr IS Bptr:, with no
   arithmetic allowed) compiler-generated reference counting is also
   implementable and safe.

What say you? (shoot me down in flames by all means, but suggest an
alternative if you can as I feel this is a big sticking point for
acceptance, certainly bigger than the lack of recursion.)



Mark Ian Barlow                Non-Linear Control Consultants Ltd.
Mark@xxxxxxxxxxxxxxxx            Voice / Fax: +44 (0)1207 562 154