Re: pluralization idea that keeps bugging me
To me this sounds like use Lingua::EN::Pluralize::DSL; which would overload your grammar locally to parse strings this way. However, due to i18n reasons this should not be in the core. It might make sense to ship a slightly modernized Locale::MakeText with Perl 6 so that it can be used in the compiler itself, but unless a fully open ended system like L::MT is included I think having anything at all might be damaging, because this will encourage people to use the partial solution that is already built in instead of the complete on eon the CPAN (c.f. many core modules). -- Yuval Kogman [EMAIL PROTECTED] http://nothingmuch.woobling.org 0xEBD27418
Re: pluralization idea that keeps bugging me
On Sat, Jan 26, 2008 at 18:43:50 -0800, Jonathan Lang wrote: Right. One last question: is this (i.e., extending a string's grammar) a keep simple things simple thing, or a keep difficult things doable thing? I'm going to guess somewhere in between. It should be about the same level of complexity as Filter::Simple, except with much finer control and more correctness. I'm not the best person to answer this though. -- Yuval Kogman [EMAIL PROTECTED] http://nothingmuch.woobling.org 0xEBD27418 pgpEFwVt1e30B.pgp Description: PGP signature
Re: pluralization idea that keeps bugging me
On Sat, Jan 26, 2008 at 18:12:17 -0800, Jonathan Lang wrote: This _does_ appear to be something more suitable for a Locale:: module. I just wonder if there are enough hooks in the core to allow for an appropriately brief syntax to be introduced in a module: can one roll one's own string interpolations as things stand? E.g., is there a way to add meaning to backslashed characters in a string that would normally lack meaning? You can subclass the grammar and change everything. Theoretically that's a yes =) -- Yuval Kogman [EMAIL PROTECTED] http://nothingmuch.woobling.org 0xEBD27418 pgpSWUL6t3dFZ.pgp Description: PGP signature
Re: PERL arrays
On Tue, Jun 05, 2007 at 14:36:51 -0700, [EMAIL PROTECTED] wrote: how do i declare loop through and print a 4 dim array in PERL You listen in class. Or buy a book. Sorry, but we're not here to do your homework, and this is not a general Perl help mailing list. You can also probably get by this far using some online tutorial. -- Yuval Kogman [EMAIL PROTECTED] http://nothingmuch.woobling.org 0xEBD27418 pgp3Ah41oHUYd.pgp Description: PGP signature
Re: Should a dirhandle be a filehandle-like iterator?
Why bother, actually, when it can just be a lazy list... Opendir and
closedir are very oldschool, and can be retained for whatever
technical detail they are needed, but in most modern code I think
that:
for readdir($dir_name) { .say }
should work as well.
The act of opening a directory is something I never quite got...
Even a directory with millions of entries is still peanuts in todays
memory sizes, and if it does need to be iterated very carefully the
old variants can still be around. readdir() returning a list doesn't
have to be inefficient but it's easier to screw up with it and make
it bloat.
--
Yuval Kogman [EMAIL PROTECTED]
http://nothingmuch.woobling.org 0xEBD27418
pgpBdBGiCHX3R.pgp
Description: PGP signature
Interrogating closures
Hi,
I think a partial unification of objects and code refs in userspace
is going to be a nice features.
Closures allow people to put arbitrary complexity into a very simple
api that is, in OO terms, just one method (the actual function
call).
Consequentially the closure may never reveal any information about
it's actual behavior.
I think the convenience of closures can be enhanced by allowing
closures to declare that certain captured variables are in fact
instance data (see below for ideas on how).
A trivial example:
my @callback_list;
$some_object.register_callback(sub { for @callback_list - f { f() }
});
sub add_callback (f) {
push @callback_list, f;
}
This allows to register a number of callbacks to $some_object using
a simple combinator.
The problem is that without writing the add_callback api we lose the
ability to modify this list, effectively forcing us to create an
api.
Perhaps a better approach is to create a callbackregistry class:
class CallbackRegistry {
has @callbacks;
method trigger {
for @callbacks - f { f() };
}
method make_meta_callback {
sub { self.trigger }; # interesting question here...
can we close over lexical subs like self?
}
}
Then we make a callback registry, and do something like
$some_object.register_callback( $registry.make_meta_callback());
Essentially what this is doing is reimplementing the concepts of
closures in OO terms.
This layer could be removed by doing something like this:
# first we define the API of the closure
class ListOfCallbacksCallback isa Closure {
has @callbacks;
}
my @callbacks;
sub { @callbacks } but ListOfCallbacksCallback; # not quite sure of this
Essentially this would overload sub capture, and make it into a
constructor call of some sort. Variable renaming facilities would be
nice, but even just a capture containing the body and all the
closed over variables would be cool.
This keeps things concise and lightweight, but does add the ability
to inspect (via a well defined api) what a closure is encapsulating,
etc.
--
Yuval Kogman [EMAIL PROTECTED]
http://nothingmuch.woobling.org 0xEBD27418
pgpOAFxEttvsl.pgp
Description: PGP signature
Re: Interrogating closures
On Thu, Nov 30, 2006 at 09:13:42 -0800, Larry Wall wrote:
my $x = 42;
f := sub {
have $.x;
say $x;
...
}
say f.x;
hmm... That looks nice.
Maybe even this makes sense:
sub {
have $.x;
method blah { }
}
Conversely, I'd also like to be able to do Closure, which is a
subrole of Code with a constructor. Or rather, an instantiated Code
is a proto of Closure ;-)
--
Yuval Kogman [EMAIL PROTECTED]
http://nothingmuch.woobling.org 0xEBD27418
pgp65NtyIUkFl.pgp
Description: PGP signature
Closures, compile time, pad protos
Hi,
Anatoly and I don't know what this bit of code prints:
foo();
foo();
for 1..3 {
my $x ::= 3;
sub foo { say ++$x };
say ++$x
};
Is it 4, 5, 6, 6, 6 or 4, 5, 3, 3, 3? It's almost definitely not 4,
5, 6, 7, 8.
I can't rationalize 4, 5, 6, 7, 8 while maintaining the notion that
$x is actually lexical.
To rationalize the other examples:
4, 5, 6, 6, 6 means that the foo declaration does not capture over
an instance of the $x bar, but the actual value in the pad proto
itself (the value that will be the default value of newly allocated
$x variabless).
4, 5, 3, 3, 3 means that at compile time all variables are
instantiated once for BEGIN time captures. Observe:
foo();
bar();
for 1..3 {
my $x;
sub foo { say ++$x }
sub bar { say ++$x }
say ++$x;
}
prints 1, 2, 1, 1, 1 because $x is allocated once at compile time
and captured into both foo and bar, and then separately allocated
once more for each iteration of the loop.
If this is indeed the case, then there is a semantics problem:
foo();
foo();
for 1..3 {
my $x; BEGIN { $x = 3 };
sub foo { say ++$x };
say ++$x
};
Must be 4, 5, 1, 1, 1. This is because BEGIN { } and the
foo share the same compile time allocated copy of $x, but this is
not the copy in the loop.
A related issue is:
foo();
foo();
for 1..3 {
my $x = 10;
sub foo { say ++$x };
say ++$x;
}
Is that 11, 12, 10, 10, 10, or 11, 12, 13, 13, 13, or 1, 2, 10, 10, 10?
Lastly,
sub foo {
my $x;
sub { sub { say ++$x } }
};
my $bar = foo();
my $gorch = $bar.();
$gorch.();
$gorch.();
my $quxx = $bar.();
$quxx.();
$quxx.();
obviously results in the sequence 0, 1, but does the second call to
$bar create a new sequence in $quxx, or is that instance of $x
shared between $gorch and $quxx? Intuitively i'd say it is shared,
which means that the outer sub declaration implicitly captures $x as
well. Can anyone confirm?
Obviously
my $zot = foo().();
$zot.();
$zot.();
Does create a new sequence.
--
Yuval Kogman [EMAIL PROTECTED]
http://nothingmuch.woobling.org 0xEBD27418
pgpUCL8XSaAwR.pgp
Description: PGP signature
Re: Closures, compile time, pad protos
On Wed, Nov 22, 2006 at 18:55:15 +0100, Juerd wrote:
Yuval Kogman skribis 2006-11-22 16:01 (+0200):
my $x ::= 3;
sub foo { say ++$x };
Why would you be allowed to ++ this $x? It's bound to an rvalue!
Perhaps my $x ::= BEGIN { Scalar.new( :value(3) ) }
What we meant to be doing was to pre-set this value at compile time
to 3.
That doesn't really matter though
--
Yuval Kogman [EMAIL PROTECTED]
http://nothingmuch.woobling.org 0xEBD27418
pgpJXYYbnkuYL.pgp
Description: PGP signature
Re: Trying to make a new operator
On Sun, Sep 17, 2006 at 16:35:39 +0100, Daniel Hulme wrote: What am I doing wrong? Sounds like you need to define (or at least declare) the new operator before you use it. Perl 6, like Perl 5 compiles with a single pass, so when you are using your random operator, it hasn't yet read the declaration further down the file. s/use/parse/; -- Yuval Kogman [EMAIL PROTECTED] http://nothingmuch.woobling.org 0xEBD27418 pgpecCgUDpDGS.pgp Description: PGP signature
Re: CGI Session management (was Re: the CGI.pm in Perl 6)
On Mon, Sep 11, 2006 at 13:31:55 -0700, Michael Snoyman wrote: I agree completely. In that vein, I think that one thing a lot of web developers would like to have available more easily would be session management. In PHP it's as simple as $_SESSION['key'] = 'value'. I understand that CGI.pm is a fundemantally different concept from PHP and that this can't be completely taken care of by the module. Still, if something could be written in, I think it would make many people's lives simpler. Please... no... There are *so* many ways to do session handling that lugging them all into CGI.pm will just make a mess. It'd work much better as mixin plugins of some sort. I'd be happy to discuss my conclusions from redesigning the Catalyst session handling, if you like. -- Yuval Kogman [EMAIL PROTECTED] http://nothingmuch.woobling.org 0xEBD27418 pgpVLxZTi14RK.pgp Description: PGP signature
Re: synopses on smoke server
There are two other smoke servers to look into... One is written in Catalyst + DBIC, by yours truly. http://dev.catalystframework.org/repos/Catalyst/trunk/examples/SmokeServer I've stopped working on it due to lack of interest - nobody seemed unhappy enough with the currrent smoke server. Another is written in Jifty: http://search.cpan.org/dist/Test-Chimps/ It's further along, but is a little more specific to BP's workflow. -- Yuval Kogman [EMAIL PROTECTED] http://nothingmuch.woobling.org 0xEBD27418 pgpyHr3SZiGXL.pgp Description: PGP signature
Re: synopses on smoke server
On Tue, Sep 05, 2006 at 12:26:32 -0400, jesse wrote: Actually, it uses Jifty::DBI for its storage, but it's not a jifty app ;) Oh! The _intent_ was to make the tool more general than the existing pugs smoker. If we've somehow messed that up, I'd like to hear about it. Oh! I thought the Anna integration with the repo and all that was the tailored precisely for you guys. I stand corrected =) -- Yuval Kogman [EMAIL PROTECTED] http://nothingmuch.woobling.org 0xEBD27418 pgp2Etmw71YFR.pgp Description: PGP signature
Re: return Types: what are the enforcement details?
On Tue, Aug 29, 2006 at 19:49:38 -0500, Mark Stosberg wrote:
I'm interested in helping to write some tests for return types, but
I'd like some clarifications about them first. Are they just
declarations that help Perl optimize stuff, or they actually contracts?
'of' is the contractual form, 'returns' is a constraint but it's
more like a cast.
demo:
sub foo of Array {
my %h = ( a = 1 );
return %h;
}
sub zoo returns Array {
my %h = ( a = 1 );
return %h;
}
# Hashes are happily returned, despite the Array return types.
my %b = foo(); say %b.perl;
my %c = foo(); say %c.perl;
^-- z ?
Intuitively I would say that both subroutines force the hash into an
array, at minimum, and foo might be checked more thoroughly.
In the case of foo(), foo itself might not compile, or my %b = foo()
might not compile, or both.
In the case of zoo(), i think it's just a runtime conversion to an
array. There's no reason why this conversion can't happen explicitly
as well as implicitly, like with my %h = () = %other_hash.
However, conversions that cannot be made could be cought at compile
time, emitting a warning on an error depending if the runtime is a
warning or an error.
--
Yuval Kogman [EMAIL PROTECTED]
http://nothingmuch.woobling.org 0xEBD27418
pgprdGNAViO2E.pgp
Description: PGP signature
Re: Curious corner cases concerning closure cloning
On Mon, Aug 14, 2006 at 16:01:47 +, Luke Palmer wrote:
What do these do?
Intuition based answers:
for 1,2 {
my $code = {
my $x;
BEGIN { $x = 42 }
$x;
};
say $code();
}
I think the closure would be emitted equivalently to my $x = 42, or
perhaps $x is not in the BEGIN blocks scope at all.
for 1,2 {
my $code = {
state $x;
BEGIN { $x = 42 } # mind you, not FIRST
$x++;
};
say $code();
say $code();
}
Again, assuming the BEGIN { } body is not even compile but it's side
effect is meaningful, this is the same as
state $x = 42;
but starting to get a little tougher to justify.
Perhaps it does that, but also emits a warning e.g. 'implicit
initial value for future-scoped lexical' or something like that.
for 1,2 - $x {
END { say $x }
}
undef, because END is like a declaration putting the closure in some
global, and doesn't actually happen at runtime.
Otoh
for 1,2 - $x {
state $y = $x;
END { say $y }
}
Might work
--
Yuval Kogman [EMAIL PROTECTED]
http://nothingmuch.woobling.org 0xEBD27418
pgp3UksysQ5Kj.pgp
Description: PGP signature
Re: request addition of immutable Blob type
What about str? Or is it called buf now? -- Yuval Kogman [EMAIL PROTECTED] http://nothingmuch.woobling.org 0xEBD27418 pgp4nJlEWZWEj.pgp Description: PGP signature
Re: weak roles
On Tue, Aug 08, 2006 at 09:05:07 +0200, Mark Overmeer wrote: Sometimes, the external interface of a module looks the same, and there are cases where the internals behave as such as well. In general, however, the internals are more different then the user code shows. That makes your proposal unworkable. The whole point is to implement the same interface in terms of different internals. For different approaches to tackle the (in this case e-mail) problems you need different internal helper objects, different methods, different attributes. It is in general hard to force an extra interface definition inside the same class. That's why they are in separate roles that are off by default. These roles are orthogonal. But that's not all. A header contains fields, which are usually objects as well. How would you include variation in those in the definition? Every off by default role is distinct. You cannot use them simultaneously if they conflict. And different versions of one module which use your Email::Abstract module? You must not try to understand the structure of other modules into such a detail, because you cannot maintain it. Huh? Delegates are not sufficient to implement such couplings between unrelated modules: you commonly need serious parameter rewrites. Delegates are nice within a homogeneous concept. Email::Abstract works. It's not the most pleasant thing, which is why it's problematic, but it *does* do the job. The only way I have found to work is with wrapper objects which translate between the two modules. a.k.a a delegate The advantanges are that you have localized the hassle of interfacing to one class, and you hide the internal complexity of both sides (OO is about abstraction!). Which is much more work than what roles make you do. Of course, we could use the Email::Abstract interface as a base- class to all email related modules, but you know that this wouldn't work for the Perl community... Base classes, as opposed to roles, don't work well at *all* for these types of scenarios. -- Yuval Kogman [EMAIL PROTECTED] http://nothingmuch.woobling.org 0xEBD27418 pgp8oZIwW4xxN.pgp Description: PGP signature
Re: weak roles
On Tue, Aug 08, 2006 at 09:05:07 +0200, Mark Overmeer wrote: Of course, we could use the Email::Abstract interface as a base- class to all email related modules, but you know that this wouldn't work for the Perl community... Actually I'd like to expand on this. There are two problem with your solution, that are not community related. The first is that this is no different from using the role Email::Abstract or whatever it'll be in the classes. Roles can be abstract, too. The second is the issue i raised though - when It's too difficult to put together two (or more) abstract roles (or base classes) in the same class, you may declare how to do all of them in a conflicting way. That is you can be both Email::Abstract and Email::Abstract::Better, even though they define different interfaces by simply declaring that you cannot be both of them at the same time, and whoever is invoking the methods must explicitly say which behavior it prefers. -- Yuval Kogman [EMAIL PROTECTED] http://nothingmuch.woobling.org 0xEBD27418 pgpx3ynOr3Awk.pgp Description: PGP signature
Type annotation on expressions
Is there any way to type annotate a single expression, without using a temporary variable? my Moose $x = $y; # definitely a Moose now, may have been coerced foo( $x );# foo() doesn't necessarily say it wants Moose Is it possible to say this one expression? Haskell's syntax is shiny but everybody wants the colon: foo( ( $x :: Moose ) ); If we do find something (please ignore the fact that :: is probably not going to be the syntax), are these two the same? my $x = ( $y :: Moose ); my Moose $x = $y; -- Yuval Kogman [EMAIL PROTECTED] http://nothingmuch.woobling.org 0xEBD27418 pgpzIfILjn7ZS.pgp Description: PGP signature
Re: Type annotation on expressions
On Tue, Aug 08, 2006 at 11:12:11 +0100, Daniel Hulme wrote: I may be in a little world of my own here, but isn't this what 'as' is supposed to do? foo($x as Moose); as is a method invocation not a type annotation... It's related, but not the same (last I heard) -- Yuval Kogman [EMAIL PROTECTED] http://nothingmuch.woobling.org 0xEBD27418 pgpI6862poq6D.pgp Description: PGP signature
Re: weak roles
On Tue, Aug 08, 2006 at 11:14:40 +, Luke Palmer wrote: Mail::TheOneTrueWay.new.header; # which one? Either neither, or the default one (which is declared default by the class). A related question: if Mail::SomeAPI and Mail::SomeOtherAPI both exported a method, say send, and you mentioned it outside the weak role blocks, which one does it call. If mentioned means used, then that's a conflict. If it gets that far you *really* need a delegate. If mentioned means declared than neither - it's the same one for both. Well, yeah, but I think they're the right solution. They may be right, but it's hard to get an organically growing community to design their code for them. I personally prefer delegates for almost any design dillema, but most CPAN modules aren't that way. snipped stuff about adaptors Yes, this is necessary for anything heavyweight and probably better design, but again, hard to encourage on a wide scale. Oh, and hello everyone. Long time no see :-) Welcome back =) -- Yuval Kogman [EMAIL PROTECTED] http://nothingmuch.woobling.org 0xEBD27418 pgppRdobmMO5g.pgp Description: PGP signature
Re: Type annotation on expressions
Actually this particular example is just like coercion, and it's a bad one sorry. It's much more relevant for: fun( $x.foo :: Bar ); in order to annotate the return type for a call's context even if the 'fun' function's signature accepts Any. -- Yuval Kogman [EMAIL PROTECTED] http://nothingmuch.woobling.org 0xEBD27418 pgp1jsciRk7Zg.pgp Description: PGP signature
Re: weak roles
On Tue, Aug 08, 2006 at 11:35:30 +, Luke Palmer wrote: On 8/8/06, Yuval Kogman [EMAIL PROTECTED] wrote: I personally prefer delegates for almost any design dillema, but most CPAN modules aren't that way. Well, what way are they? Usually not polymorphic at all. We have the capabilities to do very flexible polymorphism with delegation today. Roles aren't necessary from a purist perspective, they just make it much easier to do very flexible polymorphism more often since it'll be easier. How else has this problem been solved? I dunno... If a function declares a parameter as a SomeAPI and then passes it on to a helper function, which leaves it untyped, which then calls header, what happens? Since your proposal is lexical, SomeOtherAPI's is called, which is probably not what was intended. My original idea was that this is again an ambiguity error - without the helper function stating which role it's using it cannot dispatch the header method at all, since it's in a role-conflicted state. -- Yuval Kogman [EMAIL PROTECTED] http://nothingmuch.woobling.org 0xEBD27418 pgpMMiHOMFs7O.pgp Description: PGP signature
Re: weak roles
On Tue, Aug 08, 2006 at 12:00:03 +, Luke Palmer wrote:
The difference, though, is that this ambiguity error happens at
call-time, whereas most ambiguity errors happen at composition time.
As I saw it it's not really a role, it's more of a no-op coercion.
Instead of actually writing an adaptor class, you could get off
cheaply if the adaptor doesn't need any more instance data than is
already provided by the main object.
So yes, it's runtime, but it doesn't matter.
It strikes me that there is a happy medium.
class Mail::TheOneTrueWay {
has $.some_api adapts Mail::SomeAPI {
method header;
# this method has different semantics for
# each role. It would normally conflict.
}
has $.some_other_api adapts Mail::SomeOtherAPI {
method header;
}
method body; # this method is shared between the two roles
}
Which would pull all that multiple delegation bullshit in my earlier
post. Creating the class is just as easy, and using it involves
putting .some_api and .some_other_api in appropriate places like a
delegation interface. It's not quite as DWIMmy, but the class
doesn't do either role so errors will be caught quickly. It is also
annotation-agnostic.
Hmm... Are the 'adapts' things actual class bodies? Like an inner
class?
--
Yuval Kogman [EMAIL PROTECTED]
http://nothingmuch.woobling.org 0xEBD27418
pgplmImaQgApM.pgp
Description: PGP signature
Re: Type annotation on expressions
On Tue, Aug 08, 2006 at 11:42:15 +, Luke Palmer wrote:
I'm not up-to-date on coersion; last I checked it was hand-wavily
defined.
Currently it's a unary multimethod:
my $hamburger = $cow.as(Food);
However, the MMD rules are counterintuitive for dispatch rules.
The reason annotation came up is because I felt it shouldn't be a
parameter at all, but a nullary multimethod on the return value:
my $hamburger = $cow.as :: Food;
Larry had mentioned that return.signature is basically the
invocation context.
If we do have a n ullary `as` the annotations are essentially
parameters on the anonymous function that is the CPS continuation.
That continuation's signature is used to perform MMD dispatch on
'as' by matching the -- stuff in opposite priority order.
The current problem is:
12:15 audreyt Point is Shape; 3DPoint is Point
12:15 audreyt er I mean Poind3d
12:15 audreyt Point3d
12:15 audreyt you have an object $o
12:15 audreyt you want to get back Point
12:15 audreyt say $o.as(Point).x
12:16 audreyt $o is actually of class Moose
12:16 audreyt Moose has
12:16 audreyt multi method as (Shape)
12:16 audreyt multi method as (Point3d)
12:16 audreyt if we list as using the normal MMD rule
12:16 audreyt proto as ($) {}
12:16 audreyt then Point comes in and Shape is selected
12:17 audreyt but we want Point3d
12:17 audreyt not Shape, to win
12:17 nothingmuch isn't .as(Point) going to fail if it
returns a Shape?
12:17 nothingmuch i mean
12:17 nothingmuch the rules here are reversed
12:17 nothingmuch Point is not a parameter to .as in the
natural sense
12:17 audreyt it is going to fail only if we consider the
return type
http://colabti.de/irclogger/irclogger_log/perl6?date=2006-08-08,Tuesel=359#l545
for more discussion.
--
Yuval Kogman [EMAIL PROTECTED]
http://nothingmuch.woobling.org 0xEBD27418
pgplKfIqh5Ipr.pgp
Description: PGP signature
weak roles
The CPAN has many reinvented wheels. This happened since we have so
many authors (== opinions) over so many years.
For example, we have Mail::Message to Email::Simple, to
Mail::Internet to They all do the same thing differently.
Then there is Email::Abstract, which provides a simplified API for
all of these together, so that modules like Mail::Thread can work
with either.
With the introduction of roles, supposedly this is going to be less
of a problem. Email::Abstract would ideally be a role that the
organically grown message abstracting classes just 'do'.
However, suppose that Email::Abstract itself would be reinvented.
The message modules now have to choose between either
Email::Abstract or Email::Abstract::Better as the one role to do
(since they probably conflict), or it will have to do weird magic to
disambiguate in a context sensitive way.
I think a nice idea to work around this would be to introduce weak
roles, that are lexically scoped.
The way it could work is a bit like this:
class Mail::TheOneTrueWay {
does Mail::SomeAPI is weak {
method header; # this method has different semantics for
# each role. It would normally conflict.
}
does Mail::SomeOtherAPI is weak {
method header;
}
method body; # this method is shared between the two roles
}
Then, when a module is expecting a message object it declares the
role it wants this object to do for this scope:
sub analyze_mail ( Mail::SomeAPI $message ) {
$message.foo; # unambiguous
}
This way coercion can be avoided, which means that keeping mutable
coerced objects synchronized is no longer necessary, thus
simplifying the code path and encouraging even more
pluggability/polymorphism.
I'm not sure on the behavior of $obj.does outside of the role
strenghning scope.
I am pretty sure that this should be purely lexical, and not
dynamic, even for .does (if it's true on the inside).
Perhaps an invokation of an ambiguous method is an error for the
caller ($object responds to N flavours of the header method, you
must explicitly say which flavour you prefer right now).
Delegates are another way around this but let's face it:
1. they're not as popular as they should be
2. they're more classes to write
3. they're harder to use
Consequentially we have fairly few delegate based APIs for these
problems (Email:Abstract is the only one I know).
--
Yuval Kogman [EMAIL PROTECTED]
http://nothingmuch.woobling.org 0xEBD27418
pgpzS1FVkV3jl.pgp
Description: PGP signature
underscores in the core lib
Hi,
Audrey mentioned that Perl 6 is trying to avoid underscores in the
core library.
It came up when I asked why valid isn't called value_id because
if ( $user_input.valid ) { } reads fairly confusingly.
So, a few questions:
1. what is the official naming style for the Pelr 6 standard
library (not just functions, but methods for core objects, the MOP,
the compiler toolchain, the truely absolutely core modules, etc).
2. What is bad about underscores? From what I know most people tend
to think that $object.do_that_action is the clearest way of naming
methods, and the technical reasons to avoid these (long symbol
names, lots of typing) are no longer really valid nowadays (with
editor autocompletion, etc).
3. why are some core methods named ALLCAPS (BUILD, BUILDALL)? Or
perhaps more accurately, which types of other methods should also be
in ALLCAPS? and is ALL_CAPS also OK? Or is that for constants?
4. If really make a departure from short names, will things that
sort of model POSIX (IO, etc) have short synonyms? or will these be
named in their short form?
A request to the thread participants - please try and form your
arguments on a good for everyone level, not just what your
personal preferences are. I don't think that anyone's opinion
matters except @Larry's, and you're not going to change their minds
if you simply present stylistic argumetns.
---
My own spiel:
I would like to see a slight departure from the C-style naming
convention (which I must admit i really really dislike - remembering
std c library names when you don't use them all the time is tricky,
and consequentially so is looking them up in the docs).
I would very much like Perl 6 to be a language that's easy to read
as you go along, where consulting the documentation isn't always
necessary to understand what's going on.
A unix head may read:
$file.chown( $user );
wait( $pid );
easily, but anyone with sufficient understanding of the program's
behavior can understand what
$file.change_owner( $user );
wait_for_process( $process_id );
is without being aware of the conventions.
Of course, this has downsides too- it defies an existing convention,
(These are standins for old UNIX functions which everyone already
knows).
However, we will also have new APIs, like the OO meta model:
my @attrs = $meta.attributes; # shallow
my @deep = $meta.compute_all_attributes; # deep, also from superclasses
Than
my @attrs = $meta.attrs;
my @deep = $meta.compattrs;
--
Yuval Kogman [EMAIL PROTECTED]
http://nothingmuch.woobling.org 0xEBD27418
pgpPWBBdd6XLw.pgp
Description: PGP signature
Re: ===, =:=, ~~, eq and == revisited (blame ajs!) -- Explained
On Fri, Jul 14, 2006 at 11:42:24 +0100, Smylers wrote: I'm afraid I still don't get it. Or rather, while I can manage to read an explanation of what one of these operators does and see how it applies to the variables in the examples next to it, I am struggling to retain a feeling of _why_ I would want to use any of these operators in real-life Perl 6 code. To compare deep structures ;-) Already in Perl 5 having 2 different equality operators is something that learners often stumble over. But only for low level types. To see if two objects are the same, or two hashes, you need to use Data::Compare, or to overload either == or eq, neither of which is a perfect fit. I have to catch my flight, so I'll explain more later. -- Yuval Kogman [EMAIL PROTECTED] http://nothingmuch.woobling.org 0xEBD27418 pgpjrJLdJQ8jS.pgp Description: PGP signature
Re: optimizing with === immutable comparitor
On Fri, Jul 14, 2006 at 00:30:20 -0700, Darren Duncan wrote: This may go without saying, but ... ... This is a VM issue. It clarifies semantics, and the runtime VM may choose to do this freely for simple values (but not for objects which just pretend using .id). In short: yes, the semantics allow that, but it has nothing to do with the language it might not even be faster. -- Yuval Kogman [EMAIL PROTECTED] http://nothingmuch.woobling.org 0xEBD27418 pgpMbWueVorC2.pgp Description: PGP signature
Re: ===, =:=, ~~, eq and == revisited (blame ajs!) -- Explained
On Fri, Jul 14, 2006 at 09:22:10 -0700, Dave Whipp wrote: Darren Duncan wrote: Assuming that all elements of $a and $b are themselves immutable to all levels of recursion, === then does a full deep copy like eqv. If at any level we get a mutable object, then at that point it turns into =:= (a trivial case) and stops. ( 1, 2.0, 3 ) === ( 1,2,3 ) True or false? false More imprtantly, how do I tell perl what I mean? The best I can think of is: [] (@a »==« @b) Vs [] (@a »eq« @b) Neither - it's on the natural types. If the types are different it's != -- Yuval Kogman [EMAIL PROTECTED] http://nothingmuch.woobling.org 0xEBD27418 pgpGRy3LtVSsx.pgp Description: PGP signature
Re: ===, =:=, ~~, eq and == revisited (blame ajs!)
On Thu, Jul 13, 2006 at 00:55:30 -0700, Darren Duncan wrote:
So, in the general case, it would seem best if the binary operator === was
just an ordinary method that each class provides, rather than requiring
classes to defined a .id. Or
in addition to this to help with performance, a .id can exist anyway that
optionally returns an appropriate hash of an object.
But what is the benefit here?
Keying by object is a difficult topic. In Perl 5 you sometimes want
to key by refaddr (more often than not) because you are associating
new metadata with the instance, that does not belong inside the
instance.
On the other hand you also often want something like $obj to be
the key, if it can properly stringify, so that an object like a
currency:
my $x = Currency.new( code = USD );
my $y = Currency.new( code = USD );
$hash{$x} = 1;
say $hash{$y}; # 1
will DWIM. But this really depends on both the item being used,
*and* the way it is being used.
So I can see the value of making the second type of keying possible
and easy with an .id method (which at the very lowest level can
probably just emit e.g. a YAML representation of an object to ensure
uniqueness, if performance is *really* not an issue).
But this does not relate to equality, it's only useful for defining
it.
We were essentially questioning the reason === is specced to behave
as it currently does, because we feel that it's not very useful if
it's not clear cut that it should either *really* compare, or not
compare at all. And if it doesn't compare, we'd like a deep
comparison operator in S03.
Built-in mutable types, like Array or Hash, would not override the
Object-defined ===, which is equivalent to =:=, nor the built-in .id, which
returns the object itself. This
is reasonable in practice because the contents of those containers could be
changed at any time, especially if the containers are aliased to multiple
variables that are outside
of the testing code's control. The only thing that can be guaranteed to be
constant over time is that whether or not an object is itself, as determined
by =:=. By contrast, if
=== were to do a deep copy with mutable types, the results could not be
trusted to be repeatable because the moment after === returns, the
container's value may have changed
again, so actions done based on the === return value would be invalid if they
assumed the value to still be the same at that time, such as if the mutable
type was used as a hash
key and was to be retrievable by its value.
The behavior for arrays is useless to me, because I already have
=:=. I can write a hybrid ===/=:= operator for very special cases,
but 99% of the time I want to ask do these (arrays|hashes) contain
the same values *right now*?
User defined types can choose on their own whether to override === and/or .id
or not, and they would use their own knowledge of their internal structures
to do an appropriate
deep comparison. There is no need to try to generate some kind of unique
numerical .id for arbitrarily complex objects.
That creates a mess - sometimes objects compare themselves based on
their value, and sometimes based on their containing slot. These are
very different semantics.
--
Yuval Kogman [EMAIL PROTECTED]
http://nothingmuch.woobling.org 0xEBD27418
pgpwbesNugIxd.pgp
Description: PGP signature
Re: ===, =:=, ~~, eq and == revisited (blame ajs!) -- Explained
So, Larry assisted by Audrey explained the purpose of === vs eqv vs =:=. It makes sense now, but I still feel that as far as ergonomics go this is not perfect. Then again, I trust that Larry's opinion is probably better and at the very least more likely to be accepted than mine ;-) [1] So, this is the deal: === is for checking immutable equality. This is a bit nasty to explain. eqv is going to be deep comparison, like most of us thought '===' was going to be (I had initially thought that eqv was renamed to === when === started popping up). =:= is something completely different, but will be easy to explain in a moment. What it means for something to be immutable can be demonstrated rather easily here: my $x = 10; my $y = $x; $x === $y; # true $y++: $x === $y; # false Since numbers (and also strings) are simple values, that are not modified in place (at least not explicitly), but are instead copied and modified or just replaced when you change them, the .id of the thing inside $x and $y is bound to the value. You could rationalize this such that .id is the same if and only if it doesn't actually matter (and never will matter) if the value is in the same chunk of memory or a separate one, as far as the runtime is concerned. Arrays and hashes, and other complex types can, on the other hand have parts of them transformed without first cloning everything (which is precisely why they're useful). The underlying idea is that === can be used to test if two values are *always* going to be the same (if they're container gets a different value in it that does not mean that they are no longer the same). eqv, on the other hand is used to test whether or not two values are the same right now, without making any implications as to what their values will be later on, since they may mutate. This is deceivingly like == and eq if you assume that numbers and strings are changed, instead of replaced. Lastly, =:= is really variable($x) === variable($y) - that is, whether or not the container is the same value or not. This basically checks whether either $x or $y was at some point bound to the other, or in specific situations whether they're tied to the same representation even if they are different containers. Overridding .id is useful for when you want to imply that two items are exactly the same and will always be the same and will never change as far as their comparison is concerned (both eqv and === will always be true), even if the default implementation of === does not return true due to technical details. === can be thought of as .id eqv .id. I hope this clears things up, and thanks again, Larry and Audrey, for clearing this up. I'd like for someone with better english skills to summarize into an S03 patch please. It needs to be much shorter =) [1] My preferred ergonomics: 1. eqv goes away 2. what was eqv is renamed to === 3. === becomes =:=, which has a constant feel to it 4. =:= is rarely useful IMHO, so you can just type variable($x) =:= variable($y) Ciao -- Yuval Kogman [EMAIL PROTECTED] http://nothingmuch.woobling.org 0xEBD27418 pgpnFt3Yt2IXy.pgp Description: PGP signature
Re: Run time dispatch on ~~
On Thu, Jul 13, 2006 at 15:44:33 -0400, Aaron Sherman wrote:
Now, let's look at some of the good that ~~ does for us:
$a ~~ Some string # sameness
$a ~~ 5 # sameness
$a ~~ -{...} # test
$a ~~ /.../ # regex matching
That's great, and we don't want to mess with any of it.
But, then we have:
$a ~~ $b# uh... something
One compelling reason to have them behave exactly the same is to
allow refactoring.
If i'm using the same pattern on several inputs i'd like to maybe
delegate this to a helper sub that will actually run the ~~ for me,
in some way, and i'd like 100% compatibility.
Also, sometimes i am matching on behalf of my caller, this is very
common in dispatch algorithms, or things like tree visitors:
my @list = $tree.filter_children( $match ); # very generic and useful
--
Yuval Kogman [EMAIL PROTECTED]
http://nothingmuch.woobling.org 0xEBD27418
pgp2x3GRPz6iD.pgp
Description: PGP signature
Re: ===, =:=, ~~, eq and == revisited (blame ajs!) -- Explained
On Thu, Jul 13, 2006 at 12:50:19 -0700, Larry Wall wrote: On Thu, Jul 13, 2006 at 09:32:08PM +0300, Yuval Kogman wrote: : [1] My preferred ergonomics: : : 1. eqv goes away : 2. what was eqv is renamed to === : 3. === becomes =:=, which has a constant feel to it : 4. =:= is rarely useful IMHO, so you can just type : variable($x) =:= variable($y) It is important for eqv to be alphabetic so we can have the functional form take an optional signature parameter to specify what is compared. There's no contradiction, === could be an alias to eqv ;-) -- Yuval Kogman [EMAIL PROTECTED] http://nothingmuch.woobling.org 0xEBD27418 pgp8WhwmjRadD.pgp Description: PGP signature
Re: ===, =:=, ~~, eq and == revisited (blame ajs!) -- Explained
On Thu, Jul 13, 2006 at 21:55:15 -0700, Jonathan Lang wrote:
Apparently, there are _four_ basic kinds of comparison: the ones
mentioned above, and == (I believe that eq works enough like == that
whatever can be said about one in relation to ===, =:=, or eqv can be
said about the other). I'd be quite interested in an expansion of
David's example to demonstrate how == differs from the others.
sub infix:== ( Any $x, Any $y ) {
+$x === +$y; # propagate coercion failure warnings to caller
}
sub infix:eq ( Any $x, Any $y ) {
~$x === ~$y
}
--
Yuval Kogman [EMAIL PROTECTED]
http://nothingmuch.woobling.org 0xEBD27418
pgpA33D2068QT.pgp
Description: PGP signature
===, =:=, ~~, eq and == revisited (blame ajs!)
Over at #perl6 we had a short discussion on =:=, ===, and ~~, mostly raised by ajs's discussion on Str items and ===. After a brief discussion we managed to formulate several questions that we feel are slightly to totally unresolved. 1. what is .id on references? Is it related to the memory slot, like refaddr() in Perl 5? 2. is .id *always* a low level type representation of the object's value? It's specced that low level typed items have the same ID when they have the same value. What about complex types? 3. Are these descriptions of the operators correct? ~~ matches the left side to a description on the right side =:= makes sure the objects are actually the same single object (if $x =:= $y and you change $x.foo then $y.foo was also changed... is this .id on refs?) Is =:= really eq .id? or more like variable($x).id eq variable($y).id? === makes sure that the values are equivalent ( @foo = ( 1, 2, 3 ); @bar = ( 1, 2, 3); @foo === @bar currently works like that, but @foo = ( [ 1, 2 ], 3 ); @bar = ( [ 1, 2 ], 3 ); @foo === @bar does not (in pugs). This is not useful because we already have this return false with =:=). If they are not correct, why is there an overlap between =:=? Why is it hard to deeply compare values in 2006 without using e.g. Data::Compare? 4. will we have a deep (possibly optimized[1]) equality operator, that *will* return true for @foo = ( [ 1, 2 ], 3 ); @bar = ( [ 1, 2 ], 3 ); op(@foo, @bar)? Is it going to be easy to make the newbies use that when they mean it's the same, like they currently expect == and eq to work on simple values? 5. is there room for a new opperator? =::= makes sure the memory slot is the same (might be different for simple values). refaddr($x) == refaddr($y) in Perl 5 =:= makes sure that .ids are the same, and is useful if the .id method is meaningful for an object. A bit like Test::More::is( $x, $y ) but without the diagnosis in Perl 5, or abusing eq if the object doesn't overload stringification. === makes sure the values are the same even if they are copies/clones/whatever. Data::Compare in Perl 5. A bit like what people overload == for in Perl 5 right now (which confuses numerical equality with true equality, so we want to phase that out). ~~ makes sure the value on the right side describes the value on the left side. Reminiscient of Test::Deep::cmp_deeply, with all the various matching magic. Thanks, [1] It could, of course, be just =:= === inside, and it could optimize arrays to check length first, and it could cache checksums and it could do whatever - please don't bring this up as a performance issue, it is one of correctness and ergonomics that must be resolved first. -- Yuval Kogman [EMAIL PROTECTED] http://nothingmuch.woobling.org 0xEBD27418 pgpVx2Q88D1JG.pgp Description: PGP signature
Re: ===, =:=, ~~, eq and == revisited (blame ajs!)
If we do have deep value equality checks, then default == and eq
are probably:
sub infix:== ( $x, $y ) {
+$x === +$y;
}
sub infix:eq ( $x, $y ) {
~$x === ~$y;
}
So that the compare-as-sometype behavior is retained from perl 5
without introducing new complexity to the objects being compared as
strings/numbers.
--
Yuval Kogman [EMAIL PROTECTED]
http://nothingmuch.woobling.org 0xEBD27418
pgpNhYctTCtP5.pgp
Description: PGP signature
Re: ===, =:=, ~~, eq and == revisited (blame ajs!)
Jedai and I went through some of pugs current implementations. Here's a list of what we expect the operators to return and what they currently do. This does not exactly agree with S03 right now, but is our opinion. Force into a type before comparing values: 42 == 42 - true, same numeric value 42 == 42 - true, same numeric value 42 == 42 - true, same numeric value 42 == 42.0 - true, same numeric value 42 eq 42.0 - false, different string value 4 eq 4 - true, same string value Well typed value comparison: 42 === 42 - true, the same type 42 === 42 - false, not the same type 42 === 42 - true, the same type 42 === 42.0 - false, different value in natural type (string values) (1, 2, 3) === (1, 2, 3) - true, same value ([1, 2 ], 3 ) === ([1, 2 ], 3) - true, same value - BROKEN (actually false, since refs are not the same). S03 thinks this is actually OK. [1, 2, 3] === [1, 2, 3] - true, same value, (S03 says that this is actually broken, because references should not be the same (we disagree)) my @foo = (1, 2, 3); my @bar = @foo; @foo === @bar - true, same value. my @foo = ([1, 2], 3); my @bar = @foo; @bar === @foo - true, same value - BROKEN (S03 actually agrees with us here, since the ref is the same in this case) Slot/container equality (this is actually up to debate, but this is what we would expect if it was refaddr($x) == refaddr($y)): [ 1, 2, 3 ] =:= [ 1, 2, 3 ] - false, different containers - BROKEN (actually true) my $foo = [ 1, 2, 3 ]; $foo =:= $foo - true, same container my $foo = [ 1, 2, 3 ]; my $bar := $foo; $bar =:= $foo - true, same container my $foo = [ 1, 2, 3 ]; my $bar = $foo; $bar =:= $foo - true, ref to same container, or false since different container, unsure - currently true my @foo = (1, 2, 3); my @bar = @foo; @foo =:= @bar - false, container should be different - BROKEN (actually true) my @foo = (1, 2, 3); my @bar = @foo; @bar[1] = moose; @foo =:= @bar - false, container should be different. This actually works like we expected, appearantly pugs does some sort of COW Under := slot semantics the first test should be false, the second should be true, the third should be true, the fourth should be false, the fifth should be false, and the sixth should be false. -- Yuval Kogman [EMAIL PROTECTED] http://nothingmuch.woobling.org 0xEBD27418 pgpGSy7OFZEBd.pgp Description: PGP signature
Re: ===, =:=, ~~, eq and == revisited (blame ajs!)
On Wed, Jul 12, 2006 at 16:16:13 -0400, Aaron Sherman wrote:
Isn't that ~~?
Per S03:
Array Array arrays are comparablematch if $_ »~~« $x
~~ is really the all-purpose, bake-your-bread, clean-your-floors,
wax-your-cat operator that you're looking for.
Not at all, because:
( [ 1, 2 ], 3 ) ~~ ( { 1 }, { 1 } )
It's matching, not equality.
which is true. Ain't recursive hyperoperators grand?
It isn't a hyperoperator, it's just recursive ;-)
2. is .id *always* a low level type representation of the object's value?
It's
specced that low level typed items have the same ID when they have the same
value. What about complex types?
It cannot be for complex types or even strings... well, at least it
Imust not be Iif we care about performance
That's orthogonal. .id is used for hash keys. If you're keying y
hubble images then they must be unique for some keyspace, and that's
where .id makes a mapping.
=:= looks in the symbol table (caveat dragons) to see if LHS
refers to the same variable as the RHS. Does this dereference?
Probably not, but I'm not sure, based on S03.
Then it's a purely lexical opeation, and it doesn't even work for
my $x := $array[3];
$x =:= $array[3];
but i'll pretend you didn't say that ;-)
--
Yuval Kogman [EMAIL PROTECTED]
http://nothingmuch.woobling.org 0xEBD27418
pgpkrsvQqGF99.pgp
Description: PGP signature
Re: ===, =:=, ~~, eq and == revisited (blame ajs!)
On Wed, Jul 12, 2006 at 16:16:13 -0400, Aaron Sherman wrote: The other way to think about === would be that it tells you if its LHS *could* be constant-folded onto its RHS (if it were constant for long enough) What is the benefit here? Because of the word deep. Deep implies arbitrary work, which isn't really what you want in such a low-level operator. However, using these operator, one could easily build whatever you like. The number of times i *sigh*ed at having to reinvent deep operators in a clunky way in Perl 5 is really not in line with Perlishness and DWIM. Also ~~ is deep in exactly the same way. Perl is also not low level. I could build it, and I have, but I don't want to. It can short circuit and be faster when the structure is definitely not the same (totally different early on) or definitely the same (refaddr is equal, etc). Should I go on? I'd avoid saying memory, here. Some implementations of Perl 6 might not know what memory looks like (on a sufficiently abstract VM). Slot -- Yuval Kogman [EMAIL PROTECTED] http://nothingmuch.woobling.org 0xEBD27418 pgpAR436ytaZh.pgp Description: PGP signature
Re: S?? OS interaction, POSIX and S29
On Tue, Jul 11, 2006 at 16:46:40 -0400, Aaron Sherman wrote: There's a bit at the end of the current S29: =item A/S??: OS Interaction I've taken on a few of these, and in doing so found that I was making some assumptions. I'd like to share those and see if they make sense: * POSIX will be a low-level module that slavishly reproduces the POSIX interfaces as closely as possible (perhaps moreso than Perl 5) * OS, or whatever we call the core OS interaction module, will have an interface which is entirely driven by Perl 6 and may not resemble POSIX much at all. * OS will use POSIX to implement its functionality, so only POSIX need know how to get at the lowest level. Will that be reasonable? Am I stomping on anything? I think OS is kind of bad. Perl 6 is designed to be embeddable, retargetable, etc. Sometimes the environment well be JS like, that is you have (possibly) readonly environment calls (gettimeofday, etc), but not others (IO)... Ideally I would like to have something more partitioned, and with a less binding name than OS. That said, there's no reason why there shouldn't be a convenience wrapper around a more partitioned set of APIs, that provides a more toolchain like approach, and keeps the docs together. -- Yuval Kogman [EMAIL PROTECTED] http://nothingmuch.woobling.org 0xEBD27418 pgpLxNij9Cay0.pgp Description: PGP signature
Re: TAP extension proposal: test attributes
On Fri, Jul 07, 2006 at 08:36:33 -0500, Scott Bolte wrote: I propose using of subset of the Config::Std syntax to allow tests to declare attributes that are captured in Test::TAP::Model as a hash. That would allow the test to declare configuration information, such as its dependencies, which would be available to downstream processors of the test results. I would like this on a per-test-case level too. Pugs' test suite uses a weird syntax in the descriptions to spill out the todo category (not reason, but whether it's a bug, a force todo, unspecced, etc), the position of the test so that we can use backlinks, and color the test file in HTML, and potentially other info. It would be nice if this would be standardized. -- Yuval Kogman [EMAIL PROTECTED] http://nothingmuch.woobling.org 0xEBD27418 pgpU3j8aoOoow.pgp Description: PGP signature
Re: TAP::Harness
Please look at Test::TAP::Model and the horrrible hooks it goes through to make things work. I'd love to have a SAX like event-handler model for TAP through TAP::Harness so that I can construct Test::TAP::Model objects in a cleaner way (without the parser-is-the-model and all that mess). -- Yuval Kogman [EMAIL PROTECTED] http://nothingmuch.woobling.org 0xEBD27418 pgpcMgQCUTVKz.pgp Description: PGP signature
Re: TAP::Harness
On Sat, Jul 01, 2006 at 16:59:24 -0500, Michael G Schwern wrote: Yes, it is SAXy. You have Adam to thank for that. As my flight is delayed I'll try to make a stab at posting up the basic design. Another issue we had at work when I was abusing TAP for our C++ UT framework was that we needed more levels of nesting (TAP only supports streams and test cases - I was handling many test cases in the same stream, for nested modules... I faked files on certain markers, and used simple name mangling for the nestedness). This is actually probably off topic, since TAP revisions are not explicitly asked for... Too bad I missed talking to you at the hackathon - if I had only thought about this we could have talked in meat-space. -- Yuval Kogman [EMAIL PROTECTED] http://nothingmuch.woobling.org 0xEBD27418 pgpJMbWwaOVFC.pgp Description: PGP signature
Re: TAP extension proposal: test groups
On Sat, Jul 01, 2006 at 21:37:48 -0700, chromatic wrote: No one has provided an actual use case for it yet. YAGNI. *cough* I did. See the TAP::Harness thread... We had UT fixtures with subsections at work, which were further grouped by class, but all emitted in the same stream. That was very hacky to make work. -- Yuval Kogman [EMAIL PROTECTED] http://nothingmuch.woobling.org 0xEBD27418 pgpdvFvErE3pF.pgp Description: PGP signature
Re: Classy logging for Classes
On Thu, Jun 22, 2006 at 19:19:47 +0200, Szilakszi Bálint wrote: I'm trying to collect ideas about how could be (optionally available) logging added/implemented for classes, as in logging what methods are called at runtime, the parameters they are called with, etc. without embedding the whole logic in the methods themselves on a one-by-one basis. When the meta object protocol is exposed this will likely be a very simple meta-class mixin role. What I'm specifically looking for would be an instance based idea, so it doesn't permanently overwrite the class and thus consequently switch logging on everywhere that class is used, only for the scope of a given instance of the class. This can probably be hacked at runtime by reblessing the object into a temporarily role-mixed meta class. That said, most of the useful logging i've seen is not automatically generated. Traces are easy to do like this, but high quality logs should be hand rolled so that they convey the most meaningful representation of information. For this, aspect oriented programming can help you separate the logging from the actual body of the method, but this is not always the most correct behavior. -- Yuval Kogman [EMAIL PROTECTED] http://nothingmuch.woobling.org 0xEBD27418 pgpDfNOJ4cich.pgp Description: PGP signature
Re: easier duck typing in .can
On Sun, Jun 18, 2006 at 18:08:00 +1200, Sam Vilain wrote: Why would you not use .does or .isa there? Are you wanting this to go through all of the Class/Role's methods and check that the $object.can() them? Because if you don't control $object's class you can't change it. -- Yuval Kogman [EMAIL PROTECTED] http://nothingmuch.woobling.org 0xEBD27418 pgpO42QaY5S9n.pgp Description: PGP signature
easier duck typing in .can
Synopsis 12 specifies that:
.can interrogates any class package's CANDO multimethod for
names that are to be considered autoloadable methods in the
class
but aside from that is just a name - method iterator mapping.
Since CANDO is a multimethod, IMHO this can be safely extended to
allow:
$object.can(Class);
$object.can(Role);
to better support duck typing.
Scenarios in which this is useful are when you are mixing classes.
For example, CGI::Cookie and CGI::Simple::Cookie (perl 5 land) have
the same interface but don't strictly know about each other.
If you want to allow drop-in replacements to some objects then you
typically would rather check for duck typing than role consumption.
A real life example is CGI::Cookie::Splitter, which really doesn't
care (and for good reasons shouldn't care) what the object it's
dissecting is, as long as it follows the CGI::Cookie interface.
However, since it's not tied to the CGI::Cookie implementation in
any way except that CGI::Cookie was the first module to provide that
interface, it shouldn't require it.
Sometimes in the real world roles or base classes are not as
refactored as they should be, and if CGI::Simple::Cookie was given
the option of 'doing' CGI::Cookie but getting a headache out of it
because CGI::Cookie didn't have foresight to be easily 'done', that
shouldn't harm people.
Anyway, i'm reiterating why duck typing is good, and everyone
probably knows this already.
A complementing solution to better support duck type is from the
perspective of e.g. CGI::Simple::Cookie in my example:
http://search.cpan.org/perldoc?asa
This could be somewhat mirrorred as:
class Foo {
can Bar; # claim that you can do it, and if possible also
# get compile time verification
}
without affecting our hard earned renewed purity of .isa and .does
(due to roles in Perl 6).
Comments?
--
Yuval Kogman [EMAIL PROTECTED]
http://nothingmuch.woobling.org 0xEBD27418
pgpDjfA2jPh0W.pgp
Description: PGP signature
Re: eval
On Wed, May 24, 2006 at 19:54:53 +0300, Gabor Szabo wrote: if eval command fails, where can I get the error message ? aka $@ in P5 ? $! http://dev.perl.org/perl6/doc/design/syn/S04.html#Exception_handlers -- Yuval Kogman [EMAIL PROTECTED] http://nothingmuch.woobling.org 0xEBD27418 pgppQvQgJzFPq.pgp Description: PGP signature
Re: CPANTS is not a game.
On Tue, May 23, 2006 at 01:18:48 -0700, Michael G Schwern wrote:
I haven't looked at what's going on in CPANTS for a while but Andy's post
made me have a look and oh dear. There's a problem. CPANTS is not a game.
If you make it a game, the system does not work.
Likewise it should not test for things like
has a pod coverage test
because it's pod may be good enough even if it doesn't have a test.
This leads to attrocities like Catalyst stuff being shipped with a
boilerplate 02pod.t and 03pod_coverage.t that are disabled unless
$ENV{TEST_POD} is off. They add kwalitee, but they usually fail
making this even more of a contest when size doesn't matter ;-)
--
Yuval Kogman [EMAIL PROTECTED]
http://nothingmuch.woobling.org 0xEBD27418
pgpJrzR5jQP6v.pgp
Description: PGP signature
Re: A shorter long dot
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 We need to be careful not to require the language to solve problems that are better solved with tools. On that point I agree, but I think it was a question of aesthetics... Juerd? $foo. .bar; $ba. .bar; $x. .bar; $foo.bar; $ba.:bar; $x. :bar; Frankly I don't think there's *that* much of a difference - each has pros and cons. -- Yuval Kogman [EMAIL PROTECTED] http://nothingmuch.woobling.org 0xEBD27418 pgpFJG3Gj3Rdx.pgp Description: PGP signature
Re: Fw: ([EMAIL PROTECTED]) Re: A shorter long dot
On Sat, Apr 29, 2006 at 18:12:34 +0100, Nicholas Clark wrote: On Sat, Apr 29, 2006 at 05:59:37PM +0200, Juerd wrote: I get a message like this for every message that I send to this list. Trying to contact [EMAIL PROTECTED] did not result in response or change. Any ideas? Forward that message (with full headers) to [EMAIL PROTECTED] who will then apply the LART. As I figure I'm about to get one, I'll (also) forward mine. Just got one... By LARTing you mean forcibly unsubscribing? because the message was sent to me directly too... -- Yuval Kogman [EMAIL PROTECTED] http://nothingmuch.woobling.org 0xEBD27418 pgpKCtPumL5fF.pgp Description: PGP signature
Re: A shorter long dot
On Sat, Apr 29, 2006 at 19:03:28 -0700, chromatic wrote: Two invisible things look completely different to you? If dots looked like this: then they would be invisible. -- Yuval Kogman [EMAIL PROTECTED] http://nothingmuch.woobling.org 0xEBD27418 pgpjWtFYwS1YC.pgp Description: PGP signature
Test::Memory::Cycle (well really Devel::Cycle) - support for closures
Hi,
Andy, I know you subscribe to perl-qa so I didn't CC.
These two patches add support for detecting cycles in code
references, using PadWalker, to Devel::Cycle and Test::Memory::Cycle.
Currently this will silently stop working if PadWalker is not
installed to keep things tidy - I personally feel that this be a bit
louder, but whatever Lincoln feels is best is his own choice.
Anyway, have fun.
--
Yuval Kogman [EMAIL PROTECTED]
http://nothingmuch.woobling.org 0xEBD27418
diff -Nur Devel-Cycle-1.04/lib/Devel/Cycle.pm
Devel-Cycle-with_code/lib/Devel/Cycle.pm
--- Devel-Cycle-1.04/lib/Devel/Cycle.pm 2005-04-27 17:40:16.0 +0300
+++ Devel-Cycle-with_code/lib/Devel/Cycle.pm2006-04-24 00:57:11.0
+0300
@@ -19,6 +19,11 @@
our $VERSION = '1.04';
our $FORMATTING = 'roasted';
+BEGIN {
+ require constant;
+ constant-import( HAVE_PADWALKER = eval { require PadWalker; 1 } );
+}
+
sub find_weakened_cycle {
my $ref = shift;
my $callback = shift;
@@ -88,6 +93,15 @@
(@report,['HASH',$key,$current =
$current-{$key},$inc_weak_refs?isweak($current-{$key}):()]));
}
}
+ elsif (HAVE_PADWALKER $type eq 'CODE') {
+my $closed_vars = PadWalker::closed_over( $current );
+foreach my $varname ( sort keys %$closed_vars ) {
+my $value = $closed_vars-{$varname};
+next if !$inc_weak_refs isweak($$value);
+_find_cycle( $$value,{%$seenit},$callback,$inc_weak_refs,
+ (@report,['CODE',$varname,$current =
$$value,$inc_weak_refs?isweak($$value):()]));
+}
+ }
}
sub _do_report {
@@ -118,21 +132,25 @@
return $sygil . ($sygil ? '$' : '$$'). $prefix . $shortname . $suffix if
$type eq 'SCALAR';
return $sygil . ($sygil ? '@' : '$') . $prefix . $shortname . $suffix if
$type eq 'ARRAY';
return $sygil . ($sygil ? '%' : '$') . $prefix . $shortname . $suffix if
$type eq 'HASH';
+return $sygil . ($sygil ? '' : '$') . $prefix . $shortname . $suffix if
$type eq 'CODE';
}
}
+# why not Scalar::Util::reftype?
sub _get_type {
my $thingy = shift;
return unless ref $thingy;
return 'SCALAR' if UNIVERSAL::isa($thingy,'SCALAR') ||
UNIVERSAL::isa($thingy,'REF');
return 'ARRAY' if UNIVERSAL::isa($thingy,'ARRAY');
return 'HASH' if UNIVERSAL::isa($thingy,'HASH');
+ return 'CODE' if UNIVERSAL::isa($thingy,'CODE');
}
sub _format_index {
my ($type,$index) = @_;
return -[$index] if $type eq 'ARRAY';
return -{'$index'} if $type eq 'HASH';
+ return variable $index if $type eq 'CODE';
return;
}
diff -Nur Test-Memory-Cycle-1.02/Cycle.pm Test-Memory-Cycle-with_code/Cycle.pm
--- Test-Memory-Cycle-1.02/Cycle.pm 2005-05-17 19:02:39.0 +0300
+++ Test-Memory-Cycle-with_code/Cycle.pm2006-04-24 00:54:16.0
+0300
@@ -98,6 +98,7 @@
$str = sprintf(%s = %s,$refdisp,$valuedisp)
if $type eq 'SCALAR';
$str = sprintf(%s = %s,${refdisp}-[$index],$valuedisp)
if $type eq 'ARRAY';
$str = sprintf(%s = %s,${refdisp}-{$index},$valuedisp)
if $type eq 'HASH';
+$str = sprintf(closure %s = %s,${refdisp},
$index,$valuedisp) if $type eq 'CODE';
push( @diags, $str );
}
@@ -213,6 +214,7 @@
$sigil = '%' if $sigil eq HASH ;
$sigil = '@' if $sigil eq ARRAY ;
$sigil = '$' if $sigil eq REF ;
+$sigil = '' if $sigil eq CODE ;
$refdisp = $shortnames{ $refstr } = $sigil . $new_shortname++;
}
diff -Nur Test-Memory-Cycle-1.02/lib/Test/Memory/Cycle.pm
Test-Memory-Cycle-with_code/lib/Test/Memory/Cycle.pm
--- Test-Memory-Cycle-1.02/lib/Test/Memory/Cycle.pm 1970-01-01
02:00:00.0 +0200
+++ Test-Memory-Cycle-with_code/lib/Test/Memory/Cycle.pm2006-04-24
00:54:16.0 +0300
@@ -0,0 +1,241 @@
+package Test::Memory::Cycle;
+
+=head1 NAME
+
+Test::Memory::Cycle - Check for memory leaks and circular memory references
+
+=head1 VERSION
+
+Version 1.02
+
+=cut
+
+our $VERSION = 1.02;
+
+=head1 SYNOPSIS
+
+Perl's garbage collection has one big problem: Circular references
+can't get cleaned up. A circular reference can be as simple as two
+objects that refer to each other:
+
+my $mom = {
+name = Marilyn Lester,
+};
+
+my $me = {
+name = Andy Lester,
+mother = $mom,
+};
+$mom-{son} = $me;
+
+CTest::Memory::Cycle is built on top of CDevel::Cycle to give
+you an easy way to check for these circular references.
+
+use Test::Memory::Cycle;
+
+my $object = new MyObject;
+# Do stuff with the object.
+memory_cycle_ok( $object );
+
+You can also use Cmemory_cycle_exists() to make sure that you have a
+cycle where you expect to have one.
+
+=cut
+
+use strict;
+use warnings;
+
+use Devel::Cycle qw( find_cycle find_weakened_cycle );
+use Test::Builder;
+
+my $Test = Test::Builder-new;
+
+sub import {
+my $self = shift;
+my $caller = caller;
+no strict
Re: Test::Memory::Cycle (well really Devel::Cycle) - support for closures
Oops, bad patch. I added lib/Test/Memory/Cycle.pm as a symlink so that I don't have to 'make' each time to run the tests. -- Yuval Kogman [EMAIL PROTECTED] http://nothingmuch.woobling.org 0xEBD27418 pgpb5Xz3jyQ6k.pgp Description: PGP signature
Re: The whatever context
On Mon, Apr 10, 2006 at 14:25:35 -0700, Larry Wall wrote:
: my $x = grep { ... } @list; # returns count
I think that's already whatever context. $x contains the resulting array.
It's only if you later say +$x that you'll get the number of elems.
Just for grep or for any function?
If just grep that means that grep simply doesn't use want.
If it's any function, then it means that all are constants are
list or whatever, and all we really have are coercers.
--
Yuval Kogman [EMAIL PROTECTED]
http://nothingmuch.woobling.org 0xEBD27418
pgpKustGNNHeZ.pgp
Description: PGP signature
The whatever context
Hi...
I think that Perl 6 should have a whatever context, which is
essentially:
I want either array or scalar or whatever... You choose
so that functions like grep can return an array in whatever
context. This is best demonstrated using an example:
my $x = grep { ... } @list; # returns count
my $x = whatever grep { ... } @list; # the natural context for
# grep is array, no matter what the context really is
The usefulness of such a construct is two fold:
a. creating large anonymous structures with nested references or
scalar values without having to think (== good for when you are
evaluating a fucntion ref and you don't know what it is, but you
want the natural value to be returned).
b. writing eval bots and interactive shells:
(whatever eval $expr).perl;
;-)
--
Yuval Kogman [EMAIL PROTECTED]
http://nothingmuch.woobling.org 0xEBD27418
pgpD3MNUnph6T.pgp
Description: PGP signature
Re: Set Theory (Was: Do junctions support determining interesections of lists)
On Tue, Apr 04, 2006 at 12:02:55 -0700, Jonathan Lang wrote: Will perl6 Sets include set negation and/or a universal set? In effect, an internal flag that says, this set contains every possible element _except_ the ones listed? Sure! How else will we implement the garbage collector? ;-) -- Yuval Kogman [EMAIL PROTECTED] http://nothingmuch.woobling.org 0xEBD27418 pgpNHDuQGy9dD.pgp Description: PGP signature
Re: replacement of $
On Sun, Apr 02, 2006 at 02:04:07 +0300, Larry Wall wrote: ^^^-- (actually that was IDT in the headers) Hi, I'm in Israel and Japan at the same time! Nice one though ;-) plugIf you guys would have participated in the keysigning parties.../plug -- Yuval Kogman [EMAIL PROTECTED] http://nothingmuch.woobling.org 0xEBD27418 pgpbTq7cX8r2g.pgp Description: PGP signature
'temp $x;' with no assignment
Hi,
my $x = 5;
{
temp $x;
# is $x 5 or undef?
}
# $x is definately 10
I think it should be 5 inside, because it makes it easy to write
things like:
my $x = 5;
{
temp $x++;
# $x is 6
}
# $x is 5 again
and otherwise pretty much DWIMs, except from a historical
perspective.
--
Yuval Kogman [EMAIL PROTECTED]
http://nothingmuch.woobling.org 0xEBD27418
pgpoFwInBPODZ.pgp
Description: PGP signature
Announce: Test::TAP::HTMLMatrix 0.05 and Test::TAP::Model 0.06
These new versions of the modules let you get test run comparison. You can look at the example: http://nothingmuch.woobling.org/Test-TAP-HTMLMatrix/example.pl This example runs a test suite twice, injecting one of the runs with dummy failures. Then the two models are consolidated (the example is actually a bit overly verbose - it could have just been Test::TAP::HTMLMatrix-new( $model_ok, $modeL_failing )). The resulting HTML file displays the two test runs together, with their differences highlighted and expanded. Have fun! -- Yuval Kogman [EMAIL PROTECTED] http://nothingmuch.woobling.org 0xEBD27418 pgpnn4CFahud9.pgp Description: PGP signature
Re: 'temp $x;' with no assignment
On Mon, Mar 27, 2006 at 14:35:52 -0600, Jonathan Scott Duff wrote: On Mon, Mar 27, 2006 at 05:26:48PM +0200, Yuval Kogman wrote: How did $x become 10?!?!? :-) GHC has this lovely error: my brain just exploded I think Perl 6 should have a similar runtime warning about how it's usiong my short term memory for storage ;-) I think that if Ctemp is the new Clocal, then immediately after the Ctemp $x line, $x should hold whatever flavor of undef is appropriate. snip Is there some reason we're huffmannizing snip Because 90% of the code that people use local for in perl 5 is for counting levels and automatically unwrapping them. The other 10% are for more complex values. -- Yuval Kogman [EMAIL PROTECTED] http://nothingmuch.woobling.org 0xEBD27418 pgpydoADb9VlS.pgp Description: PGP signature
Re: 'temp $x;' with no assignment
On Mon, Mar 27, 2006 at 14:54:05 -0600, Jonathan Scott Duff wrote: Make me believe your 90/10 numbers. http://cpansearch.bulknews.net/ is broken right now... =( -- Yuval Kogman [EMAIL PROTECTED] http://nothingmuch.woobling.org 0xEBD27418 pgpaJiBDVaA0d.pgp Description: PGP signature
where will we die to?
on the #catalyst channel today we had lots of pains debugging where
a die will go to eventually, within a cascade of eval { }s and what
not.
In Perl 6 one thing that could ease this is to be able to easily
know where we will die to, without having to walk the stack and
checking which scope entries have a catch block.
The other thing is to be able to trace an exception: if we have 'die
foo but traced' then the exception should print cought at
rethrowed as it's doing that.
This second thing is much harder for me to pretend to implement
--
() Yuval Kogman [EMAIL PROTECTED] 0xEBD27418 perl hacker
/\ kung foo master: /me tips over a cow: neeyah!!
pgpoY9fblnOk2.pgp
Description: PGP signature
Re: where will we die to?
On Thu, Mar 23, 2006 at 08:14:03 -0800, Larry Wall wrote: On Thu, Mar 23, 2006 at 02:27:07PM +0200, Yuval Kogman wrote: How else would you implement it that doesn't impact performance? One of the main reasons for having exceptions is that they're exceptional, and should be pessimized with respect to ordinary code. Having to write a stack introspection routine is not that big of a hardship. Oh, i mean without *manually* walking the stack - present some standard library function like 'caller()' but only for catching frames. This is purely a usability issue... Perhaps Perl 6 should ship with some core modules for development, with this general stuff in place? For example, a help() function, like Python has, things like Devel::DumpVar, Benchmark, Test::WithoutModule, a profiler, Devel::Loaded and other such introspection shortcuts, Devel::SymDump, and even yours truely's Devel::Sub::Which (which will just be a quick hack with the MOP introspection) and Devel::STDERR::Indent ;-) These tools should be useful for writing/hacking the compiler toolchain itself - that is they should operate both within a runtime, and if possible, on the intermediate representations as well. Maybe have the debugger .wrap all CATCH blocks? That sounds nice -- Yuval Kogman [EMAIL PROTECTED] http://nothingmuch.woobling.org 0xEBD27418 pgpkPJcftg313.pgp Description: PGP signature
Re: Erroneous CPAN Testers Reports
On Tue, Mar 14, 2006 at 23:04:02 +1100, Adam Kennedy wrote: Even better would be adding two more states so that you can distinguish between prereq-failure, build-failure, test-failure and ok. Well actually I tried to sit down the other day and work out how many distinct types of success/failure events there might be, for use in PITA. The number came out to something like 15 :) Which I imagine means we end up with something like a HTTP numbering system. no no! just use strings: ok build_failure test_failure prereq_failure etc etc. Human *AND* machine readable. -- () Yuval Kogman [EMAIL PROTECTED] 0xEBD27418 perl hacker /\ kung foo master: *shu*rik*en*sh*u*rik*en*s*hur*i*ke*n*: neeyah pgpd64dMeavnV.pgp Description: PGP signature
RFC - weird stuff I had to do (for fun or profit)
Hi, In light of the Perl 6 community's increasing interest in API level design, I'd like people to share old war stories about things they had to do once, but had to jump through hoops to pull off. The point of this excercise is the edge cases of the existing perl builtin functions and core modules can be revisited and maybe better designed. Please reply to this thread with your tales of glory (or failures, and the reason they failed). -- () Yuval Kogman [EMAIL PROTECTED] 0xEBD27418 perl hacker /\ kung foo master: /me climbs a brick wall with his fingers: neeyah! pgpP4uiG0yDf6.pgp Description: PGP signature
Re: RFC - weird stuff I had to do (for fun or profit)
I have two stories related to files. I'll start with the failure: I wanted to write a Test::Harness wrapper that would monitor all the files/directories that the .t files of my test suite opened, and when they change to rerun only the affected tests. I am still planning on hacking this unportably using fs_usage on OSX and strace on linux, using FAM or whatever as the monitoring backend, but i would much rather have a mechanism like LD_PRELOAD for perl, with which i could add fancy hooks for IO operations without resorting to deep magic. The second story is abou Devel::FIXME. Devel::FIXME installs a subreference in @INC, that is always triggerred first. Then it recursively re-requires the file that was asked for, and this time when the callback is triggerred it pretends to fail. When it finds the file using the normal require, it will then read the file line by line, and report all FIXMEs using a cool api to filter unwanted ones. It then has additional boilerplate code to fake the success of an included module. Luckily all require return values are passed in scalar context so I didn't have to worry about *that* ;-) Audrey subsequently told me about the (undocumented) feature that lets you *return* a subroutine ref from a subroutine ref in @INC, that lets you get the source of the file that was normally found line by line for filtering. THat's what Acme::use::strict::with::pride, but I didn't know of it at the time. It's still pretty brutal ;-) Conclusions: I would have been happier if I could have a nice hook interface with which i could trap both module includes, and all IO operations and insert my own magic into the mess to aid me in my *DEVELOPMENT* process (not production related at all =) -- () Yuval Kogman [EMAIL PROTECTED] 0xEBD27418 perl hacker /\ kung foo master: /me sneaks up from another MIME part: neeyah! pgpWzpWCCJujk.pgp Description: PGP signature
Re: Erroneous CPAN Testers Reports
On Mon, Mar 13, 2006 at 14:31:53 -0700, Jerry D. Hedden wrote: Today, I filed a bug report against CPANPLUS because it sometimes fails to detect missing prerequisites, resulting in bogus FAIL reports being generated against modules: http://rt.cpan.org/Ticket/Display.html?id=18144 Here are two examples of such failures: http://www.nntp.perl.org/group/perl.cpan.testers/289146 http://nntp.x.perl.org/group/perl.cpan.testers/297161 I just got one (err, several) too, when my module became a prereq =( http://www.nntp.perl.org/group/perl.cpan.testers/297804 The *really* bad thing is that i didn't even get a Can't locate ok.pm in @INC in the output, only that some tests failed, and no further output. -- () Yuval Kogman [EMAIL PROTECTED] 0xEBD27418 perl hacker /\ kung foo master: /me wields bonsai kittens: neeyah pgpZHqvaQAflF.pgp Description: PGP signature
Re: XML parsing in P6
On Mon, Mar 13, 2006 at 00:27:32 +0530, Premshree Pillai wrote: Hello, [not sure if this belongs to this list; if not, apologies, and maybe point me to the right list] #perl6 on freenode might be a better choice - much more people are active. New to P6. Just compiled Pugs on OS X, so am just playing around. I was wondering if there's any XML parsing module available in Pugs. I saw an XML-SAX in misc/, but was wondering how to use it -- or of it can be used in the first place. That's a port of the Perl 5 XML::SAX (http://search.cpan.org/perldoc?XML::SAX) which is basically a parser factory... Unfortunately it doesn't seem like anyone actuallu wrote an XML::SAX driver in perl 6 yet. If there isn't one, can I use a P5 module in P6? I remember seeing something like use P5ModuleName--per5. Is that the current state of the art? Yes: you can do something like use perl5:XML::SAX; in Perl 6 code, and get the [reasonably] sane API that XML::SAX offers, along with the *HUGE* array of drivers. Essentialy XML::SAX wants you to inherit from some handler base class, and then handle events like 'start_tag', etc. Some more fun XML modules exist on on the CPAN, which provide more treeish APIs than event parser APIs. Ciao! -- () Yuval Kogman [EMAIL PROTECTED] 0xEBD27418 perl hacker /\ kung foo master: /me climbs a brick wall with his fingers: neeyah! pgplqLqOqmFwV.pgp Description: PGP signature
Re: XML parsing in P6
On Mon, Mar 13, 2006 at 01:00:42 +0530, Premshree Pillai wrote: On 3/13/06, Yuval Kogman [EMAIL PROTECTED] wrote: #perl6 on freenode might be a better choice - much more people are active. I know. I am currently at a friend's place, and seems like (for whatever reason), his ISP has blocked certain ports (don't ask me to use a web-based client :-p). You can probably have a shell account on feather.perl6.nl (Juerd needs your full name and I don't know if this can be done by proxy or not), and definately on my machine, where you can use screen/irssi to your heart's content, if you please. Okay, this works fine. But now how do I actually inline P5 code in a P6 program? I just tried using XML::Parser::Lite::Tree, but (obviously?) am getting errors. Paste code / errors? Essentialy XML::SAX wants you to inherit from some handler base class, and then handle events like 'start_tag', etc. Yeah, aware - have used SAX parsers in perl and otherwise. Ah, i thought you were a Ruby guy and since you asked what the XML::SAX thing was I didn't think you've used it before. -- () Yuval Kogman [EMAIL PROTECTED] 0xEBD27418 perl hacker /\ kung foo master: /me beats up some cheese: neeyah! pgpBoFieUTlli.pgp Description: PGP signature
Re: XML parsing in P6
On Sun, Mar 12, 2006 at 21:42:59 +0200, Yuval Kogman wrote: You can probably have a shell account on feather.perl6.nl (Juerd needs your full name and I don't know if this can be done by proxy or not), and definately on my machine, where you can use screen/irssi to your heart's content, if you please. Oh, additionally for when i'm stuck in your kind of situation I have port 443 mapped to ssh on my machine, and I think feather does that too if audrey is in the mood ;-) -- () Yuval Kogman [EMAIL PROTECTED] 0xEBD27418 perl hacker /\ kung foo master: /me tips over a cow: neeyah!! pgpBqrhNNwF3L.pgp Description: PGP signature
Re: XML parsing in P6
On Mon, Mar 13, 2006 at 06:33:06 +, Luke Palmer wrote: Luke Luke! You're back from the dead! *dance* -- () Yuval Kogman [EMAIL PROTECTED] 0xEBD27418 perl hacker /\ kung foo master: /me beats up some cheese: neeyah! pgpuZTuJK9VUu.pgp Description: PGP signature
Re: Show-stopping Bug in Module::Install and the Havoc it Created
On Fri, Mar 10, 2006 at 13:36:26 +0100, Tels wrote: So the bug might not affect everyone - but it is bad and makes me re-consider using Module::Install only when necessary. Module::Install makes sense for applications and deployment and all that For regular CPAN modules I think it's overkill. -- () Yuval Kogman [EMAIL PROTECTED] 0xEBD27418 perl hacker /\ kung foo master: /me wields bonsai kittens: neeyah pgp3nqjk41dmP.pgp Description: PGP signature
Re: What is the Value of t/0-signature.t?
On Thu, Mar 09, 2006 at 12:51:02 -0800, chromatic wrote: Hi all, In http://rt.cpan.org/Ticket/Display.html?id=17934, a Test::MockObject user dislikes the t/0-signature.t test that always runs. If the user does not have Module::Signature installed, no tests run. If the user does have Module::Signature installed but not configured properly, the test will fail. The problem with these is that Module::Signature fails when it should warn if the key is not present in the user's keyring. If this technical issue is solved then regardless of whether or not signature tests are useless (i think they are, but then again i also think i have some modules with Test::Distribution that checks that... so I am a hypocrit ;-) the usability of these tests will be good enough. (I'm CCing audrey so that she'll know I'm dissing her module ;-) -- () Yuval Kogman [EMAIL PROTECTED] 0xEBD27418 perl hacker /\ kung foo master: /me beats up some cheese: neeyah! pgpSgMswRPJbv.pgp Description: PGP signature
Re: ANNOUNCE - Smolder 0.01
On Sat, Mar 04, 2006 at 09:09:00 -0500, Michael Peters wrote: It's very similar in nature to the Pugs smoke test server, but is completely project agnostic. It's also completely self contained (contains local copies all of it's Perl modules and a local apache/mod_perl). It's released in binary packages (currently there's only 1 binary package, but more will hopefully be coming) and also a source distribution from which you can build a binary package. All it requires is an existing version of Perl 5.8.x (might work with 5.6.x but that hasn't been tested) and MySQL 4.x. Could you please please please pretty please with a cherry on top add SQLite support? Another, much more pretentious request is that you refactor anything and everything you can into generic modules and put them on the CPAN. -- () Yuval Kogman [EMAIL PROTECTED] 0xEBD27418 perl hacker /\ kung foo master: /me dodges cabbages like macalypse log N: neeyah! pgpb3Ys8tDric.pgp Description: PGP signature
Re: socket addresses (was Re: early draft of I/O PDD)
On Sun, Mar 05, 2006 at 18:34:26 +, Nicholas Clark wrote: On Fri, Mar 03, 2006 at 05:54:43PM -0600, Joshua Isom wrote: I don't think it's really been addressed, at least not recently, but what about IPv6? By the time perl6 becomes commonplace and used often(and thus, parrot), IPv6 will be common enough that problems could occur. Currently it's not speced or stated, aside from a comment in PIO_sockaddr_in. The draft has: =item * Csockaddr returns a string representing a socket address, generated from a port number (integer) and an address (string). I don't think that this is appropriate. It's IPv4 specific. It doesn't cover AF_UNIX (er, AF_LOCAL), IPv6, or any of the other address formats (of which I'm not sure if any other than IPX are still commonly used. I'm not sure how to make an appropriate interface, partly as I have little idea if it's possible to make a sufficiently flexible abstraction for address names. IPv4 and IPv6 both use addresses and port numbers. AF_LOCAL just uses a string, which is a file system path. But I think that specifying an op for just one address format is too narrow. Objects that stringify! Objects that stringify! -- () Yuval Kogman [EMAIL PROTECTED] 0xEBD27418 perl hacker /\ kung foo master: /me whallops greyface with a fnord: neeyah!!! pgp2d8OPP5NHE.pgp Description: PGP signature
Re: ANNOUNCE - Smolder 0.01
On Sun, Mar 05, 2006 at 17:55:03 -0500, Michael Peters wrote: It's already resulted in Test::TAP::XML. Nothing immediately jumps out as applicable outside of smolder, but I'm sure more will come up. I've also got some planned improvements to Test::Harness::Straps and Test::TAP::Model that should make it easier to gather more information. Shlomi Fish wrote Test::Run, a Test::Harness fork and was considering improving Test::TAP::Model as well... It might be beneficial for you guys to help each other out if you can. -- () Yuval Kogman [EMAIL PROTECTED] 0xEBD27418 perl hacker /\ kung foo master: uhm, no, I think I'll sit this one out..: neeyah! pgpvSc6ngPJyD.pgp Description: PGP signature
Re: early draft of I/O PDD
With respect to async IO (regretfully I get to see a lot of this at $job): Each operation can be async, or sync, with a similar API. There should be enough hooks to be able to wait on a specific operation happenning on a stream, any operation on a stream, any operation on a group of streams, and any operation on any stream. The resulting set of operations should be optionally available, as this is one of the biggest sources of boilerplate in posix aio in C. aio_suspend (or a wrapper on top of it) should probably be the event loops default idle loop, and it should keep a flag raised such that if the aio event loop wrapper knows that an event that was not waited on finished, the user code can check on that easily. A possiblity for a unified AIO/SIO interface could be that each IO op returns an operation handle, and you can ask that handle about it's status (running, finished, error), get it's results from the handle, and also ask it to block. This could have a high overhead due to storage creation, but it's generally a pretty flexible and portable abstraction. On Fri, Mar 03, 2006 at 11:27:05 -0800, Allison Randal wrote: We're going to try something a little different. With Chip's blessing I've written a very early draft of the PDD for I/O (not numbered yet). The attached PDD isn't a completed document with Chip's seal of approval, it's a seed for discussion. What I need from you all is comments. What's missing? What's inaccurate? What's accurate for the current state of Parrot, but is something you always intended to write out later? What thoughts have you had on how the I/O subsystem should work? All contributions cheerfully welcomed, from a single sentence to several pages of text. Chip won't be making design decisions during the conversation. He may not even participate much, since part of the point is to split the work into parallel tasks so we can get more done than is humanly possible for one person. I'll use the discussion to write up a more complete PDD (probably with a few alternatives written in), and then work with Chip to review/revise it. Thanks, Allison -- () Yuval Kogman [EMAIL PROTECTED] 0xEBD27418 perl hacker /\ kung foo master: /me sushi-spin-kicks : neeyah pgp8tEwohagCA.pgp Description: PGP signature
Perl 6 design wiki?
I think Perl 6 could use a wiki for several things: 1. creating a place where people can easily find user annotations of the synopses etc 2. scratch pad areas for people to write musings, criticism, discussion and so forth in a way that the community can revise. This complements theh discussion process as carried out on the list because it's not time oriented - people can stumble upon a wiki page at a later date more easily than they would find mailing list archives. 3. a collection of idioms, patterns, ideas, style guides, reccomendations, translation info and so forth - the less formal documentation of a language, if you will. Pugs has example code, some quick start guides, and a few other nice things in it's repository, which are not pugs specific in any way. -- () Yuval Kogman [EMAIL PROTECTED] 0xEBD27418 perl hacker /\ kung foo master: : neeyah! pgpwysUBcr6bP.pgp Description: PGP signature
Re: Separate compilation and compile-time things
One way to think of your macro example (instead of the -import one, which is harder to define, i think): Every time you use a module it's used by the compiler, and by the emitted code. The compiler loads the macros, the emitted code loads the non-macro stuff. Since the clsoure is created in the compiler's runtime this is slightly consistent ;-) -- () Yuval Kogman [EMAIL PROTECTED] 0xEBD27418 perl hacker /\ kung foo master: /me supports the ASCII Ribbon Campaign: neeyah!!! pgpWiJRp1WJ6s.pgp Description: PGP signature
Re: Separate compilation and compile-time things
On Thu, Mar 02, 2006 at 15:13:07 +0200, Zohar Kelrich wrote:
We were discussing some confusing macro behaviours, when we came upon this
curious thing. This code is really simple in p5, as it doesn't really have
separate compilation, but in p6, the modules can be pre- compiled or cached.
8--
module ImportHeadache;
my $m;
sub import() {
$m++;
}
sub report is export { $m };
sub deport {...}
#-- Meanwhile, elsewhere!
module Elsewhere;
use ImportHeadache; # I'm calling import at Elsewhere's compile time!
#-- Meanwhile, another elsewhere!
module Elsewhere2;
use ImportHeadache; # I'm calling import at Elsewhere2's compile time!
#-- Main program
use v6;
use Elsewhere;
use Elsewhere2;
use ImportHeadache;
say report; # What should I say?
--8
The result is, of course, (1..3).pick(), depending on whether the modules
were compiled by the same compiler instance at the same time.
Perl 6 is specced such that it's always separate compilation, so
this should probably always be 0, unless you're tying the value to
disk.
The way it's handled:
$m is reallocated every time a module is used, and thrown away after
it finished compiling.
Then the resulting code will be linked, after $m was garbage
collected. This code can be relinked as many times as we want.
The problem seems to be that we have statefulness that we expect to survive
compilation boundaries.
Well, Perl 5 didn't have such boundries =)
All statefulness in Perl 6 is not saved. Values and code are
dumoped, and will be loaded on every link. This means that this does
not get saved back to disk. This also means that linkage could be
cached.
So, should each compilation unit get a fresh environment? Or should this
simply work like I think it currently does, and just hopefully not bite
people
too often? Should doing what this is trying to do be possible in a
different, longer-huffmanized way?
I think separate compilation is more consistent - it allows much
--
() Yuval Kogman [EMAIL PROTECTED] 0xEBD27418 perl hacker
/\ kung foo master: /me tips over a cow: neeyah!!
pgp8X8bmCof23.pgp
Description: PGP signature
Re: A proposition for streamlining Perl 6 development
On Wed, Feb 08, 2006 at 12:37:05 -0800, chromatic wrote: On Tuesday 07 February 2006 23:55, Yuval Kogman wrote: Does this imply that we should think up this process? Go ahead. We'll start at the Israel hackathon, with a little preamble. 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 doubt it'll work now, either... Here is my reply on #perl6 to your discussion on Perl 6: My reply: http://colabti.de/irclogger/irclogger_log/perl6?date=2006-02-09,Thusel=11 Your discussion: http://colabti.de/irclogger/irclogger_log/perl6?date=2006-02-08,Wedsel=348#l558 I have doubts that specifying a complete compiler and toolchain without at least some trial and error will work, but I could be wrong. Trial and error is always required, and a very good tool for innovation in the hands of the community. I don't think Big Bang design is ever good, but I also believe a rough plan with easy to understand milestones (as opposed to a daunting cliff) are required, even if not formal or even on paper. Also, I am trying to formulate a plan that will help us write most of the parts in Perl 6, *NOT* Haskell, because I, like you, despite my love for Haskell, think it's just too inaccessible. What I'd like is to optimize the modularization such that Pugs serves as a bootstrap parser/interpreter/compiler - a good solid tool to help us write: The Perl 6 standard library in Perl 6 (with stubs for IO, system calls, and other things that cannot be defined in a pure language) The Perl 6 compiler toolchain in Perl 6 (the linker, compiler, emitters, and an interpreter, too). And then eventually refactor the current state of pugs into a haskell runtime, and and possibly a historical parser/compiler that we can use to compare things to. The way things are headed now, we are just shy of being able to write good tools in Perl 6 using pugs - it's too slow, the object model is not finalized, the grammar is not extensible, etc etc. These are many things that are mentioned in the synopses but not described in enough detail, and if we want the other parts to be in Perl 6 we need these done in haskell first, and then rewritten. If we get them later, we'll have to write the other parts in haskell too. 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. Yes, that's an excellent start, and in fact, I think this is what Audrey plans on starting with at the prehackathon, when she arrives in Israel and works with Gaal. Unfortunately for myself, I will be unable to follow this discussion as of ~14:00 GMT, today (Feb 9th) as I'm going to visit my grand parents in Austria, and try not to die while snowboarding. -- () Yuval Kogman [EMAIL PROTECTED] 0xEBD27418 perl hacker /\ kung foo master: /me tips over a cow: neeyah!! pgpRKRygJtTjG.pgp Description: PGP signature
Re: A proposition for streamlining Perl 6 development
I'd like to have a crack at rephrasing this, since everyone but stevan seems to be getting the wrong impression. Perl 6 has some hard to answer questions. The questions the community has answered so far are: * How the VM will work/look * What the syntax/feature requirements are If we ignore pugs for a second. These are though questions to answer, and I have no criticism whatsoever that they took long to answer. Development speed is *NOT* what this post was about. What I do think is that there is something in the middle of these two big questions, and they are: * How will the Perl 6 compiler be designed (parts, etc) * What are the definitions of some of the standard features mentioned in the Synopses ( S29 is a good start, but we need more than the standard perlfunc) If we let Perl 6 continue to grow organically we will have answers to these questions, but we will likely invest lots of effort in trial and error. I think that some of these questions can be answered based on some up front design, thinking, and decision making, thus helping us direct our trial and error efforts towards a more defined goal. Furthermore, I think this has important implications on the quality of the implementation of the Perl 6 compiler and standard library, and that we should start worrying about that too. The second (much larger) part of the post contains a sort of draft, if you will, of what I think can be a good start towards trying to answer these questions. Thanks -- () Yuval Kogman [EMAIL PROTECTED] 0xEBD27418 perl hacker /\ kung foo master: /methinks long and hard, and runs away: neeyah!!! pgpEyRQC2JVbl.pgp Description: PGP signature
A proposition for streamlining Perl 6 development
is to try and separate the parts even more - the prelude is a mess right now, many of it's part are duplicated across the backends, the standard library that is mashed into the prelude, and into pugs core itself, etc. After this step I think the multiple backend approach should be refactored heavily to share as much code as possible, in accordance with the plans I posted (confusingly termed Circular Prelude stuff back then, see also VM support listed above). The biggest missing component of the compiler is: self hosting grammar, real macro support all the way down, a linker (the groundwork for this has improved with the new lexical importing code lately), and type checking. The Perl 5 compatibility layer: an additional deprecated library that emulates the Perl 5 standard library which wasn't absorbed into Perl 6 the perl 5 to perl 6 converter Integration with Ponie to enhance code reuse Additional criticism: Right now the biggest problem in Perl 6 land is project management. We, as a community, are facing a task which is sliced into chunks that are just way too big in my opinion. People burn out. People have to do things more related to day jobs (that's why my pugs hacking is on hold, for example), people think things half way, etc. If we have a layered approach we can concentrate on providing something that is more balanced ... Phew. Ciao! -- () Yuval Kogman [EMAIL PROTECTED] 0xEBD27418 perl hacker /\ kung foo master: /me spreads pj3Ar using 0wnage: neeyah!!! pgpTSz073ssT9.pgp Description: PGP signature
Re: A proposition for streamlining Perl 6 development
On Tue, Feb 07, 2006 at 14:02:54 -0800, chromatic wrote: 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. Separation to subprojects was not what I meant. I think the best way to describe it is to take concepts which I think are correct for writing clean code: * separation of concerns * layering * prefer generic components to specific ones and to try and apply them to Perl 6's design, which is a bit too big for any implementation effort to complete as one whole unit. If we have more steps and clearer milestones for whatever is between parrot and the syntax/feature level design implementation will be easier. One way to start creating these milestones is to try to refactor the design of the language. 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. That was entirely not my point =( De-facto we have people running PIL on javascript. It works more than parrot does. The design of Perl 6 itself should be agnostic to where people are developing backends IRL. -- () Yuval Kogman [EMAIL PROTECTED] 0xEBD27418 perl hacker /\ kung foo master: /me wields bonsai kittens: neeyah pgpziyhoCyxlz.pgp Description: PGP signature
Re: A proposition for streamlining Perl 6 development
On Wed, Feb 08, 2006 at 08:59:35 +0800, Audrey Tang wrote: On 2/8/06, Yuval Kogman [EMAIL PROTECTED] wrote: If Audrey is willing, I think a correct new direction for pugs is to try and separate the parts even more - the prelude is a mess right now, many of it's part are duplicated across the backends, the standard library that is mashed into the prelude, and into pugs core itself, etc. Er, of course I'm willing, that was exactly we've been moving toward in the recent weeks. :-) Though an explicit Standard Library design -- as compared to Perl5's which was grown out gradually by the porters and CPAN folks -- is tricky, and I'm not yet ready for that, lacking a practical understanding of how module interfaces and roles can be applied to this diverse design space. By standard library is i don't mean core modules - it's Perl 6's perlfunc + some really critical pieces. So I will be focusing on Prelude (the part of the language that always gets loaded by default) refactoring as well as providing an OO core calculus that can support this, and take advantage of the target VM's vast library instead of writing them in Perl 6, at least up until 6.2831 (the primary target VM is Perl 5, then Parrot, then JavaScript.) Aye =) -- () Yuval Kogman [EMAIL PROTECTED] 0xEBD27418 perl hacker /\ kung foo master: /me wields bonsai kittens: neeyah pgpkSfVxlONBs.pgp Description: PGP signature
Re: A proposition for streamlining Perl 6 development
On Tue, Feb 07, 2006 at 18:51:03 -0500, David K Storrs wrote: So, to bring it down to brass tacks: there are 5 big chunks (S15, S16, S18, S21, S23) that remain to be be written, a 6th (S08) that needs to be written but will probably be fairly short, and 5 (S28, S30-33) that need to be compiled out of the mass of emails flying through the lists. I know that substantial progress has been in defining the semantics of all of these topics, and I have the impression that it's mostly a question of wrapping up the last 5-20% of each one, compiling all the data, and writing the Synopsis. I'd say that qualifies as light at the end of the tunnel indeed! The point I was trying to raise is that the Synopses are a very high level, top down angle on the language's design. They have *NOTHING* about any implementation details like: the design of the compiler the design of the runtime the design of the object space The layers of Perl 6 (what is an optional module? what is a macro (see also 'use')? what is the core essence of Perl 6?). Except implying that these things will be implemented in Perl 6, and will be somehow worked out. Now, I have no objection to this - the Synopses are sort of like requirement docs. But we do need something that's between where parrot is today, and a top down view of all of Perl 6 - and that's a lot of chunks. What I'm trying to say is that letting the part in the middle grow completely organically and ad-hoc is not a good thing, and that the pugs developers really have no authority as to making design decisions. We need those things to happen and they're getting overlooked, and in my opinion the first step into this is refactoring the design into several layers. Bottom line - there's much more than 5 missing chunks in the design, as I see it - designing the implementation is nontrivial. Also, none of the synopses are really 100% complete - S12 does not detail the meta model's methods and features, for example. The doc explaining macros does not detail what the AST macros get (the definition of the AST). Etc etc etc. These things are also important to implementation, and amount to a huge chunk of code. If we can layer this code, chunk it up, componentize it and make it clean we we can implement it more easily. -- () Yuval Kogman [EMAIL PROTECTED] 0xEBD27418 perl hacker /\ kung foo master: /me groks YAML like the grasshopper: neeyah!! pgpINCVaWGh9r.pgp Description: PGP signature
Re: A proposition for streamlining Perl 6 development
On Tue, Feb 07, 2006 at 23:11:32 -0800, Allison Randal wrote: On Feb 7, 2006, at 19:21, Stevan Little wrote: Perl 6 will get implemented. Oh, of that I have no doubt. Never did, and neither does Yuval (if I may speak for him while he is asleep :). But all that we are trying to do here is shake out some cobwebs, a little spring cleaning if you will. Excellent. I wish you much fun! :) Does this imply that we should think up this process? If so, I have made many many contributions on this topic to perl6-language on this topic, and I feel like they have been mostly overlooked. 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. I am asking for your (all of you) help in clarifying the big void in the middle - the design of the perl 6 runtime, not just syntax/features. What I'm suggesting is a start in this clarification - trying to componentize the existing syntax/feature spec that we do have, so tha the design of the runtime can be simplified and more concrete/attainable. -- () Yuval Kogman [EMAIL PROTECTED] 0xEBD27418 perl hacker /\ kung foo master: /me does not drink tibetian laxative tea: neeyah! pgpacYRPkWgIO.pgp Description: PGP signature
Re: facades, use_ok, and lexical export
What we need to do is find a way to do this at compile time. One way is to make use_ok a macro. The whole thing with linkage in Perl 6 is that it's supposed to happen at compile time so that things are overall saner, but that it can happen at runtime if we really really mean it. use_ok as a function could simply import $module into the non lexical scope because it's a runtime thing, unless it's made into a macro/some other compile time construct, that is more declarative in nature, and makes the whole process more opaque. -- () Yuval Kogman [EMAIL PROTECTED] 0xEBD27418 perl hacker /\ kung foo master: /me whallops greyface with a fnord: neeyah!!!
Re: Perl grammar for Perl5 - Perl6
On Wed, Dec 07, 2005 at 16:48:11 -0500, Peter Schwenn wrote: Dear Perl6 Language, I am Perl user from near year 0. For me the easiest way to learn (, track, and get to the point of contributing to) Perl6 would be a Perl grammar (a regex rule set in, preferably, Perl6) that transforms any Perl5 script into a Perl6. Of couse, besides learning Perl6 for a regex'r or Perl5'r such as myself, and tracking, and documenting 6, it would have huge use for Perl5 users making or considering the transition. IMHO machine translation is not that good a way to start learning - the real benefit of Perl 6 is in the features which have no perl 5 equivalents and solve problems much more elegantly. The best thing to do is to hang out on #perl6 and get involved with the test suite, as well as reading the synopses. Perhaps writing a toy program or something like that could also help. For example one can infer the structure and some of the rules from http://svn.openfoundry.org/pugs/docs/other/porting_howto which is however written out in informal (not regex) rules such as $array[idx] - @array[idx] These are rules for humans with lots and lots of context info... Furthermore, they are more of a perl 6 gotcha list, for perl 5 programmers than a translation guide. Is there such a Perl5-Perl6 translator underway? Larry Wall is working on using the perl (5) interpreter to create compiled output (as opposed to just something that executes in memory) that can then be read by a translator without actually parsing perl 5. Before this happens this will be very very hard - the high level language has vast amounts of implications on execution etc, but the opcode tree is much more simpler to predict (for a computer). p.s. The developing form of such a grammar could likely lead to a grammar package which facilitates rule sets for languages in other domains, in terms of illuminating means of choosing among modes for rule ordering, collecting, scoping, re-application, recursion, exclusion and so forth. Since perl 5's actual parser and tokenizer will be used for this it won't be very extensible, but this is important because perl is reallly hard to parse. -- () Yuval Kogman [EMAIL PROTECTED] 0xEBD27418 perl hacker /\ kung foo master: /me supports the ASCII Ribbon Campaign: neeyah!!! pgpYtSG9AVmvL.pgp Description: PGP signature
Re: Capabilities in Perl6?
On Thu, Dec 01, 2005 at 10:54:14 -0500, Rob Kinyon wrote: I just read the slides about CAPerl (http://caperl.links.org/) and it's an interesting idea. The ideas I tossed around regarding the circular prelude should make perl 6 be roughly on the same level as javascript in terms of this security stuff. This is a very good start towards a model where a crippled runtime is mixed with a fully priviliged one, with grey areas in the middle. -- () Yuval Kogman [EMAIL PROTECTED] 0xEBD27418 perl hacker /\ kung foo master: : neeyah! pgphItl8rypLf.pgp Description: PGP signature
Re: testing Javascript applications ?
On Mon, Nov 28, 2005 at 20:25:48 +, Mark Stosberg wrote: But now how I can test the application? I have a link that uses AJAX to pull in some content that gets displayed in a new layer, including a form I'd like to submit. http://www.qapodcast.com/news/2005/11/02/qa-podcast-7-talking-selenium-with-luke-closs That and unit tests for your ajax handlers should do it. -- () Yuval Kogman [EMAIL PROTECTED] 0xEBD27418 perl hacker /\ kung foo master: /me kicks %s on the nose: neeyah! pgpwsZLSuUi4B.pgp Description: PGP signature
Re: Classification syntax [Was: Renaming grep]
On Fri, Nov 18, 2005 at 11:36:33 -0800, Larry Wall wrote:
If we had some kind of partitioning operator, it'd probably be generalized
to sorting into bins by number, where 0 and 1 are degenerate cases for
booleans. But since we'd almost certainly make the general form
(@bin0, @bin1, @bin2...) := classify { calc_int($_ } LIST;
For me it seems to make more sense that in the higher-order scheme
of things classify presents functions to it's body. Instead of
relying on the return value from the body, it gets a number of
functions that it can invoke to append a function.
This is more general since it allows classification to include
duplicates.
Grep is simply:
sub grep (filter, [EMAIL PROTECTED]) {
classify - $x, f {
f($x) if filter($x);
} [EMAIL PROTECTED];
}
--
() Yuval Kogman [EMAIL PROTECTED] 0xEBD27418 perl hacker
/\ kung foo master: /me does not drink tibetian laxative tea: neeyah!
pgpJajdFgPsEB.pgp
Description: PGP signature
Re: Role Method Conflicts and Disambiguation
On Wed, Nov 02, 2005 at 16:37:29 -0600, Jonathan Scott Duff wrote: On Tue, Nov 01, 2005 at 04:02:04PM -0800, Jonathan Lang wrote: True enough; but it needn't be true that d have the same tools available to resolve the conflicts that c has. There are three ways that a role can deal with a conflict: 1. choose one of a set of available methods to call its own. 2. create a version of its own. 3. pass the buck. In the first case, the question is how we define the set of available methods: do we make the full hierarchy of ancestors available to the role, or do we say that only the immediate parents are available? People keep using the word hierarchy when talking about roles and I keep thinking that it is the one word that definitely does NOT apply. Heirarchies are for classes and inheritance relationships, not roles and composition. Uh, roles are composed wrt to the hierarchy of who does who. In my world view, a role that is composed of two other roles has full view of the methods/attributes defined in the roles that compose it because the landscape is quite flat. There are no hills and valleys. When it finally comes down to composing into a class, the class sees all of the methods/attributes provided by each and every role even the role inside a role inside a roles. The composition is basically mixin with some exceptions, but there's still a hierarchy roles A and B are composed into C at compile time. If both A and B define a method foo(), then there is a conflict (immediately, at compile time) unless you've somehow told perl that it should defer composition until it's actually composing classes. Class composition also happens at compile time... There's no reason to make the error occur too early for usefulness to be around. As long as it's not too late ;-) -- () Yuval Kogman [EMAIL PROTECTED] 0xEBD27418 perl hacker /\ kung foo master: : neeyah! pgpJsS5MicP4a.pgp Description: PGP signature
Re: Role Method Conflicts and Disambiguation
On Fri, Oct 28, 2005 at 14:19:46 -0400, Stevan Little wrote:
Yuval,
On Oct 28, 2005, at 10:59 AM, Yuval Kogman wrote:
On Thu, Oct 27, 2005 at 22:19:16 -0400, Stevan Little wrote:
Now, at this point we have a method conflict in suspension since
(according to A/S-12) method conflicts do
not throw an error until a role is composed into a class. This means that
when I do this:
class MyClass does FooBar {}
an exception is thrown. Unless of course MyClass has a foo method, which
will disambiguate the conflict.
My question then is, can FooBar (the role) disambiguate the foo conflict?
IMHO yes, but it doesn't have too. It should be able to leave it to
the class to decide.
If we allow the class to decide if things break or not, then we
potentially allow for the system to be in a very unstable state. A
method conflict means that neither method gets consumed, and at
that point we have a gapping hole in our class.
And compilation will not finish unless the class plugs the hole...
role a;
role b;
role c does a does b;
class d does c;
If there is a conflict at c, it might be a conflict that c knows how
to resolve, or it might be a conflict that c's documentation says
the user has to decide on, depending on what they prefer.
What I'm saying is that the hole in c can be consumed by d, and if
it isn't plugged in either c or d, you get an error.
I think it's useful from a role perspective, because that way you
can let the user decide on some conflicts.
While I can't think of an example, I don't think there is much risk
- this doesn't take away functionality. The only issue is that you
can compile a role with a conflict and it doesn't complain till you
actually use the role (this should be taken care of by writing the
simplest of tests for your role). It does open doors for higher
complexity composition. Especially if you have a deep hierarchy of
role consumption:
a b c d
\ / \ /
e f
\- g -/
(role g does e does f, e does a, does b...)
Let's say that a and b conflict at 2 points. E can resolve one of
them, and leave the other one for g to decide.
Perhaps methods in f are used to resolve e with dynamic dispatch:
role g does e does f {
method conflicts_in_a_and_b ($arg) {
given .method_from_role_f($arg) {
when Condition { .a::conflicts_in_a_and_b($arg)
}
defualt { .b::conflicts_in_a_and_b($arg) }
}
}
}
This is, IMHO legitimate use.
The only restriction should be that when runtime begins no class (or
anything that can be instantiated) is allowed to still have a
conflict.;
In the end, we will have probably looked inside every method defined in
Foo, Bar, FooBar and Baz in order
to properly write MyClass2. IMHO, this is sort of defeating the
usefulness of roles at this point.
I disagree - you have to know what a role is actually giving you to
exploit it. Too much black boxing makes your programming language
seem like a Kafka story.
Why? does it introduce bugs? ;-P
If you can't see at all into the code you use you eventually run
into problems like the shlemiel the painter algorithm for C
strings (google to find refs for that, too long to explain here).
Frequently when using library code whose documentation is not
perfect (and in opensource almost no documentation is ever perfect)
I have a great privilige - search.cpan.org has a one click path to
seeing the source code of any module i'm considering to install.
This allows me to see how something works, estimate how hard it will
be to extend it if the need should arise, assess the quality of the
code, and make sure I understood things correctly.
This spirit of openness should be maintained. You don't have to take
apart a role and recompose it and what not, breaking encapsulation.
But you should be able to fudge it slightly, because the author of
the role might not be getting paid to fix it to your needs, and you
may have to get slightly hackish.
--
() Yuval Kogman [EMAIL PROTECTED] 0xEBD27418 perl hacker
/\ kung foo master: /me whallops greyface with a fnord: neeyah!!!
pgpcm9H3z1CWi.pgp
Description: PGP signature
Re: Role Method Conflicts and Disambiguation
On Fri, Oct 28, 2005 at 14:04:35 -0500, Jonathan Scott Duff wrote: That there will not be two slots for $:foo in Xy, but only one. But, I'm probably wrong about this as the X role may have methods that use $:foo in one way and the Y role may have methods that use $:foo in some other, incompatible way, so perhaps there will be a conflict just as when there are 2 methods of the same name. Uh, that's horrible, because it means private attributes have only the disadvantages of privacy (no access) and not the advantages (separation, no conflicts). non-private attributes should conflict, but private attributes are no one's business except the package which made them. -- () Yuval Kogman [EMAIL PROTECTED] 0xEBD27418 perl hacker /\ kung foo master: uhm, no, I think I'll sit this one out..: neeyah! pgpSU9hxLHLy8.pgp Description: PGP signature
Re: Role Method Conflicts and Disambiguation
On Thu, Oct 27, 2005 at 22:19:16 -0400, Stevan Little wrote:
Hello all,
I have a question about method conflict resolution works for roles, and I
cannot seem to find this in any
of the Apoc/Syn documents.
Here is the basic issue:
role Foo {
method foo { ... }
method bar { ... } # we will use this later :)
}
role Bar {
method foo { ... }
}
role FooBar {
does Foo;
does Bar;
}
Now, at this point we have a method conflict in suspension since (according
to A/S-12) method conflicts do
not throw an error until a role is composed into a class. This means that
when I do this:
class MyClass does FooBar {}
an exception is thrown. Unless of course MyClass has a foo method, which
will disambiguate the conflict.
My question then is, can FooBar (the role) disambiguate the foo conflict?
IMHO yes, but it doesn't have too. It should be able to leave it to
the class to decide.
role FooBar {
does Foo;
does Bar;
method foo { ... }
}
Now, on the surface this seems obvious, of course the FooBar role should be
able to disambiguate. However,
when we expand the example other issues show up.
role Baz {
does Foo;
}
class MyClass2 does FooBar does Baz {} # Will this die?
splice
But thats not all, we have a potential problem with foo again. Baz will
provide foo from Foo, but FooBar
will provide it's own foo (which we used to disambiguate). So our
disambiguation is not ambiguated
again.
/splice
yes, since the methods are coming from different context, and they
may have different meanings. While FooBar::foo resolves the conflict
from the assimilation of Foo::foo and Bar::foo, it does it only
within FooBar.
If, OTOH we have a diamond inheritence:
role A { method foo { ... } }
role B does A {};
role C does A {};
class D does A does B { };
I'm not sure we need to resolve the conflict.
Now, since MyClass2 actually does Foo twice, does that mean bar creates a
conflcit? Since bar would be
found through FooBar and Baz. I would think the answer here would be no, and
that we would build some
kind of unique list of roles so as to avoid repeated consumption like this.
No conflict - an assimilated role is identicle to itself even
through different paths since it doesn't get access to private or
protected member data of it's consuming roles.
If, on the other hand, we have
role X trusts Foo does Foo {
has $:foo;
}
role Y trusts Foo does Foo {
has $:foo;
}
role Foo {
method foo {
$:foo++;
}
}
class C does X does Y { }
there is a conflict, because Foo is reaching into either X's private
member $:foo or Y's private member $:foo (btw, they should never
conflict with each other).
The moment a method will have behavior that is different in two
different role consumptions it will be conflicting, but this will
only happen to a method from the same class if it has some private
symbols resolved at role composition time using class friendship.
I think it is ambiguous, s
A (deceptively) simple solution to this is that MyClass2 needs to
disambiguate. But this means that our
roles are not really black boxes anymore. In order to properly disambiguate
this we need to know where
all the foo methods are coming from (Foo, Bar and FooBar), and potentially
what is inside these foo
methods (especially in the case of FooBar since it is attempting to
disambiguate, it's behavior could be
very specific). It probably would also become important to know what other
methods foo interacts with
since we potentially have 3 different expected versions of foo.
method foo is Foo::foo;
or
method foo (*$a) { ./Foo::foo(*$a) }
or
foo ::= Foo::foo;
In the end, we will have probably looked inside every method defined in Foo,
Bar, FooBar and Baz in order
to properly write MyClass2. IMHO, this is sort of defeating the usefulness
of roles at this point.
I disagree - you have to know what a role is actually giving you to
exploit it. Too much black boxing makes your programming language
seem like a Kafka story.
So what do you all think??
Role method conflicts should only be dealt with if the user knows
what the roles are actually doing anyway. This will probably be
familiar code, and if not it warrants familiarity.
I don't think we can let the user use library code without being
aware of the library code internals at all. Abstraction that works
like this is usually either crippled or useless. 90% of the time you
don't want to know, but there are exceptions.
--
() Yuval Kogman [EMAIL PROTECTED] 0xEBD27418 perl hacker
/\ kung foo master: /me sushi-spin-kicks : neeyah
pgpmmr3g6z6ZK.pgp
Description: PGP signature
Re: Role Method Conflicts and Disambiguation
On Fri, Oct 28, 2005 at 10:38:31 -0500, Jonathan Scott Duff wrote:
You mean composition. There is no role inheritance :)
Oops ;-)
I'm assuming you meant
class D does B does C { ... }
I always do that crap... =(
I'm not sure we need to resolve the conflict.
It depends on when composition happens. If A is composed immediately
into B and C as soon as the role is processed, then when D is being
composed, all it sees are a foo method from the B role and a foo method
from the C role.
If, however, roles aren't composed into other roles but only into
classes, then I think that
class D does B does C { ... }
would be equivalent to
class D does A does B does C { ... }
since the roles B and C would carry the uncomposed A role along with
them.
I think of class inheritence (mixin or otherwise) as an N-ary tree
with ordered branches. That is, if you inherit two classes, one
comes after the other.
Roles differ because the tree is unordered and all roles assimilated
into a specific consumer must be treated equally (and will thus
conflict).
This allows roles to be more reusable than classes for generic
tasks, because if there is a conflict it usually implies namespace
clashes, not extended behavior.
Making everything into flattenned set is not a feature. It can be
the way things are really implemented later, but it's a lossy
representation - information about who 'does' who is lost.
In my opinion it's better to compose all role information in the
largest chunks possible (read - as late as possible in a given
linkage/compilation cycle) for the same reasons that JIT
optimizations are more effective: you know much more. However, care
must be taken to ensure that this is not too late, to the point that
the user does not get useful information.
Quoth A12:
It's not clear whether roles should be allowed to grant trust. In
the absence of evidence to the contrary, I'm inclined to say not. We
can always relax that later if, after many large, longitudinal, double-
blind studies, it turns out to be both safe and effective.
Has that changed?
Also, I don't think that role is something that can be trusted :)
A12/S12 only talk about trusting classes.
The role doesn't grant trust to a class that consumes it - it simply
says the role Foo has access to my guts when I assimilate it.
Class trust is something slightly more complex, since it's
inherited. I think that excert says It's not clear whether roles
should be allowed to make a class trust another class when they are
consumed.
there is a conflict, because Foo is reaching into either X's private
member $:foo or Y's private member $:foo (btw, they should never
conflict with each other).
Er, there is only one $:foo. X doesn't have any private members, nor
does Y (because they're roles). Only C has private members. So,
modulo the multiple composition of Foo, I don't think there's a
conflict.
Really? I didn't know that... In that case roles are broken... They
will need instance data (that doesn't conflict when it's private) to
support the methods they give their consumers.
Is there any good reason to not allow roles to introduce member data
into a class?
--
() Yuval Kogman [EMAIL PROTECTED] 0xEBD27418 perl hacker
/\ kung foo master: /me whallops greyface with a fnord: neeyah!!!
pgpXvBUI05J23.pgp
Description: PGP signature
Re: Rough thoughts on the Object Space
On Wed, Oct 26, 2005 at 11:00:55 -0700, Larry Wall wrote:
Yes, Perl 5 is conceptually a 3-pass compiler, but the passes have to
be interwoven to do the literate compilation thing that Perl demands.
But it's recursively interwoven If it was nonrecursive things
would be much uglier ;-)
IMHO, to ammend to stevan's mail, one fundamental step is linking.
This happens in the middle of the type checking phase - some type
info is extracted from a single unit, and other type info is
extracted from already compiled units that are being linked.
In Perl 5 linkage was completely ad-hoc, and was imperative, and
side effect reliant, as opposed to declarative:
*{$sym} = $subref;
The reason this part is fundamental is that it implies the
separation between the bits of code.
--
() Yuval Kogman [EMAIL PROTECTED] 0xEBD27418 perl hacker
/\ kung foo master: /methinks long and hard, and runs away: neeyah!!!
pgpmCOR5vHTHf.pgp
Description: PGP signature
