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 16:07 -0400, David Storrs wrote:
> My understanding is that a Role is an abstract (i.e. cannot be
> instantiated) blob of methods and, possibly, data. The purpose of a
> Role is to paste it into a class--in other words, a Role is a not a
> type, it is a part of a type.
Nope, it's a type. What is a type besides a named blob of methods and,
possibly, data?
> The point of this is to force the programmer to give a reasonable
> constraint...when they expect something that Wags, does it need to be
> a Dog, or will any Animal that can Wag be sufficient? Or are they
> really looking for absolutely anything that is capable of Wagging?
The latter.
As soon as you require signatures to enforce *how* the arguments fulfill
a type constraint, you've violated a principle design goal of roles,
namely that it's more important that something fulfills the requirements
of type ("RobotDog understands bark() in the context of Doglike, not
Treelike") than that it fulfills the requirements of the type by
inheriting from a base class, delegating to a contained object, applying
a role, or whatever other way you can imagine.
-- 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
Re: MML dispatch
On Tue, 2005-07-19 at 12:37 +0200, "TSa (Thomas Sandlaß)" wrote: > I would think that the programmer specifies what type a class > implements by letting it do a set of roles. This implies that > by default a class does the very unspecific Any. Why would a class not also define a type? -- c
Re: More on Roles, .does(), and .isa() (was Re: Quick OO .isa question)
On Tue, 2005-07-19 at 18:47 +0200, "TSa (Thomas Sandlaß)" wrote:
> I strongly agree. They should share the same namespace. Since
> code objects constitute types they also share this namespace.
> This means that any two lines of
>
> class Foo {...}
> roleFoo {...}
> sub Foo {...}
> method Foo {...}
> subtype Foo of Any where {...}
>
> in the same scope should be a simple redefinition/redeclaration error.
I don't understand this. What does a scope have to do with a namespace?
Why does a code object constitute a type?
I can understand there being separate types, perhaps, for Method,
Submethod, MultiSub, MultiMethod, and so on, but I don't understand the
purpose of sharing a namespace between types and function names, nor of
having funcitons declare/define/denote/de-whatever types.
-- 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: Do I need "has $.foo;" for accessor-only virtual attributes?
On Fri, 2005-07-22 at 20:35 +0200, "TSa (Thomas Sandlaß)" wrote: > Ups, I hoped that the type system would find out mismatches of the > objects actual structure and the methods expectations of it. Essentially > rendering the method in question not applicable to the object anymore. I'm not sure that scanning every active object at every sequence point is feasable in the face of rand() and AUTOMETH(). At some point I'm willing to say that if you lie about what your classes can do and someone catches you, you'll suffer the consequences. -- 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:($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 B&D 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
Re: Perl 6 Summary for 2005-11-14 through 2005-11-21
On Wed, 2005-11-23 at 01:39 +0100, Leopold Toetsch wrote: > But my argument was: whenever you > start introspecting a call frame, by almost whatever means, this will > keep the call frame alive[1] (see Continuation or Closure). That is: > timely destruction doesn't work for example... Destruction or finalization? That is, if I have a filehandle I really want to close at the end of a scope but I don't care when GC drags it into the void, will the close happen even if there's introspection somewhere? -- c
Re: Flunking tests and failing code
On Mon, 2005-12-05 at 07:54 +, Luke Palmer wrote:
> I wonder if there is a macroey thing that we can do here. That is,
> could we make:
>
> ok(1);
> is(1, 1);
> like("foo", /foo/);
>
> Into:
>
> ok(1);
> ok(1 == 1);
> ok("foo" ~~ /foo/);
Can you do it without giving up the nice diagnostics that
Test::More::is() provides?
Note that Test.pm in Perl 5 uses ok() for everything and that DWIMmery
too often doesn't.
-- c
Re: handling undef better
On Friday 16 December 2005 18:15, Darren Duncan wrote: > Therefore, I propose that the default behaviour of Perl 6 be changed > or maintained such that: > > 0. An undefined value should never magically change into a defined > value, at least by default. This is fairly well at odds with the principle that users shouldn't have to bear the burden of static typing if they don't want it. It sounds like you want to override the coercion of undef to fail, at least in a lexical scope. Go for it. I can't see it as a default behavior though. Sure, the literal expression "6 + undef" is pretty silly, but I don't really want to write "6 + Maybe $variable" (sorry, Haskellers) everywhere when the compiler is perfectly capable of DWIMming in the 98% of cases where $variable is undefined because I like being so lazy as not to initialize explicitly every possible variable I could ever declare, being very careful to distinguish between 0, '', and undef in boolean context. I suspect the remaining two percent of cases, I won't write "6 + undef" either. -- c
Re: handling undef better
On Friday 16 December 2005 22:25, Darren Duncan wrote: > At 10:07 PM -0800 12/16/05, chromatic wrote: > >This is fairly well at odds with the principle that users shouldn't have > > to bear the burden of static typing if they don't want it. > This matter is unrelated to static typing. The state of whether a > variable is defined or not is orthoganal to its container type. I didn't say container typing. As I see it, your concern is what happens when trying to *coerce* something containing the undefined value. > But more to the point, if you assign your default values at strategic > places, you are not writing very much extra code at all. Objection: "not very much" extra code is asymptotically greater than no extra code. A change this great from Perl 5 seems like it ought to provide a whole heap of benefit to make up for the whole big heap of inconvenience everyone now has to live with. So far, I'm not even seeing a little heap of benefit. Mathematical-theoretic purity is a nice idea, but I'm usually too busy trying to do actual work to appreciate anything beyond "hey, can I write robust, maintainable working code without too much effort and time?" > Those few characters are nothing considering the amount of hassle > they can save. I didn't buy that argument from the "static manifest typing everywhere" folks either. What happens if you have a sparse array with the greatest index of 10 and you want to assign something with an index of 100? Do you have to give the array an explicit default value? What if you create it in a module somewhere? What if it's a generic array and you don't know when you create it what type of default value it should contain? What if 0 is a valid value that means something entirely different from "default initialized but unassigned"? All of a sudden, am I going to have to care about the default value of every container I create or receive from somewhere, just in case its notion of truth and definedness doesn't match mine? If so, how inconvenient is the code? If not, why not? -- c
Re: [OT?] Quote (was: "Re: handling undef better")
On Monday 19 December 2005 05:06, Michele Dondi wrote: > Speaking of which: > | The connection between the language in which we think/program and the > | problems and solutions we can imagine is very close. For this reason > | restricting language features with the intent of eliminating programmer > | errors is at best dangerous. > >-- Bjarne Stroustrup In theory, I agree. In practice, HEY look over there at that thing that is not C++! -- c
perl6-language@perl.org
On Wednesday 18 January 2006 14:13, Stevan Little wrote: > Do we really still need to retain the old Perl 5 version of &bless? > What purpose does it serve that p6opaque does not do in a better/ > faster/cleaner way? Interoperability with Perl 5 code. Now if you want to write a p6opaque <-> Perl 5 thunking layer -- c
perl6-language@perl.org
On Wednesday 18 January 2006 17:57, Rob Kinyon wrote: > Well, for one thing, you can't write OO code in P5. I'll play your semantic game if you play my what-if game. I have a fair bit of Perl 5 code. Ponie works. I want to migrate my Perl 5 code to Perl 6 slowly. Everything new is Perl 6 code. When I have a chance, I migrate classes and modules from Perl 5 to Perl 6 code. I have a handful of Perl 5 classes. One day, I need to subclass one of them. Per my goal, I do so in Perl 6. Of course, it has to interoperate with the Perl 5 in the system, per that pesky Liskov rule. If I can specify an alternate internal representation for the object corresponding to the appropriate internal representation for the Perl 5 class I'm extending, great! If not, your programming language sucks and doesn't do what the box leads me to believe that it should do -- especially if the answer is "Well you shouldn't want to do that." -- c PS - You can't write procedural code in Haskell. You can't write functional code in C. You can't write readable code in Ada. Okay, I think that's out of my system now.
perl6-language@perl.org
On Wednesday 18 January 2006 18:54, Stevan Little wrote: > Are you thinking that one would be able to bless a Perl 5 reference > into a Perl 6 package? Not really, but depending on the what Perl 6 bless() does it might work. > I would argue then that we really don't need Perl 6 &bless for this, > and we can just use Perl 5's &bless. After all, if Perl 5 can call > Perl 6 functions, then Perl 5 will need to understand Perl 6's > packages, and vice-versa. If this is true then Perl 5's bless should > be able to accept a Perl 6 package value and DWIM. However, this > would probably be a somewhat ugly solution to whatever problem it is > you are trying to solve since your Perl 6 code would be weighted down > with Perl 5 OO-isms. In fact, I would argue that doing it this way is > not the right way, and instead using Perl 6 OO and delegating to a > Perl 5 object is a better option. In the long-term sure. However, I don't know how far interoperability will get if we expect everyone to do everything The Right Way all at once. > Or are you thinking that a Perl 6 value should be blessed into a Perl > 5 package? That's closer to what I had in mind. > I think there is a real serious issue here since the hash the Perl 5 > package would be expecting is a ref to an HV, and the Perl 6 value it > would be getting would be an instance of the ^Hash class (itself a > subclass of ^Object). This is actually where i see the fundemental > problem with a Perl 6 &bless which is capable of blessing Perl 6 > references. There are no Perl 6 references like we had in Perl 5, > they are *all* objects now. Would not the Perl 5 layer see the Perl 6 > instance of ^Hash as an object? If not, then we must already have a > Perl 6 opaque (the ^Hash instance) to Perl 5 HV converter/proxy/magic- > jellybean/thunk so I don't need to write it :) Why would Perl 6 bless() bless references? I've always seen it as specifying the underlying storage container for the object's instance data. (Hey, my last rigorous reading of S12 predates my current project. I could be wrong.) If Ponie is there and this code runs on Parrot and Ponie uses Perl 5 PMCs, they're theoretically available to Perl 6, with the proper invocations or magic or thunking or whatever. > Or maybe you are you thinking that a Perl 6 class can inherit from a > Perl 5 class? Absolutely. > To be honest, i think this is better handled with delegation, and can > even be automated using the attribute delegation features described > in A/S12. I have serious doubts about round-tripping with delegation, having tried to do it. I want to subclass a Perl 5 class with Perl 6 code and use objects of that class within Perl 5 code without them having to know that I'm doing something sneaky. It'll be a true pity if that's *truly* impossible. > The biggest problem with this would be object initialization. The > normal Perl 6 BUILDALL/BUILD code could not be used here since Perl 5 > does not have the meta-object protocol to support such behaviors, nor > is there a common enough Perl 5 object initialization idiom to work > with here. The end result is that you probably end up having to do a > bunch of manual initialization code. Sure, but that's a per-representation thunking layer writable in Perl 6 code. It might be somewhat tricky, but it's not completely hideously unsolvable code -- if it's possible. > And let's not forget that our Perl 6 blessed hash is not the same as > the Perl 5 blessed hash, so there might be confusion/issues there > too. We also have the issue here of where does ^Object fit into our > inheritance now? Is the Perl 5 package the top of our @ISA tree? or > do we insert ^Object in there somewhere too? > > Or maybe you are you thinking that a Perl 5 class can inherit from a > Perl 6 class? I'm not nearly Australian enough for that kind of madness. > So in conclusion, I think that a Perl 6 &bless which acts like a Perl > 5 &bless is not as useful as your seem to indicate. I'm pretty sure that's not what I was advocating. I'm pretty sure the design thinking has always been: 1) by default, your object is opaque 2) if you don't want this, you can always use bless() For interoperability with Perl 5 classes, I don't want to use an opaque object. Ergo, I want to use bless() (or something, but does that explain why I think bless() is important?). > It is certainly not the magic bullet of interoperability. I don't think we > can really avoid not having a p6opaque->p5-blessed-ref magic-thunker. I don't want to translate opaque objects into blessed references. They should be opaque everywhere. I do want the option to rewrite as little Perl 5 code as possible just to get the program to work, though. -- c
perl6-language@perl.org
On Wednesday 18 January 2006 19:11, Rob Kinyon wrote: > As for how that will be handled, I would think that it would be as follows: > - in Perl6, objects created in another language will be treated as > p6opaque (unless some other unbox is a more suitable $repr). ... and I specify this exactly how? -- c
perl6-language@perl.org
On Wednesday 18 January 2006 19:39, Rob Kinyon wrote: > No, you want to specify the $repr in CREATE(). But, p6hash will still > not be the same as a ref to an HV. Frankly, I think you're better off > letting Parrot mediate things the same way it would mediate Ruby and > Perl6 or Perl5 and Python. Worrying about it in userland is just going > to cause you headaches. Answer me this then -- under your scheme, can I subclass a Perl 5 class with Perl 6 code, instantiate the subclass, and use that object in Perl 5 code as if the subclass were Perl 5 code, without rewriting all of my Perl 5 code? -- c
Re: Class methods vs. Instance methods
On Thursday 19 January 2006 06:48, Rob Kinyon wrote: > "Any practical programming language with structural subtyping will > probably let you create and use aliases for type names (so you don't > have to write the full form everywhere). However, the underlying type > system will only consider the structure of the type when doing its > job." > > What's wrong with Perl doing things that way? duck-typing with names > ... sounds like a plan to me ... Accidental structural equivalence is a problem -- it's one of the things wrong with C's so-called type system, for example. I like to think of roles as nominally-tagged (and checked) structural subtyping. When you're *defining* a type, its structure matters. When you're *using* it, its behavior matters. It would be nice to keep those two separate. -- c
Re: Perl 6's &bless is (seriously) broken
On Thursday 19 January 2006 13:10, Rob Kinyon wrote: > &bless was a brilliant idea for Perl5. It's wrong for Perl6. Perhaps you meant to write "Tagging a reference with a package name worked for Perl 5. It's wrong for Perl 6." Certainly I can agree with that. Yet this whole discussion feels like the argument that there should be no system() operator in Perl 6 because the system() operator in Perl 5 returns the wrong value. -- c
perl6-language@perl.org
On Wednesday 18 January 2006 20:02, Rob Kinyon wrote: > On 1/18/06, chromatic <[EMAIL PROTECTED]> wrote: > > Answer me this then -- under your scheme, can I subclass a Perl 5 class > > with Perl 6 code, instantiate the subclass, and use that object in Perl 5 > > code as if the subclass were Perl 5 code, without rewriting all of my > > Perl 5 code? > > You have two cross-language interactions. > 1) Subclass a LangX class in LangY > 2) Instantiate a LangY class and use that object in LangZ > That LangX === LangZ is irrelevant to the discussion. Unless, of course, if $omeone had promised backwards compatibility with LangZ 5 from LangY 6. > So long as you aren't peeking behind the curtain (method calls only), > Parrot should be able to mediate everything. In other words, if your > code is good OO code, then you shouldn't have any problems. In other words, your answer to my question is "no". Fine. Next question. If Ponie and Perl 6 are both running on Parrot, and if Ponie has PMCs that represent Perl 5 data containers, such as p5hash, p5array, p5symbol, and so on, what's the problem with having a Perl 6 object that uses one of those PMCs as its internal storage? I realize one of Stevan's objections is "But if you use a Hash, does your object automatically support the .keys method and .kv and so on?" to which I reply "No, of course not. That's silly. It just uses the Hash for *storage*." Is that your objection to bless()? I don't mean to handwave here -- there are definitely issues to consider when crossing a language boundary related to method dispatch (and the last I remember from design meetings was "things change there and you shouldn't expect that they stay the same"), but the resistance to allowing different storage types for objects completely baffles me. Or is the question about "Why is there a need for bless() when you can already pass arguments to CREATE()?" In that case I dunno. -- c
perl6-language@perl.org
On Thursday 19 January 2006 19:50, Rob Kinyon wrote: > Nothing. Just like it's not a problem if Perl6 uses one of the > Ruby-specific PMCs for storage. In fact, the alternate $repr idea is > specifically to allow for the use of foreign datatypes as storage. > Luke's excellent example is to use a C-struct as your storage. ... but ... > Storage of what? What are you trying to do that you need to use an > object to store your attributes? Why aren't you just using the method > -that- object is using? I can't reconcile these two paragraphs. > No. My objection to bless() is BUILD() and CREATE(). There's already a > mechanism in the P6 OO system for specifying the internal > representation of the instance. This is Perl. The "there should be one obvious way to do it" ship, canoe, raft, and water wings have sailed, paddled, floated, and inflated. -- c
perl6-language@perl.org
On Friday 20 January 2006 07:14, Rob Kinyon wrote: > I think this entire issue is rising out of the fact that very very few > people in this discussion are familiar with the design of the MOP. > Stevan and a few others are the primary movers and I'm lucky enough to > have been Stevan's sounding board for a few pieces. Once you grok the > MOP, it's really hard to imagine wanting to use bless(). I don't think that it's a fair assumption that, for example, I haven't followed the metamodel discussions and designs. Nor do I think it's a fair assumption that people who want to interoperate with a lot of Perl 5 code should have to understand the finer points of metamodels and metaobject protocols in the default case. -- c
perl6-language@perl.org
On Thursday 19 January 2006 21:53, Stevan Little wrote:
> Okay, so when you say alternate storage then you mean that a class
> like this:
>
> class Foo {
> has $.bar;
> method new ($class, %params) {
> $class.bless('p5Hash', %params);
> }
> method baz {
> $.bar += 1;
> }
> }
>
> should use a PMC representation of a p5 hash as it's storage, and
> that the method baz does the right thing here?
Yes.
> Because that makes sense to me. However, what doesn't make sense
> would be if I had to write &baz like this:
>
> method baz {
> self->{'bar'} += 1;
> }
>
> In other words, if this is just a detail of the storage, and does not
> affect user code at all, then I am okay with it. This though would
> mean that you would not have direct access to the underlying data
> structure (the p5 hash).
I don't think it's impossible, but it's fairly ugly and I'm okay if you can't
do it by default from the Perl 6 side. I certainly wouldn't use it.
From the Perl 6 side, I would rather use Perl 6 looking code.
> Okay, then I assume you mean it to behave the same way as with the
> p5hash, that it is completely transparent to the user that you are
> using a p5hash or a p6hash or a p6opaque?
From Perl 6? Yes.
> In which case,.. I say okay. But note again that you have not
> provided access to the underlying data structure (the p6hash a.k.a -
> an instance of ^Hash).
Agreed.
> With p5, you /can/ get to the underlying data structure. This is a
> break which will hamper the backwards compatibility effort I think.
With Perl 5, you can *appear* to get to the underlying data structure. Yet
tie() is basically free on Ponie and there's a metaclass mediating access to
the underlying storage. I think that makes the problem solvable.
(Does using an alternate type of storage mean you need an alternate metaclass?
Perhaps, perhaps not -- but the practical effects of syntax have to come from
somewhere.)
As long as you can use Perl 5 classes in Perl 6 without rewriting all of the
Perl 5 code, I'm happy.
-- c
Re: A proposition for streamlining Perl 6 development
On Tuesday 07 February 2006 13:28, Yuval Kogman wrote: > Right now the biggest problem in Perl 6 land is project management. I disagree, but even if it were true, I don't think the solution is to add more project management and design to partition the process into even more subprojects of nebulous definition and dubious benefit. If you *want* Perl 6/Scheme running on Spidermonkey, that's cool. I just don't see an army of volunteers magically appearing to make it work, not in the least because it's Yet Another Rewrite From Scratch. -- c
Re: A proposition for streamlining Perl 6 development
On Tuesday 07 February 2006 14:17, Yuval Kogman wrote: > If we have more steps and clearer milestones for whatever is between > parrot and the syntax/feature level design implementation will be > easier. Parrot has had such milestones for well over a year. > De-facto we have people running PIL on javascript. > It works more than parrot does. No, it works *differently* from Parrot, just as an LR parser works differently from an LR parser. Don't make the mistake of thinking "Wow, it took Parrot X months to get a working PGE, while the Pugs version only took Y weeks", especially because the Pugs version had the benefit of looking at *already designed, debugged, and tested* Parrot code. > The design of Perl 6 itself should be agnostic to where people are > developing backends IRL. That's a nice goal in the sense of diversity, but I remain unconvinced of its utility in speeding up the implementation. Every abstraction comes at a price. The recent velocity of Pugs toward the goal of running on N multiple backends rather than one backend seems to argue that education is still cheaper than ignorance. -- c PS - Yes, that *is* a Greek-English pun. Language interoperability is a good thing.
Re: A proposition for streamlining Perl 6 development
On Tuesday 07 February 2006 15:56, Stevan Little wrote: > The Pugs project and the Parrot project have had very different goals > actually (at least Pugs did from the early days). Pugs aimed to be > able to evaluate Perl 6 code, as a way of testing the language > features and design. It did not really attempt (until the PIL work > began) to provide a VM for Perl 6 to run on. In my mind, that's the most valuable thing Pugs could do. > And even the PIL work began as a way to strip Perl 6 down to a more > managable core calculus which was easier to interpret, the multiple backends > seemed to grow out of that as a side-effect. But they're not free to support. Now I'm not arguing that the existence of multiple backends takes effort away from a single unified backend. This is open development. People work on what they want to work on. Still, finding the greatest common factor of features between LLVM, Scheme, Spidermonkey, classic Pugs, Parrot, the CLR, the JVM, Perl 5, and whatever other VM is out there means pushing a lot of things up the implementation stack. > Much of what Yuval is proposing is ways to fill that hole and to > decompose and refactor the current Perl 6 development process so that > we can have a real production Perl 6 to play with that much sooner. I agree that that's his goal. I disagree on its appropriateness. There are people who can write a bootstrapping compiler from the top down in such a way that normal people can write the user-level primitives in that language. I've met those people. I'm not one of them. There are precious few of them for any language, much less Perl 6. It's not fast. It's not free. It's not clear that they'll suddenly appear to do this work if there's a comprehensive, intelligible rework of the Perl 6 plan. I could be wrong and if Yuval writes the plan and it works, great! I'm happy to be wrong. > But also have a Perl 6 that some PhD canidate can re-write the > type-checker for his thesis project or that some volunteer hobbiest > can re-implement the core in FORTH or some open source hacker can hack > the circular prelude to make the Schwartzian transformation that much > quicker and efficient. Again, I can see the theoretical benefit to that, but it's still not free. The well-worn adage is "Good, fast, or cheap -- pick two." Perl 6 development right now is cheap but hopefully good. Reducing the goodness might make it faster. Reducing the cheapness might too. I think the real problem is somewhere in there. > IMHO breaking down the project into smaller more digestable chunks > carries as much risk of failure as putting all the eggs into single > Parrot nest. Exactly how is Yuval's proposal making the chunks more digestible? There's sort of a dearth of Scheme, CLOS, Haskell, and Scala experts in Perl 6 development right now. Where are they going to come from to write all this stuff? -- c
Re: A proposition for streamlining Perl 6 development
On Tuesday 07 February 2006 23:55, Yuval Kogman wrote: > Does this imply that we should think up this process? Go ahead. > If I propose a concrete plan for the implementation of Perl 6 in a > layered fashion it will probably be even more overlooked. > > I have no authority, and this is not something I can do on my own. If other people find it valuable, that's all the authority you need. The last time someone tried to set forth a complete specification in a particular order was the Perl 6 documentation project. That didn't work then. I have doubts that specifying a complete compiler and toolchain without at least some trial and error will work, but I could be wrong. Maybe the right place to start is to gather a list of all of the questions you need to have answered and all of the features people want, and then try to unify them into a Perl 6-ish whole. -- c
Re: Instance attributes collision
On Sunday 12 February 2006 17:11, Yiyi Hu wrote:
> For perl 6,
> Array and Scalar are in different namespace.
> So,
> class A { has $.a; has @.a };
>
> what will A.new.a return by default?
>
> An Error? or Scalar has a higher priority?
Seems like a compile-time warning (at least) to me.
-- c
Re: foo..bar or long dot and the range operator
On Wednesday 12 April 2006 00:06, TSa wrote: > Doesn't that discontinuity devalue the long dot? Its purpose is > alignment in the first palce. For a one char diff in length one > now needs > > foo. .bar; > self. .bar; > > instead of > > foo .bar; > self.bar; Or even: foo.bar; self.bar; I *still* don't understand the problem this long dot is trying to solve. -- c
Re: A shorter long dot
On Saturday 29 April 2006 16:58, Yuval Kogman wrote: > On Sun, Apr 30, 2006 at 10:49:45 +1000, Damian Conway wrote: > > This would make the enormous semantic difference between: > > > >foo. :bar() > > > > and: > > > >foo :bar() > > > > depend on a visual difference of about four pixels. :-( > > You're not counting the space around the dot, which counts. To me > they look completely different Two invisible things look completely different to you? -- c
Re: A shorter long dot
On Saturday 29 April 2006 18:29, Yuval Kogman wrote: > If dots looked like this: > > > > then they would be invisible. Use a laptop with a speck of dust in the wrong place in slightly wrong lighting and the wrong four pixels might as well be invisible. Precious few of @Larry deserve the nickname Ol' Eagle Eye. This really doesn't seem like a place to argue for such subtlety when the difference in behavior is so large. -- c
Re: A shorter long dot
On Saturday 29 April 2006 21:50, Damian Conway wrote: > Is: > > > $antler. .bar; > > $xyzzy. .bar; > > $blah. .bar; > > $foo. .bar; > > really so intolerable, for those who are gung-ho to line up the method > names? I'm still wondering what's awful about: $antler.bar; $xyzzy.bar; $blah.bar; $foo.bar; -- c
Re: [svn:perl6-synopsis] r9197 - doc/trunk/design/syn
On Thursday 11 May 2006 14:54, Smylers wrote: > What about :gappy, to indicate that there have to be gaps in the source > text at the points where there are gaps in the pattern? I like this better. Forming a new compound word and then abbreviating it seems confusing -- and I'm a native English speaker. -- c
[svn:perl6-synopsis] r9305 - doc/trunk/design/syn
Author: chromatic Date: Sun May 21 14:11:09 2006 New Revision: 9305 Modified: doc/trunk/design/syn/S06.pod Log: Minor typo fix. Modified: doc/trunk/design/syn/S06.pod == --- doc/trunk/design/syn/S06.pod(original) +++ doc/trunk/design/syn/S06.podSun May 21 14:11:09 2006 @@ -53,7 +53,7 @@ =head1 Routine modifiers B (keyword: C) are routines that can have multiple -variants that shares the same name, selected by arity, types, or some +variants that share the same name, selected by arity, types, or some other constraints. They may have multliple invocants. B (keyword: C) specify the commonalities (such
Re: optimizing with === immutable comparitor
On Friday 14 July 2006 00:30, Darren Duncan wrote: > This may go without saying, but ... > > If $a === $b means what I think it does, then I believe that a > not-premature implementation optimization of === would be that it > always $a := $b if it was returning true, so that any future === of > $a and $b or aliases thereof could short-circuit with a =:= test even > if they weren't created as aliases, and Perl would be automatically > more memory efficient without those extra storage copies. > > I know that was an implementation issue, but I think that it stands > to be explicitly stated anyway, as it is a very simple and effective > way to make Perl programs more resource efficient, possibly by orders > of magnitude, over not doing so. First there was copy-on-write and now there's share-on-compare? > (The only time this may not work is if so-called immutable types are > tied to external resourses, but then I'm not sure how often this > would happen in practice so it could just be an exception if > necessary. The above-stated rule would still stand for any resources > managed by Perl itself.) In the absence of much Perl 6 code either way, I wonder at the value of adding such an extreme side effect to a simple comparison operation. This goes way beyond loop hoisting and constant folding. I can understand singleton value types (even Perl 5 does that with PL_undef), but ... wow, you have a lot more faith in local code analysis than I do. -- c
Re: Fwd: Classes / roles as sets / subsets
On Tuesday 29 August 2006 13:26, Jonathan Lang wrote: > Perl6 handles both object-orientation (through inheritance) and > role-playing (through composition). What exactly does inheritance have to do with object orientation, except that some OO systems support inheritance? Plenty of OO systems get along just fine without it. I wrote a fuller explanation of roles in my work weblog: http://www.oreillynet.com/onlamp/blog/2006/08/roles_composable_units_of_obje.html -- c
Re: class interface of roles
On Monday 02 October 2006 08:58, Jonathan Lang wrote:
> I wonder if it would be worthwhile to extend the syntax of roles so
> that you could prepend a "no" on any declarative line, resulting in a
> compilation error any time something composing that role attempts to
> include the feature in question. So, for instance, you might have
>
> role Bar {
> no method baz (Num, Str);
> }
>
> class Foo does Bar {
> method baz (Num $n, Str $s) { ... } # compilation error: Bar
> forbade this method!
> }
This feels like the false-cognate problem waiting to creep back in.
-- c
Re: "Don't tell me what I can't do!"
On Monday 02 October 2006 12:32, Jonathan Lang wrote: > Before we start talking about how such a thing might be implemented, > I'd like to see a solid argument in favor of implementing it at all. > What benefit can be derived by letting a module specify additional > strictures for its users? Ditto for a role placing restrictions on > the classes that do it. Benefit #1: incompetent programmers who really really need to write mission-critical code (the ones that the Java designers apparently had in mind) now have only a million ways to write terrible code. Uh, that's it. -- c
Re: "Don't tell me what I can't do!"
On Tuesday 03 October 2006 10:06, Aaron Sherman wrote: > Would there be such tools used in the core libraries? Maybe, maybe not, > we could discuss that. If they were implemented in the core libraries > would there be a universal "no bondage" flag that shut them off? > Probably, since that's something that Perl tends to like doing. The assumption I remember from the design meetings was always "No library designer has the knowledge or the right to tell me how fast or strict my program has to run." Whatever B&D you do in the privacy of your own modules is fine, but if it leaks out past encapsulation boundaries, expect that somewhere you might offend community standards. In my opinion,Perl 6 should spell "no bondage": #!/usr/bin/perl6 -- c
Re: "Don't tell me what I can't do!"
On Wednesday 04 October 2006 01:05, jesse wrote: > One of the things that many shops have defected from Perl to Java for > is the additional handcuffs that Java provides for less-than-experienced > developers. Giving me the power to control what my team, or folks using > my language variant, do could be a huge win. The point is that the person writing the program decides which handcuffs or costumes all of the code has to wear, not the person writing the libraries. If you want to set a policy for your organization, that's fine. It is just Not Okay for me or anyone to write a module right now that dictates exactly the strictness of every program written in the next twenty years that uses it. -- c
Re: "Don't tell me what I can't do!"
On Wednesday 04 October 2006 12:09, jesse wrote: > Perhaps I'm misunderstanding what you mean by "person writing the > program" and "person writing the libraries." In fact, I've _gotta_ > be. I'd like to be able to put my strictures in a library rather than > forcing them into the main body of a program. Are you saying > you don't want to let people do this? Let me rephrase. Libraries and modules can be as strict or as lax as they like, but the program *using* those libraries and modules should always be able to override those strictures. If you write a class in a library and declare it as closed, that's fine -- but any program that uses the class should always have the option of saying "Nope, not closed. I need to do something with it." It's the person *using* the libraries and modules and classes who knows how strict they need to be, how closed they need to be, and how optimized they need to be. If any of those policies are irreversible--if they leak out of libraries and modules and classes--then there is a problem. -- c
Re: "Don't tell me what I can't do!"
On Wednesday 04 October 2006 12:48, jesse wrote: > Ok. So, I think what you're saying is that it's not a matter of "don't let > people write libraries that add strictures to code that uses those modules" > but a matter of "perl should always give you enough rope to turn off any > stricture imposed on you by external code." > > Do I have that right? Yes. You might also add "... or enable further strictures", but that sounds like what I was trying to say. -- c
Re: "Don't tell me what I can't do!"
On Wednesday 04 October 2006 13:25, Trey Harris wrote:
> I read it as "yes, you *can* put strictures on the using code into a
> library, though I wouldn't do it and would say that any module that does
> so shouldn't be released on CPAN for general use. But even if you can do
> that, you *must* always be able to turn the strictures back off."
> chromatic, is that a fair paraphrase?
Yes.
> I don't have any problem with that sentiment--if I were you and needed to
> enforce some style on other programmers who work with me, I'd just tell
> them to use my library and not unuse it. It's a human problem, not a
> technical one, if they insist on unusing it by nefarious means.
Very much so. It seems silly to put up barriers such that clever people have
to use ugly and hackish tricks to do clever things while attempting to use
technology to solve the social problem of other people doing really bad
things. If you violate my first law of software development ("Don't hire
monkeys!"), then you should at least follow its corollary ("Train your
monkeys well and watch them very carefully. Note how unfulfilling your life
is for violating the first law.").
> That philosophy doesn't present any problems with DBC checks, which as I
> mentioned before probably have to handled as a program-global flag rather
> than as a lexical pragma anyway. (I'm toying with the notion of
> "jurisdictions" that packages could subscribe to across which a set of
> contracts would be enforceable, allowing them to do DBC while still using
> or being used by code out in some other lawless jurisdiction. Code that
> doesn't explicitly join some jurisdiction would by default be lawless,
> thus living by the philosophy chromatic's espousing. I think that could
> be made to work, though jurisdictions would have to be at a package, not
> scope, level. I need to think about it more, though.)
That sort of thing ought to be quite possible, but the less work we spend on
giving people the illusion that this discipline is inescapable and perfectly
capable, the more time we'll have to tell them how to avoid hiring monkeys,
which actually fixes more problems in software development than anything else
I've ever seen.
-- c
Re: how typish are roles
On Wednesday 25 October 2006 03:04, Trey Harris wrote: > I'll let @Larry speak for @Larry, but at one point I was told that when > C or C appear in signatures, those are roles, not classes; if > you examined a particular Array or Hash, the class would be some > implementation of the Array or Hash role, perhaps something like > C or C or so on. So I'd tend to agree > that roles "are the heavyweights in the type department." Yes. When you specify a type to constrain some operation, you specify that the target entity must perform that role. > Unless you're actually composing or inheriting from something, you > shouldn't care whether its type derives from a role, a class, a type set, > or a type parameter. Yes. > I think the question (which you didn't directly raise, but I've heard from > others) of whether "role" or "class" will have primacy is kind of as > pointless as asking whether "subroutines" or "code blocks" have primacy: > you can't use the former without the latter; the former is a useful > abstraction for the latter, especially when code gets larger or is meant > for sharing; and while each have places where they're more appropriate, > either can be used in place of the other given a bit of syntactic > twiddling. Well... maybe. I believe strongly that you can build a really good system with roles as the fundamental abstraction and where classes are a specialization, but doing the other way around is much more difficult and less cohesive. > I can read S12 as saying that classes always do an eponymous role, and so > role is what typing is "really" based on. Yes. > In other words, I agree that it's fuzzy, but I personally read the > fuziness as intentional, so as to allow implementations flexibility and > prevent bad dependencies on particular "inner workings" of the type > system. That fuzziness is classic $Larry. Some of the rest of @Larry can be more *mumble*matic. -- c
Re: where constraints as roles (was Re: how typish are roles)
On Saturday 28 October 2006 09:15, Larry Wall wrote: > My initial inclination is to say that "where" clauses in a signature > are only there for pattern matching, and do not modify the official > type of the parameter within the function body. However, on a "subset" > the "where" clause is there precisely to contribute to the typing, > so if you want the extra constraints to apply to all uses of the > parameter variable within the body, you'd need to declare a subset > type that enforces it. Right; it's awfully difficult to have nominal typing in a room full of blank "Hello my name is" tags. > On the other hand, I can imagine that an alternative would be to say > that a "where" clause will always "subsetize" the official type; > that would imply that we'd need to add a "when" clause for mere > pattern matching. Something to be said for making such a distinction, > if it can be taught. -- c
Re: Y not
On Tuesday 20 February 2007 12:42, Larry Wall wrote: > 'Course, if someone goes ahead and adds the Y combinator, one must > naturally begin to wonder what the YY combinator would be... :-) Obviously it generates a function so anonymous that it can't even refer to itself. I call it the depressed existentialist solipsist operator. -- c
Re: What criteria mark the closure of perl6 specification
On Saturday 24 February 2007 22:42, Richard Hainsworth wrote: > But while perl6 continues > its evolution, without a tangible end, few are going to dedicate time > and effort to write documentation for such as me. (eg. How out of date > are the Exegesis files?) You could make a very similar argument for Perl 5. I'm not sure anyone expected--as recently as a year ago--that 5.10 would get a slew of new regex features, for example. -- c
Re: What criteria mark the closure of perl6 specification
On Sunday 25 February 2007 12:56, Geoffrey Broadwell wrote: > As I mentioned in another thread, but didn't make clear in that email: I > don't need a "finished" spec. I need the *current* version of spec to > actually be mostly implemented. The implementors want the same thing. > And if it's not fun, I won't end up putting any of my very > limited free time into it. Neither will the implementors. -- c
Re: What criteria mark the closure of perl6 specification
On Sunday 25 February 2007 13:57, Geoffrey Broadwell wrote: > I'm not trying to say that the implementors should rush either, nor am I > complaining about current status; I grok the dynamics of volunteer code. > I merely disagree with the "spec is all-important" crowd. I personally > have a preference for "rough consensus and working code", and I wanted > to make sure that viewpoint wasn't lost. Me too. I also want to point out that we're not nearly at the point where adding more developers--for as much or as little as they want to contribute--will slow things down. -- c
Re: Packed array status?
On Sunday 25 February 2007 12:40, Geoffrey Broadwell wrote: > What backends support packed native arrays at this point? And what's > the performance like? Parrot does have ManagedStruct and UnManagedStruct PMCs for mapping complex C structures. The syntax to define them is a little grotty, but once you've done that, using them is easy--especially with named access. Performance is good. You don't have to cross the C/HLL boundary to work with the memory, as Parrot can do that directly. I don't know if Patrick has using PIR libraries working in Perl 6 yet, but the last time we talked about it, he said it would take just a bit of work. Wrapping well-designed libraries for Parrot's NCI is easy. I can show you the basics in an hour and you'll be well on your way. -- c
Re: Packed array status?
On Monday 26 February 2007 11:29, Geoffrey Broadwell wrote: > Does Perl 6 on Parrot have Perl 5 connectivity? Not until Perl 6 can use PIR code. After that, it depends on what you want to do with the two. If you can get Parrot::Embed compiled and running on your machine, Perl 5 can have Parrot connectivity. (As far as I know, Windows is the only broken platform now, but I already knew that.) -- c
Re: Working on punie + rindolf (the implementation) Reloaded
On Tuesday 10 April 2007 18:51, Shlomi Fish wrote: > > (Although it seems the most interesting promises made by parrot - fast > > typeless code for example - are not going to be delivered, too). > Hmmm I haven't been closely following Parrot. Despite this mention, this thread is off-topic for the Parrot list, and probably the Perl 6 Language list too. The Parrot list is happy to discuss implementations and languages targeting Parrot. Complaints are welcome only in the form of bug reports sent to [EMAIL PROTECTED] Neither flames nor whining are welcome at all. -- c
Re: Is Perl 6 too late?
On Thursday 03 May 2007 03:06:43 Andrew Shitov wrote: > What is nedded is a very simple step: Contributors. -- c
Re: Is Perl 6 too late?
On Sunday 13 May 2007 15:42:30 Thomas Wittek wrote: > What makes Perl hard to read is the excessive use of special characters > (/\W/). It also makes Mandarin and other ideographic languages impossible to read. As evidence I admit that, though I am very smart, *I* can't read them. (Try to ignore the billion-plus people who can.) > Global variables with cryptic names, that no beginner can make any sense > of by reading it. And after not working with "$<" for some months I > can't remember it either, although I've got quite some Perl experience. Most of those have gone away. > Additionally I'm not a friend of sigils: I'm not a friend of potential conflicts between built-in operators and my identifier names (and especially the conflicts between scalar, aggregate, type, and function names). > I would also like semicolons to be optional. There are far more cases of > single line statements than multiline statements. So you would save > quite some characters, when the semicolon would be optional and you > could concatenate multiline statements with e.g. a backslash. When (smart) people talk about Python's whitespace problem, they don't mean *horizontal* whitespace. > Some say that there are too much operators in Perl(6). I partially > agree. That's like saying there are too many function calls in Scheme. Perl's an operator-oriented language! > People not only want code that _is_ sexy, but they also want it to > _look_ sexy. You'll have to find me more than a handful of Dylan hackers to start to convince me of that! -- c
Re: Is Perl 6 too late?
On Monday 14 May 2007 04:28:15 Thomas Wittek wrote: > > I'm not a friend of potential conflicts between built-in operators and my > > identifier names (and especially the conflicts between scalar, aggregate, > > type, and function names). > As I partially wrote Moritz, I > a) don't think that it's the case very often. you have to write the > sigil a thousand times where it wouldn't be useful for only 1 case where > you'd have a name conflict. > b) even if there would be a conflict, it might be considered bad style > to use identical identifiers (besides the sigil) for different things > (vars/objects/subs/operators/...). theproblemlinguisticallyspeakingisthatsometimespunctuationishighlyimportant\ fromareadabilitystandpointyoumaynotliketheuseofspacescommasdashesupper\ casinghyphensandperiodsbutitmakesatremendousdifferencetoreadabilitywhether\ youlikeitornotasitmaybebadstyleifyoudontputspacesbetweentwowordsandtheresult\ lookslikeawordthatsomeonemaydefineinthefuture There *are* a few linguists involved in Perl. > So semicolons don't seem to be the best invention since sliced bread. > There should be extra-syntax for the rare cases (multiline) and not for > the common ones. Somehow English seems to get by with periods at the ends of statements, though almost no one pronounces them. > But I don't like doing implicit type casting with operators. > It's even discouraged in Perl5 as we have a warning for that. > So maybe it'd be a good idea to completely drop it. I can't really see that changing DWIM to DWTWM is anything but a step backwards in Perlishness. > >> People not only want code that _is_ sexy, but they also want it to > >> _look_ sexy. > At least almost everyone to whom I said, that I do most work in Perl, > responded with some sentence containing the word "ugly" or "unreadable". > To get away from that image, it's neccessary to do some radical changes > I think. I agree. You need less ignorant colleagues. I'm not sure Perl 6 can fix that. By the way, I'm still waiting to meet your cadre of Dylan hackers. -- c
Re: Is Perl 6 too late?
On Monday 14 May 2007 04:35:19 Thomas Wittek wrote: > BTW: Why do so much people say "go away if you don't like it" instead of > being open for ideas and discussing them from a neutral point of view? Perhaps you're not a native English speaker, but running into the room and saying "Perl 6 doesn't have a compelling vision", "Everyone thinks Perl is ugly", and "Python and Ruby are doing things better than Perl 6" is *not* the way to start a friendly and neutral discussion, as if a sane, calm, neutral discussion of programming language designs and tradeoffs were possible. -- c
Re: Sigils by example
On Monday 14 May 2007 15:48:24 Thomas Wittek wrote: > But it should be no problem to put out a warning/error at runtime (or > maybe even at compile time) when a variable name clashes with a method > name. Do you always know all of the method names in your entire memory space at compile time? -- c
Parrot 0.4.12 "Of the Caribbean" Released
As I sailed into Shadow, a white bird of my desire came and sat upon my
right shoulder, and I wrote a note and tied it to its leg and sent it on
its way. The note said, "I am coming," and it was signed by me.
...
The sun hung low on my left and the winds bellied the sails and propelled
me onward. I cursed once and then laughed.
I was free and I was running, but I had made it this far. I now had the
chance I'd wanted all along.
A black bird of my desire came and sat on my left shoulder, and I wrote a
note and tied it to its leg and sent it off into the west.
It said, "Eric--I'll be back," and it was signed: "Corwin, Lord of Amber."
A demon wind propelled me east of the sun.
-- Nine Princes in Amber, Roger Zelazny
On behalf of the Parrot team, I'm proud to announce Parrot 0.4.12 "Of the
Caribbean." Parrot (http://parrotcode.org/) is a virtual machine aimed at
running all dynamic languages.
Parrot 0.4.12 can be obtained via CPAN (soon), or follow the
download instructions at http://parrotcode.org/source.html.
For those who would like to develop on Parrot, or help develop
Parrot itself, we recommend using Subversion or SVK on the
source code repository to get the latest and best Parrot code.
The next release will take place on 19 June 2007.
Parrot 0.4.12 News:
- Build:
+ even more refactorings and improvements in configuration system
+ improved tests and documentation for configuration system
- Languages:
+ Updated abc, PHP ("Plumhead"), Lua, Tcl
+ Reclaimed Lisp
- Design:
+ new PMC PDD draft partially completed
- Implementation:
+ continued implementation of PDD 15 (Objects)
+ minor garbage collector and memory management improvements
+ several memory leaks resolved
+ extended support for compilers other than GCC
+ improved C++ compiler compatibility
+ enhanced support for Solaris, non-MSVC Win32, and other platforms
Thanks to all our contributors for making this possible, and our
sponsors for supporting this project.
Enjoy!
Re: propose renaming Hash to Dict
On Thursday 31 May 2007 17:36:40 Chas Owens wrote:
> Except of course those poor schmucks who foolishly wrote code like
>
> if (ref $arg eq 'HASH') { ... }
I know you're teasing, but it *would* be nice to see that sort of code just
magically go away.
-- c
Re: Web Module (Was: Perl6 new features)
On Thursday 21 June 2007 15:23:38 Smylers wrote: > Has Larry yet decreed whether Web will be bundled with Perl 6? I also like to proceed from the assumption that the only core modules should be those required to install other modules. -- c
Re: Web Module (Was: Perl6 new features)
On Friday 22 June 2007 11:07:35 Chas Owens wrote: > Please, god, no. Or at least make two distributions: Bare Perl 6 and > Perl 6. Many companies have a "Only Core Perl" policy. They refuse > to install CPAN modules because "We don't trust them". I think of this the same way I think of "Do not drink even if you mix with beer" labels on bleach bottles. Stupid people often remove their genes from the pool. We should not discourage stupid business practices from doing the same. -- c
Re: Web Module (Was: Perl6 new features)
On Monday 25 June 2007 00:57:18 Hakim Cassimally wrote: > Releasing a language without a useful, easily installable library bundle > could quite reasonably be construed as a stupid business practice. Of course. Yet some dozen years later, the argument for keeping interfaces such as File::Find (because sysadmins should learn all about closures and callbacks but can only understand global variables) and code such as CGI.pm (it was SelfLoader before SelfLoader was cool and *that* was a while ago) in the Perl 5 core has absolutely nothing to do with quality, ease of use, or suitability for the problem domain and everything to do with incidentally having been first and, thus, immediate evolutionary dead ends. -- c
Parrot 0.5.0 "Caulked Snack" released!
Jack had avoided looking into his sons' faces during this Oration, because he reckoned they'd not wish to be seen with tears streaming down their faces. But looking up at Jimmy now he saw dry eyes and a quizzical if impatient phizz. Turning the other way, he saw Danny gazing distractedly at the White Tower. ... "Before you embark on a new life overseas, assuming that is your fate," Jack said, "find Eliza and tell her she is my true love." And then he jerked the chains loose from the restraining grip of first Jimmy, then Danny. He leaned forward, pushed off against the rail with both feet, and launched himself into space above London. His cloak spread in the wind of his flight like the wings of an eagle, revealing, to anyone who might be gazing up into the sky, a lining made from cloth-of-gold that glistered in the rays of the setting sun like the chariot of Apollo. He was on his way down. -- Neal Stephenson, The System of the World On behalf of the Parrot team, I'm proud to announce Parrot 0.5.0 "Caulked Snack." Parrot (http://parrotcode.org/) is a virtual machine aimed at running all dynamic languages. Parrot 0.5.0 is available from the CPAN (soon), or follow the download instructions at http://parrotcode.org/source.html. For those who would like to develop on Parrot, or help develop Parrot itself, we recommend using Subversion or SVK on the source code repository to get the latest and best Parrot code. Parrot 0.5.0 News: - Implementation + PDD15 (OO) branch merged with trunk; this release contains a working, tested implementation of the latest OO model + Added pop_eh/push_eh_p/count_eh opcodes + Add --runcore command line option + Add gcdebug runcore to help track down GC bugs + minor improvements to IA-32 JIT - Documentation + PDD19 (PIR): updates to macros, .pcc* directives + PDD25 (Concurrency): updated + PDD26 (AST): draft approved + PDD23 (Exceptions): draft approved + Copyright cleanups - Languages/Compilers + languages/APL: minor updates, PDD15 conformance + languages/dotnet: minor updates + languages/lua: minor updates, PDD15 conformance + languages/lisp: minor updates + languages/perl6: minor updates, PDD15 conformance + languages/plumhead: minor updates + languages/punie: minor updates, PDD15 conformance + languages/nqp: minor updates + languages/scheme: many updates, PDD15 conformance, improved tests, use PMCs instead of primitive registers to represent values + languages/tcl: bugfixes, PDD15 conformance + languages/WMLScript: minor updates + compilers/pirc: updates from PDD19, PDD06 + compilers/pct: minor updates, PDD15 conformance + compilers/pge: PDD15 conformance + compilers/tge: PDD15 conformance - Configuration + Improve test coverage + Improve reporting when a step fails; allow abort on failure - Miscellaneous + More coding standard conformance, tests, cleanup, speedups, warnings cleanup + Bug cleanup, esp. GC bugs + Eliminate .imc extension (use .pir) + Simplify some core config steps to not allow interactive prompting - Removed + clear_eh opcode Thanks to all our contributors for making this possible, and our sponsors for supporting this project. Enjoy!
Re: xml and perl 6
On Wednesday 28 November 2007 10:59:30 James Fuller wrote: > I do not nec. agree with 'a particular grammer is not' part of the > core ... if that grammar is so common to every problem (like regex is) > then why not include it? Because it's not necessary for getting and installing other extension modules. The criterion for including a module in the core is "Is this necessary to get and install other modules?" not "Why not include this module?" -- c
Re: xml and perl 6
On Thursday 29 November 2007 03:21:18 cdumont wrote: > By listening to you all, we shouldn't even think to implement file > access... Please drop the sarcasm. > A programming language is made by humans and subject to the same evolutions > and bugs and in the end is alive and will die. > A programming language should evoluate, try to respond quickly to the > actual environment in order to survive or expand. Have you *seen* how much time p5p spends on keeping little-used modules that someone successfully argued were absoutely vital to the future of Perl now and forever up to date? If you want to talk about responding quickly to the environment, look at the CPAN. If you want to talk about a low work to value ratio, look at keeping things like B::CC up to date and passing their tests. Now there's a vestigial organ. -- c
Re: xml and perl 6
On Thursday 29 November 2007 07:07:18 James Fuller wrote: > I have been arguing that having some simple functionality, provided by > the core, would potentially harmonize usage across modules and promote > better understanding of code, in general, through consistent usage. That didn't work for File::Find in Perl 5. What makes you think "we'll SURELY get it right THIS time"? (Put another way, of all of the uses you've seen of File::Find, how many of them were beautiful or seemed like natural expressions of programmer intent?) -- c
Re: Standards bearers (was "Re: xml and perl 6")
On Saturday 08 December 2007 06:50:48 Richard Hainsworth wrote: > Surely, some concentrated thought by the inventive and resouceful minds of > who lead this project should go into language utilisation and > popularisation. My goodness, @Larry's pretty darn busy trying to build the core kernel of Perl 6 in such a way that the rest of the world can build beautiful and useful things around that kernel much in the same way that the CPAN as a whole is the shining gem of Perl 5. You, Mr. Hainsworth, and every other person reading this message from December 2007 through the singularity (aka Perl 7) officially have my permission to think about this yourself and pitch in! (Fixing the mixed metaphor in my first paragraph is a good start. Reading S11 is step two.) No one ever needed permission, but if it makes anyone feel better, there it is. -- c
Re: Standards bearers (was "Re: xml and perl 6")
On Sunday 09 December 2007 22:04:30 Richard Hainsworth wrote: > I download pugs and parrot from > SVN repositories, written tests - one of which still hangs the > compilation of pugs. Indeed the test I wrote for pugs concerned the > ability of pugs to use existing CPAN modules. I have tried parrot with > SDL and the tests fail. My aim was to write a P6 GUI module so that from > the start it would be easy for P6 users to generate UI interfaces easily. If you send me or the Parrot list the Parrot test results, I will do my best to fix them. > Unfortunately, despite my eagerness, I am not a professional programmer > with the time or the skill to fix the problems. Where I can contribute > is to express a view about how P6 might best be developed. Hey, I'm a trained musician and sometimes novelist who develops software on the side, and the primary reasons @Larry absorbed me are that: 1) I transcribe conversations faster than anyone else on the team 2) I had a working keycard to O'Reilly's Tarsier meeting room in Sebastopol and the reason I keep working on this stuff is: 3) I'm some combination of too stubborn or too stupid not to keep working on it All it takes to make a contribution is a fraction of my stupid or my stubborn plus some spare time. -- c
Bite-sized Tasks for the Interested (was Re: Standards bearers)
On Tuesday 11 December 2007 09:20:22 Paul Hodges wrote: > But on this general note, is there any current organization or location > where small problems are being parcelled out? I'd love to help, but my > time is as limited as everyone's If I could get small bites of work > to do, maybe I could contribute something useful. > > Anyone requesting one black-box module or function at a time? Or am I > pipe dreaming? I used to publish a Pugs and a Parrot task of the week in the Perl.com newsletter, but there didn't seem to be much uptake and so it slowly dissolved. It might be nice to have a small list of bite-sized tasks for the interested linked off of dev.perl.org/perl6 and the various project pages. I know there's a Perl 6 wiki around here somewhere, so in theory all we need is someone to prune the page regularly and poke various projects asking for a couple of small tasks for the uninitiated. -- c
Re: Bite-sized Tasks for the Interested (was Re: Standards bearers)
On Thursday 13 December 2007 13:37:19 ispyhumanfly wrote: > Any questions? :) Is it possible to see a list of tasks without the barrier of creating an account, requesting an invite, or logging in? I understand that a little bit of administrative overhead is useful, but I'd also like to see as little friction to getting started as possible. If the solution is to put a link on the appropriate Perl 6 sites saying "Bite-sized tasks for the interested, see this wiki page and then hop on this IRC channel or send a mail to this list", that's probably fine. -- c
Re: Perl6::Doc # Hail to the new pharao
On Friday 28 December 2007 17:04:40 herbert breunung wrote: > I have also plans to add my perl article (once they transelated) for $foo > perl magazine and maybe some perl.com articles, if chomatic allowes. It's fine with O'Reilly, as long as the authors of the articles agree (they hold the copyright). Where I'm the author, you have my permission. O'Reilly generally asks that you include a link to the original article as published on our site, but that's a request and not a requirement. -- c
Re: Official Perl 6 and Parrot wikis
On Saturday 29 December 2007 06:56:45 Mark J. Reed wrote: > Maybe it's just me, but it > seems like it will just feed the all-too-common perception that Perl > is for CGI scripts, and "real" web apps need to be written in > something else (be it Java, PHP, Ruby/Rails, whatever). Proposed new rule: for every ten contributions to the wiki, you get one bikeshed mail. -- c
Re: Official Perl 6 and Parrot wikis
On Saturday 29 December 2007 13:35:00 Mark J. Reed wrote: > Ok, consider me duly chastised. Sorry for the sidetracking. It's not a *bad* idea, but it's less important in my mind than getting useful information on the wiki. Anyone who wants to pursue it can do so, but I'd like to forestall a long digression on the list about it. That's all. -- c
Re: $?OS semantics
On Monday 07 January 2008 08:42:06 Trey Harris wrote:
> Then we can have roles that describe cross-cutting behavior of various
> OS's (like POSIX):
>
> my &trytolink;
> give $?OS {
> when OS::HasSymlinks { &trytolink := &*symlink; }
> when OS::HasLinks { &trytolink := &*link; }
> default { &trytolink :=
> -> ($old, $new) { fail X::LinkNotAvailable }
> }
> }
I agree, but these examples seem more like characteristics of filesystems than
an OS.
-- c
