The first day of the conference was probably the most interesting to me and there was loads of good stuff. It all started with the invited talk by Joe Armstrong about Erlang. Apparently he is quite well known as an opponent of OO programming, so was a bit of an odd choice, but a good one. He was an excellent speaker and the talk was not actually very confrontational. He expounded a lot of good design ideas and concepts and evangelised a bit for Erlang (which seems pretty hot right now in PL circles). He has a real thing against mutable state, which, I guess, in its shared incarnation with concurrency around, is fair. I liked the idea that you don't catch expcetions, but let the process fail, but I'm not entirely convinced you can do this in real life, since other processes are going to have to catch the mess at some point. The other controversial point (according to me) is that we 'natively' understand concurrency, but not OO. I think the opposite is true, I think objects and classes are pretty natural, but that we function very sequentially. We only really notice what other people (processes) are doing when we interact occasionaly. But I think this is even more reason to like something like Erlang which really concentrates on concurrency.
The invited talk was also good beccause it seemed to capture a few of the big 'feels' of the conference - that concurrency is hard and fertile ground for research, and that we might be reaching the limits of OO research (although I don't think I agree with the latter, I do with the former).
The first proper talk was on gradual typing, a great idea that is getting some attention recently in various guises, this is another iterative development in the field. The idea is to be able to safely combine dynamically and statically typed program fragments (and some kind of grey area between the two). I really think this is the way forward for programming languages, especially as type systems get more complex.
Next up (in my notes) is Werner again, this time talking about extending universe type systems with generics. This is the continuation of the work at FOOL that I describe below. Surfice to say I like it a lot and its worth reading.
Possibly the most controversial talk of the conference was on object identity and relation types. The authors propose special classes called relations where the equals and hashcode methods are automatically supplied by the compiler by comparing fields marked 'key'. This was the first step towards some kind of heap/database project. A few members of the audience disliked the use of the term object identity in such a context, but I think this is a pretty petty objection, changing things for the better is what we are meant to be doing. I kind of liked this, it addresses a long standing problem (the subtyping/equals mismatch) and does it nice and simply. However, the extra syntax and machinary seems a lot of effort for what is really a fairly small problem.
To round off the day was the panel discussion, discussing the future for OO programming languages. Martin Odersky and Gilad Bracha gave the most interesting and animated opening talks, but the rest of the discussion was a bit too restrained. Popular points were about concurrency and the (allegedly) growing division between expert and casual programmers. Whether reflection was essential for OO programming seemed to get people excited too.
Tuesday, August 07, 2007
FTfJP 07 (at ECOOP)
The second day at ECOOP was taken up with the FTfJP workshop. There were lots of interesting talks and I'll only blog about a few of them. I spent all day there, but I really should have been elsewhere at 2 to listen to Gilad Bracha's talk at DyLA, which lots of people were talking about and sounded pretty interesting from chatting to Gilad. The talk was (apparently, I still need to read the paper) about Gilad's new language which he is developing at Cadence. All I really know is that it is dynamically types and involves some kind of virtual class construct, of which I am a big fan!
So onto the talks, the accompanying papers can be found at the FTfJP link above:
First up was a good looking lad talking about some wildcards rubbish. I thought the talk went pretty well and I got interested questions, so at least some people were following and were interested. I also got some useful feedback afterwards, so that is always nice.
Vincent Cremet or Philippe Altherr - Adding Type Constructor Polymorphism to Java - This was a nice idea to make Java generics more expressive by allowing formal type parameters to be parameterised, thus having the power of full type constructors. You get quite a lot of extra expressivity for no extra syntactic constructs and very little syntactic overhead, which is similar to what already exists, so its a winner all round really. However, it does make the declaration of generic classes even more complex and ugly, so I can't see it being in Java 7.
Chieri Saito - The Essence of Lightweight Family Polymorphism - This was really interesting to me, particularly as I think the lightweight family polymorphism idea is great. The idea here was to attempt to translate lightweight family polymorphism programs into Java with generics to discover how much of their system is syntactic sugar and how much is actually new. They found that most could be translated away, but they needed an extra construct, to give a more specialised type to 'this', in order to translate the complete language. This was formally done by translating .FJ to FGJ.
Elena Giachino - Seperating Type, Behaviour and State to Acheive Very Fine-Grained Reuse - this is another neat idea, this takes the ideas behind traits a step further and further breaks up classes, so there are seperate constructs for behaviour, state, object creation and types. This seems to break things down to the bottom level and means reuse levels are really high. This is very elegant and interesting, however, there must be a tradeoff in the real world with practicality, and having so many little 'micro-classes' kicking around must get to be hard work, I think this even came across in the talk as the conceptual divisions were pretty porous and so in the examples bits of state would appear in the behaviour modules and so forth. Still a great idea and intellectually very interesting.
So onto the talks, the accompanying papers can be found at the FTfJP link above:
First up was a good looking lad talking about some wildcards rubbish. I thought the talk went pretty well and I got interested questions, so at least some people were following and were interested. I also got some useful feedback afterwards, so that is always nice.
Vincent Cremet or Philippe Altherr - Adding Type Constructor Polymorphism to Java - This was a nice idea to make Java generics more expressive by allowing formal type parameters to be parameterised, thus having the power of full type constructors. You get quite a lot of extra expressivity for no extra syntactic constructs and very little syntactic overhead, which is similar to what already exists, so its a winner all round really. However, it does make the declaration of generic classes even more complex and ugly, so I can't see it being in Java 7.
Chieri Saito - The Essence of Lightweight Family Polymorphism - This was really interesting to me, particularly as I think the lightweight family polymorphism idea is great. The idea here was to attempt to translate lightweight family polymorphism programs into Java with generics to discover how much of their system is syntactic sugar and how much is actually new. They found that most could be translated away, but they needed an extra construct, to give a more specialised type to 'this', in order to translate the complete language. This was formally done by translating .FJ to FGJ.
Elena Giachino - Seperating Type, Behaviour and State to Acheive Very Fine-Grained Reuse - this is another neat idea, this takes the ideas behind traits a step further and further breaks up classes, so there are seperate constructs for behaviour, state, object creation and types. This seems to break things down to the bottom level and means reuse levels are really high. This is very elegant and interesting, however, there must be a tradeoff in the real world with practicality, and having so many little 'micro-classes' kicking around must get to be hard work, I think this even came across in the talk as the conceptual divisions were pretty porous and so in the examples bits of state would appear in the behaviour modules and so forth. Still a great idea and intellectually very interesting.
Monday, August 06, 2007
ECOOP 07 - Berlin - IWACO
I was in Berlin last week for ECOOP. The conference was really interesting, I got to meet lots of interesting and important people and I got to explore Berlin a bit too - it is, in fact, a wonderful city - I was well impressed! As I have quite a lot to say, I'll go one day at a time:
On the monday I attended the IWACO workshop, there were talks of 5, 10 and 25 minutes (I think) and nearly all were interesting, the ones I found most interesting were (papers available here):
Erik Ernst - Exclusive References (Primitive Associations) - Combining virtual classes and ownership is a great idea, Erik has an alternative that looks interesting and made me want to read the paper, I think its stuff I need to think about...
Matthew Parkinson - Class Invariants - The End of the Road? - Interesting and deliberately contraversial talk about the limitations of class invariants. Class invariants are described as too inflexible beacuse they can not describe the invariants of a group of classes (eg subject-observer). A heavier alternative using predicates is proposed. I don't know much about class invariants, but the argument seemed to make sense. However, class invariants have the advantage that they are easy to understand for the programmer, which seems to be lost by using predicates. I think this is another motivation for family polymorphism/virtual classes, as class invariants over a family should solve the problem - hmm, another research idea...
Invited talk on X10 by Vijay Saraswat - sounds very interesting and I look forward to reading the paper when its finished. He talked about having constraint types in X10 and extending FJ with xonstraint types as a formal version. These constraint types are a form of depedent types and the type system is undecidable, but he argued that this was not a big problem.
Johan Ostland (I think) - On the benefit of adding modes to owners (Ownership, Uniqueness and Immutability) - Extending ownership types with mutability annotations - simple and effective idea, looks good.
James Noble - Ownership meets Java and Peter Muller - State of the universe addess - These two talks were meant to give an overview of the current state of the art in the two 'competing' systems of ownership types and universes. Both were good talks and convincing, and both outlined really exiciting directions for future work. I guess the result is that ownership types are more flexible and powerful and univeses are easier to use and have less overhead, hopefully we'll get the best of both worlds one day...
John Boyland - Iterators can be independent "from" their collections - an intersting, if complex, solution to the iterators/ownership mismatch. I need to read the paper on this one!
??? - Using ownership types to support library aliasing boundaries - good talk on using ownership in a C++ library which their students used to produce a 3d game. The combination of concurrency and ownership was interesting, they adopted a message passing approach and used 'tethers' to communicate back to the message sending process.
Werner Dietl - Runtime Universe Type Inference - a really good presentation, Werner used a live demo with funky animations to demonstrate the inference of unvierse types. All seemed to work nicely.
Mawan Abi-Antoun - Compile-Time Views of Execution Structure Based on Ownership and Ownership Domains in the real world - the first talk presented a system to visually present the runtime structure of objects using ownership domains. The visualisation is produced at compile time but still gives the dynamic structure of the program. The second talk presented an implementation of ownership domains and a case study on how ownership domains can be added to existing programs. Finding that they served as a useful way to identify bad design 'smells'. I thought this is an interesting point, that seems so obvious when you think about it - a mechanism used for enforcing design in the type system, when applied to an existing system, can be used to identify bad design!
In summary - yay for ownership!
More on the rest of the conference to follow...
On the monday I attended the IWACO workshop, there were talks of 5, 10 and 25 minutes (I think) and nearly all were interesting, the ones I found most interesting were (papers available here):
Erik Ernst - Exclusive References (Primitive Associations) - Combining virtual classes and ownership is a great idea, Erik has an alternative that looks interesting and made me want to read the paper, I think its stuff I need to think about...
Matthew Parkinson - Class Invariants - The End of the Road? - Interesting and deliberately contraversial talk about the limitations of class invariants. Class invariants are described as too inflexible beacuse they can not describe the invariants of a group of classes (eg subject-observer). A heavier alternative using predicates is proposed. I don't know much about class invariants, but the argument seemed to make sense. However, class invariants have the advantage that they are easy to understand for the programmer, which seems to be lost by using predicates. I think this is another motivation for family polymorphism/virtual classes, as class invariants over a family should solve the problem - hmm, another research idea...
Invited talk on X10 by Vijay Saraswat - sounds very interesting and I look forward to reading the paper when its finished. He talked about having constraint types in X10 and extending FJ with xonstraint types as a formal version. These constraint types are a form of depedent types and the type system is undecidable, but he argued that this was not a big problem.
Johan Ostland (I think) - On the benefit of adding modes to owners (Ownership, Uniqueness and Immutability) - Extending ownership types with mutability annotations - simple and effective idea, looks good.
James Noble - Ownership meets Java and Peter Muller - State of the universe addess - These two talks were meant to give an overview of the current state of the art in the two 'competing' systems of ownership types and universes. Both were good talks and convincing, and both outlined really exiciting directions for future work. I guess the result is that ownership types are more flexible and powerful and univeses are easier to use and have less overhead, hopefully we'll get the best of both worlds one day...
John Boyland - Iterators can be independent "from" their collections - an intersting, if complex, solution to the iterators/ownership mismatch. I need to read the paper on this one!
??? - Using ownership types to support library aliasing boundaries - good talk on using ownership in a C++ library which their students used to produce a 3d game. The combination of concurrency and ownership was interesting, they adopted a message passing approach and used 'tethers' to communicate back to the message sending process.
Werner Dietl - Runtime Universe Type Inference - a really good presentation, Werner used a live demo with funky animations to demonstrate the inference of unvierse types. All seemed to work nicely.
Mawan Abi-Antoun - Compile-Time Views of Execution Structure Based on Ownership and Ownership Domains in the real world - the first talk presented a system to visually present the runtime structure of objects using ownership domains. The visualisation is produced at compile time but still gives the dynamic structure of the program. The second talk presented an implementation of ownership domains and a case study on how ownership domains can be added to existing programs. Finding that they served as a useful way to identify bad design 'smells'. I thought this is an interesting point, that seems so obvious when you think about it - a mechanism used for enforcing design in the type system, when applied to an existing system, can be used to identify bad design!
In summary - yay for ownership!
More on the rest of the conference to follow...
Saturday, July 28, 2007
Papers
The papers mentioned below (Multiple Ownership and Towards an Existential Types Model for Java Wildcards) are now available from my website:
http://www.nicholascameron.co.uk/papers/index.html
http://www.nicholascameron.co.uk/papers/index.html
F-bounds and wildcards
An odd one this, that doesn't fit into our current model of wildcards. First, to set the scene, remember that the Java type checker always treats wildcards as unique. So, for example, if a method requires a parameter with type Pair and we give it a Pair it will not type check (since each wildcard is capture converted to a different, fresh type variable).
However, if we have a generic class C that has an f-bounded formal type variable:
class C<X extends C<X>> ....
And we instantiate this type with wildcards, C<? extends C<?>>, it does type check. This is surprising since the type variables in the declaration are the same and yet the wildcards in the wildcard type are 'different', but here they are regarded as the same wildcard! There is no unsoundness as we can not create a type that violates the constraints of the formal parameters, but it is surprising that the type checker can apply this knowledge to the wildcard type.
Time to upgrade our model...
However, if we have a generic class C that has an f-bounded formal type variable:
class C<X extends C<X>> ....
And we instantiate this type with wildcards, C<? extends C<?>>, it does type check. This is surprising since the type variables in the declaration are the same and yet the wildcards in the wildcard type are 'different', but here they are regarded as the same wildcard! There is no unsoundness as we can not create a type that violates the constraints of the formal parameters, but it is surprising that the type checker can apply this knowledge to the wildcard type.
Time to upgrade our model...
Sunday, June 10, 2007
MOJO and \existsJ papers
I was suitably elated to have two papers accepted in the last month or so. The first, with Sophia Drossopoulou, James Noble and Matthew Smith, is called Multiple Ownership and has been accepted at OOPSLA. We describe a system of ownership types where objects may have multiple owners. The formal language described is MOJO. The description using simple sets (the 'Venn diagram' decription) is particularly pleasing in its simplicity.
The second paper (Towards an Existential Types Model for Java wityh Wildcards) is written with Sophia and Erik Ernst and describes an OO calculus with traditional-style existential types that we describe as partially modelling Java with Wildcards. It is a nice summary of some of the work we have done towards proving type soundness for Java with Wildcards; which we are still working on, and is looking like it will occupy the bulk of my thesis!
I've been lucky to work some really good people on both papers, and they have been an excellent experience.
I'll post links to copies of the papers once we've made corrections and generally given them a little extra polish.
The second paper (Towards an Existential Types Model for Java wityh Wildcards) is written with Sophia and Erik Ernst and describes an OO calculus with traditional-style existential types that we describe as partially modelling Java with Wildcards. It is a nice summary of some of the work we have done towards proving type soundness for Java with Wildcards; which we are still working on, and is looking like it will occupy the bulk of my thesis!
I've been lucky to work some really good people on both papers, and they have been an excellent experience.
I'll post links to copies of the papers once we've made corrections and generally given them a little extra polish.
Sunday, January 28, 2007
Functional vs OO languages
Passing judgement on this kind of thing is a bit out of my scope, but I was wound up enough by one of the invited talks at POPL to put my opinion to paper (as it were). First of all, there are a few issues, first is imperative vs functional (ie state-less) programming and the other is abstraction using objects (usually classes) vs abstraction using functions (and, in particular, higher order functions). As the two are usually lumped together so will I, as I'm not so much expressing an opinion as expressing my disgust at other peoples'.
So, I have a problem with the "functional languages are better" opinion that seems to be going around a large part of the programming languages community at the moment. First off, we are all engineers to some degree and should realise there is no such thing as 'better' and especially not 'best'. Functional may be better sometimes and imperative at others. Secondly, I know functional languages are easier to reason about for theorists, easy to optimise, easier to parallelise and generally easier to work with (for theorists); BUT, that doesn't mean they are better for programmers (they might be, but there is no logical implication here). Third: there was a big theme at POPL this year to listen to the software engineers, which is for sure a good idea; however, most software engineers want OO languages, not functional ones, because they believe they scale better to large projects. Maybe they are wrong, but it seems odd to want to listen to them, but then ignore this rather large point. Lastly, my personal opinion is that the better language in a given situation is the one that better matches the underlying physical situation. For things like image processing this may well be a functional model. However, we live in a stateful world and most things in it have state (including programmer's brains), it therefore seems like avoinding state in many programming situations increases the mismatch between the physical and abstract models and thus makes the programs harder to write and understand.
On a side note, Chet Murphy's talk at POPL inspired this overlong rant, and it was kind of inspiring; he certainly had good results and it was a novel and practical use for more hi-tec languages. BUT, it wound me up for a few reasons: it had a hint of preaching to the choir about it; I didn't like the blanket statement (unbacked up) that functional languages are better (which set off the above rant); I didn't agree that functional interefaces to a module imply that the module can naturally be written better in a functional way (there may be internal state that is hard to get rid of, further more at the largest level of abstraction, everything has a functional interface, but not all programs can be happily rewritten in a functional language); the result seemed to be that a mess of a program in one language ran like a dog, when rewritten nicely in another language it ran much faster. This seems to miss the point that the rewriting itself (no matter which language was used) would probably result in improved efficency. Basically, a lot of what he said may be both true and impressive, but the implications he drew didn't seem to be warranted.
So, I have a problem with the "functional languages are better" opinion that seems to be going around a large part of the programming languages community at the moment. First off, we are all engineers to some degree and should realise there is no such thing as 'better' and especially not 'best'. Functional may be better sometimes and imperative at others. Secondly, I know functional languages are easier to reason about for theorists, easy to optimise, easier to parallelise and generally easier to work with (for theorists); BUT, that doesn't mean they are better for programmers (they might be, but there is no logical implication here). Third: there was a big theme at POPL this year to listen to the software engineers, which is for sure a good idea; however, most software engineers want OO languages, not functional ones, because they believe they scale better to large projects. Maybe they are wrong, but it seems odd to want to listen to them, but then ignore this rather large point. Lastly, my personal opinion is that the better language in a given situation is the one that better matches the underlying physical situation. For things like image processing this may well be a functional model. However, we live in a stateful world and most things in it have state (including programmer's brains), it therefore seems like avoinding state in many programming situations increases the mismatch between the physical and abstract models and thus makes the programs harder to write and understand.
On a side note, Chet Murphy's talk at POPL inspired this overlong rant, and it was kind of inspiring; he certainly had good results and it was a novel and practical use for more hi-tec languages. BUT, it wound me up for a few reasons: it had a hint of preaching to the choir about it; I didn't like the blanket statement (unbacked up) that functional languages are better (which set off the above rant); I didn't agree that functional interefaces to a module imply that the module can naturally be written better in a functional way (there may be internal state that is hard to get rid of, further more at the largest level of abstraction, everything has a functional interface, but not all programs can be happily rewritten in a functional language); the result seemed to be that a mess of a program in one language ran like a dog, when rewritten nicely in another language it ran much faster. This seems to miss the point that the rewriting itself (no matter which language was used) would probably result in improved efficency. Basically, a lot of what he said may be both true and impressive, but the implications he drew didn't seem to be warranted.
Thursday, January 25, 2007
Arrays considered harmful
I've come to the conclusion that arrays are bad. They really have no place in a modern programming language and should go the way of the pointer: being considered an implementation detail.
The reason is that lists are just simply better: they are more flexible, allow for a wider variety of implementaion, give the compiler more room to optimise, are easier to type (this is probably the best reason here, consider the grief Java arrays cause to the type system), integrate nicely into an object-oriented model, etc, etc. All that is needed is some syntactic support so they are as easy to use as arrays and allow the compiler to optimise lists to arrays as it sees fit (as far as I'm aware this is fairly easy to do). Of course we can still let systems programmers have arrays just as they have pointers, but 99% of programmers should never use them.
I hope to never have to deal with arrays again (not that I do already), and never have to answer questions about how such and such a feature will work with arrays. If I can type generic collections that should be enough.
The reason is that lists are just simply better: they are more flexible, allow for a wider variety of implementaion, give the compiler more room to optimise, are easier to type (this is probably the best reason here, consider the grief Java arrays cause to the type system), integrate nicely into an object-oriented model, etc, etc. All that is needed is some syntactic support so they are as easy to use as arrays and allow the compiler to optimise lists to arrays as it sees fit (as far as I'm aware this is fairly easy to do). Of course we can still let systems programmers have arrays just as they have pointers, but 99% of programmers should never use them.
I hope to never have to deal with arrays again (not that I do already), and never have to answer questions about how such and such a feature will work with arrays. If I can type generic collections that should be enough.
Wednesday, January 24, 2007
POPL and FOOL/WOOD '07
I was privileged to attend the POPL conference in Nice last week, followed by the FOOL/WOOD workshop on the saturday. I had a great time (especially enjoying the sunny weather, I managed to fall asleep in the sun on the beach at one point), it was my first 'proper' conference experience and once I got into the swing of things a bit, I really enjoyed talking to lots of interesting and reputable people and soaking up all the brain waves floating around.
Most of the talks were excellent and very interesting, even in topics from which I normally run away from screaming. A lot of the subject matter at POPL was a out of my usual scope and went a bit over my head, and that I was still interested in the talks is a real credit to the presenters. FOOL on the other hand was so spot on, topic wise, that I was pretty much in research heaven. Almost every talk was relevant, interesting and well-presented.
I'll go over some of the talks/papers that interested me below. Links to the papers can be found here or here.
POPL:
- Invited talk: Advanced Programming Language Design in Enterprise Software: A lambda-calculus theorist wanders into a datacenter
I thought this was going to be inspiring, but actually it was a bit disappointing. In the end it just made me angry and I'll have a rant on the functional vs imperative (OO, more to the point) thing in another post. - Operational Semantics for Multi-Language Programming
An interesting (and necessary) idea is how to integrate type systems between programming languages or calculi. This seems like the first paper in a series building up to do this properly, but even so, it is well developed and a good solution to this problem. - Semantics of Static Pointcuts in AspectJ
Although I loathe aspects from a software engineering prespective, they seem to be fairly hot right now, and they do allow for some nice programming techniques. This is a formalism of the pointcut language of AspectJ as does just what it says on the tin. The use of Datalog as an 'intermediate language' adds a bit of spice to the mixture. I admit to being surprised that somthing like this has not been before. - A typed Intermediate Language for Compiling Multiple Inheritance
Again, I'm surprised this hasn't been done before, and, in a way, I wasn't sure why this was so important. But, I think to compiler people it is quite cool. Anyway, I really liked the talk and hope one day to be able to understand the paper as it sounded interesting. - Cork: Dynamic Memory Leak Detection for Garbage-Collected Languages
Very cool use of profiling/dynamic analysis of programs. I liked the talk because dynamic analysis is something I've not really come across before and profiling and instrumentation stuff has always interested me. I will go back and try to understand the theory in detail, but the intuitive stuff was quite exciting. - Scrap Your Boilerplate with Xpath-like Combinators
This really got me thinking. XSLT and Xpath are pretty intersting subjects and there has to be a better way to deal with these and XML in programming languages (in fact its getting a lot of attention at the moment). Other than the motivation the talk and paper were pretty heavy going (at least with my lack of knowledge about FPLs), but I'll definitly be reading the paper in some detail. - Towards a Mechanized Metatheory of Standard ML
A 'rather than you than me' bit of research this. It is important and necessarywork, but it looks like really dull stuff to actually do! The talk, though, was far from dull. - Extracting Queries by Static Analysis of Transparent Persistence
Another interesting paper on integrating queries/databases with programming languages, a bit of a hot topic at the moment, me thinks. The idea here is to use transparent persistence, but extract queries during compilation for the sake of efficency. It sounded like a really good idea and the details seem interesting. Another talk, that 'sucked me in'. - Assessing Security Threats of Looping Constructs
I enjoyed this talk as the subject matter was interesting from a non-academic perspective. I always find information theory-style stuff quite cool, I don;t really know well. The talk was really well presented too. - Javascript Instrumentation for Browser Security
Again, an interesting talk due to the subject matter, browser security being relavent to pretty much everyone. The scheme presented here seemed solid and straightforward (in a good way). The complications due to the nature of Javascript were well explained and solutions presented. I was not completely convinced that it dealt with 100% of cases correctly, in the question and answers there seemed a degree of reliance on conservatism and the fact that no legitimate program would use techniques that appeared to be obfuscation. Still, I should read the paper more thoroughly before passing judgement.
FOOL/WOOD:
- Generic Universe Types
Werner gave a really good talk, reminding me that ownership is awsome, and convincing me that universe types are a pretty good idea. The contribution itself (extending universe types to type parameters) seems very nice: a slight extension to generics and universes that produces an elegant system and some real benefits for the programmer. - Fine-Grained Api Evolution for Method Deprecation and Anti-Deprecation
This seemed like one of those really useful things that people have been struggling with for a long time. This solution sounds like a good one, although interface evolution seems to be one of those problems that will never be properly solved. Its part of the Scala project so should get some real world testing, I'll be interested to see how it performs in practice. The talk itself was good, and got me interested in something I'd normally just skip over. - Invited talk: Fortress and Object-Oriented Programming
It was good to hear about Fortress without all the parallelism stuff that (although important) I'm not really intersted in. The syntax thing wasn't too over-played for a change either. Instead Eric focussed on the object model and related elements. The talk was good and it was nice to see some large scale, real world, innovative language design in action (I've been following Fortress for a while now). Fortress has some interesting ideas in the object model, an (almost) class-less system with traits for reuse and some practical
looking details. Its looking like a fairly innovative and practical system, although not as radical as it sounded at first. - Variant Path Types for Scalable Extensibility
A topic close to my heart, being related to virtual classes and similar mechanisms. The authors have an approach that has classes belonging to classes as opposed to classes belonging to objects (as in Tribe and VC etc.). This approach is attractive because it is simple and does not require a dependent type system, but the loss of flexibilty and expressiveness is considerable. They go someway to addressing that with this paper, the system vastly increases the flexibilty with a simple and low overhead type system (an extension of exact types). It is impressive work, but I can't help thinking that when they work this to its logical conclusion they'll end up with something very similer to the Tribe/VC model.... - On Decidability of Nominal Subtyping with Variance
Interesting stuff again, and closely related to my work on wildcards. Andrew Kennedy gave a really good talk on decidabilty for simpler variance systems; starting off with examples that crashed the Java and Scala compilers (good for getting your attention!). The result seemed to be that these systems (pretty much what C# and Scala have) are theoretically undecidable, but are saved by unintentional tweaks in the specifications. How this crosses over to Java remains to be seen. - Formalizing and Extending C# Type Inference
Probably the best talk of the conference, Gavin Bierman had amazing energy and presentation skills. The talk basically went over his exprience in writing a type inference algorithm for C# 3.0, which to be honest sounded like a nightmare. The reasons for the complications were not obvious and it was interesting subject matter. The future work also sounds tricky... - Combining Structural Subtyping and External Dispatch
This is an idea for combining structural and nominal subtyping. The motivation was good and it looks like an interesting concept, I'd be interested to see how it works out in practice (or at least a more fleshed out theory). Although the syntax looks quite similar to standard OO languages, I think the truth is that there is a big difference arising from the typing that would affect how programs are written etc. I'll be going back and reading the paper in
detail soon. - LazyJ: Seamless Lazy Evaluation in Java
Not coming from a functional background, I don't really know if lazy evaluation is a good idea for OO languages or practical programming. But, it is an interesting concept, and if it were to be a good idea then this is how it should be done! The language was simple and yet seemed to do everything it needed to; the extensions fitted nicely into Java and the details had been thought through (even though there were a lot of ideas from the audience).
Looking forward to next year already...
Tuesday, November 07, 2006
Flattening and class tables
Brief intro: a class table is (often) used when modelling OO languages to store the details of a class. Sometimes (I can't think of a paper off the top of my head) they store just the same information as is given syntactically in a class declaration. Sometimes (as is normally done with Traits and also in the Tribe paper by Clarke et al.) they do more than this: they store a flattened view of the classes. This means a class in the class table has all the methods and fields it has access to via inheritance. A class C with method m1() that extends a class D with method m2() would be represented in the class table as a method C with methods m1() and m2(). The inheritance hierarchy has been flattened.
The (uncovered) meat of this post: flattening is cool! First off I think it makes for slightly simpler formal systems, but more importantly it gives a formal defintion of the object model of a language.
A language's object model is the set of mechanisms (inheritance, trait composition, delegation, etc.) that allow a programmer to define objects and classes and their relationships. It is very often the most interesting part of a language. However, defining a language's object model is quite difficult. We generally resort to a core language that has a minimum of expressions but the important bits of the object model (for example Featherweight Java). Indeed we require such a language to prove type safety and other similar properties. However, the class table gives us a way to describe the object model without the baggage of expressions. The flattened classes are, in a way, the interface of a class - the set of methods and fields that can be called on an object of that class. The syntax of the language corresponds to an implementation - how the programmer can define which classes have which methods and fields in a succint and useful manner. The functions that do the flattening effectively describe the object model as a translation from the syntactic object model to its semantics (the flattened object model).
That isn't explained very well, but I hope it gives a glimmer of insight into why my formal systems will have flattened class tables in the future.
The (uncovered) meat of this post: flattening is cool! First off I think it makes for slightly simpler formal systems, but more importantly it gives a formal defintion of the object model of a language.
A language's object model is the set of mechanisms (inheritance, trait composition, delegation, etc.) that allow a programmer to define objects and classes and their relationships. It is very often the most interesting part of a language. However, defining a language's object model is quite difficult. We generally resort to a core language that has a minimum of expressions but the important bits of the object model (for example Featherweight Java). Indeed we require such a language to prove type safety and other similar properties. However, the class table gives us a way to describe the object model without the baggage of expressions. The flattened classes are, in a way, the interface of a class - the set of methods and fields that can be called on an object of that class. The syntax of the language corresponds to an implementation - how the programmer can define which classes have which methods and fields in a succint and useful manner. The functions that do the flattening effectively describe the object model as a translation from the syntactic object model to its semantics (the flattened object model).
That isn't explained very well, but I hope it gives a glimmer of insight into why my formal systems will have flattened class tables in the future.
Subscribe to:
Posts (Atom)