Re: Next Apocalypse

2003-09-18 Thread Andy Wardley 
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

2003-09-18 Thread Austin Hastings 

--- 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

2003-09-18 Thread chromatic 
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

2003-09-18 Thread Austin Hastings 

--- 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 Cmy Dog $spot is sealed; -- 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

2003-09-18 Thread chromatic 
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