On 11-07-07 10:17 AM, Lindsey Kuper wrote:
It's been suggested that we start by splitting trans into two pieces. The first would be, more or less, all the trans_X() functions where 'X' is recognizably something in the AST, and the second would be everything else: support functions, glue, LLVM type constructors, and such. Eventually, the second piece could be split further, if we want.
Sounds good. It's definitely overgrown.
Marijn has pointed out that when we do this, we'll encounter a lot of repeated code in the first piece that could be abstracted out into common utility stuff that can go into the second. That's one reason why we're doing this: to make opportunities for that kind of abstraction more obvious. Right now, it's hard to see them because trans is so big. Eventually, I could see the second piece evolving into the "LLVM combinator library" that we've often wished we had.
Factoring as we see opportunities to do so is always appropriate. Setting out to come up with a "combinator library" is a nice idea, but it's not immediately obvious to me what it *means* beyond "factoring as we see opportunities". I don't *ignore* opportunities for factoring, typically!
It's also been suggested that it would be be nice to come up with a better abstraction for block contexts and other kinds of contexts that right now have to be threaded through most of the functions in trans. I'm open to suggestions for what to do about that.
I don't think there's an easy way here. If it's some kind of implicit state in the translation module (or object), you wind up in the world of pain we were in in rustboot, where functions that generate little snippets of code *alter* "the implicit block", and you're left trying to figure out what on earth happened when it goes wrong.
I think some kind of manual threading is the best we can do. It's much more functional style (despite modifying buffers-of-LLVM-instructions; at least those buffers have independent value-identities).
We could do a better job with obj-ifying the various contexts though, and factoring helper functions to methods on them.
I think that sums up the current thinking on 'how'. Comments, questions, concerns? As for the 'when' part, since a lot of people work on trans, we'll need to pick a flag day by which work-in-progress should be in. Suggestions?
I don't think a flag day is necessary. Introduce a new file for support routines and start moving functions, one at a time. When you see redundancy, try to factor it :)
-Graydon _______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
