Re: Next Apocalypse
chromatic wrote: > The thinking at the last design meeting was that you'd explicitly say > "Consider this class closed; I won't muck with it in this application" > at compile time if you need the extra optimization in a particular > application. In Dylan, this is called a sealed class. It tells the compiler that it's safe to resolve method names to slot numbers at parse time, IIRC. Seems like a nice idea. A
Re: Next Apocalypse
--- Andy Wardley <[EMAIL PROTECTED]> wrote:
> chromatic wrote:
> > The thinking at the last design meeting was that you'd explicitly
> say
> > "Consider this class closed; I won't muck with it in this
> application"
> > at compile time if you need the extra optimization in a particular
> > application.
>
> In Dylan, this is called a sealed class. It tells the compiler that
> it's safe to resolve method names to slot numbers at parse time,
> IIRC. Seems like a nice idea.
Sounds like a potential keyword, or perhaps a ubiquitous method, or
both. But how to differentiate "sealed under optimization" versus
"sealed under inheritance"?
Perhaps it would be better to specify an optimizability attribute at
some level?
package Foo is optimized "all";
sub foo is optimized("!call") {...}
=Austin
Re: Next Apocalypse
On Thursday, September 18, 2003, at 07:49 AM, Austin Hastings wrote: Sounds like a potential keyword, or perhaps a ubiquitous method, or both. But how to differentiate "sealed under optimization" versus "sealed under inheritance"? I don't understand the question. The point is not for module authors to say "no one can ever extend or modify this class". It's for module users to say "I'm not extending or modifying this class". Perhaps it would be better to specify an optimizability attribute at some level? That seems possible, from the same level. -- c
Re: Next Apocalypse
--- chromatic <[EMAIL PROTECTED]> wrote: > On Thursday, September 18, 2003, at 07:49 AM, Austin Hastings wrote: > > > Sounds like a potential keyword, or perhaps a ubiquitous method, or > > both. But how to differentiate "sealed under optimization" versus > > "sealed under inheritance"? > > I don't understand the question. I want CSE and loop unrolling, say, but don't want to prevent polymorphic dispatch by declaring C -- if someone gives me a Beagle, I want to call Beagle::bark, not Dog::bark. > > The point is not for module authors to say "no one can ever extend or > > modify this class". It's for module users to say "I'm not extending > or > modifying this class". > > > Perhaps it would be better to specify an optimizability attribute > at > > some level? > > That seems possible, from the same level. Yes. =Austin
Re: Next Apocalypse
On Thursday, September 18, 2003, at 12:33 PM, Gordon Henriksen wrote: Ah, shouldn't optimization be automatic? Much preferrable to provide opt-out optimizations instead of opt-in optimizations. No. That's why I tend to opt-out of writing in C and opt-in to writing Perl. Perl (all versions) and Parrot are built around the assumption that just about anything can change at run-time. Optimizing the language for the sake of optimization at the expense of programmer convenience doesn't feel very Perlish to me. -- c
