Re: Macro arguments themselves
--- Austin Hastings <[EMAIL PROTECTED]> wrote: > > --- Luke Palmer <[EMAIL PROTECTED]> > wrote: > > > 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: ..." I admit that last bit was tonge in cheek.:-) I don't want to impune anyone's talent. But seriously, I think it would be a lot of work. Alex __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com
Constant array or array of constant?
I was reading through E6 again, and noticed something a little
troubling:
sub part ([EMAIL PROTECTED] is rw) {...}
Well, I @_ C! Otherwise we wouldn't be able to
C things off of it. What was actually meant, I presume, is:
sub part ([EMAIL PROTECTED] of (Object is rw)) {...} #[1]
Or something. Basically, it's not the array that's read-only by
default, it's the elements.
I figure this would be a common thing to declare, so, hey!, how about a
new keyword? C as an alias for C.
sub foo(@x is constant) {...} # Constant structure, rw elements
sub foo(@x) {...} # Same
sub foo(@x are constant) {...} # Constant elements
So it seems that the default signature would be:
sub foo([EMAIL PROTECTED] is copy are constant) {...}
Which would be just how:
sub foo([EMAIL PROTECTED]) {...}
Would behave.
Luke
[1] Is C looser or tighter than C?
Re: Next Apocalypse
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 forest,
like Inform has, where irrespective of class any given object can have
up to one parent at any given time, which can change at runtime, 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?
--
$;=sub{$/};@;=map{my($a,$b)=($_,$;);$;=sub{$a.$b->()}}
split//,"[EMAIL PROTECTED]/ --";$\=$ ;-> ();print$/
Re: Next Apocalypse
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... 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, which can change at runtime, 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? Not.. exactly that. There are a lot of useful object systems around, and it's not like Perl to choose just one of them. In Perl 5, it was possible to change your parent I at runtime, but that's because data wasn't a part of Perl 5's (minimalist) classes. In Perl 6, classes associate attributes with themselves, so I imagine that it's only possible to switch parent objects, not parent classes. And I also presume that an object can have as many parents as it likes. 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. Luke
Re: Next Apocalypse
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 that represent containers (variables) and things that represent values (and even some broken things that try to be both), with no syntactic help to distinguish them. And its syntax reserves "const" but doesn't use it for anything. As long as we have "is rw" and its friends, we can -- with suitable care -- make sure that a subclass of a value-representing class is also a value-representing class, so there's no semantic need to say "never any subclasses" but we can still do CSE and other neat stuff at compile time. 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. Will we require methods in subclasses to use the same signatures as the methods they're overriding? -Martin -- 4GL ... it's code Jim, but not as we know it.
