On Sat, Jun 22, 2013 at 8:28 AM, Nick Wellnhofer <[email protected]> wrote: > On Jun 22, 2013, at 01:59 , Nathan Kurz <[email protected]> wrote: > >> Have either of you looked at it? Are there things you want to support >> that it does not? > > Regarding features of dynamic languages, I don't think they make sense for > Clownfish.
I wasn't suggesting that Clownfish should backend to Étoilé. As you and Marvin note, much more general than Clownfish needs. I was wondering instead whether its features are superset of what Clownfish seeks to provide, to understand whether I should study how it solved the fragile ABI problem (which I think it has) or whether its solution was inapplicable to Clownfish because it lacked something else essential. > One thing that Objective-C and > other dynamic languages support, for example, is adding methods or even > instance variables at runtime. Currently (although underinformed) I think that offering non-fragile instance variables is practically synonymous with the ability to ability to add instance variables to the compiled extension at runtime. One doesn't need to support this or expose it to the user, but behind the scenes I think the implementation will be very similar. > This would slow down Clownfish a lot. I worry about that too, but I think this may be required if we want a truly non-fragile ABI. This is part of the reason I think the tradeoff of accepting a degree of fragility may be worthwhile. On the other hand, the Étoilé paper said they were achieving 80% of straight C speed using cached accessors and assembly dispatch. > To get acceptable speed, you'll need something like inline caching which > isn't feasible in plain C. I read about needing assembly to re-pass the arguments for methods. I didn't really understand the reasoning, at least for BSD/Linux x64. Are there other reasons too? Also, how concerned are we with "plain C" versus inline assembly? On the bright side, Clownfish's "once-registered-forever-frozen" approach would make caching simpler. > But there are some useful features from languages with static OO like Java > that could be implemented without impact on > performance. Class methods should be an easy one, for example. Interfaces > would be useful, too, but more involved. Marvin -- Look! Is that a yeti over there across the valley? The feature I'd really like is to be able to override a individual methods or classes at the registration time. What I like about aiming for a non-fragile-ABI is that I'm hoping this is something I can sneak in while Marvin isn't looking. Marvin -- Sorry, I thought I saw something moving. On Sat, Jun 22, 2013 at 2:53 PM, Marvin Humphrey <[email protected]> wrote: > On Fri, Jun 21, 2013 at 4:59 PM, Nathan Kurz <[email protected]> wrote: >> As/if Clownfish moves to having more of a runtime role (which I think >> it has to if truly non-fragile ABI is desired) it seems like it would >> have a lot in common with the Objective C runtimes. In particular, >> the Étoilé runtime seems to have a lot of the same features you are >> looking for. > > Clownfish is a symbiotic object system. Though it may be used standalone, it > is designed to pair with a "host" dynamic language, not to provide a platform > on top of which the dynamic language can run. Yes, although I think that at its core the difference between "symbiotic object system" and "dynamic language runtime" is blurrier than it might seem. If one wants to be non-fragile, one needs dynamic method dispatch. To insulate compiled extensions from changes in the core, Clownfish needs to support many of the same features a dynamic language does. If I squint just right, I can see the start-time registration, object configuration, and late-binding as a JIT compile from the dynamic "Clownfish" to something efficiently executable. > Étoilé must > provide a feature set which is the *superset* of all features in all supported > languages. > > In contrast, the Clownfish object model is deliberately classical and > conservative. Instead of trying to be all things to all languages, Clownfish > only attempts to provide a *subset* of selected features. Check. Were you able to tell at a glance whether Étoilé's features are indeed a superset of those Clownfish wants to provide? > Rather than Étoilé, the two options I'd mention as closest to Clownfish are > GObject/Vala and SWIG/C++. > > http://en.wikipedia.org/wiki/GObject > http://search.cpan.org/perldoc?Glib::Object::Subclass > http://en.wikipedia.org/wiki/Vala_%28programming_language%29 > http://www.swig.org/Doc2.0/SWIGPlus.html I think I'm familiar with Swig, but not with GObject or Vala. I'll check them out. > However, neither offers a solution to the fragile ABI problem, so they are not > appropriate for CPAN-style distributed development of compiled extensions. This is why I think you might be in dynamic language territory. The goals of Clownfish may be entirely different, but I think the bag-of-tricks may be more similar to Étoilé than Swig. Don't know yet about GObject. > Admittedly, Clownfish instance variables still present fragile ABI problems at > the moment; addressing that issue is very important, in my opinion. I'm taking your word that it's important, and trying to figure out how to minimize the performance impact. I don't have the lay of the land yet, and am trying to figure out what's already been done and what needs to be novel. --nate
