Gaal Yahas wrote:
On Wed, Jun 08, 2005 at 12:29:33PM -0700, Larry Wall wrote:

There will certainly be an event manager for all sorts of events floating
around in Perl 6.  The main trick will be to hide this from the people
who aren't interested.  The other trick will be to actually spec it,
since up till now I've assumed that it should be specced by the people
who are actually into that sort of thing.  Looks like you're one of
them.  :-)

There's the touchy issue of what minimum compatibility level we're
promising to deliver on all platforms. This is an issue in pugs already,
where Windows GHC isn't compiled with POSIX libraries so we're stumped on
the interface for even relatively basic things, such as how (or whether) might offer O_EXCL.

Is part of the vision something like the explicit cross-platform nature
of Java? Will I be able to write Perl6 code with a certain flag that
possibly limits my choice of modules/builtins, but which promises me
identical behavior on all supported platforms?

To take a notorious example, you mentioned fork() -- if this event manager
becomes part of Perl6, does that mean we're required to emulate fork()
on win32?

Your point is well taken. Hell, even I was debating generalising even further from "fork" to "preload". As in, having Perl emit an event which says "Hey everybody, now would be a _really_ good time to load everything in, because after we $whatever, it's going to be a lot more expensive to load them in at run-time that to just load them now and benefit from copy-on-write/threads/whatever."

Sort of a "disable run-time loading and load stuff now" event.

The reason I wanted a ten lines of code solution is so that the fork()-on-win32 issue is less of a problem.

If perl itself ONLY does (in p5 term)...

Some::EventManager->fire('prefork') if $INC{"Some/"};

..then it would matter less whether or not fork ever happens on Win32.

The module would simply register with Some::EventManager for a different set of events depending on which platform it is on. as it exists for P5 today doesn't _really_ care about fork(). What it _really_ wants to know is "Should I run-time load or not? Tell me when we need to stop run-time loading".

Some::EventManager might be part of the core, but it certainly wouldn't be loaded by default. It's just a normal module that gets loaded when someone needs to use it.

I'm a minimalist. I want something to does the absolute least amount of work needed to let me know about events I simply can't find out about any other way, and that perhaps we can add additional events to later.

I certainly DON'T want something big enough and heavy enough to be able to write on top of.

Reply via email to