XC strong typing?

[Folknology]

XC is a strongly typed language which aims to provide safety particularly with concurrency, it is much tighter than C in this regard with its references rather than pointers and bounds checked arrays etc.

It is also a CSP inspired language as far as I can tell, this helps it get the benefit from and event driven hardware model underneath. In addition we see much safer communication methods encouraging the use of channels rather than shared arrays or storage.

However it is when one starts getting serious about using channels it starts to become confusing. here in the centre of a strongly typed language we have channels that have no type safety or type checking whatsoever? This is odd because in a distributed concurrent software model (like CSP) the only interface that one can design spanning threads and cores is channel based. So when one comes to design modules that can operate across threads/cores etc.. one is forced to drop down into a non typed approach. I am not saying using non typed or dynamic typing is good or bad (I have experience in both), rather I find it strange dropping to unchecked dynamic typing in a strongly typed language. Obviously in strongly type languages one leans heavily on the compiler in ways which you wouldn't in dynamically type languages, yet here within XC were are being expected to do dynamic typing within a strongly typed environment.

So my questions are:
1) Obviously there is a good historical reason why this is the case, I can't figure it, but would love someone to explain it to me, after all I'm still a relative newbie..
2) Secondly given this odd mix there is likely some good safe design patterns to help avoid the potential issues likely to arise with this heady mix, I would love for someone to give me some ideas of these patterns.
3) And thirdly is the situation likely to change, will strong typing for channels be added to XC in the near future. If so what form will it take? will it be like prototypes found in Occam or some other novel approach?

regards
Al

[Berni]

it could be that such a check on each channel operation would slow down things too much. The behavior caused by mismatched types on channels can seam really confusing tho as all of a sudden the code locks up for no reason it seams.(I know i was banging by head once why the code keeps locking up, not knowing this before)
They could meaby get the debugger to pop up "Hey your types are wrong" when you do it. So it clearly alerts that you messed up the types on a channel.

This channel stuff should be made a little bit more fool prof as its completely new to everyone starting with xmos.

Id also find it very useful if the server and client thing with channels could be done with the background. Like when you want to turn on a LED from a other core you need to set up a server and use a channel to connect it to the client on another thread from where you call the command to toggle the LED. Im sure this could somehow be done in the background so you can simply call led(1);

[dave]

What can I say?

I invented the channel protocols in occam - because of the issues you have raised.

But there were some issues. The protocols look like data-types - but there are some
differences. For example, the protocols include items where the length is defined
at run-time by the sender - so it's not possible for the input process to define a
data-type that can store everything received from the channel.

Variant protocols - very useful in defining the interface to processes used in
system components - have a similar problem.

For XC, my plan was to do the checks dynamically. The key check was to be
structure equivalence. This means that the checks also work for software
components loaded and communicated at runtime.

The architecture has a lot of control tokens - easily sent and checked - to
do all of this. But we're not using them yet!

It may be that we should do the occam-style protocols anyway - they do cover
a lot of the common cases - and catch a lot of programming errors.

Anyway, I am now working on this. My thinking is that we should be building
software components that are connected to their environment only through
channels/ports. It's going to be essential to check that the protocols on
the channels are correctly followed.

[Folknology]

Thanks for the quick response David

But there were some issues. The protocols look like data-types - but there are some
differences. For example, the protocols include items where the length is defined
at run-time by the sender - so it's not possible for the input process to define a
data-type that can store everything received from the channel.

I would like to understand these cases better do you have some good examples

Variant protocols - very useful in defining the interface to processes used in
system components - have a similar problem.

Having defined interfaces can be very useful for reusable modules and libraries, being able to specify service interfaces is particularly helpful. Would it be possible to have default typed (safe) channels and specific non-typed channels for expert usage or may dynamic typing. I'm not sure if that makes it easier for the compiler or not. You obviously understand what's underneath and I don't have that visibility , I would love to understand more of it.

It may be that we should do the Occam-style protocols anyway - they do cover
a lot of the common cases - and catch a lot of programming errors.

I think it would be useful, also have you seen this thread on the OSIG group we have been discussing the syntax of such things as protocols. I would love your thoughts on them particularly with making them more "C" like than Occam like..

Anyway, I am now working on this. My thinking is that we should be building
software components that are connected to their environment only through
channels/ports. It's going to be essential to check that the protocols on
the channels are correctly followed.

Agreed 100% and as soon as is humanly possible, thus if there is anything the community can do to help just ask..

regards
Al