This week's summary
The Perl 6 Summary for the week ending 20031214
It looks like things are starting to slow down slightly as we run up to
Christmas, but the quality of discussion remains high. We'll start with
the usual trawl through perl6-internals.
Testing for null
Dan ruled on last week's discussion of testing for undef in Parrot.
We're getting a new "isnull" branch op along with a new Undef PMC. Leo
Tötsch implemented it with his usual alacrity.
http://groups.google.com/[EMAIL PROTECTED]
How many comparison ops do we need again?
One of the annoyances of writing something that's really going to be
used is that you can't get away with the equivalent of outlining your
proof on the blackboard, waving your hands and saying "The details are
left as an exercise for the interested reader". A case in point is
Parrot's array of comparison branch operators. For a while now we've
been getting by with a sparsely populated array of such beasties. This
week saw people (well, okay then, Leo, but he has the productivity of
people) doing the detail work to get the full range implemented.
http://groups.google.com/[EMAIL PROTECTED]
Incorrect scoping of constants in IMCC
Dan wasn't happy with the scoping of the ".const" directive in IMCC
(essentially constants are sub/block scoped, which makes them pretty
much useless for the things constants are normally used for). Melvin
Smith made the fix.
http://groups.google.com/[EMAIL PROTECTED]
Objects and Namespaces
Dan had mandated that the Parrot internal equivalent of the Perlish
"Package::Name" should be "Package\0Name". Nobody (Dan included) liked
the embedded nulls mandated in Dan's original spec. After some
discussion he posted a description of a new hierarchical namespace
design.
Dan pointed out that the use of hierarchical namespaces would probably
mean that the semantics (and syntax) of "find_global" would need to be
adjusted.
http://groups.google.com/[EMAIL PROTECTED]
http://groups.google.com/[EMAIL PROTECTED]
-- The New Namespace
Dan Sugalski, IMCC Bugfinder General
Dan's been writing more PIR code by hand, and is discovering
infelicities as he goes.
http://groups.google.com/[EMAIL PROTECTED]
http://groups.google.com/[EMAIL PROTECTED]
Macros, PIR and PASM
Following his bout of IMCC bug spotting, Dan announced a decision about
macros in PIR and PASM code. Essentially, Parrot's built in PIR and PASM
parsers do not need to do macros as 'macro assemblers are for people,
not compilers'. Because of this, Dan would like to see any macro
processing moved out of the core binary and into an external tool.
(Which can always be invoked via the hypothetical macro-parrot.pl).
Melvin Smith suggested that it would probably be worth extracting the
existing macro processor from imcc.l and moving it into a separate
library.
http://groups.google.com/[EMAIL PROTECTED]
Meanwhile, in perl6-language
The language list continues to fascinate (and not in the 'car crash' way
it has done on occasions in the past) with an ongoing conversation
between Larry on the one hand (seemingly designing on the hoof and
certainly doing a great deal of thinking aloud) and everyone else on the
other hand getting clarification or extrapolating to the point where
Larry has to step in and do a little bit more design.
I'm finding it hard to do a proper summary of what's going on because so
much is changing (and because so much of what seems to be set in quick
drying concrete now is so novel.)
Essentially the discussion revolves around Roles, which are sort of like
Java interfaces, sort of like mixins and nothing like either. In his
'Vocabulary' post, Luke Palmer describes a Role as 'A collection of
methods [and/or attributes] to be incorporated into a class sans
inheritance [...]. Used with "does"'. In this new world, a property
("$bar but Red" etc) is a kind of degenerate role.
At the same time though, we're getting other gems. For instance, Perl 6
is going to get something a little like "final", but instead of it being
a declaration made in a type's implementation ("This is the one, the
only Integer and you may not inherit from it or ever alter it!"), it
will become a promise made by a type's user not to attempt to monkey
with it come run time, which should set the code generator free to use
optimizations that aren't safe when everything's dynamic.
So, if you're interested in how Perl 6's OO system is going to work, now
is the time to get involved in the language list. If there's something
you've always wanted to do or something about Perl's current OO that you
love and want to retain, it's time to speak up for it. The odds are good
that you'll be able to do what you want using the mechanisms being
designed, bu
Re: This week's summary
The Perl 6 Summarizer <[EMAIL PROTECTED]> writes: > Vocabulary > If you're even vaguely interested in the workings of Perl 6's object > system, you need to read the referenced post. > > Luke Palmer, worrying about people using Object related vocabulary in > subtly inconsistent ways, posted a glossary explaining how OO > terminology is used in a Perl 6 context. Casey West wrapped it up in a > POD, which will, I hope, end up on dev.perl.org soon. > > Of course, there were a few corrections for subtleties, a few rethinks > of the design so far, and general gratitude for at least having a > baseline document that people could refer to. > > http://groups.google.com/[EMAIL PROTECTED] This should, of course, read: http://groups.google.com/[EMAIL PROTECTED] Apologies for the confusion. -- Beware the Perl 6 early morning joggers -- Allison Randal
Re: This week's summary
Piers Cawley writes: > The Perl 6 Summarizer <[EMAIL PROTECTED]> writes: > > Vocabulary > > If you're even vaguely interested in the workings of Perl 6's object > > system, you need to read the referenced post. > > > > Luke Palmer, worrying about people using Object related vocabulary in > > subtly inconsistent ways, posted a glossary explaining how OO > > terminology is used in a Perl 6 context. Casey West wrapped it up in a > > POD, which will, I hope, end up on dev.perl.org soon. > > > > Of course, there were a few corrections for subtleties, a few rethinks > > of the design so far, and general gratitude for at least having a > > baseline document that people could refer to. > > > > http://groups.google.com/[EMAIL PROTECTED] > > This should, of course, read: > > http://groups.google.com/[EMAIL PROTECTED] Or even: http://groups.google.com/[EMAIL PROTECTED] :-p Luke
Re: Object Order of Precedence (Was: Vocabulary)
Jonathan Lang writes: > Larry Wall wrote: > > Well, nothing much really supercedes the class. Even traits have > > to be requested by the class, and if you have an entirely different > > metaclass, it's probably declared with a different keyword than > > C. (But sure, multiple traits will have to applied in order > > of declaration, and I don't doubt there will be ordering dependencies.) > > My apologies; I'm apparently a bit weak on my object-oriented terminology. > I'm not quite sure what's being meant here by "metaclass", other than a > vague concept that it's somehow similar to the relationship between logic > and metalogic. Also, I was under the impression that the writers of the > "tTraits" paper that you referred us to disliked "mixins" largely because > they _did_ use an order-of-precedence conflict resolution scheme; surely > their concerns would apply equally well to what we're calling traits? I think metaclass is referring to the thing that knows how to associate attributes with their corresponding objects, how do dispatch methods to their corresponding code objects, and whatnot. > > I think the normative way to supercede a class should be to > > subclass it. That's what OO is supposed to be all about, after all. > > If we can keep that orthogonal to role composition, we stand a good > > chance of being able to do a lot of what AOP claims to do without > > the downsides of AOP's own slatheron approach. Or more precisely, > > we can resort to AOP-style wrappers where we really need them, and > > avoid them where we don't. > > As I don't know what AOP is, this is largely lost on me. But I'm all for > keeping various aspects of perl orthogonal to each other if it's > reasonable to do so. Likewise, my main concern isn't so much "how to > supercede a class" as it is "how to keep a class from superceding a role > that it doesn't know about". C does a pretty good job of introducing one to AOP, at least the extent to which Perl is capable of it (which is quite a lot). > > I'm probably spouting nonsense. I just hope it's good-sounding > > nonsense... > > More importantly, it seems to be _useful_ nonsense. I just hope that _my_ > nonsense is more useful than it is annoying. :) Luke
Re: Vocabulary
Michael Lazzaro writes: > > On Sunday, December 14, 2003, at 06:14 PM, Larry Wall wrote: > >But the agreement could be implied by silence. If, by the time the > >entire program is parsed, nobody has said they want to extend an > >interface, then the interface can be considered closed. In other > >words, if you think you *might* want to extend an interface at run > >time, you'd better say so at compile time somehow. I think that's > >about as far as we can push it in the "final" direction. > > That seems a very fair rule, especially if it adds a smidge more speed. > Runtime extension will likely be very unusual Unless you're me. Or Damian. Or a fair number of other programmers who like to dive into the Perl Dark Side on a regular basis. > -- requiring it to be explicit seems reasonable. It seems so. Knowing Larry, I'm sure this is an ungrounded fear, but I definitely want to be able to declare in a module "I'm going to be screwing with stuff; keep out of my way," so that I don't impose any awkward declarations on my module users. If that request can be made more explicit in the cases where that's possible, great, but the general declaration should be available. Luke > > >I'm probably spouting nonsense. I just hope it's good-sounding > >nonsense... > > It's beyond good-sounding, it's frickin' awesome. > > MikeL >
Re: Vocabulary
On Tue, Dec 16, 2003 at 07:05:19AM -0700, Luke Palmer wrote: : Michael Lazzaro writes: : > : > On Sunday, December 14, 2003, at 06:14 PM, Larry Wall wrote: : > >But the agreement could be implied by silence. If, by the time the : > >entire program is parsed, nobody has said they want to extend an : > >interface, then the interface can be considered closed. In other : > >words, if you think you *might* want to extend an interface at run : > >time, you'd better say so at compile time somehow. I think that's : > >about as far as we can push it in the "final" direction. : > : > That seems a very fair rule, especially if it adds a smidge more speed. : > Runtime extension will likely be very unusual : : Unless you're me. Or Damian. Or a fair number of other programmers who : like to dive into the Perl Dark Side on a regular basis. : : > -- requiring it to be explicit seems reasonable. : : It seems so. Knowing Larry, I'm sure this is an ungrounded fear, but I : definitely want to be able to declare in a module "I'm going to be : screwing with stuff; keep out of my way," so that I don't impose any : awkward declarations on my module users. If that request can be made : more explicit in the cases where that's possible, great, but the general : declaration should be available. Okay, we'll call the general declaration: use $& or some such. :-) Seriously, I hope we can provide a framework in which you can screw around to your heart's content while modules are being compiled, and to a lesser extent after compilation. But we'll never get to a programming-in-the-large model if we can't limit most of the screwing around to the lexical scope currently being compiled, or at least to a known subset of the code. Modules that turn off optimization for all other modules are going to be about as popular as $&. So the general declaration should probably be something easy to see like: use STRANGE_SEMANTICS_THAT_SLOW_EVERYONE_DOWN; That will encourage people to be more specific about what they want to pessimize. Certainly, your fancy module should be encouraged to declare these things on behalf of its users if it can. I'm not suggesting that Lukian or Damianly modules force such declarations onto the users unless it's impossible for the module to know. And it seems to me that with sufficient control over the user's grammar, you can often get that information into your own fancy module somehow. Might take a few macros though, or analysis of the user's code at CHECK time (or maybe just before). And in general, it's probably not necessary to declare all the new interfaces, but only those interfaces known at compile time that want to stay open. Any interfaces added at run time are probably assumed to be open. So in some cases you might find yourself deriving a single open class at compile time from which you can derive other open classes later. But still, the principle remains that original declarer of an interface doesn't know in general whether its users are going to want to extend it. At some point the users have to take responsibility if they want their code to run fast. Or run at all... So we need to make it very easy for users to provide this kind of information when it's needed. Larry
Re: Vocabulary
On Tuesday, December 16, 2003, at 09:07 AM, Larry Wall wrote:
Seriously, I hope we can provide a framework in which you can screw
around to your heart's content while modules are being compiled,
and to a lesser extent after compilation. But we'll never get to a
programming-in-the-large model if we can't limit most of the screwing
around to the lexical scope currently being compiled, or at least
to a known subset of the code. Modules that turn off optimization
for all other modules are going to be about as popular as $&. So
the general declaration should probably be something easy to see like:
use STRANGE_SEMANTICS_THAT_SLOW_EVERYONE_DOWN;
That will encourage people to be more specific about what they want
to pessimize. Certainly, your fancy module should be encouraged
to declare these things on behalf of its users if it can. I'm not
suggesting that Lukian or Damianly modules force such declarations onto
the users unless it's impossible for the module to know. And it seems
to me that with sufficient control over the user's grammar, you can
often get that information into your own fancy module somehow.
Might take a few macros though, or analysis of the user's code at
CHECK time (or maybe just before).
And in general, it's probably not necessary to declare all the new
interfaces, but only those interfaces known at compile time that want
to stay open. Any interfaces added at run time are probably assumed
to be open. So in some cases you might find yourself deriving a
single open class at compile time from which you can derive other
open classes later.
Exactly, assuming I correctly understand. :-)
My own first instinct would be that the run-time extensibility of a
particular interface/class would simply be a trait attached to that
class... by default, classes don't get it. By limiting or not limiting
the amount of runtime screwin' around you can do with the class, it is
therefore able to control the level of optimization that calls to
methods, etc., are given -- but specific to that particular
interface/class, not to the module and certainly not to the program in
general.
class Wombat is runtime_extensible { ... };
So everything is closed, except the specific classes which are not.
Even when you are (to use an example from my own code) making runtime
subclasses on-the-fly, you're almost always starting from some common
base class. (And 'almost' is probably an unneeded qualifier, there.
As is 'probably'.)
As far as users of your class being able to specify that they want
something runtime-extensible, when your original module didn't call for
it, I don't see that as a problem, if they can just add the trait to
your class shortly after they C the package containing it, if such
things are possible -- or, for that matter, simply subclass your
original into a runtime_extensible class:
class Wombat { ... }; # Not runtime extensible
class MyWombat is Wombat
is runtime_extensible { ... }; # Runtime extensible
Now, it might be that declaring MyWombat to be runtime_extensible
actually silently disables some compile-time optimizations not only for
it, but for all its superclasses/roles/etc., depending on how
intelligent and far reaching those optimizations may be. Not sure.
Still, the fact that you are _requesting_ that happen is specific to
the particular class that needs it -- and should be associated with
that class, such that if that class later falls into disuse, the
optimizations silently reappear.
(At first glance, I am less sure of the need to have similar
functionality for entire modules, as opposed to classes, but perhaps
someone out there can come up with an example.)
MikeL
Re: Vocabulary
On Tue, 2003-12-16 at 12:06, Michael Lazzaro wrote: > My own first instinct would be that the run-time extensibility of a > particular interface/class would simply be a trait attached to that > class... by default, classes don't get it. That doesn't sound very dynamic. At the post-OSCON design meetings, Larry suggested that the user of a class or library could say "I'm not going to muck about with this at runtime and any extra optimization would be nice, so go ahead and do whatever you can do it." Putting that opportunity on the user has several advantages: - the library writer isn't responsible for getting the library completely perfect, because library users can make changes if necessary - the common case (run-time extension and manipulation) needs less code (that is, you don't have to say "Mother, may I take advantage of the features of the dynamic language I'm supposed to be?" to take advantage of those features) - the user of the library can choose specific optimizations when and where he needs them -- c
RE: Vocabulary
finally by default? None for me; thanks, though. -- Gordon Henriksen IT Manager ICLUBcentral Inc. [EMAIL PROTECTED]
Re: Vocabulary
On Tue, Dec 16, 2003 at 12:06:46PM -0800, Michael Lazzaro wrote:
> As far as users of your class being able to specify that they want
> something runtime-extensible, when your original module didn't call for
> it, I don't see that as a problem, if they can just add the trait to
> your class shortly after they C the package containing it, if such
> things are possible
I think it kind of hinges on the ability to undo optimizations.
Just to restate things a bit to make sure I understand ... when perl
compiles a class, it assumes it's closed and accordingly applies
whatever optimizations it can unless it sees that the programmer
explicitly asked otherwise. Those classes that are "closed" can be
opened at run-time and the user pays the penalty then when they try to
modify the class (and pays twice because of the compile-time
optimizations that perl applied and are now undoing).
But does everybody pay some penalty because of it? I hope not.
Presumably we keep the source around for a reparse if necessary
anyway? Or perhaps we have "unoptimized" bytecode laying around ready
to be switched in for the optimized bytecode when necessary.
> class Wombat { ... }; # Not runtime extensible
> class MyWombat is Wombat
> is runtime_extensible { ... }; # Runtime extensible
>
> Now, it might be that declaring MyWombat to be runtime_extensible
> actually silently disables some compile-time optimizations not only for
> it, but for all its superclasses/roles/etc., depending on how
> intelligent and far reaching those optimizations may be.
I hope not.
> Not sure.
> Still, the fact that you are _requesting_ that happen is specific to
> the particular class that needs it -- and should be associated with
> that class,
Yep.
> such that if that class later falls into disuse, the
> optimizations silently reappear.
That would be *some* trick!
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
Re: Vocabulary
According to Jonathan Scott Duff: > Those classes that are "closed" can be opened at run-time and the > user pays the penalty then when they try to modify the class [...] The optimization that can be reversed is not the true optimization. -- Chip Salzenberg - a.k.a. - <[EMAIL PROTECTED]> "I wanted to play hopscotch with the impenetrable mystery of existence, but he stepped in a wormhole and had to go in early." // MST3K
Re: Vocabulary
Chip Salzenberg writes:
> According to Jonathan Scott Duff:
> > Those classes that are "closed" can be opened at run-time and the
> > user pays the penalty then when they try to modify the class [...]
>
> The optimization that can be reversed is not the true optimization.
While poetic and concise, I think that statement needs to be driven into
the ground a bit more.
Over on p6i, I think we're basically in agreement that the ability to
undo optimizations is nothing we can count on. Unless there is a
breakthrough in computer science any time soon, this while loop:
sub one() { 1 };
sub go() {
my $x = 0;
while $x++ < one { # loop optimized away
%main::{'&one'} = sub { 10 };
print "Boing!\n";
}
}
Is not something that can can be re-inserted when we find out one() has
changed. While it's possible to make it so go() is unoptimized on the
next call, that's not good enough. We expect changes to act instantly.
But if you separate parsing and code-generation time, you can make
optimizations earlier based on declarations later, which is just fine.
It allows you to say:
use PresumptuousModule << SomeClass >>;
class SomeClass is extensible { };
Then even if the writer of PresumptuousModule thinks you'll be better
off with the optimization, you can tell him otherwise. But you have to
do it before the code is generated.
Luke
Re: Vocabulary
Larry Wall writes: > On Tue, Dec 16, 2003 at 07:05:19AM -0700, Luke Palmer wrote: > : Michael Lazzaro writes: > : > > : > On Sunday, December 14, 2003, at 06:14 PM, Larry Wall wrote: > : > >But the agreement could be implied by silence. If, by the time the > : > >entire program is parsed, nobody has said they want to extend an > : > >interface, then the interface can be considered closed. In other > : > >words, if you think you *might* want to extend an interface at run > : > >time, you'd better say so at compile time somehow. I think that's > : > >about as far as we can push it in the "final" direction. > : > > : > That seems a very fair rule, especially if it adds a smidge more speed. > : > Runtime extension will likely be very unusual > : > : Unless you're me. Or Damian. Or a fair number of other programmers who > : like to dive into the Perl Dark Side on a regular basis. > : > : > -- requiring it to be explicit seems reasonable. > : > : It seems so. Knowing Larry, I'm sure this is an ungrounded fear, but I > : definitely want to be able to declare in a module "I'm going to be > : screwing with stuff; keep out of my way," so that I don't impose any > : awkward declarations on my module users. If that request can be made > : more explicit in the cases where that's possible, great, but the general > : declaration should be available. > > Okay, we'll call the general declaration: > > use $& > > or some such. :-) > > Seriously, I hope we can provide a framework in which you can screw > around to your heart's content while modules are being compiled, > and to a lesser extent after compilation. But we'll never get to a > programming-in-the-large model if we can't limit most of the screwing > around to the lexical scope currently being compiled, or at least > to a known subset of the code. Modules that turn off optimization > for all other modules are going to be about as popular as $&. So > the general declaration should probably be something easy to see like: > > use STRANGE_SEMANTICS_THAT_SLOW_EVERYONE_DOWN; Hmm, I guess that's true. A module author shouldn't have the the freedom to say that his classes are completely untouchable, because he doesn't know what you're going to be doing with them. But correspondingly, I guess, a module author shouldn't have the freedom to slow everybody down because he was lazy about figuring out what needed to be declared "open". But Perl hinges on laziness, doesn't it? Eh, I trust that Perl 6 will make it easy to figure that out in most cases. I was coming from the perspective that 90% of my projects don't need speed; but I can say no such thing on account of my users. And what about that un-accounted-for 10%? Perhaps the real detterent to using such a thing would be making it generate a warning when -w is on. You get the peer pressure thing; people frown upon you when you use the pragma unwisely. So, yeah, I agree with you now. Luke
Re: Vocabulary
On Tuesday, December 16, 2003, at 12:20 PM, Gordon Henriksen wrote: finally by default? None for me; thanks, though. I don't think so; we're just talking about whether you can extend a class at _runtime_, not _compiletime_. Whether or not Perl can have some degree of confidence that, once a program is compiled, it won't have to assume the worst-case possibility of runtime alteration of every class, upon every single method call, just in case you've screwed with something. They still aren't "final" classes, in that you can subclass them at will. You just can't subclass them _runtime_, via C, unless you've specifically marked that you want to allow that for that _specific_ class. As Larry hypothesized: The other reason for "final" is to make it easy for the compiler to optimize. That's also problematical. As implemented by Java, it's a premature optimization. The point at which you'd like to know this sort of thing is just after parsing the entire program and just before code generation. And the promises have to come from the users of interfaces, not the providers, because the providers don't know how their services are going to be used. Methods, roles, and classes may never declare themselves final. They may be declared final only by the agreement of all their users. But the agreement could be implied by silence. If, by the time the entire program is parsed, nobody has said they want to extend an interface, then the interface can be considered closed. In other words, if you think you *might* want to extend an interface at run time, you'd better say so at compile time somehow. I think that's about as far as we can push it in the "final" direction. -and- Actually, I think making people declare what they want to extend might actually provide a nice little safety mechanism for what can be modified by the eval and what can't. It's not exactly Safe, but it's a little safer. -and- Seriously, I hope we can provide a framework in which you can screw around to your heart's content while modules are being compiled, and to a lesser extent after compilation. But we'll never get to a programming-in-the-large model if we can't limit most of the screwing around to the lexical scope currently being compiled, or at least to a known subset of the code. So, if I may interpret that; it might not be so bad to have to declare whether or not you were going to extend/alter a class at runtime, in order that Perl could optimize what it knows at compile-time for the 99.5% of the classes that you wouldn't be doing that for. MikeL
Re: Vocabulary
On Tuesday, December 16, 2003, at 03:00 PM, Luke Palmer wrote: But Perl hinges on laziness, doesn't it? Eh, I trust that Perl 6 will make it easy to figure that out in most cases. I was coming from the perspective that 90% of my projects don't need speed; but I can say no such thing on account of my users. And what about that un-accounted-for 10%? As someone who has 90% of their projects relying very critically on speed, and who has had to battle a number of clients' IT departments over the years in defense of said speed compared to other popular languages which, out of spite, I will not name, I beg you to never speak or think that sentence again. ;-) MikeL
Re: Vocabulary
According to Michael Lazzaro: > As someone who has 90% of their projects relying very critically on > speed ... an anecdote ... > and who has had to battle a number of clients' IT departments > over the years in defense of said speed compared to other popular > languages which, out of spite, I will not name, ... and a public relations issue. Let us not confuse them. -- Chip Salzenberg - a.k.a. - <[EMAIL PROTECTED]> "I wanted to play hopscotch with the impenetrable mystery of existence, but he stepped in a wormhole and had to go in early." // MST3K
Re: Vocabulary
Larry Wall <[EMAIL PROTECTED]> writes: > On Tue, Dec 16, 2003 at 07:05:19AM -0700, Luke Palmer wrote: > : Michael Lazzaro writes: > : > > : > On Sunday, December 14, 2003, at 06:14 PM, Larry Wall wrote: > : > >But the agreement could be implied by silence. If, by the time the > : > >entire program is parsed, nobody has said they want to extend an > : > >interface, then the interface can be considered closed. In other > : > >words, if you think you *might* want to extend an interface at run > : > >time, you'd better say so at compile time somehow. I think that's > : > >about as far as we can push it in the "final" direction. > : > > : > That seems a very fair rule, especially if it adds a smidge more speed. > : > Runtime extension will likely be very unusual > : > : Unless you're me. Or Damian. Or a fair number of other programmers who > : like to dive into the Perl Dark Side on a regular basis. > : > : > -- requiring it to be explicit seems reasonable. > : > : It seems so. Knowing Larry, I'm sure this is an ungrounded fear, but I > : definitely want to be able to declare in a module "I'm going to be > : screwing with stuff; keep out of my way," so that I don't impose any > : awkward declarations on my module users. If that request can be made > : more explicit in the cases where that's possible, great, but the general > : declaration should be available. > > Okay, we'll call the general declaration: > > use $& > > or some such. :-) > > Seriously, I hope we can provide a framework in which you can screw > around to your heart's content while modules are being compiled, > and to a lesser extent after compilation. But we'll never get to a > programming-in-the-large model if we can't limit most of the screwing > around to the lexical scope currently being compiled, or at least > to a known subset of the code. Modules that turn off optimization > for all other modules are going to be about as popular as $&. Or the debugger. Or a refactoring tool. Or a Class browser... > So the general declaration should probably be something easy to see > like: > > use STRANGE_SEMANTICS_THAT_SLOW_EVERYONE_DOWN; No question about that. > That will encourage people to be more specific about what they want > to pessimize. Certainly, your fancy module should be encouraged > to declare these things on behalf of its users if it can. I'm not > suggesting that Lukian or Damianly modules force such declarations onto > the users unless it's impossible for the module to know. And it seems > to me that with sufficient control over the user's grammar, you can > often get that information into your own fancy module somehow. > Might take a few macros though, or analysis of the user's code at > CHECK time (or maybe just before). When you say CHECK time, do you mean there'll be a CHECK phase for code that gets required at run time? -- Beware the Perl 6 early morning joggers -- Allison Randal
Re: Vocabulary
Michael Lazzaro <[EMAIL PROTECTED]> writes: > On Tuesday, December 16, 2003, at 12:20 PM, Gordon Henriksen wrote: >> finally by default? None for me; thanks, though. > > I don't think so; we're just talking about whether you can extend a > class at _runtime_, not _compiletime_. Whether or not Perl can have > some degree of confidence that, once a program is compiled, it won't > have to assume the worst-case possibility of runtime alteration of > every class, upon every single method call, just in case you've > screwed with something. There's still a hell of a lot of stuff you can do with 'cached' optimization that can be thrown away if anything changes. What the 'final' type declarations would do is allow the compiler to throw away the unoptimized paths and the checks for dynamic changes that mean the optimization has to be thrown out and started again. -- Beware the Perl 6 early morning joggers -- Allison Randal
Re: Vocabulary
On Tuesday, December 16, 2003, at 04:01 PM, Chip Salzenberg wrote: According to Michael Lazzaro: As someone who has 90% of their projects relying very critically on speed ... an anecdote ... Yes. and who has had to battle a number of clients' IT departments over the years in defense of said speed compared to other popular languages which, out of spite, I will not name, ... and a public relations issue. Yes, again. Let us not confuse them. I'm not sure I understand which part of that is in conflict. Is it the premise that some people use Perl in environments in which speed is an issue, the premise that Perl5 has a public relations issue about being inappropriate for speed-critical environments, or the conflation that someone that works in speed-critical environments, and wishes to use Perl, is going to run up against the public-relations issue? MikeL
Re: Vocabulary
On Wed, Dec 17, 2003 at 12:15:04AM +, Piers Cawley wrote: > There's still a hell of a lot of stuff you can do with 'cached' > optimization that can be thrown away if anything changes. What the > 'final' type declarations would do is allow the compiler to throw away > the unoptimized paths and the checks for dynamic changes that mean the > optimization has to be thrown out and started again. As Luke pointed out in an earlier message, you can encounter grave difficulty (i.e. halting problem unsolvable sort of difficulty) in trying to unoptimize a piece of code that is in the middle of being executed. Just about any subroutine call might (but almost always won't :-) happen to execute code that makes the current subroutine have to revert to unoptimized (or differently optimized) form. When that subroutine call returns after such a rare occurrence, it can't return to the unoptimized code (because there could be missing context because the calling routine got this far using the optimized code and may have skipped stuff that is (now) necessary) and it can't return to the old code (because its optimization might now be wrong).
Re: Vocabulary
According to Michael Lazzaro:
> On Tuesday, December 16, 2003, at 04:01 PM, Chip Salzenberg wrote:
> >... an anecdote ...
> >... and a public relations issue.
> >Let us not confuse them.
>
> I'm not sure I understand which part of that is in conflict.
Speed is for users. PR is for non-users.
You want speed? OK, we can talk about the actual speed you actually
need based on your actual usage patterns. But from a design
perspective you're a collection of anecote, not a user base; so your
usage patterns may be irrelevant to Perl in the big picture.
In a separate matter, non-users may perceive Perl {5,6} to be too slow
for their needs; more to the point, they may *assume* that it is too
slow without research and testing. That assumption is a public
relations issue -- ironically, one which is fundamentally disconnected
from the question of Perl's _actual_ efficiency.
--
Chip Salzenberg - a.k.a. - <[EMAIL PROTECTED]>
"I wanted to play hopscotch with the impenetrable mystery of existence,
but he stepped in a wormhole and had to go in early." // MST3K
Re: Vocabulary
On Wed, Dec 17, 2003 at 12:11:59AM +, Piers Cawley wrote: : When you say CHECK time, do you mean there'll be a CHECK phase for : code that gets required at run time? Dunno about that. When I say CHECK time I'm primarily referring to the end of the main compilation. Perl 5 appears to ignore CHECK blocks declared at run time, so in the absence of other considerations I suspect Perl 6 might do the same. Larry
Re: Vocabulary
On Tuesday, December 16, 2003, at 05:36 PM, Chip Salzenberg wrote:
Speed is for users. PR is for non-users.
You want speed? OK, we can talk about the actual speed you actually
need based on your actual usage patterns. But from a design
perspective you're a collection of anecote, not a user base; so your
usage patterns may be irrelevant to Perl in the big picture.
In a separate matter, non-users may perceive Perl {5,6} to be too slow
for their needs; more to the point, they may *assume* that it is too
slow without research and testing. That assumption is a public
relations issue -- ironically, one which is fundamentally disconnected
from the question of Perl's _actual_ efficiency.
Well, just for clarification; in my anecdotal case (server-side web
applications), the speed I actually need is "as much as I can get", and
"all the time". Every N cycles I save represents an increase in peak
traffic capabilities per server, which is, from a marketing
perspective, essential.
If a potential client company needs to decide between two server-based
products -- my Perl based product, and a competing Java-based one --
one of the first questions they ask is "how much traffic can it handle
for X dollars of hardware and software". I don't have to win that
benchmark, but I have to be close. Otherwise I don't get to play.
I agree, it is frequently the case that the question of speed is made
critical by people who most assuredly do not need it. But they still
decide that way, and I have found that asserting to them that speed is
not important has been... well, less than effective. I do not doubt
that P6 will be much more competitive, speed-wise, than P5 -- but if it
could actually _win_ a few benchmarks, it would turn my company's use
of Perl from a PR problem to a PR advantage.
your usage patterns may be irrelevant to Perl in the big picture.
The thought has crossed my mind repeatedly, believe me.
MikeL
Re: Vocabulary
Michael Lazzaro writes: > I agree, it is frequently the case that the question of speed is made > critical by people who most assuredly do not need it. But they still > decide that way, and I have found that asserting to them that speed is > not important has been... well, less than effective. I do not doubt > that P6 will be much more competitive, speed-wise, than P5 -- but if it > could actually _win_ a few benchmarks, it would turn my company's use > of Perl from a PR problem to a PR advantage. In the presence of parrot's JIT, competing should be no problem. I'm not entirely sure Perl 6 will be faster than Perl 5 on the average. But the difference is that Perl 6 will allow you to make fast code where you need it. For instance (and the main one, probably), using native (lowercase) types allows you to JIT, and using JIT is just... well, you have to see it for yourself. Amazing. But since, as I've said, I don't do speed-critical work, I won't be usually using lowercase types. And that trades me flexibility for speed. And from what I've seen of Java, if you need speed, hand-optimizing your inner loop to parrot assembly should blow Java out of the water. Without needing a C compiler (I despise XS). Luke > >your usage patterns may be irrelevant to Perl in the big picture. > > The thought has crossed my mind repeatedly, believe me. > > MikeL >
Re: Vocabulary
Larry Wall wrote in perl.perl6.language : > On Wed, Dec 17, 2003 at 12:11:59AM +, Piers Cawley wrote: >: When you say CHECK time, do you mean there'll be a CHECK phase for >: code that gets required at run time? > > Dunno about that. When I say CHECK time I'm primarily referring > to the end of the main compilation. Perl 5 appears to ignore CHECK > blocks declared at run time, so in the absence of other considerations > I suspect Perl 6 might do the same. This has proven to be inconvenient except for a few specialized usages, such as the B::/O compiler framework. There's a need (more or less) for special blocks that can be run at the end of the compilation phase of any arbitrary compilation unit.
Re: This week's summary
Luke Palmer <[EMAIL PROTECTED]> writes: > Piers Cawley writes: >> The Perl 6 Summarizer <[EMAIL PROTECTED]> writes: >> > >> > http://groups.google.com/[EMAIL PROTECTED] >> >> This should, of course, read: >> >> http://groups.google.com/[EMAIL PROTECTED] > > Or even: > > http://groups.google.com/[EMAIL PROTECTED] We have a winner!
