On Mon, 2007-04-16 at 22:12 -0400, Chris King wrote:
> > Here Sin is a *design* for a chip,
> This reminds me a lot of Pict [1]... Pict is based on the pi calculus
> and has channels which are much like Felix's channels (except that
> they are asynchronous).
See also JoCaml which is a high level implementation of
the join calculus. JoCaml at least has an advantage over
Felix in that the 'plugin' mechanism handles synchronous
and asynchronous connections with the same syntax,
namely a traditional function call.
However a state-machine model using chips and wires
is better for larger systems I think.
However JoCaml uses actual Posix threads for its implementation
and so isn't suitable for large scale programming. Actually
ocaml vm-threads probably would be if Inria put some work
into making it faster.
> > in Cauchy illustrates one of the problems. We're actually
> > connecting here to a Newton chip which does this:
> >
> > var &b : double <- read bin;
> > var &n : int <- read nin;
> >
> > It's vital that reads and writes be correctly ordered,
> > or the circuit deadlocks.
>
> This seems like Forth or assembler, where a failure to call a function
> with the proper number of arguments in the proper order results in a
> runtime error.
Yes. This construction is made using "assembly level"
primitives. The demonstration shows how to do that.
What we need is sugar to wrap it up. For example
any function
f: d -> c
can be converted into a chip by a single HOF:
proc enchip[d,c] (f:d->c)
(din:ischannel[d], cout:oschannel[o])
{
again:>
var &x: d <- read din;
var y = f x;
write (cout, y);
goto again;
}
Similarly one can automate filters, using perhaps the
Unix notation:
start < input | a | b | c > output
which is basically just a monad.
Better support in Felix for 'Domain Specific Sub-Languages' (DSSLs)
would really help.
> I could be missing something, but why not just pass a
> tuple?
I assume you mean read/write a tuple? Of course in the example
case you can, but only because in this case the two inputs
are written by two outputs of a single other chip in
sequence.
You might build a different model where this wasn't so:
the model might do something different semantically,
but the two wire connection is then more general.
As usual .. nothing saves you from making design decisions.
For example .. you can always make a chip that reads
two inputs and write a tuple to 'solve' the problem
you are reading a tuple.
And conversely .. you can make a demultiplexor that
reads a tuple and write the components on two channels
in order -- this makes the problem of ensuring the ordering
condition is met easy to verify if you "compose" a new
chip out of the original one plus the demux.
> And for "variable-length" calls where you really want to read
> items sequentially (as in the inner loop of Newton), you could pass a
> channel to the process as an argument. That way you could take full
> advantage of the type system to ensure that no deadlocks occur when
> "calling" a process.
I'm not sure I quite follow the argument. It is certainly
possible to have higher order channels .. channels that
you read channels off :)
> Overall I like the idea but I disagree that it's any more modular than
> a good functional programming language. Functional module systems
> such as O'Caml's really get to the heart of modularity: you can
> manipulate both "ends" of a module functor the same way you can
> manipulate the inputs and outputs of a chip.
No, you can't. What you're missing is the mandatory control
neutrality requirement. If you've read Meyer's OOSC the
principles of modularity are written nicely: explicit
interfaces, open/closed principle, etc.
Meyer left out one vital principal: control neutrality.
Ocaml is *Particularly BAD* from this viewpoint.
Perhaps Jacques can explain this better, i.e. from
a more theoretical viewpoint.
An example: folds and STL style iterators are control
inverse. Iterators rock for users -- folds suck big time.
Folds rock for implementors -- iterators suck for implementors.
Why is this? Because they're both wrong. Fold uses a user
supplied CALLBACK to merge elements. Callbacks suck
BECAUSE they're functions. Fold is the master, you
supply a slave. You have to maintain state manually. YUK!
[The burden is eased if the operation is purely functional,
and you do then gain some extra safety guarantees but
the technique is not general, even with laziness IMHO]
Ditto for implementing iterators in C++. They suck.
You have to maintain state manually.
Using iterators is provably superior to callbacks:
you can implement fold in a couple of lines of code:
In fact that code is already in the standard library
of both C++ and Felix. In C++ it is called accumulate.
In Felix it is called fold:
instance Sequence[stl_vector[t],stl_vector_iterator[t],t] {
...
fun fold[i] (f:i->t->i) (var acc:i) (x:stl_vector[t]):i= {
var s = begin x; var e = end x;
whilst s != e do acc = f acc (*s); ++s; done;
return acc;
}
}
[excuse the specificity to stl_vector here .. Felix has
some higher order typeclass support now that should
eliminate this -- see Monad -- but I haven't gotten
around to doing it]
The PROBLEM is you want to *implement* iterators the
same way but you can't: the master/slave relationship
is fixed in the designs.
So the designs -- BOTH the designs -- are wrong.
They fail the 'control neutral' requirement.
This is where languages with call/cc or some other
way of providing continuation passing natively shine.
Unfortunately .. Ocaml isn't one of them, and it isn't
lazy either. Laziness is closely related: eg a list
comprehension = lazy list is actually a stream
and provides a functional wrapper which hides the
cooperative 'yield'.
So you might argue Haskell 'passes' the control neutrality
requirement because of laziness: Ocaml definitely cannot
do it natively. In fact this is one of the key reasons
I started developing Felix!
--
John Skaller <skaller at users dot sf dot net>
Felix, successor to C++: http://felix.sf.net
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Felix-language mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/felix-language
