"John Whorfin" <_@[EMAIL PROTECTED]
> wrote in message
news:47611be8$0$9878$afc38c87@[EMAIL PROTECTED]
>> well, one idea I encountered recently was CSP, which implementing as a
>> library feature was simple enough that I did this during part of one of
>> my morning cl***** (diverting a little of my attention from the
>> lecture...).
>
> You may want to investigate occam and the entire slew of languages that
> targetted the transputer. occam embodied much of CSP and the transputer
> was an occam "engine". CSP/occam's alternates (ALT) is one thing that is
> not nicely done, IMHO, without direct syntax sup****t. Defining
structures
> or arrays to hold channels, and optional guards, at run-time is messy,
> occam's ALT is far easier to use. occam also has TIMERs and the AFTER
> construct making timed ALT constructs simple to express and "replicated
> ALT" for handling multiple input channels. Don't get me wrong. I'm
> addicted to C expression syntax and have been using it for well over 20
> years but the occam CSP-inspired concurrency features were quite nice.
>
I don't know. I implemented the whole thing as function calls.
dyt chn;
chn=chnNew();
chnPutInt(chn, 3);
i=chnGetInt(chn)+chnGetInt(chn);
....
all the passing machinery is done internal to these functions.
for syntax I had considered overloading '<<' binary, adding '<<' as a
unary,
and adding a built-in 'chan' type (would be a combining type, much as
'complex').
for the most part, all this should be fairly minor (just, I don't want to
add any new syntax right at this point, for other reasons...)..
chn<<3;
i=<<chn + <<chn;
albeit, I would like something other than '<<', not much better options
exist right now ('<-' can't be added apart from violating the C standard).
'<<' as a prefix operator looks terribly ugly IMO.
'~', though validly a unary operator (thus avoiding needing to add new
operator handling), and not cla****ng with anything useful, may not give
the
intended effect.
i=~chn + ~chn;
or such...
> Transputer C compilers invariably had extensions to take advantage of
the
> processor's features (channel I/O is directly implemented by the
> processor). One, who's name escapes me, permitted channels as lvalues
and
> rvalues allowing expressions such as "out = in1 + in2" to perform
implicit
> channel I/O. I think the explicit get/put operations are safer overall
> from a program comprehension PoV but the implicit form is kind of neat.
I had considered making it explicit.
explicit handling allows first-class handling of channels as values.
|
