Re: Next Apocalypse
Luke Palmer <[EMAIL PROTECTED]> writes:
> Also, the "standard library", however large or small that will be, will
> definitely be mutable at runtime. There'll be none of that Java "you
> can't subclass String, because we think you shouldn't" crap.
Great. But will it also be possible to add methods (or modify them)
to an existing class at runtime? You only have to look at a Smalltalk
image to see packages adding helper methods to Object and the like
(better to add a do nothing method to Object that find yourself doing
C<$thing.do_that if $thing.can('do_that')> all the time...)
Re: Macro arguments themselves
Luke Palmer <[EMAIL PROTECTED]> writes: > Alex Burr writes: >> In theory you could write one as a perl6 macro, although it would be >> more convenient if there was someway of obtaining the syntax tree of a >> previously defined function other than quoting it (unless I've missed >> that?). > > There is a large class of cool optimizations possible when you combine > notifications with storing the syntax tree at runtime, so I think it > will be possible to get the syntax tree of a previously defined > function. Probably just a method on Code objects. I'll be very disappointed if you can't get the syntax tree at runtime, though I have the feeling that it might require a compilation switch of some sort.
Re: Macro arguments themselves
Austin Hastings <[EMAIL PROTECTED]> writes: > --- Luke Palmer <[EMAIL PROTECTED]> wrote: >> Alex Burr writes: > >> > But I confidently predict that no-one with write a useful >> > partial evaluator for perl6. The language is simply too big. >> >> Then again, there are some very talented people with a lot of free >> time in the Perl community; I wouldn't count it out. > > That looked to me like a "Damian troll", hoping that DC would pop up > and say, "Oh, no. It can be done in six lines of P6. See: ..." No fair trolling someone when he's on holiday.
Re: Next Apocalypse
Piers Cawley writes:
> Luke Palmer <[EMAIL PROTECTED]> writes:
> > Also, the "standard library", however large or small that will be, will
> > definitely be mutable at runtime. There'll be none of that Java "you
> > can't subclass String, because we think you shouldn't" crap.
>
> Great. But will it also be possible to add methods (or modify them)
> to an existing class at runtime?
Parrot supports it, so I don't see why Perl wouldn't.
> You only have to look at a Smalltalk image to see packages adding
> helper methods to Object and the like (better to add a do nothing
> method to Object that find yourself doing C<$thing.do_that if
> $thing.can('do_that')> all the time...)
Agreed completely. Plus, there are some cool things you can do by
mutating methods of Object, like implementing auto-rollback variables.
(A6 C behavior).
Luke
Re: Next Apocalypse
Luke Palmer <[EMAIL PROTECTED]> writes:
> Piers Cawley writes:
>> Luke Palmer <[EMAIL PROTECTED]> writes:
>> > Also, the "standard library", however large or small that will be, will
>> > definitely be mutable at runtime. There'll be none of that Java "you
>> > can't subclass String, because we think you shouldn't" crap.
>>
>> Great. But will it also be possible to add methods (or modify them)
>> to an existing class at runtime?
>
> Parrot supports it, so I don't see why Perl wouldn't.
>
>> You only have to look at a Smalltalk image to see packages adding
>> helper methods to Object and the like (better to add a do nothing
>> method to Object that find yourself doing C<$thing.do_that if
>> $thing.can('do_that')> all the time...)
>
> Agreed completely. Plus, there are some cool things you can do by
> mutating methods of Object, like implementing auto-rollback variables.
> (A6 C behavior).
Shhh!
Re: Next Apocalypse
On Sun, 14 Sep 2003, Gordon Henriksen wrote: > On Saturday, September 13, 2003, at 11:33 , [EMAIL PROTECTED] > wrote: > > > On Sat, 13 Sep 2003, Luke Palmer wrote: > > > > Of course having a "no subclasses" tag means the compiler can change a > > method call into a direct subroutine call, but I would hope that method > > calling will be fast enough that it won't need to. > > A strategy to actually keep that optimization, and apply it to much more > code, would be that the JIT compiler could optimize for the case that > there are no known subclasses, and pessimize that only if a subclass > were later loaded. > > I think this is one of the features Leo's been on about with respect to > notifications. That's one of the reasons notifications were designed in, yes. There's a growing body of interesting work on what's essentially disposable or partially-useful optimizations. Given the dynamic nature of most of the languages we care about for parrot, throwaway optimizations make a lot of sense--we can build optimized versions of functions for the current structure, and redo them if the structure changes. This isn't entirely an easy task, however, since you can't throw away or redo a function/method/sub/whatever that you're already in somewhere in the call-chain, which means any optimizations will have to be either checked at runtime or undoable when code is in the middle of them. (Which is a decidedly non-trivial thing, and impossible in general, though possibly not in specific cases) I don't see any reason to not allow marking a class as final (though that's not hugely useful), closed (which is far more useful), or declared objects as exact types rather than subtypable. (Which is, in conjunction with closing a class, hugely useful) Which is to say that marking a class as unenhanceable and Foo variables as holding *only* objects of type Foo and not child classes, gets us a lot more than marking a class as final. (Which does the same thing, but globally, and not necessarily usefully) Dan
Re: Next Apocalypse
On 13 Sep 2003, Jonadab the Unsightly One wrote: > Dan Sugalski <[EMAIL PROTECTED]> writes: > > > Next Apocalypse is objects, and that'll take time. > > Objects are *worth* more time than a lot of the other topics. > Arguably, they're just as important as subroutines, in a modern > language. Oh, I dunno -- it's not like there's all that much to objects, but I might be a touch biased here. (I'd say they're worth more time because people get so worked up over them, not because they're particularly complex, complicated, or difficult) > Speaking of objects... are we going to have a built-in object forest, > like Inform has, where irrespective of class any given object can have > up to one parent at any given time, Multiple parent classes, yes. Parent objects, no. (Unless you consider composition of objects from multiple parent classes with each class having instance variables in the objects as multiple parent objects. In which case the answer's yes) > which can change at runtime, Well, the inheritance hierarchy for a class can change at runtime, though we'd really rather you didn't do that, so I suppose you could do it for individual objects--they'd just get a transparent singleton class that you'd mess around with from there. I think I may be missing your point. > and > be able to declare objects as starting out their lives with a given > parent object, move them at runtime from one parent to another (taking > any of their own children that they might have along with them), fetch > a list of the children or siblings of an object, and so forth? Erm I don't think so. I get the feeling that Inform had a different view of OO than we do. Dan
Re: Next Apocalypse
On Mon, 15 Sep 2003, Piers Cawley wrote: > Luke Palmer <[EMAIL PROTECTED]> writes: > > Also, the "standard library", however large or small that will be, will > > definitely be mutable at runtime. There'll be none of that Java "you > > can't subclass String, because we think you shouldn't" crap. > > Great. But will it also be possible to add methods (or modify them) > to an existing class at runtime? Unless the class has been explicitly closed, yes. Dan
Re: Next Apocalypse
[Recipients trimmed back to just the list, because it had gotten very
silly. When replying to someone who's on the list, there's no need to
copy them personally, too; they just end up with duplicates. :)]
On 2003-09-15 at 09:21:18, Piers Cawley wrote:
> Great. But will it also be possible to add methods (or modify them)
> to an existing class at runtime? You only have to look at a Smalltalk
> image to see packages adding helper methods to Object and the like
> (better to add a do nothing method to Object that find yourself doing
> C<$thing.do_that if $thing.can('do_that')> all the time...)
No need to go as far as Smalltalk; just look at Ruby (which probably took
the idea from Smalltalk, but that's beside the point. :)). There are
all sorts of libraries that do their thing by adding methods to
other classes. Not just to Object, but to specific built-in classes
such as Time, Date, Numeric, Fixnum, String, etc.
I'm not saying that this is necessarily the cleanest way to
implement an add-on; it's easy to argue that this sort of thing is
best accomplished by a static class or module method that takes an
instance of the class in question as a parameter. But it's a nice
thing to have in the toolkit.
--
Mark REED| CNN Internet Technology
1 CNN Center Rm SW0831G | [EMAIL PROTECTED]
Atlanta, GA 30348 USA | +1 404 827 4754
Re: Next Apocalypse
[EMAIL PROTECTED] (Piers Cawley) writes: > Great. But will it also be possible to add methods (or modify them) > to an existing class at runtime? You only have to look at a Smalltalk > image to see packages adding helper methods to Object and the like People get upset when CPAN authors add stuff to UNIVERSAL:: :) -- "Anyone attempting to generate random numbers by deterministic means is, of course, living in a state of sin." -- John Von Neumann
Re: Next Apocalypse
On 15 Sep 2003, Simon Cozens wrote: > [EMAIL PROTECTED] (Piers Cawley) writes: > > Great. But will it also be possible to add methods (or modify them) > > to an existing class at runtime? You only have to look at a Smalltalk > > image to see packages adding helper methods to Object and the like > > People get upset when CPAN authors add stuff to UNIVERSAL:: :) Yeah, but does that actually *stop* anyone? :-P Dan
Re: Next Apocalypse
--- Dan Sugalski <[EMAIL PROTECTED]> wrote: > On Sun, 14 Sep 2003, Gordon Henriksen wrote: > > > On Saturday, September 13, 2003, at 11:33 , [EMAIL PROTECTED] > > > wrote: > > > > > On Sat, 13 Sep 2003, Luke Palmer wrote: > > > > > > Of course having a "no subclasses" tag means the compiler can > change a > > > method call into a direct subroutine call, but I would hope that > method > > > calling will be fast enough that it won't need to. > > > > A strategy to actually keep that optimization, and apply it to much > more > > code, would be that the JIT compiler could optimize for the case > that > > there are no known subclasses, and pessimize that only if a > subclass > > were later loaded. > > > > I think this is one of the features Leo's been on about with > respect to > > notifications. > > That's one of the reasons notifications were designed in, yes. > There's a growing body of interesting work on what's essentially > disposable or partially-useful optimizations. Given the dynamic > nature of most of the languages we care about for parrot, > throwaway optimizations make a lot of > sense--we can build optimized versions of functions for the current > structure, and redo them if the structure changes. > > This isn't entirely an easy task, however, since you can't throw away > or redo a function/method/sub/whatever that you're already in > somewhere in the call-chain, which means any optimizations will > have to be either checked at runtime or undoable when code is in > the middle of them. Why is this? Given that threads are present, and given the continuation based nature of the interpreter, I assume that code blocks can be closured. So why not allocate JITed methods on the heap and manage them as first class closures, so that the stackref will hold them until the stack exits? =Austin
Re: Next Apocalypse
Simon Cozens <[EMAIL PROTECTED]> writes: > [EMAIL PROTECTED] (Piers Cawley) writes: >> Great. But will it also be possible to add methods (or modify them) >> to an existing class at runtime? You only have to look at a Smalltalk >> image to see packages adding helper methods to Object and the like > > People get upset when CPAN authors add stuff to UNIVERSAL:: :) More fool people.
Re: Next Apocalypse
Austin Hastings <[EMAIL PROTECTED]> writes: >> There's a growing body of interesting work on what's essentially >> disposable or partially-useful optimizations. Given the dynamic >> nature of most of the languages we care about for parrot, throwaway >> optimizations make a lot of sense--we can build optimized versions >> of functions for the current structure, and redo them if the >> structure changes. >> >> This isn't entirely an easy task, however, since you can't throw >> away or redo a function/method/sub/whatever that you're already in >> somewhere in the call-chain, which means any optimizations will >> have to be either checked at runtime or undoable when code is in >> the middle of them. > > Why is this? > > Given that threads are present, and given the continuation based > nature of the interpreter, I assume that code blocks can be > closured. So why not allocate JITed methods on the heap and manage > them as first class closures, so that the stackref will hold them > until the stack exits? Ooh, cunning.
Re: Macro arguments themselves
On Mon, 15 Sep 2003, Piers Cawley wrote: > Luke Palmer <[EMAIL PROTECTED]> writes: > > > Alex Burr writes: > >> In theory you could write one as a perl6 macro, although it would be > >> more convenient if there was someway of obtaining the syntax tree of a > >> previously defined function other than quoting it (unless I've missed > >> that?). > > > > There is a large class of cool optimizations possible when you combine > > notifications with storing the syntax tree at runtime, so I think it > > will be possible to get the syntax tree of a previously defined > > function. Probably just a method on Code objects. > > I'll be very disappointed if you can't get the syntax tree at > runtime, though I have the feeling that it might require a > compilation switch of some sort. The syntax tree will be stored by default, though it will be strippable from the bytecode files for space and/or paranoia reasons. Dan
Re: Next Apocalypse
On Mon, 15 Sep 2003, Austin Hastings wrote: > --- Dan Sugalski <[EMAIL PROTECTED]> wrote: > > This isn't entirely an easy task, however, since you can't throw away > > or redo a function/method/sub/whatever that you're already in > > somewhere in the call-chain, which means any optimizations will > > have to be either checked at runtime or undoable when code is in > > the middle of them. > > Why is this? Because there are some assertions that can lead the optimizer to make some fundamental assumptions, and if those assumptions get violated or redefined while you're in the middle of executing a function that makes use of those assumptions, well... Changing a function from pure to impure, adding an overloaded operator, or changing the core structure of a class can all result in code that needs regeneration. That's no big deal for code you haven't executed yet, but if you have: a = 1; b = 12; foo(); c = a + b; and a and b are both passive classes, that can get transformed to a = 1; b = 12; foo(); c = 13; but if foo changes the rules of the game (adding an overloaded + to a or b's class) then the code in that sub could be incorrect. You can, of course, stop even potential optimization once the first "I can change the rules" operation is found, but since even assignment can change the rules that's where we are right now. We'd like to get better by optimizing based on what we can see at compile time, but that's a very, very difficult thing to do. Dan
RE: Next Apocalypse
Austin Hastings wrote:
> Dan Sugalski <[EMAIL PROTECTED]> wrote:
>
> > There's a growing body of interesting work on what's essentially
> > disposable or partially-useful optimizations. Given the dynamic
> > nature of most of the languages we care about for parrot,
> > throwaway optimizations make a lot of sense--we can build optimized
> > versions of functions for the current structure, and redo them if
> > the structure changes.
> >
> > This isn't entirely an easy task, however, since you can't throw
> > away or redo a function/method/sub/whatever that you're already in
> > somewhere in the call-chain, which means any optimizations will
> > have to be either checked at runtime or undoable when code is in
> > the middle of them.
>
> Why is this?
>
> Given that threads are present, and given the continuation based
> nature of the interpreter, I assume that code blocks can be closured.
> So why not allocate JITed methods on the heap and manage them as first
> class closures, so that the stackref will hold them until the stack
> exits?
Austin,
That's a fine and dandy way to do some things, like progressive
optimization ala HotSpot. (e.g., "Oh! I've been called 10,000 times.
Maybe you should bother to run a peephole analyzer over me?") But when
an assumption made by the already-executing routine is actually
violated, it causes incorrect behavior. Here's an example:
class My::PluginBase;
method say_hi() {
# Default implementation.
print "Hello, world.\n";
}
package main;
load_plugin($filepath) { ... }
my $plugin is My::PluginBase;
$plugin = load_plugin($ARGV[0]);
$plugin.SayHi();
Now, while it would obviously seem a bad idea to you, it would be
reasonable for perl to initially optimize the method call
$plugin.say_hi() to the function call My::PluginBase::say_hi($plugin).
But when load_plugin loads a subclass of My::PluginBase from the file
specified in $ARGV[0], then that assumption is violated. Now, the
optimization has to be backed out, or the program will never call the
subclass's say_hi. Letting the GC clean up the old version of main when
the notification is received isn't enough--the existing stack frame must
actually be rewritten to use the newly-compiled version.
--
Gordon Henriksen
IT Manager
ICLUBcentral Inc.
[EMAIL PROTECTED]
Re: Next Apocalypse
On Mon, Sep 15, 2003 at 11:19:22AM -0400, Dan Sugalski wrote: > Changing a function from pure to impure, adding an overloaded operator, or > changing the core structure of a class can all result in code that needs > regeneration. That's no big deal for code you haven't executed yet, but if > you have: > > a = 1; > b = 12; > foo(); > c = a + b; > but if foo changes the rules of the game (adding an overloaded + to a or > b's class) then the code in that sub could be incorrect. > > You can, of course, stop even potential optimization once the first "I can > change the rules" operation is found, but since even assignment can change > the rules that's where we are right now. We'd like to get better by > optimizing based on what we can see at compile time, but that's a very, > very difficult thing to do. Sorry if this is a crack fuelled idea, and sorry that I don't have a patch handy to implement it, but might the following work: 0: retain the original bytecode 1: JIT the above subroutine as if a and b remain integers However, at all the "change the world" points (presumably they are de facto sequence points, and will we need to take the concept from C?) put an op in the JIT stream "check if world changed" 2: If the world has changed, jump out of the JIT code back into the bytecode interpreter at that point I fear that this would mean that the JIT wouldn't just have to insert lots of "has world changed" ops, but also an awful lot of fixup code that nearly never gets executed; code to stuff values back from processor registers into parrot registers. Then again, as this code is rarely executed and isn't speed critical (after the world has changed you're likely to be in the the switch core, which isn't slow) maybe the fixup would actually be better as densely compressed special bytecode instructions on which processor registers to save where in the parrot interpreter struct. Effectively the JIT code would have an escape hatch instruction for every debuggable position in the original parrot source. This seems expensive on space, but is the only way I can think of to implement JITting of (say) arithmetic on loops where there are calls midway which could tie/overload/ whatever the very variables used in the loops. Nicholas Clark
Re: Next Apocalypse
Nicholas Clark writes:
> On Mon, Sep 15, 2003 at 11:19:22AM -0400, Dan Sugalski wrote:
>
> > Changing a function from pure to impure, adding an overloaded operator, or
> > changing the core structure of a class can all result in code that needs
> > regeneration. That's no big deal for code you haven't executed yet, but if
> > you have:
> >
> > a = 1;
> > b = 12;
> > foo();
> > c = a + b;
>
> > but if foo changes the rules of the game (adding an overloaded + to a or
> > b's class) then the code in that sub could be incorrect.
> >
> > You can, of course, stop even potential optimization once the first "I can
> > change the rules" operation is found, but since even assignment can change
> > the rules that's where we are right now. We'd like to get better by
> > optimizing based on what we can see at compile time, but that's a very,
> > very difficult thing to do.
>
> Sorry if this is a crack fuelled idea, and sorry that I don't have a patch
> handy to implement it, but might the following work:
>
> 0: retain the original bytecode
> 1: JIT the above subroutine as if a and b remain integers
>However, at all the "change the world" points
>(presumably they are de facto sequence points, and will we need to
> take the concept from C?)
>put an op in the JIT stream "check if world changed"
> 2: If the world has changed, jump out of the JIT code back into the
>bytecode interpreter at that point
No, I think Parrot will still only JIT I&N registers. Optimization
includes way more than just JIT.
I was thinking, the compiler could emit two functions: one that works
on regular PMC's, and one that works with I registers. The latter would
then be JITted as usual, and JIT doesn't need to do anything special.
The focus here, I think, is the following problem class:
sub twenty_five() { 25 }# Optimized to inline
sub foo() {
print twenty_five; # Inlined
&twenty_five := { 36 };
print twenty_five; # Uh oh, inlined from before
}
The problem is we need to somehow un-optimize while we're running. That
is most likely a very very hard thing to do, so another solution is
probably needed.
Luke
Re: Next Apocalypse
At 3:30 PM -0600 9/15/03, Luke Palmer wrote: The problem is we need to somehow un-optimize while we're running. That is most likely a very very hard thing to do, so another solution is probably needed. It is, indeed, a very hard problem. It's solvable if you disallow several classes of optimization (basically ones that involve code motion) that make things less than optimal. You can also scatter a lot of tests for invalidations and have the notification system set the flags, though there are still code motion problems there. (Loops are particularly troublesome) -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Next Apocalypse
At 5:07 PM -0500 9/15/03, Jonathan Scott Duff wrote:
On Mon, Sep 15, 2003 at 03:30:06PM -0600, Luke Palmer wrote:
The focus here, I think, is the following problem class:
sub twenty_five() { 25 }# Optimized to inline
sub foo() {
print twenty_five; # Inlined
&twenty_five := { 36 };
print twenty_five; # Uh oh, inlined from before
}
The problem is we need to somehow un-optimize while we're running. That
is most likely a very very hard thing to do, so another solution is
probably needed.
A naive approach would be to cache the names and positions of things
that are optimized such that when one of the cached things are
modified, the optimization could be replaced with either another
optimization (as in the case above) or an instruction to execute some
other code (when we can't optimize the change).
That doesn't work in the face of code motion, reordering, or
simplification, unfortunately. :(
--
Dan
--"it's like this"---
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
Re: Next Apocalypse
On Mon, 15 Sep 2003, Dan Sugalski wrote: > > Great. But will it also be possible to add methods (or modify them) > > to an existing class at runtime? > > Unless the class has been explicitly closed, yes. That strikes me as back-to-front. The easy-to-optimise case should be the easy-to-type case; otherwise a lot of optimisation that should be possible isn't because the programmers are too inexperienced/lazy/confused to put the "closed" tags in. And it would be a better chance to warn at compile time about doing things which are potentially troublesome. But whichever way this goes, I take it we'll have warnings like: Changed method definition Class::foo may not take effect in pending initialiser at program.pl line 9. Overridden method definition MyClass::foo (new subclass of Class) may not take effect in pending function bar() in zot() at Zot.pm line 5 in other() at Other.pm line 10 at program.pl line 123.
Re: Next Apocalypse
On Mon, 2003-09-15 at 17:39, [EMAIL PROTECTED] wrote: > The easy-to-optimise case should be the easy-to-type case; otherwise a lot > of optimisation that should be possible isn't because the programmers are > too inexperienced/lazy/confused to put the "closed" tags in. 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. It's up to the user of a library to ask for that much optimization, not the library designer to consult the entrails whether anyone might ever possibly consider wanting to do something he didn't foresee. -- c
This week's summary
The Perl 6 Summary for the week ending 20030914 Welcome to this week's Perl 6 Summary. And what better way could there be of spending the morning of your 36th birthday than by reading through a bunch of old messages in a couple of mailing lists and boiling them down into a summary? Hmm... you have a point. Still, I'd just spend the day feeling slightly guilty if I did that. And I'd spend more than just the day feeling guilty if I did that, but thanks for the offer. Ahem. Continuing the thread of "So little was said we might as well get it over with and move onto the meat of the week", we'll start this week with the language list. Dispatch on context Piers Cawley wondered about doing multiple dispatch based on context and came up with a scheme which involved wrapping multimethods in a simple method that would 'reify' context so that it could be used as a multimethod argument. Luke Palmer came up with a better notation for handling class arguments to multimethods than Piers's suggestion... http://xrl.us/tgd Next Apocalypse In a transparent (and successful) attempt to generate some traffic on the language list, Jonathan Scott Duff wondered when the next Apocalypse was due. (If anyone's reading this who isn't up to speed on the Perl 6 design process, Apocalypses are Larry's design documents which describe the syntax and semantics of Perl 6. In theory they reflect the structure of *Programming Perl*, but the order may vary slightly). Dan Sugalski popped up with an answer "Not for a while". The thing is, the next Apocalypse is objects, and judging by the amount of time it took Dan to get object internals finalized (hah!) over on perl6-internals, getting objects right in Perl 6 is going to take a time. Dan thought that Damian may well get Exegesis 7, formats, out sooner. (Apocalypse 7 boiled down to the following: "See Damian"). However, Damian is currently on holiday for the first time in too long, Dan hoped (and I agree) that Damian wouldn't answer for a few weeks. There was general agreement that getting objects right deserved as much time as it needed. Luke Palmer dropped a few hints though (and made your summarizer happy by noting that 'the standard library will definitely be mutable at runtime'. http://xrl.us/tge Macro arguments themselves Alex Burr responded to a question about Macro arguments that Luke Palmer posed on the second of August (you have to love the dizzying pace of life on perl6-language). Alex suggested the partial evaluation might be handy but predicted that nobody will write a useful partial evaluator for Perl 6 as the language is 'simply too big'. The thread went on to discuss ways of getting at syntax trees from precompiled code and whether or not Alex had been serious in his prediction. http://xrl.us/tgf Meanwhile, in perl6-internals Of AST And YAL At the back end of last week, Leo Tötsch announced that he was looking into the AST (Abstract Syntax Tree) interface to Parrot by implementing parts of Yet Another Language (YAL). What's been done so far looks remarkably impressive, and Leo wondered whether to commit the changes. He noted that the work was currently totally standalone and could be distributed as a tar file instead. Michal Wallace liked it, noting that he'd like to merge in all the pirate code generation stuff. James Michal DuPont suggested using the redland RDF API, and representing the syntax trees with RDF. Not being a fan of XML (Who is?) Leo was unconvinced, worrying that he wasn't keen on having an external library in such a central place in Parrot. James pointed out that RDF isn't necessarily XML, and that the redland API wasn't quite the same as the redland library. Meanwhile, Leo put a YAL distribution up on his web page. http://xrl.us/tgg http://toetsch.at/yal/ vtable->dump The "How to do serialization right" thread rumbled on. Threads continue to make things hard. http://xrl.us/tgh Parrot Z-Machine Amir Karger continued his investigation of what would be needed to get Parrot emulating the Z-machine. Later in the week he announced that he was about to start coding. Go Amir! http://xrl.us/tgi Moving IMCC Everyone admits that languages/imcc is the wrong place for something as central to Parrot as IMCC. Leo wants to make a top-level imcc directory. Dan wants to move the current top-level C code to a core directory and move the IMCC stuff into that directory as well (without an imcc subdirectory). Quite what the Right Thing is hasn't yet been decided so IMCC remains in the wrong place. Robert Spier thought that we should wait 'til after the next Parrot release anyway. http://xrl.us/tgj Leon Brocard Speaks! Leo Tötsch noted that ther
RE: This week's summary
Piers Cawley: # Welcome to this week's Perl 6 Summary. And what better way could there # be of spending the morning of your 36th birthday than by reading # through a bunch of old messages in a couple of mailing lists and # boiling them down into a summary? Happy birthday, Piers. Enjoy *that*. ;^) --Brent Dax <[EMAIL PROTECTED]> Perl and Parrot hacker "Yeah, and my underwear is flame-retardant--that doesn't mean I'm gonna set myself on fire to prove it."
RE: This week's summary
On Mon, 15 Sep 2003, Brent Dax wrote: > Piers Cawley: > # Welcome to this week's Perl 6 Summary. And what better way could > there > # be of spending the morning of your 36th birthday than by reading > # through a bunch of old messages in a couple of mailing lists and > # boiling them down into a summary? > > Happy birthday, Piers. Enjoy *that*. ;^) Just don't tell him that he's twice your age. (Which, come to think of it, I am as well... :) Pondering an Old Fogey Moment, Dan
RE: This week's summary
Poor guy, I just told him the same thing off-list. Well I come to think of it, I guess that makes me an old fogey too. -Melvin Dan Sugalski <[EMAIL PROTECTED]> 09/15/2003 11:39 AM To: Brent Dax <[EMAIL PROTECTED]> cc: [EMAIL PROTECTED], <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]> Subject:RE: This week's summary On Mon, 15 Sep 2003, Brent Dax wrote: > Piers Cawley: > # Welcome to this week's Perl 6 Summary. And what better way could > there > # be of spending the morning of your 36th birthday than by reading > # through a bunch of old messages in a couple of mailing lists and > # boiling them down into a summary? > > Happy birthday, Piers. Enjoy *that*. ;^) Just don't tell him that he's twice your age. (Which, come to think of it, I am as well... :) Pondering an Old Fogey Moment, Dan
Re: Next Apocalypse
> Because there are some assertions that can lead the optimizer to make some > fundamental assumptions, and if those assumptions get violated or > redefined while you're in the middle of executing a function that makes > use of those assumptions, well... > > Changing a function from pure to impure, adding an overloaded operator, or > changing the core structure of a class can all result in code that needs > regeneration. That's no big deal for code you haven't executed yet, but if > you have: > > a = 1; > b = 12; > foo(); > c = a + b; > > and a and b are both passive classes, that can get transformed to > > a = 1; > b = 12; > foo(); > c = 13; > > but if foo changes the rules of the game (adding an overloaded + to a or > b's class) then the code in that sub could be incorrect. > > You can, of course, stop even potential optimization once the first "I can > change the rules" operation is found, but since even assignment can change > the rules that's where we are right now. We'd like to get better by > optimizing based on what we can see at compile time, but that's a very, > very difficult thing to do. How about retaining some "debug" info, (line number come to mind), but only at expression level?? So in your example if foo() changed the + operator, it would return into the calling_sub() at expression 4 (numbered from 1 here :-), notice that something has changed, recompile the sub, and continue processing at expression 4. Phil
Re: Next Apocalypse
On Mon, Sep 15, 2003 at 03:30:06PM -0600, Luke Palmer wrote:
> The focus here, I think, is the following problem class:
>
> sub twenty_five() { 25 }# Optimized to inline
> sub foo() {
> print twenty_five; # Inlined
> &twenty_five := { 36 };
> print twenty_five; # Uh oh, inlined from before
> }
>
> The problem is we need to somehow un-optimize while we're running. That
> is most likely a very very hard thing to do, so another solution is
> probably needed.
A naive approach would be to cache the names and positions of things
that are optimized such that when one of the cached things are
modified, the optimization could be replaced with either another
optimization (as in the case above) or an instruction to execute some
other code (when we can't optimize the change).
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
Re: Next Apocalypse
On Tue, 16 Sep 2003 [EMAIL PROTECTED] wrote: > On Mon, 15 Sep 2003, Dan Sugalski wrote: > > > Great. But will it also be possible to add methods (or modify them) > > > to an existing class at runtime? > > > > Unless the class has been explicitly closed, yes. > > That strikes me as back-to-front. > > The easy-to-optimise case should be the easy-to-type case; otherwise a lot > of optimisation that should be possible isn't because the programmers are > too inexperienced/lazy/confused to put the "closed" tags in. It would, in fact, be back-to-front if performance was the primary goal. And, while it is *a* goal, it is not *the* goal. >From Parrot's standpoint, it doesn't make much difference--once you start spitting out assembly you can be expected to be explicit, so it's a matter of what the language designer wants. While Larry's the ultimate arbiter, and I am *not* Larry, generally he favors flexibility over speed as the default, especially when you can get it at the current speed (that is, perl 5's speed) or faster. You don't lose anything over what you have now with that flexibility enabled, and if you want to restrict yourself for the extra boost, you can explicitly do that. Then again, he may also decide that things are open until the end of primary compilation, at which point things are closed--you never know... :) Dan
