On 15/11/2012, at 7:27 AM, Dobes Vandermeer wrote: > The main missing link between Felix and that is the ability to easy "package" > an object to provide just the virtual members of a type class while keeping > the "true" type hidden, thus allowing collections of heterogeneous elements.
I think I would agree with this (although I'm not sure I understand it). Type classes provide overloading disguised as parametric polymorphism. That's it. There's no object system or state involved. The virtuals are static virtual, there's no dispatch involved. (In Haskell they have to pass dictionaries around because they insist on separate compilation). Objects (as in Felix Java like objects) are just collections of function closures, so they capture shared state. They're fully dynamic, a lot more so than anything Java does. Indeed the syntactic sugar is there to *hide* the dynamic power. Dobes is right there's a HUGE gap between a type class virtual and a slot in a record holding a function closure. Quite a few times I want to instantiate a type class with an object and cannot. There's a reason: type classes work in their limited way because they're based on solid mathematics. They're not ideal, but what they do they do right. Object in Felix work for the same reason: they're based on an implementation trick which uses the core functional system which again is based on solid mathematics. OO does not work as a paradigm -- a fact also based on solid mathematics. Classes as in C++ and Java are certainly useful, when the modelling is subject to the constraints of the theory: dynamic linear dispatch works for properties and not relations. Felix doesn't have this at the moment. It used to, but the extensions to the core compiler needed to support it were extremely complex and hard to manage -- a symptom of a broken system. The dynamic objects we have now only required a single extension to the compiler (to support addition of record fields aka row polymorphism). What's more, these objects are much more powerful, and they're also structurally typed. The Java like syntactic sugar is not there to provide OO -- its there to HIDE the true power of the system, which, in the end, is entirely derived from the core functional programming concept of closures. What's missing here is that all this stuff is just wrapping and sugar intended to suport development of the REAL advance made by Felix: synchronous fibres integrated with asynchronous events. Almost all the technology put in recently is there to support the eventual development of the control system (fibres, threads, parallelism, etc). Interestingly the most successful recent addition to Felix (IMHO) is the streams/iterators stuff .. which is a different way to do a very specialised kind of coroutine. Fibres with channels is a lot more general but much harder to use. A lot of the type system, objects, etc, is there to allow experimenting with the fibration and encapsulation of idiomatic usage (read boilerplate!) in a useable syntax. -- 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
