Re: Internals Design job description
[email protected] (Dan Sugalski)
| Newsgroups | perl.bootstrap |
|---|---|
| Message-ID | <[email protected]> |
At 03:50 PM 7/25/00 +0100, Tim Bunce wrote: >On Tue, Jul 25, 2000 at 10:23:24AM -0400, Dan Sugalski wrote: > > This is due soon, so before I forget: > > > > The Internals Design job description > > ==================================== > > > > The whole point of this position is to be responsible for, though not > > necessarily design (as we have lots of clever people), the internal > > interfaces perl presents. The primary target is for programs that embed > > perl, extensions that perl embeds, and (to a lesser extent) embedded > > systems. The design of the internal data structures and code flow is a > > secondary responsibility, but it's more an advisory position there, as the > > internals will tend to flow naturally from the language design and > > interfacing requirements. In the event that perl gets partitioned (into > > lexer/parser, optmizer, and execution engine, say) this position's > > responsible for the interfaces between those partitions as well. > > > > In other words, my job is to make sure perl talks nicely and easily with > > the rest of the world, and to itself. The code behind the conversation is > > someone else's responsibility. > >Probably a nit-pick... that sounds more like "Internals *API* Design" >rather than "Internals Design" to me. That was the original intent--I think the position's mildly misnamed. (It was supposed to be the back-end analog to the language design, which is arguably the front end API design position) >Somewhat related to that... I'm a little concerned that you have >"internal data structures and code flow" as a "secondary responsibility". >While I see your point, to some extent, I'd rather they were considered >together. I don't see any value in making a primary/secondary >distinction here. Ah. It was partially because I'm comfortable saying "That is *not* the interface we're going to present to programs that embed us", while I'm not nearly as comfortable doing the same thing for, say, the structures underlying a scalar or the optree or whatever. On the other hand, this is as much a committee chair position as anything else, so as long as someone knows what they're doing it's not an issue. I'll revise the job description after another cup of coffee and get it out for comment. Dan --------------------------------------"it's like this"------------------- Dan Sugalski even samurai [email protected] have teddy bears and even teddy bears get drunk