HALLAM@physics.oxford.ac.uk ("Phillip M. Hallam-Baker") (05/16/91)
Luiz Felipe Perrone's problem with CHAN OF ANY would appear to be due to the fact that internal and external channels are handled differently. (yes yes yes i know it's the same instruction blah blah blah....) Data sent on external chanels is reduced to a bit stream. The atomic unit is the byte. Data sent on internal channels is moved using a block move the atomic unit is a label. Thus CHAN OF ANY fred PAR fred ! 1 ; 2 [2]INT array : fred ? array will only work when fred is placed on an exernal channel. This is not an error in the occam implementation. CHAN OF ANY is there for cases where there is a need to "play dirty" However Luiz's original problem was entirely reasonable. Occam just dosen't handle records and in the real world records are what the punters need. I know you can fiddle arround with aliases IS RETYPES etc but this is messy. There are also performance implications - the code produced by the D605 toolkit is quite wierd, and does not perform a large number of obvious optimisations. It would be nice to have a stripped down version of occam with a more usable typing mechanism which would handle records. This should be integrated to the channel PROTOCOL declarations. Phill Hallam-Baker
andy@research.canon.oz.au (Andy Newman) (05/18/91)
In article <29382.9105161115@prg.oxford.ac.uk> HALLAM@physics.oxford.ac.uk ("Phillip M. Hallam-Baker") writes: >It would be nice to have a stripped down version of occam with a more >usable typing mechanism which would handle records. This should be integrated >to the channel PROTOCOL declarations. I don't think that it should be necessarially "stripped-down". What would you want to remove? Adding user defined types (definitely structures, enumerations would be nice and sub-ranges would help compile time checking) to occam would take it out of the 1950's. Of course user-defined types should be allowed in PROTOCOL's, just as the primitive types are allowed. The hardest problems with structures is defining the syntax of field selection (the '.' has been stolen, rats) and handling variants (if full Pascal-like structuring is wanted). Enumerations and sub-ranges would seem to be excellent candidates for occam due to the extra compile time checking they can provide. In a large occam project I was involved in (10 people, 200K+ lines of code) one of the greatest problems was mixing up parameters to procedures. The occam compiler can't catch this as they're all INT (or something) and doesn't know the intent of the programmer. Even a method of defining new names for types and some checking of type usage would stop this. Just what is happening to occam? I met David May several years ago and he discussed some of the features he wanted to incorporate in occam-3 (modules, user defined types, etc...), is there any information available on this? On another track has anyone thought about Concurrent-C (the Bell Labs one not the occam'ised C's you can get) on Transputers? -- Andy Newman (andy@research.canon.oz.au) Canon Info. Systems Research Australia