Re: Stuff in core (was Re: date interface, on language (was Re: perl6 requirements, on bootstrap))
On Wed, Aug 02, 2000 at 05:03:34PM +0100, Tim Bunce wrote: > Where we differ, I think, is that you expressed a desire for things like > the SystemV IPC functions to be 'known' by perl in advance. I'm saying > that we shouldn't have many, if any, pre-defined hooks to extensions. > > Let the 'use' of an 'interface definition', or something like it, bring > in what you need. Right. We don't have to be source compatable, we will be translating. So the translator would know what current keywords have been demoted to modules/subs For example when the translator sees localtime, it could know to do a C Graham.
Re: Stuff in core (was Re: date interface, on language (was Re: perl6 requirements, on bootstrap))
On Wed, Aug 02, 2000 at 11:17:56AM -0400, Dan Sugalski wrote: > At 12:11 PM 8/2/00 +0100, Tim Bunce wrote: > >Thinking about that some more, I can imagine that... > > > >a) The 'use' of an 'interface definition' could optionally just define > >stubs that will trigger the 'use' of a module to implement it when > >first called. > > > >b) An 'interface definition' could cover multiple modules > >(or, more strictly, multiple interface definitions for those modules). > >Thus a single 'use' of an 'interface definition' thingy could save > >many lines of individual 'use' statements. > > Yup, that pretty much summarizes things. I'm thinking of some sort of list > of functions (pre-munched appropriately, so the lexer has fast access to > it) with attached prototypes and shared library routine names. You use, > say, localtime and perl automagically loads in perl_localtime.so. I don't think we'd go to quite that level of granularity! But we could. Where we differ, I think, is that you expressed a desire for things like the SystemV IPC functions to be 'known' by perl in advance. I'm saying that we shouldn't have many, if any, pre-defined hooks to extensions. Let the 'use' of an 'interface definition', or something like it, bring in what you need. Tim.
Re: Stuff in core (was Re: date interface, on language (was Re: perl6 requirements, on bootstrap))
--- Dan Sugalski <[EMAIL PROTECTED]> wrote: > At 12:11 PM 8/2/00 +0100, Tim Bunce wrote: > >Thinking about that some more, I can imagine that... > > > >a) The 'use' of an 'interface definition' could > optionally just define > >stubs that will trigger the 'use' of a module to > implement it when > >first called. > > > >b) An 'interface definition' could cover multiple > modules > >(or, more strictly, multiple interface definitions > for those modules). > >Thus a single 'use' of an 'interface definition' > thingy could save > >many lines of individual 'use' statements. > > Yup, that pretty much summarizes things. I'm thinking of > some sort of list > of functions (pre-munched appropriately, so the lexer has > fast access to > it) with attached prototypes and shared library routine > names. You use, > say, localtime and perl automagically loads in > perl_localtime.so. > > I wanted to do this not so much to reduce the size of the > core (They're not > *that* much code) as to reduce the number of opcodes > being used. I really, > *really* want to trim down the opcode list. Hear, hear! However, one thing I would like to see is the removal of some ov the horrible polymorphism imposed on some of the opcodes. I understand that opcodes may need to do different things depending on their context or argument types, but there really isn't much of an excuse (that I know of, correct me if I'm wrong) for pp_readline to be supporting OP_READLINE and *OP_GLOB*! Doing so reduces code legibility, and imposes unneeded bloat (and cache misses) on verious pp functions. -- BKS __ Do You Yahoo!? Kick off your party with Yahoo! Invites. http://invites.yahoo.com/
Re: Stuff in core (was Re: date interface, on language (was Re: perl6 requirements, on bootstrap))
At 02:18 PM 8/2/00 +0100, Piers Cawley wrote: >Dan Sugalski <[EMAIL PROTECTED]> writes: > > From a language perspective, I have a scheme to allow us to yank all the > > cruft (sockets, shm, messages, localtime...) out into separate libraries, > > yet pull them in on demand without needing a use. > >a la dbmopen in perl5? A step beyond that. Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Stuff in core (was Re: date interface, on language (was Re: perl6 requirements, on bootstrap))
At 12:11 PM 8/2/00 +0100, Tim Bunce wrote: >Thinking about that some more, I can imagine that... > >a) The 'use' of an 'interface definition' could optionally just define >stubs that will trigger the 'use' of a module to implement it when >first called. > >b) An 'interface definition' could cover multiple modules >(or, more strictly, multiple interface definitions for those modules). >Thus a single 'use' of an 'interface definition' thingy could save >many lines of individual 'use' statements. Yup, that pretty much summarizes things. I'm thinking of some sort of list of functions (pre-munched appropriately, so the lexer has fast access to it) with attached prototypes and shared library routine names. You use, say, localtime and perl automagically loads in perl_localtime.so. I wanted to do this not so much to reduce the size of the core (They're not *that* much code) as to reduce the number of opcodes being used. I really, *really* want to trim down the opcode list. Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Stuff in core (was Re: date interface, on language (was Re: perl6 requirements, on bootstrap))
Dan Sugalski <[EMAIL PROTECTED]> writes: > From a language perspective, I have a scheme to allow us to yank all the > cruft (sockets, shm, messages, localtime...) out into separate libraries, > yet pull them in on demand without needing a use. a la dbmopen in perl5? -- Piers
Re: Stuff in core (was Re: date interface, on language (was Re: perl6 requirements, on bootstrap))
At 01:35 PM 8/2/00 +0900, Simon Cozens wrote: >On Wed, Aug 02, 2000 at 12:16:33AM -0400, Dan Sugalski wrote: > > From a language perspective, I have a scheme to allow us to yank all the > > cruft (sockets, shm, messages, localtime...) out into separate libraries, > > yet pull them in on demand without needing a use. > >Yep, yep. That's unquestionably the Right Thing. IMO. Would you like me to >do an RFC, or would you want more time working out the Plan? I'll take care of it in the morning. (It's half past Way Too Late here) Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Stuff in core (was Re: date interface, on language (was Re: perl6 requirements, on bootstrap))
On Wed, Aug 02, 2000 at 11:25:52AM +0100, Tim Bunce wrote: > On Wed, Aug 02, 2000 at 12:16:33AM -0400, Dan Sugalski wrote: > > > > I'd actually like to see some work on the shared memory and IPC stuff on > > the language list--it'd be nice to have them in as mostly-primitives, > > though in a more platform-neutral way. > > "mostly-primitives" sounds like a fudge. Like the hacks used to get 'lock' > into the perl5. perl6 shouldn't need 'mostly-primitives'. > > > From a language perspective, I have a scheme to allow us to yank all the > > cruft (sockets, shm, messages, localtime...) out into separate libraries, > > yet pull them in on demand without needing a use. > > Why worry about a use? > > Larry is thinking long and hard about 'interface definition' issues. > Specificaly in relation to enabling multiple versions of a module to > co-exist and, importantly, enabling multiple alternate implementations > of the same interface. > > Let's wait and see where that goes first. Thinking about that some more, I can imagine that... a) The 'use' of an 'interface definition' could optionally just define stubs that will trigger the 'use' of a module to implement it when first called. b) An 'interface definition' could cover multiple modules (or, more strictly, multiple interface definitions for those modules). Thus a single 'use' of an 'interface definition' thingy could save many lines of individual 'use' statements. Tim.
Re: Stuff in core (was Re: date interface, on language (was Re: perl6 requirements, on bootstrap))
On Wed, Aug 02, 2000 at 12:16:33AM -0400, Dan Sugalski wrote: > > I'd actually like to see some work on the shared memory and IPC stuff on > the language list--it'd be nice to have them in as mostly-primitives, > though in a more platform-neutral way. "mostly-primitives" sounds like a fudge. Like the hacks used to get 'lock' into the perl5. perl6 shouldn't need 'mostly-primitives'. > From a language perspective, I have a scheme to allow us to yank all the > cruft (sockets, shm, messages, localtime...) out into separate libraries, > yet pull them in on demand without needing a use. Why worry about a use? Larry is thinking long and hard about 'interface definition' issues. Specificaly in relation to enabling multiple versions of a module to co-exist and, importantly, enabling multiple alternate implementations of the same interface. Let's wait and see where that goes first. Tim.
Re: Stuff in core (was Re: date interface, on language (was Re: perl6 requirements, on bootstrap))
On Wed, Aug 02, 2000 at 12:16:33AM -0400, Dan Sugalski wrote:
> From a language perspective, I have a scheme to allow us to yank all the
> cruft (sockets, shm, messages, localtime...) out into separate libraries,
> yet pull them in on demand without needing a use.
Yep, yep. That's unquestionably the Right Thing. IMO. Would you like me to
do an RFC, or would you want more time working out the Plan?
--
For true believers, LORD would be K\textsc{nuth} in TeX, and
L\textsc{amport} in LaTeX. Atheists prefer \phantom{LORD}. Agnostics
may need to use the ifthen package.
- Chris Boyd, comp.text.tex
Re: Stuff in core (was Re: date interface, on language (was Re: perl6 requirements, on bootstrap))
At 01:02 PM 8/2/00 +0900, Simon Cozens wrote: >On Tue, Aug 01, 2000 at 11:37:49PM -0400, Dan Sugalski wrote: > > Right. That was my point. (The original poster wanted to pull IO out of > the > > core entirely) > >Ah. Barbarians-at-gates approach, then. Damn straight. Dump the boiling oil! :) >On the other hand, there is a lot of rubbish that *can* go out of core; >I'd like to see core being syntax-plus-essentials. System V IPC, for >instance, isn't essential. I think "essential" could be easily defined as >"stuff which is portable pretty much everywhere"; the socket stuff can go >into a separate library, for instance. I'd actually like to see some work on the shared memory and IPC stuff on the language list--it'd be nice to have them in as mostly-primitives, though in a more platform-neutral way. >This probably wouldn't affect speed too drastically because these things >could always be linked in statically a la Dynaloader. Or dynamically via magic, but that's a separate issue. (I have a Plan! But not, alas, an RFC. Yet...) >But this is now an internals issue, so the list football starts again. Don't >you just love arbitrary distinctions? Yes I do, actually. The details of implementing semi-core things (which live between a module and an opcode) will likely make all sorts of people's eyes glaze over, and that's just not useful. Which is why any followups to this will go over to the internals list. From a language perspective, I have a scheme to allow us to yank all the cruft (sockets, shm, messages, localtime...) out into separate libraries, yet pull them in on demand without needing a use. >VMS must die! I think not. "Those who do not understand VMS are doomed to re-implemement it. Badly." As the linux folks are finding, but that's a separate issue entirely. Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Stuff in core (was Re: date interface, on language (was Re: perl6 requirements, on bootstrap))
On Tue, Aug 01, 2000 at 11:37:49PM -0400, Dan Sugalski wrote: > Right. That was my point. (The original poster wanted to pull IO out of the > core entirely) Ah. Barbarians-at-gates approach, then. On the other hand, there is a lot of rubbish that *can* go out of core; I'd like to see core being syntax-plus-essentials. System V IPC, for instance, isn't essential. I think "essential" could be easily defined as "stuff which is portable pretty much everywhere"; the socket stuff can go into a separate library, for instance. This probably wouldn't affect speed too drastically because these things could always be linked in statically a la Dynaloader. But this is now an internals issue, so the list football starts again. Don't you just love arbitrary distinctions? -- VMS must die!
