On Wed, Feb 24, 2010 at 7:01 PM, Andrew Whitworth <[email protected]>wrote:
> As for the object model, you are right that Parrot's is a lot more > flexible than JVM or CLI. However, our object model is still > relatively immature and a lot of work needs to be done to really make > it as flexible and robust as it needs to be. We're always looking for > help in this regard, and if you would like to get involved to start > sharing ideas I'm sure it would be very welcome. Specifically, if you > could explain the kinds of features that your project needs, that > would help us out so we can be sure to support them. > > Right now, my project hasn't been touched in a meaningful way in a few years, and I know there's quite a bit of TLC I need to show it. I'll be happy to help any way I can from a static language theory standpoint, but until I really dig back in, I can only share theory. That being said, I would think a static language object model is going to be a little bit different then a dynamic object model. The most significant is going to be that once you have a object in a static language, calling a method or accessing attributes is a very simple lookup. This is because all of the method entry points can be calculated at compile time since you know exactly which method a class can call. The other major difference I foresee are attributes. At it's basic level, in a static language, an object is a chunk of memory that holds all of it's attributes as well as a pointer to the class metadata and vtable. So being able to support what amounts to a struct in C would be, I assume, important. > > Hopefully, this brings a little more light to my reasoning and thoughts > on > > the idea. Maybe the best way to describe my thought process right now is > an > > alternate virtual instruction and register set that shares a common > runtime > > with parrot. > > now thats an interesting idea, and I would definitely like to discuss > it more. Ideally Parrot's internals should not depend on specific > knowledge of the opset, so you could in theory supplant a new opset > and runcore on top of the runtime. > > I've started to poke around the code to try and get familiar with what is going on. It's a little hard to follow since everything seems to get a lot of preprocessing, but I'm starting to see how everything interact with each other. I have some ideas, but one question that comes to mind is what does a dynamic opset do that a static opset wouldn't and the other way around? > > I did a little research into implementing FORTRAN on parrot over the > > weekend, but decided that I don't know FORTRAN enough to do anything > quickly > > with it. However, it sure sounds like a interesting and entertaining > hack. > > I've looked at exactly the same idea too. I would definitely try to > contribute if you started a project for it. > > --Andrew Whitworth > I mentioned before that my project needs some TLC, and if I get a chance, I'm going to try and work on it. I had considered doing C instead since that's a little more familiar to me, but both require some rework to get working well. So I think FORTRAN will give me more opportunities to work on some core code, plus having the added benefit of appreciating modern languages. I am going to try and hop on IRC soon and check out that scene. -Jon Gentle
_______________________________________________ http://lists.parrot.org/mailman/listinfo/parrot-dev
