develooper Front page | perl.bootstrap | Postings from July 2000

Re: Internals Design job description

Thread Previous | Thread Next
Dan Sugalski
July 25, 2000 08:16
Re: Internals Design job description
Message ID:
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.


--------------------------------------"it's like this"-------------------
Dan Sugalski                          even samurai                         have teddy bears and even
                                      teddy bears get drunk

Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About