On 21/11/2012, at 8:21 AM, Dobes Vandermeer wrote: > Ah right, the closures would have to use a uniform calling style, no way > around that.
As you're aware from previous discussions, Felix makes some uncomfortable compromises, including allowing uninitialised variables, using the machine stack, and other stuff, in order to maintain some semblance of "compatibility" with C/C++. Some of the compromises are historical, some are just guesses that had consequences which are much uglier than expected, and some can be fixed if sufficient resources are thrown at them. Without actual users writing actual code there is no way to weigh the actual costs and benefits -- and very little incentive to allocate resources. At the moment, I am so impressed with the simplifications that streams/iterators have made, I look for something else that can also provide similar improvement. By far the least understood and used feature of the language is the one it was actually designed for: synchronous threads. I know from experience that the low level primitives are very hard to use right. Machine I constructed with them don't work unless everything is started up and connected in exactly the right order (otherwise you get a deadlock suicide), and there's a lot of housekeeping to share about the schannels. So in a similar way the "java like objects and interfaces" leverages simple primitives like records and closures and a bit of syntax to provide a new high power subsystem, I'd like to find a nice DSSL that can be implemented with threads/channels. Streams/iterators actually use continuations now, but they're not using schannels. Yielding generators are much weaker than channels -- but this weakness of semantics is also a sufficient simplification that the system fits easily with the usual subroutine call mechanism and "for v in iterator" is a very simple syntax extension which just provides some minor cleanup. I have only two use cases for threads/channels. One is a too simple: the webserver. The other is broken and hard to share: the SDL examples. SDL is no longer supported by the developers. It also failed to provide the consistency really required. Still, using synchronous channels to make some simple examples work demonstrated just how powerful the "chip" paradigm really is. Parts of games that are normally coupled in code were easily separated using this technology. One use case I think about is generalised parsing, i.e. a parser which, when there are alternatives, launches a fibre to explore each alternative. But that may need broadcast which schannel doesn't support .. hmm ... Anyhow what is needed now are developers who can see the potential of the system and stick with development long enough to realise goals. The system is highly flexible, maybe too much for the average programmer: there isn't even a fixed "language" (other than the C++ on which the run time is based). -- john skaller skal...@users.sourceforge.net http://felix-lang.org ------------------------------------------------------------------------------ Monitor your physical, virtual and cloud infrastructure from a single web console. Get in-depth insight into apps, servers, databases, vmware, SAP, cloud infrastructure, etc. Download 30-day Free Trial. Pricing starts from $795 for 25 servers or applications! http://p.sf.net/sfu/zoho_dev2dev_nov _______________________________________________ Felix-language mailing list Felix-language@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/felix-language
