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->
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 un
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)
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 Class
--- 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,
> >
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.
> Pa
Now that Apocalypse 12 is out, which one is Larry going to work on next?
Joe Gottman
--- Stéphane Payrard <[EMAIL PROTECTED]> wrote:
> With Perl6, few people will compile whole librairies but most
> will load bytecode. At this late stage there is little place for
> tunable optimization except JITting or it would defeat the
> sharing of such code between different intances of Perl
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-
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-i
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.
>
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
--- 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 do
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 autho
--- 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
> > applica
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 t
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 optimi
--- 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
> h
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 af
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 t
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 w
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 [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.
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_f
> 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 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 de
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;
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
&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 optimizati
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 h
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
> yo
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 ma
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
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 buil
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
--- 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
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
>
[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 t
[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
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.
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 a
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
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 t
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
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 method
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
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 th
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
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 hav
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 th
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"
Somethi
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?
In these quiet times, it would be nice to hear from the language design
team every now and then even if nothing but a "still working"
52 matches
Mail list logo
