Here's much better version:
///////////////////
// First, a simple fibre to copy from one channel to another
noinline proc copy[T] (i:ischannel[T],o:oschannel[T]) ()
{
while true do
var x = read i;
write (o,x);
done
}
// Now, here's a multiplexor.
proc mux[T] (inp:1->opt[ischannel[T]], out:oschannel[T]) ()
{
for i in inp do spawn_fthread$ copy(i,out); done
}
// This is ultra-cool!
// It uses a stream iterator so it will accept an array, list,
// or any other data structure with an iterator.
// Here are our channels.
var i1,o1 = mk_ioschannel_pair[int]();
var i2,o2 = mk_ioschannel_pair[int]();
var i3,o3 = mk_ioschannel_pair[int]();
// We're going to muliplex channels 1 and 2 into channel 3
spawn_fthread$ mux ( iterator (i1,i2), o3 );
// write some stuff to channel 1
spawn_fthread { write (o1, 1); };
// write some stuff to channel 2
spawn_fthread { write (o2, 2); };
// read the data from channel 3
println$ read i3;
println$ read i3;
/////////////////
BTW: curiously, although streams are so useful,
there doesn't seem to be any abstraction in the library for them!
If there were, we could dispense with the need to write
the word "iterator" in:
iterator (i1, i2)
instead, we just require any data structure of
class Streamable[Container, ValueType] and construct
the iterator from that.
Hmm .. so I did that!!!
///////////////////////////////////
class Streamable[ContainerType, ValueType] {
virtual fun make_iterator : ContainerType -> 1 -> opt[ValueType];
}
instance[T,N] Streamable[T^N,T] {
fun make_iterator (a: T^N ) => iterator a;
}
proc mux[C,T with Streamable[C,ischannel[T]]] (a:C, out:oschannel[T]) ()
{
var it : 1 -> opt[ischannel[T]] = make_iterator a;
for i in it do spawn_fthread$ copy(i,out); done
}
spawn_fthread$ mux ( (i1,i2), o3 );
spawn_fthread { write (o1, 1); };
spawn_fthread { write (o2, 2); };
println$ read i3;
println$ read i3;
////////////////////////////////
Note that I used "make_iterator" as the virtual function.
I did that so as not to hide the iterator functions already
defined for arrays, lists, etc.
With this technology, these functions shouldn't be defined
as class members, but in instances of class Streamable.
All this shows how awesomely powerful Felix is becoming.
****************************************************************
For a long time I focussed on the type system, installation,
optimisation, parser, etc. Things every language needs.
I basically ignored the core features that differentiate Felix
from other languages, embodied in the run time system.
That's because the other more standard stuff (if you count
user defined syntax as standard stuff) is a pre-requisite
for properly managing the facilities enabled by the
core control inversion technology.
Now, it's paying off -- technically.
Just need a user/developer base.
--
john skaller
skal...@users.sourceforge.net
http://felix-lang.org
------------------------------------------------------------------------------
Keep yourself connected to Go Parallel:
DESIGN Expert tips on starting your parallel project right.
http://goparallel.sourceforge.net/
_______________________________________________
Felix-language mailing list
Felix-language@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/felix-language
