Austin Hastings [EMAIL PROTECTED] writes:
Of course, how hard can it be to implement the .parent property?
.parent and also .children, plus .moveto and .remove (which doesn't
actually destroy the object but sets its parent to undef, basically,
cleaning up the .children property of its parent),
On Tue, 29 Jun 2004, Jonadab the Unsightly One wrote:
Austin Hastings [EMAIL PROTECTED] writes:
Of course, how hard can it be to implement the .parent property?
.parent and also .children, plus .moveto and .remove (which doesn't
actually destroy the object but sets its parent to undef,
Dan Sugalski [EMAIL PROTECTED] writes:
Sure, no big deal. Also, don't forget the trival matter of moving
from a class-based object system
No, the object system in question is still class-based. The object
forest is orthogonal to that.
--
$;=sub{$/};@;=map{my($a,$b)=($_,$;);$;=sub{$a.$b-()}}
Dan Sugalski [EMAIL PROTECTED] writes:
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.
Not remotely the same thing.
Parent
--- Jonadab the Unsightly One [EMAIL PROTECTED] wrote:
Dan Sugalski [EMAIL PROTECTED] writes:
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
Austin Hastings writes:
Of course, how hard can it be to implement the .parent property?
You'll want it on just about everything, though, so the change will
probably be to CORE::MetaClass. It still shouldn't be that hard to do.
Maybe Luke Palmer will post a solution... :-)
use
On Thu, 18 Sep 2003, Andy Wardley 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
chromatic wrote:
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.
Ah, shouldn't optimization be automatic? Much preferrable to provide
opt-out optimizations instead of opt-in
On Thu, Sep 18, 2003 at 02:12:31PM -0700, chromatic wrote:
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
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
--- 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
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
--- 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
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
Austin Hastings wrote:
[... code example ...]
Good point to raise, but I'm not sure about your conclusion.
12 and 13 don't exist *in registers,* but they do certainly do exist at
various points: in the original source, in the AST, and in the
unoptimized PASM (if any). The registers were
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;
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
My, is this a conspiracy to drag -internals onto -language to make it look alive? :)
You guys almost made me drop my coffee mug...
--
Robin Berjon [EMAIL PROTECTED]
Research Scientist, Expway http://expway.com/
7FC0 6F5F D864 EFB8 08CE 8E74 58E6 D5DB 4889 2488
On Tue, 16 Sep 2003, Ph. Marek wrote:
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
On Mon, Sep 15, 2003 at 11:49:52AM -0400, Gordon Henriksen wrote:
Austin Hastings wrote:
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
David Storrs wrote:
This discussion seems to contain two separate problems, and I'm not
always sure which one is being addressed. The components I see are:
1) Detecting when the assumptions have been violated and the code has
to be changed; and,
2) Actually making the change after we
--- Gordon Henriksen [EMAIL PROTECTED] wrote:
David Storrs wrote:
This discussion seems to contain two separate problems, and I'm not
always sure which one is being addressed. The components I see
are:
1) Detecting when the assumptions have been violated and the code
has
to be
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
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
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
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
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
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.
[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
[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
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
--- 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
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
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
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
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
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
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
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
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
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;
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
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,
On Saturday, September 13, 2003, at 11:33 , [EMAIL PROTECTED]
wrote:
On Sat, 13 Sep 2003, Luke Palmer wrote:
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
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.
Speaking of objects... are we going to have a built-in object
Jonadab the Unsightly One writes:
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.
Speaking of objects...
On Sat, 13 Sep 2003, Luke Palmer wrote:
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.
Java's standard class library is a mishmash of things
Jonathan Scott Duff wrote:
This is mostly just a gratuitous message so that Piers has something
to talk about in the next summary
I bet Leon has something to say about that.
Better would be We're working on X and have hashed out the details
of Y but are having problems with Z
Something
On Tue, 9 Sep 2003, Jonathan Scott Duff wrote:
This is mostly just a gratuitous message so that Piers has something
to talk about in the next summary ;-), but when's the next
Apocalypse due out?
Well, I don't know if Leon (Hi Piers!) has better information than I do,
but the short answer is
49 matches
Mail list logo
