[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?:
PROTOCOL IS
CASE
PROTOCOL PARENT
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
SEQ
... initialise
WHILE alive
ALT
... 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
ditto.
> 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>:
SEQ
IF
SIZE <name> < A
CAUSEERROR()
TRUE
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.)
(1)
--}}}
--
Mark Ian Barlow Non-Linear Control Consultants Ltd.
-----------------------------------------------------------------
Mark@xxxxxxxxxxxxxxxx Voice / Fax: +44 (0)1207 562 154