Well consider a type class:
class Widget[T] {virtual draw(w:T...) ;} ;
instance Widget [button] { draw(w:button...){...} } ;
Wouldn't it be nice if you could do:
val b = makeButton () ;
val w = b as Widget;
draw(w,...) ;
The compiler can generate a record type with all the virtual functions of
Widget in it and an instance of Widget for that record type that delegates
each virtual method to the matching member function. Then you have some
syntax "x as Widget" to construct that record from any other type that has
an implementation of Widget available.
This is kind of how they did it in Rust and it is nice in that you only use
dynamic dispatch when you have explicitly said you need it. The rest of the
time you can dispatch directly by using the static type. People mainly
only need dynamic dispatch in special cases like how you're using objects
now - probably heterogeneous collections.
This would also leverage the existing support for inheritance in type
classes.
Given this can almost be implemented as a syntactic desugaring it won’t
violate the rules already in place. I think it was tricky to implement in
the current compiler because desugaring code doesn't know what type classes
and type class instances are defined.
Basically it is a way to create what objects currently are in Felix but
reusing the type class as a way to define things.
On Nov 14, 2012 3:33 PM, "john skaller" <skal...@users.sourceforge.net>
wrote:
>
> 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
>
> --
> You received this message because you are subscribed to the Google Groups
> "Felix Language" group.
> To post to this group, send email to felix-langu...@googlegroups.com.
> To unsubscribe from this group, send email to
> felix-language+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/felix-language?hl=en.
>
>
------------------------------------------------------------------------------
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
