On Tue, 2007-02-20 at 12:24 +0100, Ramon Diaz-Uriarte wrote: > > > Now, following with the tradition of "it is sooo easy to ask for > > > stuff": my superficial understanding is that distributed, concurrent, > > > and parallel computing using shared memory can be a lot harder and > > > error prone (e.g., "Concepts, Techniques, and Models of Comp. Progr", > > > from van Roy and Haridi). If at all possible, when/why/how to choose > > > Felix over Erlang (or Oz) and how to complement both (your sentence of > > > "Felix to create ... that Erlang would manage ...") would be something > > > great to have in the docs. > > > > Because it isn't a lot harder, that's crap. Message passing > > is easier to analyse, but some kinds of things will require > > much more complex programs. > > > > Please, do not make Van Roy and Haridi responsible for my above > statement. It might just be my lack of understanding.
It's like saying functional programming is better than imperative programming. That's crap for the same reason. They're actually equivalent .. FP is better suited for some things, and imperative for others .. which is why most FPL's give you both. Even Haskell has its monadic style .. which demonstrates the equivalence. There's no doubt functions are better understood than mutations, but that's a weakness in research being studied now. FPLs usually have multiple features. For example some people would say declarative style was good, and FPL's provide that. As does logic programming. Even imperative systems provide declarations.. and what is a regular expression but a declarative form of what is usually considered an imperative operation (executing a state machine)? The idea in Felix is as for C++: to provide the programmer several techniques and let them choose. > > Of course you can also use mutexes etc. With fibres this > > kind of things is rarely needed, since they can't be > > pre-empted. > > > > Aha. I need to go through this much, much more carefully. But this > looks really mind blowing. Thanks a lot for the comments! Do you know > where I can find a (gentle) introduction to these issues? I actually > think "I just don't get Felix". Very little documentation exists for the cooperative multi-tasking system. > > > So the actual model is a variant of CSP plus shared memory. > > An arbitrary program isn't easy to reason about .. but > > it is possible to write code which is if you want. > > > > Just as an example -- fibres cannot deadlock! > > > > Hehe! This is a trick statement. The way the model > > is built, if fibres deadlock they're unreachable > > and get reaped by the collector, and so they don't > > exist, and hence can't be deadlocked. > > > > That is funny. Sounds a lot like magic, though ... It just dropped out of the model. Felix is basically an operating system: it has a scheduler, channels, and kernel calls (service requests). Apart from the fibres and your ordinary pthreads (both with channels), it also does asynchronous I/O. Basically if you read a socket, your fibre blocks .. but the pthread it is in doesn't. Async I/O is standard, and optimised for your OS. Again .. not many examples of how to do this .. especially as the interface is being changed (to use typeclasses). -- John Skaller <skaller at users dot sf dot net> Felix, successor to C++: http://felix.sf.net ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Felix-language mailing list Felix-language@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/felix-language
