Re: Interfaces
On Wed, 02 Oct 2002 04:12:44 -0700, Michael G Schwern wrote: I like the class Vehicle is interface as a shorthand for declaring every method of a class to be an interface. Perhaps associating a property with a class can be shorthand for associating that property with every method of the class? -- c
Re: Private contracts?
On Sat, 12 Oct 2002 08:43:46 -0700, Larry Wall wrote: On Sat, 12 Oct 2002, Graham Barr wrote: : Or even something like : : use Acme[1.0]; Hmm. Looks kinda like a subscript, which could be sliced to give an acceptable version range: use Acme[1;0..]; Might it be possible to say use any installed version of Acme below 2.0? use Acme[..2;0]; That could also be helpful. -- c
Re: Generalising properties
On Tue, 29 Oct 2002 14:19:59 -0800, Paul Johnson wrote: So I would like to see able to tag arbitrary information onto just about everything, including files, packages, classes, subroutines, blocks, control structures, statements, lines, expressions, variables and whatever else I've forgotten about. Properties can be attached to some of these. Can we generalise this at all? Of course, the applicability of this is not limited to code coverage, so it would be nice to have something as general and multi purpose as possible. But I don't want language support for saying that, that seems to be a problem for the applications that want the data, although I'd be glad to be shown that I am wrong and that the language can support that in a clean and concise way. Instead, I just want somewhere to hang arbitrary data. Dan started a thread about bytecode in p6i: http://archive.develooper.com/perl6-internals;perl.org/msg13377.html I jumped on the arbitrary metadata soapbox, and finally distilled my thoughts down to this: http://archive.develooper.com/perl6-internals;perl.org/msg13443.html It sounds like we're thinking along the same lines. This would be very handy for introspective tools (code coverage, refactoring browsers, IDEs...). -- c
Re: perl6-lang Project Management
On Tue, 05 Nov 2002 23:18:01 -0800, Allison Randal wrote: If you really want to be involved where the rubber meets the road -- where the abstract design gets tested and every last detail must be fleshed out -- you might contribute to Parrot. It has a good many of the features of the first 5 Apocalypses implemented already. One excellent opportunity is to write tests for Perl 6 features. Testing gives several benefits: - exploring the syntax with a working interpreter - mapping the boundaries of what's expected - providing good feedback for debugging Perl 6 - exposing what's not yet implemented - ensuring that regressions only happen once I'd be thrilled to help anyone learn how to do this. It's one of the most important places to contribute, but it's all-too-often overlooked. -- c
Re: In defense of zero-indexed arrays.
On Fri, 06 Dec 2002 14:16:43 +, Brad Hughes wrote: In any case, the choice of default base index is less important for Perl than for other languages given how seldom arrays in Perl are accessed by index as opposed to manipulated by push, pop, for $x (@array) loops and such. I slice a lot of lists, though, and expect the base index of a loop to have a certain resemblance to the base index of an array. -- c
Re: Variable Types Vs Value Types
On Tue, 07 Jan 2003 12:21:48 +0100, Rafael Garcia-Suarez wrote: Delegation has drawbacks compared to inheritance : you can't use a object that delegates to class Foo where an instance of Foo is expected. That sounds more like a problem with the polymorphism implementation than an argument against delegation (or even mixins). isa() considered harmful! -- c
RE: L2R/R2L syntax (was Re: Everything is an object.)
On Fri, 10 Jan 2003 14:12:12 +, Thom Boyer wrote: 'Course, then I've gotta explain why $x = 7 ~ 63; doesn't evaluate to 9 Surely because you haven't yet overloaded gozinta for the Number class! -- c
Re: A6: objects and/or types (was: P6FC)
On Fri, 14 Mar 2003 10:46:31 +, Larry Wall wrote: If you say $foo.isa(Even) it doesn't just check to see if $foo is a member of class Int, but it also checks the constraints on type Even, and returns false unless $foo is an even integer. We could still call Even a class if we wanted to, but it seems useful to me to distinguish classes that work right from classes that engage in hanky-panky. I think of types as being semi-instantiated. In a sense, this is currying of classes. Is isa() the right name? Distinguishing between type and class seems very useful. A type signature says I want something that has these traits. Checking isa says I want something that has this place within a class hierarchy. Attaching type information to a class makes sense -- you've got downwards substitutability there, but checking is it this class or a descendant when all you really mean is does it have these traits is way too specific and prevents a lot of substitutability. It's a subtle distinction. Allomorphism, anyone? -- c
Re: A6: Quick questions as I work on Perl6::Parameters
On Tue, 18 Mar 2003 20:43:00 +, Luke Palmer wrote:
Damian wrote:
caller :{.label eq 'MAINLOOP};
Errr what is that odd and disturbing notation? I don't recall ever seeing
that.
It's vaguely sinister. Must be the moustache operator.
-- c
Re: Protocols
On Saturday, July 19, 2003, at 04:25 AM, Luke Palmer wrote:
In Objective-C:
id untyped = somefunction();
idFoo typed = otherfunction();
If you send a message to Ctyped which isn't in the CFoo protocol
definition, you get warnings. Depending on the implementation, that
assignment might be dynamically interface-checked.
This is even nicer in function signatures, where accidental
polymorphism is an amazingly nice thing. If saying:
# quite possibly broken syntax
method debug ( String $s )
{
print $s.to_string;
};
really means 'String or a derived class', you're missing out on things
that support to_string.
That's really the fault of whoever wrote this method, but I'd prefer
the language guide people to make better decisions.
Now on to the implementation.
Inheritance feels like the wrong way to mark interface equivalence.
Take, for example, an object that combines a FloorWax and a
DessertTopping. Delegation's the way to go here, but if I have to
inherit from both FloorWax and DessertTopping to signify that the
object (somehow) implements both protocols appropriately, there are
subtler problems remaining. It might inherit behavior from a common
ancestor to both classes and then there's a diamond pattern.
Inheritance answers two questions. First, how does this class relate
to other things I know about? Second, where do instances of this class
get behavior?
The first is a deeper question -- besides inheritance, there's
delegation, aggregation, and reimplementation (think mock objects) that
can make two classes have equivalent interfaces. I'd like some way to
mark this equivalence *without* having to inherit from an abstract base
class and I wish that interface equivalence were checked before
inheritance, as per Luke's idea.
Class::ActsLike does something similar in Perl 5.
-- c
Re: Protocols
On Thursday, July 24, 2003, at 08:49 AM, David Wheeler wrote:
On Wednesday, July 23, 2003, at 05:57 PM, chromatic wrote:
The first is a deeper question -- besides inheritance, there's
delegation, aggregation, and reimplementation (think mock objects)
that can make two classes have equivalent interfaces. I'd like some
way to mark this equivalence *without* having to inherit from an
abstract base class and I wish that interface equivalence were
checked before inheritance, as per Luke's idea.
Sounds like you want Java-style interfaces to me.
No, I think Java interfaces are a kluge to get around copying a broken
type system and the lack of multiple inheritance.
I don't want to litter both the caller and the callee with interface
declarations that do nothing but say this thing here understands the
same methods as that thing there. The caller, fine -- that's the
place it belongs.
If I have to modify the callee to do this, I've insufficient
polymorphism.
Think of it this way. If you write Perl 5 code like this:
sub some_method
{
my $self = shift;
die Bad object unless ref $self = 'Some::Class';
# do something useful...
}
someone will have to change or override some_method() if he wants to
subclass it. You could make his life a little easier by writing:
sub some_method
{
my $self = shift;
die Bad object unless $self-isa( 'Some::Class' );
# do something useful...
}
I'm suggesting to go the next step and let the code say, Hey, if it
acts like an instance of Some::Class, I don't care where it gets its
behavior. I'll treat it like an instance of Some::Class. That's what
I do with Class::ActsLike, and that's what I'd like to see here:
sub some_method
{
my $self = shift;
die Bad object unless $self-acts_like( 'Some::Class' );
# do something useful...
}
Now it doesn't care whether I've inherited, aggregated, delegated, or
reimplemented. My argument is that it shouldn't have to care. It
should only care that I've somehow promised that what I'm passing in
behaves like it expects it to behave. How it does that is
uninteresting.
-- c
Re: Protocols
On Thursday, July 24, 2003, at 11:17 AM, Austin Hastings wrote:
No, I think Java interfaces are a kluge to get around copying a
broken type system and the lack of multiple inheritance.
Multiple Inheritance != Protocols | Interfaces
I quite agree, but I've done enough Java to know that if they could
have solved it with MI, they would have.
Protocols/Interfaces is a way of saying My structure is none of your
damn business, but I comply with the rules you've set.
Yes, exactly.
I disagree, and I hope you've simply swapped terms around.
I think you want to declare I comply with ruleset X at the callee
object level. That enables the compiler to (1) check that you're not
lying; and (2) optimize based on (1).
At least one of us is using caller/callee in the X11 sense. What I
mean and what I think you mean is:
method foo ( Thingie $t ) { ... }
$object-foo( $behaves_like_thingie );
foo() says, Give me something that I can treat like a Thingie. I
don't care HOW it does it, I just want it to do something sane.
$behaves_like_thingie is an instance of a class that somehow says,
Hey, I act like Thingie. I'm substitutable for Thingie if you don't
break my encapsulation.
If we're just confused over a bit of terminology, we're in violent
agreement on the idea, which is much more important.
-- c
Re: Protocols
On Thursday, July 24, 2003, at 05:28 PM, Benjamin Goldberg wrote: If this were Java, the way to do this would be to define a Thingie interface, and then an (archetypical) ThingieObject class... any time that we want to actually *create* Thingies, we would use new ThingieObject, but everywhere else, we would use the typename Thingie. This way, when we want a class which acts like a Thingie, but without inheriting any of it's innards, simply implement the Thingie interface, instead of inheriting the ThingyObject class. Yes, that's the Java way to do it. Surely we can do it better in Perl 6. The problem with Java interfaces is that you have to rely on the library writer to have expected you to use an interface. Given the amount of CPAN modules that, for example, expect a glob and preclude me from passing in an IO::Handle with code like this: croak Need a glob unless ref $thingie eq 'GLOB'; I'm not sure that the Java style is helpful. I'd rather not multiply entities needlessly. For our isa operator, and (perhaps more importantly) for multimethod dispatch and/or sub prototype checking, we only check if an object inherits from a class's magic parent interface, and *don't* check if it *really* inherits from that class itself. heretic Why should an implementor inherit from the interface? If inheritance and polymorphic equivalence are two different things, they ought to be handled two different ways. If anything, inheritance is a specific case of the general mechanism of marking polymorphic equivalence. Again, the interesting question isn't Does this thing derive from something I know about? It's Does this thing support the operations I expect it to support? I don't care how, just that it does. I don't want to call $mock_foo-isa( 'foo' ) because $mock_foo *isn't* a foo. I don't want to call $delegates_to_foo-isa( 'foo' ) because $delegates_to_foo *isn't* a foo. They can both handle foo-methods, but neither is a foo. /heretic -- c
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
Re: Next Apocalypse
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 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. Perhaps it would be better to specify an optimizability attribute at some level? That seems possible, from the same level. -- c
Re: Next Apocalypse
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 Parrot are built around the assumption that just about anything can change at run-time. Optimizing the language for the sake of optimization at the expense of programmer convenience doesn't feel very Perlish to me. -- c
Re: What to do....
On Fri, 2003-11-14 at 22:23, Rod Adams wrote: (If there are others working in the shadows back there, please make yourselves heard.) Allison Randal, Dan Sugalski, Hugo van der Sanden, and I usually help out. Can apocalypses be something more along the line of scratches on the wall, that then go through some level of deciphering or translation into something closer to English? Are there topics that need brainstorming that this list could take over? Probably not as such. The Perl 6 RFC process demonstrated fairly convincingly that there still needs to be one coherent design that takes into account all of the various desires and uses. Larry is shockingly good at that synthesis. (Just ask Piers Cawley; he'll wax eloquent on the subject.) On the other hand, after every Apocalypse and Exegesis, the discussion here exposes certain confusing spots and improvements to the vision. It has to be synthesized first though. Or syncretized. I certainly don't want the language to loose the internal cohesiveness that all languages need, and am suitably scared of design by committee... but I'd like to think that there's something that could be done to help matters. I'd really like to see people start turning the existing design documents into story cards and programmer tests for Perl 6. That'll make it much easier to implement the thing. Design decisions have to be broken into individual tasks at some point. Sure, some of them will change as we go along. There's enough there that can be implemented now, though, without waiting for the big thud of specifications. There's plenty of useful work to go around. Running test cases are *much* easier to implement against than anything else. (Hey, it's been working fairly well on the Perl XP Training Wiki: http://xptrain.perl-cw.com/). -- c
Re: roles (Was: enums and bitenums)
On Thu, 2003-12-11 at 18:15, Jonathan Lang wrote: Based on the source material pointed to as your inspiration for roles, I'm a little confused as to how roles and classes could be unified. From what I read in the source material, a key point of a role (well, they weren't actually calling it a 'role' there, but I'm not recalling the term that they did use) is that you get to bypass the diamond inheritence problem by relegating member variables to classes, so that when you use multiple roles to construct a class you don't have to worry about deciding which version of the variable to access in any given method. That's true, but that's incidental to the point of roles. It falls out from the important thing about roles. Without that restraint, exactly how does a role differ from a multiple inheritence model? Roles are a *more general* means of polymorphism and code reuse than inheritance. Inheritance is a *means* of performing a role, but it's not the only one. What's important about a role is that it marks the most important question (at least for polymorphic purposes): does this thing do what I'm about to ask it to do? It can do that role because of inheritance, but it can also do it because you've reimplemented all of the necessary methods, because you've aggregated an object that perform that role, or because you're delegating to an object that performs the role. If the only tool in your toolbox is isa(), you must either fake up some inheritance scheme or go without the three other allomorphic techniques. That's a shame. Roles exist because you can't fit all of the useful behavior in a system into a rigid class hierarchy -- some bits apply across classes -- without creating a mess. Again, inheritance is only one way a class can fulfill a role. It's not the only way and it's not necessarily the best way. See Class::Roles on the CPAN. -- c
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: A modest question
On Tue, 2004-01-06 at 22:26, Austin Hastings wrote:
So on the grand balance of utility, what are the metrics that traits are
supposed to help improve?
Two big ones:
- naming collections of behavior that are too fine-grained to fit into
classes cleanly
- enabling finer-grained code reuse
Consider a method that needs to print an object. You might require a
String:
sub print_it ( String $thingie )
{
print $thingie;
}
Why does it have to be a String, though? What prevents it from working
with anything that can stringify, besides the overly restrictive
signature? What if you could say (the Perl 6 equivalent of):
sub print_it ( does Stringify $thingie )
{
print $thingie.stringify();
}
That's both more general and something more specific. By asking for
what you really want, you're not coding everyone else into a corner.
Take Mail::SimpleList and Mail::TempAddress, for example. Both have
classes that represent individual addresses or mailing lists. The
appropriate parent class is Mail::Action::Address, which has the very
basic data and properties that both subclasses share.
Both simple lists and temp addresses should contain expiration dates, so
both classes need some sort of behavior to implement that.
When you throw another class into the mix, say, Mail::OneWayList, where
there's no expiration (trust me, even though it's not on the CPAN yet),
there's a problem.
I'd like to share code between all three classes that represent aliases
and Mail::Action::Address is the appropriate place to do that. I don't
want to share *all* of the code, though, so I can't really put the
expiration code in Mail::Action::Address.
I *could* subclass Mail::Action::Address and make
Mail::Action::Address::Expires and change the parent class of the temp
address and the simple list classes, but that's kinda icky as it leads
to yet another level in the class hierarchy.
By turning expiration into a role, though, everything can extend
Mail::Action::Address and only those classes that really need expiration
can do it -- and they share the code.
Contrived example? Maybe. Maybe not. Consider further James
Fitzgibbon's Mail::Action::Role::Purge. James wanted to extend all
Mail::Action subclasses to allow purging of expired addresses or lists.
That's reasonable, but it's not something I wanted to add to
Mail::Action because it doesn't know anything about expiration.
So he made it a role and decorates expirable objects with the role and
can do what he wants there.
Again, the goals are specificity, genericity, and improved reuse.
-- c
Re: A modest question
On Wed, 2004-01-07 at 00:43, Jonathan Lang wrote:
Maybe as an alternative to
role Stringify {must stringify();}
sub print_it (Stringify $thingie) {print $thingie.stringify();}
you might be able to say
sub print_it ($thingie must stringify()) {print $thingie.stringify();}
Hmm... there's a certain elegance to being able to specify one or two
requirements directly in a signature.
I'm not sure that works so well in practice. You're explicitly asking
for a method with a particular name when you're ought to be asking for a
method with a particular meaning. That is, if you said:
method threaten ( $thingie must bark() ) { ... }
passing in a Tree object would work, when what you really want something
that does Doggish things, like a Dog, an Actor in a dog costume, or a
RobotDog.
Promoting role names to a position of typishness allows roles to express
the semantics and context of method names that method names alone can't
express uniquely.
Yikes, now I sound like Larry.
LarryOr maybe not./Larry
-- c
RE: A modest question
On Thu, 2004-01-08 at 16:24, Jonathan Lang wrote: In this example, there's no difference between the Dog and Tree roles; however, this would almost certainly not be the case most of the time - at the very least, a class with a Dog role would have @.legs, while a class with the Tree role would have @.branches. However, if all that happens when you specify a demand for the Dog role in a signature is that the object must meet Dog's demands, then both crossPerson and Trog will be accepted. I would consider that a mistake. All that doing a role should imply is that somehow, that class understands the syntax *and* semantics of the methods of that role. Introspection can't reliably reveal whether $some_object.bark accesses a property (noun) or a method (verb). It's true that looking for @.legs versus @.branches could get you closer, but I'm not sure that it's been decided whether methods of a role should blissfully ignore all of the object's state. Besides, in a delegation situation, there could easily be some sort of magic that handles those attributes that the introspection mechanism might miss. -- c
Re: Traits: to renew OO inheritance in a hacker style discussion
On Thu, 2004-02-12 at 05:52, Aaron Sherman wrote: Perhaps I'm slow, but I don't see the difference between a trait and a Java interface other than the fact that traits appear to be more of a run-time construct. The easy answer is that interfaces completely suck while traits don't. :) Seriously though, Java interfaces add an alternate type system with an alternate syntax for querying. They also don't allow any sort of reasonable code re-use. Effectively, they're abstract multiply-inheritable base classes with a different name because Multiple Inheritance Is Bad! On a conceptual level, the different syntax is the worst crime because it reinforces the idea that the important question about an object is What is this object's position in a class hierarchy?, not Does this object have the same semantic meaning for these operations as I expect it to have? Then again, I usually explain it in terms of sucks, not don't even acknowledge the real problem. -- c
Re: Traits: to renew OO inheritance in a hacker style discussion
On Thu, 2004-02-12 at 11:49, Larry Wall wrote: What I'm currently thinking about is a does predicate that tells you if an object/class does a particular role completely. If you pull part of a role into a class, it returns false, because it doesn't do the complete role. However, if you use like instead, it returns a number between 0 and 1 telling you what fraction of the role's methods it uses. So you can ask if your object is more like a Dog or a Tree. Unless someone comes up with a better idea, of course. Obviously .does() is redundant with .like() == 1. But it seems like a useful redundancy. Is it more useful to find the Dog-like-ness of a class or the notion that SomeClass.bark() is semantically Dog-like, not Tree-like? I expect to care more that the object does something Dog-like with the methods I'm about to call on it than how Dog-like it is in general. Maybe that's slicing does() way too thin, but like() seems to care an awful lot about the implementation of how some class does some role. -- c
The Problem Roles Try To Solve
On Fri, 2004-02-13 at 11:02, Aaron Sherman wrote: On Thu, 2004-02-12 at 14:03, chromatic wrote: The easy answer is that interfaces completely suck while traits don't. :) Ok, so what you're saying is that they're solving for exactly the same thing, but you don't like the Java implementation. Yes and no. I don't think Java interfaces actually solve anything except let's not change the bytecode spec *again*. At least they acknowledge that single-inheritance isn't the be-all end-all of objects, but the second wrongest way to improve polymorphism is to add a second type of polymorphism with a separate implementation, philosophy, and syntax. The first, of course, is just to ignore the problem. The right way to improve polymorphism is to find common ground between inheritance, delegation, composition, aggregation, and reimplementation, make that your baseline, and support those techniques equally well. That has implications for the type system, the core libraries, and method dispatch, so it's much harder than copying an existing language and throwing out the parts you don't like. Then again, many things that are difficult are worth doing. -- c
Re: Traits: to renew OO inheritance in a hacker style discussion
On Sun, 2004-02-22 at 11:34, stevan little wrote: One thing that I noticed was that the authors seem to not intend Traits to be thought of as being like Classes. As a matter of fact they distinguish Traits from Classes in their Trait Language (contained in the above paper). So the idea of just being able to inherit the darned thing, would not work as a Trait is not a Class. Furthermore, roles are *not* inheritance. That's the point. Inheritance is not the be-all, end-all of OO, and any system that tries to fit everything into an inheritance-only model is irredeemably broken from the start. If inheritance always worked, we wouldn't need roles. Traits too are flattened into the class that uses them, so there is no true inheritance there. Traits themselves can be composed out of other traits though, but again the flattening happens and no true inheritance exists. The goal of inheritance is not to fit the world into one hierarchy. The goal of inheritance is to be able to write polymorphic code that does the right thing and is reasonably sure that any object you receive understands the method you're calling on it in the way that you intend. Unsurprisingly, that's also the goal of delegation, aggregation, composition, proxying, and reimplementation. Inheritance is only one way to accomplish that. Sometimes it's the best way. Many times, it's the worst way. That suggests that there's some deeper truth underlying all of the other polymorphic mechanisms. If that's true, you can build up all of those other systems on top of this mechanism. I think the base truth is roles, as seen in Perl 6. Again, the goal is polymorphism. Inheritance is just a means to that goal. If roles permit polymorphism separate from enforcing a particular implementation of marking polymorphic equivalence as well as code sharing, they'll be successful. See Class::Roles on the CPAN for one implementation in Perl 5. -- c
Re: Perl 6 timeline?
On Thu, 2004-02-26 at 11:50, Mark J. Reed wrote: Cool! But now I'm a little confused - what happened to Apocalypses 8 through 11? :) They were: - 8, References - 9, Data Structures - 10, Packages - 11, Modules Since 12, Objects is more important (and covers most of those anyway), it had a little push forward. There will likely be an apocalypse or exegesis or two that covers those specifically, but things change. -- c
Re: Perl 6 timeline?
On Thu, 2004-02-26 at 13:42, Simon Cozens wrote: [EMAIL PROTECTED] (Larry Wall) writes: It's the coherence that I can't delegate, and if I tried to, we would certainly end up with Second System Syndrome Done Wrong, instead of Done Right. You know, it's statements like this that make it hard for even me to be curmudgeonly. Nah, you only have to convince yourself that someone besides Larry could provide a greater coherence. I'm not saying that's likely or even true. I'm just saying that you *could* practice an extraordinary amount of self-delusion. It may help to meditate while chanting the meaningless syllables the mantra ehn tuhr priy zuh pruh groh mah ing lahn guh juh for a while. -- c
Re: Perl 6 timeline?
On Thu, 2004-02-26 at 09:31, Aaron Sherman wrote: And in it Apocalypse #26 was mentioned. Above, Larry mentions #11. At first the rate of 1 apolcalypse per month seemed to support the idea that Perl 6 would be defined within the next couple of years. However, trending shows that this function was actually logarithmic, and spacing has increased from month to quarter to half-year to year No plan survives first contact with the enemy. With Apocalypse 12 (soon!), much of the plan is finished. There are still rough edges to smooth down with regard to modules and packages, or at least how they differ from objects, but there's more than enough for implementation. 1. Larry gets help in writing these (various degrees of delegation). Already in place. See the end of Apocalypse 6 for the very short Apocalypse 7. 2. Perl 6 now (apoc 1-6), Perl 7 when the apocs are done. No. 3. Perl 5.aleph-1: Perl 5 code-base, Perl 6ish feature-set. Perl 5.10. 4. Don't worry, be happy (aka back in your hole, Hobbit! ;-) Yeah, that'd be my recommendation. I hope that everyone understands that I'm saying this because I want to help. I backed off of Perl 6 a while back, but as Perl 5 begins to feel more and more like a holding pattern for Perl 6, I find myself needing the next step to be taken for work reasons and wanting it for personal reasons. There's a compiler in progress in Parrot's languages/perl6 directory, as well as Parrot itself, documentation to write, test suites to write, synopses to read and to correct Honestly -- and I don't aim this at anyone in specific -- I really wonder where the idea comes from that people must wait until Larry makes his final pronouncement to all of mankind before doing anything. If everyone believed that, we wouldn't have much of Parrot or Perl 6 or Ponie right now. Of course, if fewer people believed that, we'd have more of each right now. I'd consider that a good thing. -- c
Re: Mutating methods
On Thu, 2004-03-11 at 13:04, Larry Wall wrote: Well, okay, not a boolean. More like a troolean. Unless it's a falselean. -- c
Re: backticks
On Wed, 2004-04-14 at 12:24, Juerd wrote:
chromatic skribis 2004-04-14 12:07 (-0700):
I think %hash`key makes sense. But I'd like to find out if more people
like this idea.
How do you request a hash slice with backticks?
You don't. There are %foofoo bar and %foo{'foo', 'bar'} already and
hash slices aren't used much at all.
That's exactly my objection to this idea. I think it goes too far to
make simple things simpler while making complex things impossible.
I really don't want to explain why there are two hash key access
mechanisms, one that only works for single keys that match a very
simplified regular expression and one that works for one or many hash
keys with no restrictions.
Simplicity is good, yes. Huffman coding is also good. But you have to
balance them with consistency of expression, usage, and semantics. I
don't think this proposal does the latter.
On the other hand, if you prod Luke Palmer, he can probably write a
macro to make this syntax work for you in under ten minutes and three
messages. In that case, it may not be a core feature, but you can have
it for very nearly free.
-- c
Re: backticks
On Thu, 2004-04-15 at 12:27, Scott Walters wrote: Without commenting on the rest of the proposal, please allow me to clear up one point: * Rather than eliciting public comment on %hash`foo (and indeed %hashfoo) the proposal is being rejected out of hand This whole thread *is* public comment. Some people like it, some people don't. Some people think it's useful. Some people think it's ugly. Some people think it simplifies things. Some people think it complicates things. Larry hasn't weighed in. Larry might not weigh in. Larry might like it. Larry might not. Larry might think it solves a real problem and come up with a nicer unification that almost everyone can live with. Hey, it's happened plenty of times before. (incidentally, the mantra of the Java community Process Now that's just rude. You are welcome to think that a certain proposal you like is the best thing ever and should certainly go in Perl 6 for whatever reason -- but claiming that the proposal has been rejected out of hand on a public mailing list where people are discussing the proposal and some people like it and some people don't is rather silly. -- c
Re: backticks
On Thu, 2004-04-15 at 13:37, Larry Wall wrote: Well, I, for one, think chromatic was right on the money. No matter how right my thoughts might have been, my tone *was* rude and that's not right. Apologies to Scott. -- c
Apocalypse 12
Perl.com has just made A12 available: http://www.perl.com/pub/a/2004/04/16/a12.html Warning -- 20 pages, the first of which is a table of contents. Enjoy, -- c
Re: A12: Conflicting Attributes in Roles
On Wed, 2004-04-21 at 04:19, Buddha Buck wrote:
From one C6PAN module:
role Dog {
has $.collar;
...
}
From a third C6PAN module:
class PoliceDog does Dog does LawEnforcementOfficer { ... }
role LawEnforcementOfficer {
method arrest { ... }
has $.collar;# for holding most recently arrested
...
}
So when my program fails to compile, who do I blame?
Whoever didn't read the documentation for the appropriate roles. :)
How do I fix it
quickly, preferrably without creating local branches of the C6PAN modules?
* Add a disambiguatey method to PoliceDog that dispatches
appropriately. (Insert handwavey well you *could* do it this way or
you *might* do it that way.)
* Force the loading of a specific version of LawEnforcementOfficer.
-- c
Re: A12: subtypes that lack methods or roles
On Fri, 2004-04-23 at 21:44, Jonathan Lang wrote: OK: I'm planning on creating a widget which must not make use of any of the indicator functionality of the HList; I don't just want to not use the functionality - I want to have its use forbidden (letting the optimizer go ahead and toss out the indicator role). So I'd like to create a subtype of HList which exceises that functionality. I think you're thinking of this backwards. Don't subclass HList. Create a new class that doesn't subclass anything and compose the appropriate roles into it. Provided the library designers have done their job and *ask for the proper role in function and method signatures, not a specific class*, you're groovy. Now I could be wrong about your intent, but the question How do I subclass a class to *remove* functionality? is the kind of Yeah, it hurts when you do that situation role-based composition try to avoid. If you have all of the pieces, put them together in a way you find most pleasing. -- c
A Gentle Reminder of P6Stories
Remember, the non-controversial decisions in A12 and the other Apocalypses, Exegeses, and Synopses are prime fodder to add to the P6 Stories wiki at http://p6stories.kwiki.org/. Good stories and, even better, small test cases with code and expected output make the Perl 6 compiler suite *much* easier to write. -- c
Re: is rw trait's effect on signature
On Thu, 2004-05-06 at 10:39, Aaron Sherman wrote:
The simple case is:
sub foo(X $i is rw) {...}
class X {...}
class Y {...}
my Y $var = 'something';
foo($var);
In this case, something kind of interesting has to happen.
Either the signature checking has to verify that Y isa X (and thus can
be used polymorphically as X, not just converted to X) ...
I'd argue 'Y does X', actually, though Dan disagrees and says Well,
whatever!
-- c
Re: is rw trait's effect on signature
On Thu, 2004-05-06 at 11:24, Dan Sugalski wrote: Well... sort of, but only because you've defined that for perl 6 classes automatically do themselves--you've conflated inheritance and interface. Which is fine, except that it falls down in the face of objects from classes that don't do that. Given: - class A, a superclass - class AB, a subclass of A - class Eh, a class that does A but does not inherit from it - subroutine signature foo(A some_object) If the signature checker checks isa, you can't pass in Eh, even though its writer has guaranteed that its semantics match those of A. If the signature checker checks does, you can pass in A, AB, or Eh, assuming that subclassing marks does on the subclass *or* that you fall back to checking isa if does fails. Either will probably work, but you and I both agree there's a problem in that does and isa overlap somewhat. We disagree on the implications of that overlap, though. Both can answer the question can this object handle this method? isa goes further, though, telling you where to look for the method if it's not part of the class itself. That's why I'm not sure making isa the base operation is the right behavior. If you put does alongside it, you have two mechanisms by which people can answer the same question -- not only is that kind of a waste, but people will do that incorrectly. If you put does atop isa, you're getting less specific and throwing out information. If you make does the base operation, you can be more specific with isa (or delegates or aggregates, if you want to be that specific) by separating the method lookup part. As a plus, languages that don't care about does don't have to do expose it. I can't see a place where it falls down -- but if some Perl 6 code asks a does question about a Ruby object, it just works. -- c
RE: is rw trait's effect on signature
On Thu, 2004-05-06 at 13:27, Austin Hastings wrote: I think we had this discussion a year or two ago, and Damian was opposed to the notion that providing the correct methods was equivalent to providing the interface or belonging to the class. His reasoning involved Dog and Tree both sharing grow, bark, etc. Perhaps he could re-explain his reasoning? I agree with his reasoning. You need some sort of context to determine whether bark() is a noun or a verb -- that'd be the name of the class (or the role, in my scheme). Trying to infer which role might apply may be nice in some cases, but as a general matter of policy it seems pretty vague and corner-casey. I'm comfortable saying if you don't mark 'does' and you don't inherit, the compiler won't guess that you do. -- c
RE: is rw trait's effect on signature
On Thu, 2004-05-06 at 13:47, Austin Hastings wrote:
Then in your example:
The class 'Eh' does A but does not inherit, did you mean:
class Eh {
method A1
method A2
method A3
}
Yes.
I had thought that Cdoes CLASS (class implicitly= role) had been
rejected.
I don't remember in particular, but it's not hard to rejig the example
to achieve the same sort of effect. The important point is that I think
using 'isa' to mean 'does' is silly.
-- c
Re: RFC eq and ==
On Mon, 2004-05-17 at 13:35, Pedro Larroy wrote: Would it be a good idea to make ==, and other numeric comparators polymorphic so they can be used also for string comparisons? How does the compiler know which is which? Is 10 a string? Is it a number? Is 10base-T a string? Is it a number? Is an object with overloaded stringification and numification a number? Is it a string? I don't know a good heuristic for solving these problems. If you have one, it's worth considering though. -- c
Re: RFC eq and ==
On Mon, 2004-05-17 at 13:51, Pedro Larroy wrote: I thought perl internally would know. At least in perl5 it has to know somehow, since you can $var++ when is numeric and also when it's a string, and behaves different in each case. True. Perl 5 scalars do keep track of the context in which you've used the data they hold. If you treat a scalar like a number, it'll behave like a number. There are some wacky corner cases, though, where you see side-effecty action at a distance. (I remember running across this at least twice, though I don't remember specific examples. DWIM usually works well.) As Luke suggests, there's also programmer clarity to consider. If determining how to compare depends on how you've used the variables to compare, is it harder to understand the code? The solution for an API designer may be be very careful, then! but I'm not sure a language designer has that luxury. -- c
Re: if not C, then what?
On Wed, 2004-06-30 at 18:18, Alexey Trofimenko wrote: P.P.S. do we have a way to imply void context on function inside expression, something like Cscalar, C+, C~, C? do? Sort of a 'meh' operator? I wonder (idly) in which circumstances the context determinator couldn't determinate void context, though. -- c
Re: String interpolation
On Tue, 2004-07-20 at 19:35, Luke Palmer wrote:
The New Way (tm) to do that would probably be sticking a role onto the
array object with which you're dealing:
my @foo does separator('//') = (1,2,3,4,5);
say [EMAIL PROTECTED]; # 1//2//3//4//5
Shh, no one's let slip the idea of curried roles yet! I'm not even
certain A12 mentioned parametric roles, let alone first-class roles.
-- c
Re: Why do users need FileHandles?
On Mon, 2004-07-19 at 14:04, David Storrs wrote: Second, I would suggest that it NOT go in a library...this is reasonably serious under-the-hood magic and should be integrated into the core for efficiency. You must have amazingly fast hard drives. -- c
Re: Revision of A12's lookahead notions
On Tue, 2004-08-17 at 12:54, Larry Wall wrote: But we'll just have to shoot anyone who makes a wisecrack like: use parens :lisp; Surely that should have its own pragma: use parenths; -- c
Re: Synopsis 2 draft 1 -- each and every
On Fri, 2004-08-20 at 14:26, Austin Hastings wrote: Dan Hursh wrote: generalimpose scalarimpose list ----- D$foo.eat$foo.bite$foo.gobble N$foo.look$foo.peek$foo.peruse hmm, I don't like eat in this case D$foo.take$foo.grab$foo.horde s/horde/hoard/ If I'd written that, I'd claim that as deliberate. Though it does leave a problem with grab as a singular noun, -- c
What Requires Core Support
On Sat, 2004-09-04 at 18:44, John Siracusa wrote: Without commenting on the issue of single-file bundling... To bring it home, I think packaging and distribution is important enough to warrant a standard, core-supported implementation. I think the specially structured dir of files and its single-file packaged (and precompiled) variants are important enough to be standardized, or core, or whatever you want to call it. ... you can find almost anyone arguing this point for almost any feature. I'm inclined to distrust it. I just don't see a way to achieve this level of transparency and elegance without core support. That's a much better gauge for whether a feature should go into the core. I don't know how this particular case fares with that metric, but it's one of the right questions to ask. -- c
Re: S5: grammar compositions
On Wed, 2004-09-15 at 12:47, Larry Wall wrote: Grammar roles? It seems sensible, having said Here's a better method of type checking and code re-use and Here's a generalization of pattern matching to make it more like programming. Not doing it would be like making closures that can't write to the closed-over variables. That's just crazy! -- c
Re: S5 updated
On Wed, 2004-09-22 at 10:49, Luke Palmer wrote: Let me come right round to my point about perl being open source. Someone has to do the work somewhere, and making it standard or core doesn't change that. It just means that it'll take longer. It also means that there's a possibility that the most recommended module for tasks such as recursively searching directories for files will have a decent interface. I really don't want to see the first attempt at any kind of interesting module stick around forever in the core for the sake of backwards compatibility. I'd like to see what kind of idioms develop, for one. -- c
Re: Improvements to execution and loading of bytecode programs and modules
On Wed, 2004-11-03 at 20:08, Milscvaer wrote: First, Perl ought to allow bytecode, already compiled, to be loaded via a bytecode equivelant to eval(), if this cannot be done already. Please read through the design documents: http://dev.perl.org/perl6/ Many of these ideas have come up already. -- c
Re: Auto My?
On Sun, 2004-12-19 at 20:25 -0600, Rod Adams wrote: One of the other reasons in favor of the idea was aesthetic. # stuff which declares $x, $z, and $q $x = 4; my $y = 7; $z = 12; my $r = 4543; $q = 121; compared to: # stuff which declares $x, $z, and $q $x = 4; $y = 7; $z = 12; $r = 4543; $q = 121; With a fixed width font, like all code editors use, all the =' like up, and I can quickly scan the var names to get to the one I want to change at that moment. If you align the equals signs yourself with spaces, you can use variable names of different lengths (and possibly improved meaningfulness in actual factual code) too. I'm only half-joking. Vertical alignment makes a dramatic difference to readability. -- c
Re: Containers vs Objects.
On Tue, 2005-02-15 at 14:26 -0600, Rod Adams wrote: The obvious statement I expect to here is Perl's always had Arrays and Hashes. While I'm not sure if they were there for Perl 1.0 (I started w/ Perl 4.xx) They were. So I'm interested in hearing what pushes Arrays and Hashes over the edge for needing their own container and sigil, whereas Junctions/Sets do not. Perl isn't a pure object-oriented language. -- c
Re: Fun with junctions (was Sets vs Junctions)
On Wed, 2005-02-16 at 08:54 -0800, David Wheeler wrote: And what of .c#? It's an alias for .java. -- c
Re: How are types related to classes and roles?
On Fri, 2005-03-04 at 21:12 +0100, Thomas Sandlaß wrote: The roles themself beeing the least member of these classes---uninstanciable pure behaviour. The intersection type/role AB is multiple inheritance (or is that roling?): I don't understand the question (I don't recognize the words lubs or glbs, for example), but I don't think this has anything at all to do with multiple inheritance. Generalizing types on a class based on inheritance is micromanagement. It cares too much about how polymorphism works. This is why putting abstract, uninstantiable classes in languages that don't support multiple inheritance is a cure worse than the disease -- it recognizes that there's a problem with forcing all type equivalence to go through inheritance, but it adds a second type system alongside the first and classes again have to know too many details about how one particular class marks its equivalence. I don't think that roles are necessarily unsubstantiable; class and role names should occupy the same namespace. It ought to be possible to have class A with a particular set of methods and class B with a set of methods of the same name and similar enough semantics for the entire set of behavior of those methods and be able to mark class B as performing the A role and to be able to pass B objects into code that asks for A objects and have things just work without A or B necessarily having to share code and definitely without them being related to each other in any sort of inheritance relationship. Maybe there's not enough behavior in a role to make it a full class, but there's enough behavior that it's useful across classes horizontally and it deserves its own name. Maybe that's not helpful, but I did warn that I didn't understand the question! -- c
Decorating Objects with Roles (was Re: Optional binding)
On Mon, 2005-03-07 at 19:40 -0800, Larry Wall wrote: On Mon, Mar 07, 2005 at 05:56:12PM -0800, David Storrs wrote: : Actually, I guess they would have to be...can you apply a role to a : bare type? : : my int does SelectOutputFile; # I would expect this to fail : my Int does SelectOutputFile; # I would expect this to work The latter always works. The former can probably be made to work in the case of roles that only add methods and don't change the storage representation, since the vtable is associated with the class and not the object. I could make the argument that it should be possible to decorate an object with a role. If that means generating a new anonymous class just to have a vtable to munge, so be it. -- c
Re: Decorating Objects with Roles (was Re: Optional binding)
On Tue, 2005-03-08 at 17:39 -0800, Larry Wall wrote: On Tue, Mar 08, 2005 at 03:23:14PM -0800, chromatic wrote: : I could make the argument that it should be possible to decorate an : object with a role. If that means generating a new anonymous class just : to have a vtable to munge, so be it. Er, how is that different from what we already said? I didn't think it was, but this explanation used simple words that didn't rely on me pretending to care about weird mathematics. -- c
[Fwd: Re: Moving the p5 standard library to p6]
Forwarded... On Sat, 2005-03-26 at 12:05 +1100, Andrew Savige wrote: Please note that I am not an expert on any of this, I was just wondering whether we are going to clean up the old p5 library interfaces as part of the move to p6. Or must we support the old p5 library interfaces for backwards compatibility? No. Please, no. :) As I see it, Perl 6 has a chance to start over with a very small set of core libraries -- perhaps embarrassingly small -- so as not to entomb our current, potentially-blepharitic guesses at good Perl 6 design principles for the next twenty years or so. If people really want File::Find or MakeMaker interface compatibility in Perl 6, I suggest a new top-level namespace, namely GodHelpYou::File::Find, though P5Compat may be less exciting and more appropriate. -- c
Re: Parameter and trait questions - just how 'only' _is_ 'read-only'?
On Wed, 2005-03-30 at 14:29 -0500, Aaron Sherman wrote: What I do not think should be allowed (and I may be contradicting Larry here, which I realize is taking my life in my hands ;) is violating the compile-time view of the static type tree. That is, you can load an object foo at run-time, without and interface definition, but it can't change the shape of the type tree or its existing interfaces. If it wants to do that, it has to provide an interface def (e.g. what an autoload module should be able to provide). I disagree, *unless* you predeclare that you don't plan to change anything -- as an optimization hint. (Though if you write a module to do this as a policy, I won't hunt you down with my +2 club of Optimize for the Programmer, not the Compiler.) I certainly plan to continue to instrument code at runtime (and not just really slushy, partially slushy, and permafrost compile time). -- c
Re: Parameter and trait questions - just how 'only' _is_ 'read-only'?
On Wed, 2005-03-30 at 15:27 -0500, Aaron Sherman wrote: Like I said, if you allow run-time munging of the type interfaces, then you can't tell if this is valid or invalid: my X $a; $a.m(1); you have to allow it always, regardless of the definition of X. In fact, you can NEVER reject ANY method or function invocation based on signature, since it might change at run-time. Is that really what you want? I want the possibility to correct bad decisions of interfaces and signatures whenever possible in the most minimally intrusive way possible. I don't want to work around a module or class or function or method where someone tried to be helpful by saying Oh, this will absolutely never change, ever and the compiler helpfully froze that decision forever. Sometimes that means changing it outside the incorrect code. I don't trust any compiler to make every decision correctly, and in cases of ambiguity I believe that I can give it better hints than it can reason for itself if I need the extra speed or safely. A compiler that assumes incorrectly and disallows programmers to do useful things because its holds those assumptions as precious is wrong -- especially in cases where even the programmer can't tell if code is valid or invalid until the program actually runs. -- c
Re: Parameter and trait questions - just how 'only' _is_ 'read-only'?
On Thu, 2005-03-31 at 13:11 -0500, Aaron Sherman wrote: I can't answer most of these well. However... One additional wrinkle is that *anyone* is allowed to declare a class non-cooperative (open or non-final) during *any* part of the compilation ... even after it is declared final? I hope so. Will core types be finalized by default? I hope not, but if so, I hope they include all of the behavior anyone could ever possibly want from them so that no one will ever have to decorate them to add that one little important missing feature. Open-Closed is a great idea until the most natural and easiest way to do something is to to redefine a little bit of the world. -- c
Re: Truely temporary variables
On Fri, 2005-04-15 at 11:21 -0500, Patrick R. Michaud wrote: On Fri, Apr 15, 2005 at 09:17:13AM -0700, Larry Wall wrote: Maybe we could define an ok operator that suppresses only the *first* warning produced by its argument(s). Then if you get multiple warnings, you at least get some indication that you've overgeneralized, even if the wrong warning comes out. Or maybe it only suppresses the first warning till you get a second warning, and then it prints both. And after the third warning, it sends you to your room with no supper. Talk about a strict permission system. If that's the case, I want a I'm the human here, darnit! option to bypass it. -- c
Re: $*CWD instead of chdir() and cwd()
On Fri, 2005-04-15 at 23:52 +0200, Juerd wrote:
Well, after failure it can be cwd() but false without breaking any real
code, because normally, you'd never if (cwd) { ... }, simply because
there's ALWAYS a cwd.
Not always -- try removing a directory that's the pwd of another
process.
-- c
Re: Parameter and trait questions - just how 'only' _is_ 'read-only'?
On Wed, 2005-03-30 at 18:35 -0500, Aaron Sherman wrote:
When the Perl 6 compiler sees:
my X $a;
$a.m(1);
What should it do?
Options:
* Accept the method call regardless of the definition of X
* Accept the method call if it matches the signature from X
* Accept the method call if {magic($*INTERP)}
That's a fair question, but I think you're leaving out several important
pieces of information:
* Where does $a come from? (As far as I see, it's just an
uninteresting undef here, but I don't know if that's the point of the
code.)
* At what point in the program are you asking what the compiler sees?
* Where's the definition of X in relation to this code?
* What pragmas are in effect here?
* What other code may have altered the type definition of X or undef?
I don't think anyone can answer your question well without assuming some
answers to my questions.
-- c
Re: BEGIN {...} and IO
On Mon, 2005-06-13 at 17:07 +0200, Ingo Blechschmidt wrote:
# No problem:
my $data = BEGIN {
my $fh = open some_file err...;
=$fh;
};
# Problem;
my $fh = BEGIN { open some_file err... };
# Compile-time filehandle leaked into runtime!
say =$fh;
Perhaps I'm being very naive, but why is this a problem? Maybe it's not
the best way to do something, but I can see it being useful in some
circumstances.
Are you worried about using up resources? If you don't refer to $fh
elsewhere, GC will take care of it. (If you really worried about it,
you'd explicitly close it somewhere.)
-- c
Re: ./method defunct
On Sun, 2005-06-19 at 02:11 +0200, Juerd wrote: Why exactly is the slash not acceptable for you? Almost everyone has said they like it. I find it ugly enough that I plan to name my invocants explicitly. -- c
Re: AUTLOAD and $_
On Mon, 2005-06-20 at 12:11 +0200, Juerd wrote: I think there exists an even simpler way to avoid any mess involved. Instead of letting AUTOLOAD receive and pass on arguments, and instead of letting AUTOLOAD call the loaded sub, why not have AUTOLOAD do its thing, and then have *perl* call the sub? Who says AUTOLOAD will always either call a loaded sub or fail? -- c
Re: AUTLOAD and $_
On Mon, 2005-06-20 at 16:37 -0600, Luke Palmer wrote:
On 6/20/05, chromatic [EMAIL PROTECTED] wrote:
Who says AUTOLOAD will always either call a loaded sub or fail?
Uh, what else can it do? It doesn't have to load a sub to return a
code reference.
I think:
class NullObject
{
sub AUTOLOAD {}
}
is better than:
class NullObject
{
sub AUTOLOAD { return sub {} }
}
Or have I misunderstood the proposal and the purpose of AUTOLOAD?
-- c
Re: AUTLOAD and $_
On Tue, 2005-06-21 at 13:35 +, Luke Palmer wrote: I think people are being pretty closed-minded about closures. I'm pretty closed-minded about writing code that does nothing to prevent the language from doing the wrong thing by default. I already have a fantastic way to write code that does nothing: I don't write it. Maybe I don't really want AUTOLOAD, though. Juerd's MISSINGSUB (or whatever the name is) has some merit, especially from a better name for what I want to do perspective. -- c
Re: AUTLOAD and $_
On Tue, 2005-06-21 at 20:08 -0500, Rod Adams wrote: Should we then perhaps rename it to: DEPRECATED_PERL5_AUTOLOAD ? Poster 1: I hate it! Poster 2: I love it! Poster 3: How about PERL_5_AUTOLOAD_DO_NOT_USE? Poster 4: That's a stupid feature to add! Poster 5: That's too much to type! Isn't there a two character combination somewhere? Poster 6: Shouldn't that be a module somewhere? Poster 7: Shouldn't that be a macro? chromatic: It's ugly. I'll never use it. Damian: Good. That's the point. chromatic: That was a straight line. -- c
Re: Quick OO .isa question
On Mon, 2005-07-11 at 15:16 +0200, Ingo Blechschmidt wrote: Bar.new.isa(Object);# true Bar.new.isa(Class); # false Bar.new.isa(Foo); # true Bar.new.isa(Bar); # true I'd like to go on a tangent to suggest that anyone who uses .isa() in actual real code ought to be doing something really really tricky, for which there absolutely is no other solution. Alternately, it's okay with me if .isa() is actually syntactic sugar for .does(), thought I don't expect much agreement on that. -- c
More on Roles, .does(), and .isa() (was Re: Quick OO .isa question)
On Mon, 2005-07-11 at 17:47 -0400, Stevan Little wrote:
I actually agree with you on that. But I would like to clarify it to
say that:
Foo.isa(Bar) # Foo.meta.isa(Bar) || Foo.meta.does(Bar)
... meaning that the .isa() which is supposed to be aliased into the
class from .meta is actually this.
I've always thought that .does() should check .isa() as well. That's
how Class::Roles works in Perl 5.
If you *really* need to know that Bar inherits from Foo, there's .isa().
If all you really care about is that Bar is Liskov-a-rific with respect
to Foo, use .does(), which checks that Bar inherits from or does the
role of Foo, whether it mixes in any methods or not.
Have I mentioned before that I think you should be able to say:
class Foo
{
method foo { ... }
method more_foo { ... }
}
class Bar does Foo
{
method foo { ... }
}
... probably get a compile-time error that Bar doesn't support
more_foo()?
I see a reason to differentiate between roles and classes on the
metalevel, but the argument is not as strong on the user-level.
I go further to see little reason to distinguish between role, class,
and type names (and what reason there is is for introspective
capabilities, not standard user-level type checking).
-- c
Re: MML dispatch
On Wed, 2005-07-13 at 17:33 -0400, David Storrs wrote:
What is a type besides a named blob of methods
and, possibly, data?
A label that says how the data is stored internally. For example,
compare Int and int. The former is a type and a blob of methods
and not necessarily abstract. The second is a type, is NOT a blob of
methods, and is definitely NOT abstract.
I contend that that's meaningless to Perl. Why does the internal
representation of data matter if the interface is the same? In Perl 5
terms, should you not be able to pass a tied hash to a module that
expects a hash because the internal implementation may be very
different?
If yes, then we have very different ideas about types and signatures and
I'm not sure we can reconcile our views.
I realize that it could appear that I've shifted the example to
container types away from your argument about value types, but I don't
think it's an important distinction here.
Making people think about what they really want is a good idea.
I agree, but only as far as what they really want is actually what they
really want. To put it another way, if you have a method that prints
something passed in, do you want a signature that says This must be a
string, perhaps with a specified encoding and internal representation
or a signature that says This must be something that stringifies?
I want the latter.
Note that there are two subtly different kinds of type constraints
under discussion: the first is what class something is, and the
second is what behavior it can exhibit.
I think the former is silly, almost always useless, and nearly always
wrong, especially in library code.
The two are very slightly different:
multi foo(Dog $x); # Must be of class
Dog, or a class that is a descendant of Dog
No, I think it must conform to the type of Dog, whether it is an
instance of the Dog class, an instance of a subclass of Dog, or
something that performs the Dog role.
Why does its internal implementation matter? What are you doing inside
foo() that its internals matter?
multi foo(Dog $x where { not $x.feral });# Must be of
anonymous class class Dog (or descendant) with $.feral set to false
Again, I think it must conform to the type of Dog, but with the
additional constraint.
The distinction I'm drawing is between pure behavior and behavior
+state. I'm drawing this based on the idea that Roles are not
allowed to have state--that they are pure virtuals, only used for
defining interface. If that is not true, then (A) I apologize for
the wasted bandwidth and (B) I'd like to have it explained what Roles
offer that justifies their existence, since they won't be anything
but a restricted form of a class.
Roles do have state.
They exist because:
1) hierarchies aren't the only way to express type relationships -- nor
are they often even a good way
2) conformity to an interface is more important than uniformity of
internal representation, especially in a language with late binding
3) non-hierarchical code-reuse is possible -- and very useful
4) making no distinction between class, role, and type names makes
genericity and polymorphism much easier and much more powerful
Aside from optimization and introspection, why is it useful for a method
signature to say This has to be a Dog or something that inherits from
Dog?
-- c
Subroutine and Method Introspection
A12 and S12 describe introspection on objects and classes. The metaclass instance has the method getmethods() which returns method descriptors. The design specifies several traits queryable through these descriptors. Methods (and subroutines) can take other traits, such as is lvalue or even user-defined traits. I can imagine that a Perl 6 port of Test::Class would suggest using trats of is startup and is tests( 4 ) to replace the use of attributes in the Perl 5 version. Currently, there's no way to query these traits through introspection, nor is there a description of the descriptors beyond indicating that they're some sort of object. I have no strong feeling as to what type of object they should be, but they ought to support some sort of traits() method to return a list of names of all available traits on the method. Passing the name of a trait to the method ought to return the value of the trait, if it is a parametrized trait. Otherwise, it could return boolean. Perhaps there's a more general mechanims that works better in specific cases. Ruby's Class#method? syntax is nice, but being able to hardcode a method name and pass a string parameter makes introspection a little more automable. Having the class for these descriptors be available and extensible also makes it possible to write a method that returns only the *interesting* traits, which might be convenient. Thoughts? -- c
Re: Exposing the Garbage Collector
On Sat, 2005-07-23 at 20:41 -0700, Brent 'Dax' Royal-Gordon wrote: Piers Cawley [EMAIL PROTECTED] wrote: It seems to me, that the way to get at all the instances of a class is to ask the Garbage Collector to do the heavy lifting for us, and ideally I'd like to see this exposed at the Perl level. It's entirely possible that Perl will be used on virtual machines where this can't be done. Will those VMs support string eval? If not, Piers' *specific* problem here mostly goes away. How much introspection and intromanipulation should Parrot guarantee on small or limited platforms in general? -- c
Re: say's return value
On Sat, 2005-07-30 at 14:56 +0300, Gaal Yahas wrote: (This introduces a potential semipredicate problem when looking at the return value of a printed 0 or while not using fatal, but the code can use a defined guard.) I don't know if returning the printed string is the right approach, but would returning '$string but true' avoid the semipredicate problem? -- c
Re: Hoping that Params::Validate is not needed in Perl6
On Wed, 2005-08-17 at 23:43 -0500, Dave Rolsky wrote: But I'd really like to get this stuff done at compile time wherever possible. If I write this: validate( credit_card_number: $number ); it should blow up at compile time, right? Does that depend on how closed you want Perl 6 to think your world is at compile time? -- c
Re: Parsing indent-sensitive languages
On Thu, 2005-09-08 at 14:59 -0700, Greg Woodhouse wrote: I agree that simply using terms like this means indentation grammars are problematic -- or does it? One thing that bothers me is that *people* don't seem to have a great deal of difficulty with them. Why not? People can parse multi-dimensionally. Computers cannot... yet. -- c
Re: \(...)?
On Mon, 2005-09-19 at 13:01 +0200, TSa wrote: Why shouldn't there be a lvalue traversal that in the end makes ($x, $y) = \($a, $b); actually mean $x = \$a; $y = \$b; Does this not go from one sequence point (evaluate the rhs sufficiently, then perform the lvalue assignments) to multiple sequence points? I'm not sure you can always reason effectively about the lack of side effects here. -- c
Re: seeing the end of the tunnel
On Wed, 2005-10-05 at 16:26 +0200, TSa wrote: I recently wrote a Perl 6 design TODO, which was surprizingly small, which enumerated the things to be done before I considered the design of Perl 6 to be finished. Larry replied with a couple more items. The type system is not on this list, right? It actually is, both in syntax and semantics. -- c
Re: Type annotations
On Fri, 2005-10-07 at 12:49 +0200, Juerd wrote: Ashley Winters skribis 2005-10-06 19:30 (-0700): my Array $a = 97; # dies eventually, but when? Runtime -- cannot coerce Int value to Array It is fully determinable at compile time. 97 will never be compatible with Array, so I see no reason to wait. If I added a multisub for Array assignment so that assigning an integer value set the length of the array, would 97 be compatible with Array? Do remember that some programs run for weeks or months, rather than a few seconds. It's nice to get all the certain failures during compile time. How about in unreachable code (which I do actually believe compilers can detect some of the time)? -- c
Re: Type annotations
On Fri, 2005-10-07 at 15:22 -0600, Luke Palmer wrote: On 10/7/05, chromatic [EMAIL PROTECTED] wrote:\ If I added a multisub for Array assignment so that assigning an integer value set the length of the array, would 97 be compatible with Array? You're not allowed to overload assignment. $ perldoc perltie I don't really care how I do it, provided that I don't have to write PIR or C just to make this possible, but I want the option to have at least same power as Perl 5 to do weird things if that's what it takes to do really useful things that you or I or @Larry can't imagine right now. But you are allowed to overload coersion. Essentially, every expression gets a coerce:as($expr, $current_context) wrapped around it (where these are optimized away when they do nothing). If you allow definition of these at runtime, there are two side-effects: 1) No typechecking can ever take place in any form. 2) No coerce calls can ever be optimized away. These are very unfortunate. So I'm inclined to say that you can't overload coersion at runtime. No one can ever overload assignment or coercion at run time because you want theoretical programs you haven't yet to run VERY VERY FAST? Me, I just want to get my job done without always having to ponder the beauty of type conceptual purity while I'm fiddling with BEGIN blocks and CHECK blocks and INIT blocks, trying to dodge inscrutable type mismatch errors while guessing the combination of the locks on the escape hatches built into the language. I'm sort of feeling the inclination to argue for a lexical RUN VERY VERY FAST switch that lets you (or me sometimes) the programmer say Go on and hurt me when it's totally worth it, not to apply cheese graters, hot peppers, and David Hasselhoff CDs with fulsome BD glee to every programmer who ever types perl6 ./hello_world.pl. -- c
Re: Type annotations
On Fri, 2005-10-07 at 17:43 -0600, Luke Palmer wrote: No, you can't overload assignment at runtime because you can't overload assigment at any time, so says the language spec (well, not any formal spec; so says Larry as far as I remember). I'm wearing my just a programmer, not a denizen of p6l hat. Pretend I don't know the difference between overloading assignment and setting special STORE magic and I want the option to be able to have Array do something meaningful and significant to both of us when I assign a constant scalar to it. Again, I don't care *how* I accomplish it, as long as I don't have to root around in the source code of Perl 6 itself to make it work. As for the first argument, presumably people put type annotations on their code so that we can do some reasoning and tell them about errors. I don't want to use a module off of 6PAN that breaks my code because its type annotations have leaked out into the rest of my code and I have no idea what the compiler error messages mean. It's sort of the anti-$, except it can make my program run faster. (Correct answers: depends on the question. Wrong answers: instantaneous.) It's up to the person who *runs* the code, not the person who writes a component and can't possibly decide from now 'til forever exactly every circumstance in which he will allow people to use the component, to decide what level of compiler complexity and strictness to allow. If my program takes a second to run, I don't want to spend several seconds performing type checks more suited for a long-running program. If my program's a network-bound server process that ought to share most of its memory, maybe I don't want to JIT things. If I'm running the final customer tests before delivering frozen bytecode to customers who won't be changing the code, maybe I want as many checks and optimizations as possible. Making the author of a module decide that is wrong. Maybe allowing a module author to request stricter typing within the module is fine, but it oughtn't be the last word on the subject. I've programmed in languages that froze certain library code at a specific level of strictness for philosophical and speed-related reasons. It was painful when I needed to do something that the language designers and library developers never thought I might need to do. Sure, I have a just a programmer hat, but that doesn't mean I can't use well-encapsulated magic when I really need it. To make this concrete -- Java's final: broken, wrong, stupid. Pick three. Types are abstractions and all abstractions break sometimes. Of the possible analysis features the compiler can perform by default, I prefer to enforce sensible symbol names, as-small-as-possible scopes, and lack of near and exact duplication. These to me are much more useful than an optional-until-someone-somewhere-uses-it type system that prevents me from finding the escape hatches purposely built into the language. -- c
Re: Proposal to make class method non-inheritable
On Wed, 2005-10-12 at 12:00 -0400, Stevan Little wrote: Usefulness aside, why do Roles and Classes need to be seperate beasts? In the current meta-model prototype, the role system is laid atop the class system so that the following is true: Class is an instance of Class Role is an instance of Class Class does Role This then means that Role also .does Role since Role is an instance of Class (which does Role). It gets very cyclical, but it essentially means that all classes can be treated as roles. This allows for all sorts of interesting things to happen actually. I've always thought that classes were more specific than roles in that you can't apply a class to another class. (Maybe that's the wrong direction of specificity. Though I am positive that .does() is more general than .isa(), I always have to stop and think about which direction co- and contra-variance goes.) Certainly I think declaring a class should imply a role of the same name, even if you can't actually apply that role and mix in state and behavior. I have to admit though, that this comes directly from Scala (so maybe we are not alone here out on the edge :) I've also heard that Sather does something similar but don't know any details. -- c
Closed Classes Polemic (was Re: What the heck is a submethod (good for))
On Wed, 2005-10-12 at 21:50 +0200, Yuval Kogman wrote: This has even more implications with closed classes to which you don't have source level access, and if this can happen it will happen - i'm pretty sure that some commercial database vendors would release closed source DBDs, for example. Closed classes should not exist. At least, they should only exist if the person *running* Perl 6 wants them to exist -- never if merely the class writer wants to close them. -- c
Re: Closed Classes Polemic (was Re: What the heck is a submethod (good for))
On Fri, 2005-10-14 at 02:18 +0200, Yuval Kogman wrote: On Wed, Oct 12, 2005 at 13:08:27 -0700, chromatic wrote: Closed classes should not exist. At least, they should only exist if the person *running* Perl 6 wants them to exist -- never if merely the class writer wants to close them. In theory I agree, and I hope that will be the defacto way of doing it, but if perl 6 gets compiled portably to many different bytecodes (which it seems like it will) someone somewhere will write a backend which allows people to encrypt, and people will use it. I think this is something we need to accept, even if it isn't something we like. I don't care if people encrypt their code. I don't have to use it. I just don't want people who merely write a module or class to be able to prevent people who actually use that module or class from using, extending, or poking around in it. No Java final, unless you're the one running the program. -- c
Re: [P6L] Closed Classes Polemic (was Re: What the heck is a submethod (good for))
On Thu, 2005-10-13 at 18:36 -0700, Chip Salzenberg wrote: On Thu, Oct 13, 2005 at 06:13:09PM -0700, chromatic wrote: I just don't want people who merely write a module or class to be able to prevent people who actually use that module or class from using, extending, or poking around in it. Sounds kind of like Linus's opinion of close-source modules. If they exist and work, he's not going to break them, but he's not going to do *anything* to specially support them. I mostly agree, but I'm not talking about the *license* of the code. I don't think that's clear to everyone reading this thread, so I think I should clarify. Regardless of the license, the author of a class or module should not be able to close off that class or module from people using that class or module who want to poke around in its guts at runtime, regardless of the license or availability of the source code. Allowing authors to say This is my namespace and you cannot touch it or This is my class and you cannot touch it or derive from it or decorate it or apply roles to it is silly, because they'll do stupid and wrong things that the rest of the world will have to work around forever, regardless of the license of their code. By all means write efficient code and well-encapsulated code and document your interfaces and intentions appropriately, but if you want to write generic and reusable code, don't optimize for situations which you can't possibly have profiled because no one has written the code for them yet. We should not encourage that. -- c
Re: Standard library for perl6? (graphical primitives)
On Sat, 2005-10-15 at 12:45 -0500, Bryan Burgers wrote: What I find exciting about parrot is that (it sounds like to me) you'll be able to run a perl6 file anywhere that has parrot, much like Java. I think what Markus is getting at is for there to be a way to display graphics through parrot everywhere parrot runs as well. Yes, different modules are extremely important, because the programmer deserves a choice, but some modules run someplaces, others run other places - it'd be a good thing to have the absolute bare essentials run everywhere. I agree, but it's not an easy question: which bare essentials are those? How big is the screen on every device where Parrot runs? Is there hardware acceleration? Is there a text-mode console? Is there a framebuffer? How many colors? Is there a back buffer? What types of input devices are available? Does the platform have POSIX support? Does it have a MMU? Can it run a compiler from the program? Is there an existing graphics library on every platform we can use or will we have to write and maintain a superset of all graphics primitives we want to provide on every platform? Does the platform support tiling or overlapping windows? Does it manage resources automatically or leave that up to the programmer? -- c
Re: Re(vised): Proposal to make class method non-inheritable
On Tue, 2005-10-18 at 10:16 -0400, Stevan Little wrote: On Oct 18, 2005, at 6:56 AM, Miroslav Silovic wrote: Uhm. I'm not sure either. :) The way I read Larry's mail, multimethods use .isa operator to detect whether $foo belongs to Foo. And for every class, Foo.isa(Foo) is true (this is exceptional behaviour of .isa). So (sidebar: it will probably use .does actually, but this an as yet unresolved detail) Consider it fairly resolved. (What? Using type as a marker of potential coercion? Yep!) -- c
Re: new sigil
On Thu, 2005-10-20 at 10:32 -0500, Steve Peters wrote: The idea of punishing programmers who choose to use certain operating system or locales just doesn't seem right to me. Haven't they already acclimated to the punishment of those operating systems already? -- c
Re: Roles vs. Classes (was Re: Ways to add behavior)
On Wed, 2005-10-26 at 20:29 -0400, Rob Kinyon wrote: I would prefer to use roles as they're closed by default, leaving class to be my powertool, if I need the power. I don't understand this desire; can you explain your reasoning? (NB: closed here, as I use it, still *does not* correspond to licensing or availability of the source code.) -- c
Re: Roles vs. Classes (was Re: Ways to add behavior)
On Wed, 2005-10-26 at 19:22 -0600, Luke Palmer wrote: But we find that many programmers make decisions that trade readability and extensibility for an extra 1% of speed, even when they are writing a command-line frontend to MPlayer[1]. If those people are module writers, then we have a bunch of modules on CPAN that are not friendly to the user who wants to use the module in the one way the writer didn't expect. Worse, that's a *theoretical* 1% of speed based on non-profiled code. And if you're going to use roles for everything because they're closed and they will gain you 2% of speed on one particular backend, then we'll have to make the same rule for them too. I know it sounds like we're babying our programmers. We are, because it's such a widespread superstition. I prefer to think of it as Helping to prevent them from writing unreusable code. And just to reinforce that it's a superstition: a theory defines a vtable. If you extend the class in an incompatible way, you have to make a new instance of its theory, defining new vtable slots. Once the new vtable is created, it is just as fast as the old one. There is no speed loss whatsoever for keeping your class open. Even further, don't forget that someone, somewhere will really need to do something you didn't think of. Either he extends your class somehow or works around it in an ugly, funky way. Which one is faster to write? Which one is faster to execute? Which one is more likely to be correct? Which one is more maintainable? -- c
Re: Ways to add behavior
On Wed, 2005-10-26 at 14:52 -0400, Uri Guttman wrote: LW == Larry Wall [EMAIL PROTECTED] writes: LW One wants to coin a word like Qlass. Unfortunately qlass is LW too easy to misread as glass. Oy veh, I'm getting notions of LW the qlass is half empty for a partially instantiated object. [EMAIL PROTECTED], i think you need some immediate mental help. please step back from the keyboard before you commit such a sin again. the next time, i will ask gloria to stick you with a knitting needle. is the smiley :) or (: ? I can't believe you missed the opportunity to write qloria. -- c
Re: Roles vs. Classes (was Re: Ways to add behavior)
On Wed, 2005-10-26 at 21:58 -0400, Rob Kinyon wrote:
Plus, the argument is a straw man. Instead of:
class Some::Class is also {
}
you would do:
class My::Version {
does Some::Class;
}
Problem solved.
Don't forget the fun of modifying all existing uses of Some::Class to
use My::Version instead, if that's even possible.
-- c
Re: $1 change issues [was Re: syntax for accessing multiple versions of a module]
On Thu, 2005-10-20 at 17:12 -0700, Nate Wiger wrote: If Perl 6 is going to be successful, this means it must change the fewest key things with the most benefits. I think there's an assumption here that not only do I not hold but I do not even understand. Suppose that I am a game developer with a small, very devoted and vocal group of fans. I interact with them regularly through IRC, message boards, and occasionally even private e-mail. I decide to create a new game and start to do some market research. Obviously I ask my core group of fans what they want. They oblige: more of everything they loved from previous games, harder difficulties, more in-jokes, and all of the new features they've always wanted in my previous games. I listen to them and write the game that my core fans want and, if I'm really surprisingly amazingly lucky, other people want it too and it's a success. More likely, it sells a few copies outside of my fanbase and I learn a painful lesson: there are more people you are not currently reaching than you are currently reaching. It's worth keeping them in mind. -- c
Re: implicitly doing a role
On Fri, 2005-11-04 at 13:15 -0500, Austin Frank wrote:
If roles are interfaces, do we want any class that provides an interface
consistent with a role to implicitly do the role? That is, if a class
fulfills all of the interface requirements of a role without actually
saying it does the role, does it do the role anyway?
No.
role Dog
{
method bark { ... }
}
class Tree
{
has $.bark;
}
A role is a named collection of behavior and state, not just a list of
method and property names. The context is highly important. It's the
difference between homonyms and allomorphs.
-- c
Implicit Role Declarations (was Re: implicitly doing a role)
On Fri, 2005-11-04 at 13:15 -0500, Austin Frank wrote: If roles are interfaces, do we want any class that provides an interface consistent with a role to implicitly do the role? That is, if a class fulfills all of the interface requirements of a role without actually saying it does the role, does it do the role anyway? After thinking about this a little more, I think there may be a bit of misunderstanding about what I want here. Having a class implicitly *do* a role if it has methods and attributes of the appropriate name is a bad idea -- there's too much room for accidental collision there. Sure, people shiny-eyed about duck typing might reasonably say Why? That doesn't make sense! but it's a careless duck typer who randomly throws objects in collections and hopes for the best. You *can* mistakenly use an object that quacks incorrectly and spend some time debugging it, but if we're providing a system that can catch some of that incorrectness, I don't see what benefit there is to subverting its ability to detect incorrectness. What I want instead, and what might seem similar in the sense that it's exactly the opposite, is implicit declaration of a role for each explicitly declared class. That is, if I declare a Dog class, there immediately springs into being a Dog role empty of everything but the expectation that whatever does that role provides everything publicly accessible that an instance of the Dog class does. You don't get the nice code-reuse of roles, but you can use your doglike object -- Mock Dog, Dog Proxy, Logged Dog, Decorated Dog -- anywhere you can use a Dog and everyone's happy. They're man's best friends, you know. -- c
Re: Hyphens vs. Underscores
On Thu, 2005-11-17 at 05:31 +0100, Daniel Brockman wrote: This is a very valid concern, but the problem will not arise unless people start mixing these two styles --- something which is very obviously not a good idea. That doesn't mean that people will avoid it, by accident or on purpose. It's a serious concern worth more consideration than just don't do it! -- c
Re: Hyphens vs. Underscores
On Thu, 2005-11-17 at 07:27 +0100, Daniel Brockman wrote: Yet you have the choice of where to put your braces, even though the braces don't lend themselves to different tasks depending on whether you put them on a new line or not. You *don't* have the choice to use different types of braces, though -- at least not by default. Is Perl 6 really in such a desperate need of new and more powerful features that issues of convenience are irrelevant? I see the proposal to treat - and _ as identical in identifiers as a feature almost as useful as making identifiers case-insensitive. Heteronymity seems too dangerous to encourage by supporting as a default. -- c
