Tuples

[Folknology]

I am curious about and XC feature - Multiple-Return Functions

I really like the feature here is an example:

Code: Select all

{char,short,char} decode_instruction(int instruction){..}

char command,destination;
short operand;

{command,operand,destination} = decode_instruction(instruction);

I find this convenient and very readable. To me however its just a function returning a tuple. So my question is, why doesn't XC have other tuple support such as:

Code: Select all

{a, b, c} = {1,2,3}
and
function({a,b,c},x)
and
c <: {a,b,c}
c :> {a.b.c}

One other question also comes to mind why {a,b,c} instead of [a,b,c] or (a,b,c) or <a,b,c>

Just curious really

[monk_is_batman]

I am a fan of tuples in general, having used them in other languages like python before, I find them useful. However, I feel that tuples would not quite make sense to have support in xc.

From what I have seen in xc it is about being based on c and the added features are based around having good support the special and extraordinary features in xmos processors. The exception of course being passing by reference and returning multiple values (feel free to mention if I forgot any). In my opinion both of these are much needed to fill the gap left by the lack of pointers that are available in c.

Therefore I think adding more features to the language supporting things like tuples would have distracted from the language and instead of being xc be a language more distant from c.

[Folknology]

Underneath Xmos XS1 is a concurrent event driven system and is thus an ideal candidate for a CSP approach. This was similar for the Transputer decades ago. Then Occam, deriving from David's work based on Hoare's CSP was used to tame the concurrent beast underneath. Moving through the decades we see "C/C++" dominating the low level programming word, despite Occam's obvious advantage its a difficult pill for the electronics dev community to swallow given their immersion in C and C extensions like C++. Its difficult enough to sell a new idea like a Transputer or event driven concurrent multi core like Xmos XS1, thus why not extend something that is more familiar? Hence we have XC, C with extensions for event driven concurrent processing and that may well be the message that one should initially get, that makes the 'sell' easier today.

However, The truth is that the power of XC is found when one understands that it's 'a wolf in sheep's clothing' because underneath it really is CSP, it was always designed to be so because that is what is needed to provide safe concurrent event driven programming for Xmos XS1.

Lets look at XC's CSP:

Code: Select all

chan c;
par {
  network1(c);
  network2(c);
}

Already we see CSP basic ingredients fork join parallelism and channels to support communication between the concurrent processes, these are similar to Occam's PAR and CHANNEL identifiers. In Occam you also have SEQ for sequential rather than parallel but in our 'C' like XC, SEQ is implied as C is sequential by default.

Code: Select all

select
{
  case :  In when pinseq(0) :> x
    process(x);
    break;
  case c :> command :
    action(command);
    break;
}

Here we see XC's select operating on ports and channels, the very stuff of CSP and a 'C' like interpretation (syntax?) from Occams ALT or Alternate identifier.

Both of these examples provide a peek at the real power under the bonnet for XC with XS1, this isn't just compensating for missing pointers - pass by reference and returning of tuples.

In reality XC's power only comes when you approach programming in a CSP rather than a 'C' like manner, if you keep thinking in 'C' you will not conquer XS1 you will be a slave to 'C'. Now don't get me wrong I love that you can drop down to C/C++ for performance or to use existing libraries, but that approach should not be used to solve issues with the XC language. XC isn't complete although it borrows a lot from Occam's CSP, it is missing certain functionality particularly the mobile concepts added by Milner which resulted in Occam being revised several times until its current carnation Occam-Pi. Milners work pointed out shortcomings of Hoare's CSP model and Added Pi Calculus into the mix, making Occam more complete. Thus I hope we will See XCPi or PiXC the addition of mobility and the channel strengthening from Protocols are IMHO required steps for XC to become complete, so that we don't have to drop down to using C pointers or C++ objects in order to make good structured programs.

Also I am trying to make some of this appear more 'C' like for example in protocols see my comments

Also I have started to try and get some CSP channel work across, take a look and let me know your thoughts, I hope to add more time permitting

If it helps rather than thinking of them as tuples think of them as anonymous structs, then its more 'C' like ;-)

P.S. We should all let some of the wolf out from under us OWOOHH...