From mboxrd@z Thu Jan  1 00:00:00 1970
Message-ID: <64e675acc95909312f93f9add34b3101@hamnavoe.com>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] MS Research reinvents Inferno?
From: Richard Miller <9fans@hamnavoe.com>
Date: Wed, 14 Dec 2005 09:42:14 +0000
In-Reply-To: <1eb2d00e94bb00e11002737277a44f77@quintile.net>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Topicbox-Message-UUID: c55a0ed0-ead0-11e9-9d60-3106f5b1d025

>> i thought that was potentially interesting (and there were other things), but i was
>> also fairly sure i'd seen that done for (a variant of) occam-2
> 
> I thought I was taught occam channels where always typed
> and the message types where fixed - though this was quite a while ago.

Occam 2 channel typing was extended with what was called 'protocols',
but the term was a bit misleading.  It was just a way of declaring the
channel to pass a complex type (e.g. a counted array, or a discriminated
union - what limbo calls an adt with a pick clause).   The compiler
checks the correctness of every individual send/receive (e.g. that the
right number of elements are communicated for a counted array - no
buffer overflows! - and that all cases of a discriminated union are handled).
But there's no checking of the sequencing of communications (e.g. you
can't specify that SYN in one direction is followed by ACK in the other).

> I was sad Transputers & occam missed.

In fact there are huge numbers of transputers today hidden inside
consumer devices, programmed presumably in occam because that's
essentially their machine language - they just aren't identified as such.

-- Richard